| 1 |
Stop motivated attackers or keep low barrier to entry; pick any one. :) |
| 2 |
|
| 3 |
Michał Górny wrote: |
| 4 |
> CAPTCHA |
| 5 |
> ========================== |
| 6 |
> A traditional way of dealing with spam -- require every new system |
| 7 |
> identifier to be confirmed by solving a CAPTCHA (or a few identifiers |
| 8 |
> for one CAPTCHA). |
| 9 |
> |
| 10 |
> The advantage of this method is that it requires a real human work to be |
| 11 |
> performed, effectively limiting the ability to submit spam. |
| 12 |
> The disadvantage is that it is cumbersome to users, so many of them will |
| 13 |
> just resign from participating. |
| 14 |
|
| 15 |
While services such as reCAPTCHA are (as said) massively intrusive, there |
| 16 |
are other, much less intrusive and even terminal-compatible ways to construct |
| 17 |
a CAPTCHA. Hello game developers, you have 80x23 "pixels" to render a puzzle |
| 18 |
for a human above the response input line - that's not so bad. |
| 19 |
|
| 20 |
Attacking something like a server-generated maths challenge rendered in a |
| 21 |
randomly chosen and maybe distorted font would require OCR and/or ML, which |
| 22 |
is fairly annoying. The only real problem then would be with OCR packages. ;) |
| 23 |
|
| 24 |
Combine with a rate limit that is increased manually as the service grows |
| 25 |
more popular. It can be a soft limit which doesn't report failure but results |
| 26 |
in queueing+maybe vetting of reports, to allow some elasticity for peaks. |
| 27 |
|
| 28 |
|
| 29 |
//Peter |
Archives