Hi Vincent, On Tue, Jan 27, 2015 at 10:37 AM, vincent(a)massol.net <vincent(a)massol.net> wrote: If you check the 2 articles I have linked in my investigation, you will see that I did not focus only on standard distorted-text image captchas, but rather on alternatives to classic CAPTCHAs. CAPTCHA is a broader term that catches various forms of anti-SPAM measures and which is basically focused on providing a challenge and the human returning a result, but other methods were presented as well, among them being some of the ones you described as well, with advantages and disadvantages. Also, both articles finish with the same conclusion, that it depends on your usecase and that you might need to mix 2 or more options together to get to agood result. Blogs are different from e-commerce sites, for example. That is why I have proposed a pluggable system that an admin configures based on his needs. If it's a public gaming site, a gamified test/CAPTCHA might be appropriate (like Are You A Human's PlayThru[1] or others); if it's a personal blog, an admin might disable CAPTCHA and use a social login feature (if his audience would be ok with that, though privacy concerns are to be considered); etc. [1] http://demo.areyouahuman.com/ "Phone/Email Confirmation" - http://www.sitepoint.com/better-captcha/ (2nd article) - Also, this does not stop a bot from automatically validating the emailed link, so it's still subject to automated attacks. If the user is not logged in, we could only recognize him the second time by using a cookie. Why not directly use NO CAPTCHA reCAPTCHA for this? Something along the lines of "Privileges Based on User Rating" from http://www.sitepoint.com/better-captcha/ (2nd article) However, this sort of stuff applies to users that have already registered and are logged in. Of course, we could imagine that it is a targeted SPAM attack where the bot has the credentials from a previously created user. This is perhaps a separate concern we need to discuss, but still important none the less. Perhaps an option in the CAPTCHA configuration to enable it even for logged-in users, in an effort to weed out bots with credentials. Also, as to not annoy users, we could have it displayed for logged in users *only* for their first 10 edits, or for their first week/month, or something along those lines. However, once the "trial period" is over and the CAPTCHA goes away, any user is likely to be used by a bot. If we leave the CAPTCHA on indefinitely, we might get good results, but risk angering users. If it's a less intrusive solution like a checkbox (i.e. NO CAPTCHA reCAPTCHA) it might be better, but users might still be annoyed by the fact that they always need to confirm they are not robots. Yep, we need to talk about it, since there is no silver bullet. My first attempt at this was targeted at first creating the tools that an admin can use and combine in order to get the right amount of protection, without torturing his users. Sure, registration and comments are our priorities, but IMO we should focus on creating tools/mechanisms that are easily reused by app creators to secure their apps as well. A mechanism for choosing a good CAPTCHA would be one of them. There are the other 2 presented anti-spam methodologies that we could try to present as tools for app developers: * honeypots/honeytraps (fields that normal users should not see but that robots eagerly fill) * timestamps (minimum processing time a human would need to fill a form vs what an automated bot that does no waiting) I wonder if we can present all these tools as options in an AntiSPAM UI, where an admin might check what he wants to apply and then an app developer would just do something like: * $services.antispam.getChallange() in the UI's form and * if ($services.antispam.verify() == true) { OK } else { SPAM } in the backend. ... and all the tools will be run in the verify() method and perform all the enabled checks: CAPTCHA, hidden fields, timestamps, etc. Perhaps even a check of the user's rating (option 2) that you have described) could be performed in the verify() method described above, so it would be extensible enough even for that use case. Even if most automated defences are easily breakable, in case of a targeted attack, as long as an admin has the power to easily try new defences by just installing an extension or configuring something in an UI, I think the chances of ending up with good results are greatly improved. WDYT about the plausibility and usefulness of such a system? Thanks, Eduard