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