Hi Vincent, On Tue, Jan 27, 2015 at 10:37 AM, [email protected] <[email protected]> wrote:

Hi Edy,

Thanks for starting this investigation.

However I think it’s the wrong one :) IMO we should investigate various CAPTCHA solutions but take a larger view at what the problem is. And, as you mentioned below, the problem is that of fighting SPAM, especially in comments. CAPTCHA is only one solution to solve this problem. And not a very effective one apparently.

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/

I haven’t thought that much about it but I can imagine at least 4 other solutions that would be interesting to investigate:

1) When a user is not logged in and wants to post a comment, ask him for his name and email address in the comment. After he submits his comment, a mail is sent to him for validation and he has to click a link to confirm posting the message.

"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.

2) When a user is not logged in and after he clicks submit on a new comment, don’t make it active right away, but instead put it on a moderation queue. Once his message is approved he’ll then be able to post all further messages without approval.

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?

<offtopic> At some point I think it would be great to gamify xwiki.org and we could imagine giving points to users when they perform interesting actions and the more points they get the more authorizations they unlock: - registering: 1 point - posting the first comment: 1 point. Points required to post a comment: 1 (otherwise the comment is moderated) - first edition of a page: 1 point - first page created: 1 point - page deleted because not correct: -2 points (page moved: 0 point) - every 10 pages edited: 1 point - 100 points: permission to create a wiki on myxwiki.org - etc </offtopic>

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.

3) Create an Admin UI screen to list all the comments in a livetable, sorted by the latest comment by default with action buttons to delete a the revision where the comment was addded + mass revision deletion action so that we can filter on the comment content and then delete all matching comments at once. This is more wiki-like than the other options 1) and 2) above but requires a higher amount of maintenance than 1 and 2.

4) Add the ability to integrate a 3rd-party comment system like intensedebate and disqus. FTR I have done that on my blog at myxwiki.org and I almost never get spam since they filter it for me: see http://massol.myxwiki.org/xwiki/bin/view/Blog/AnonymousComments (wow, time flies, this was in 2009 :))

Similar strategies can be applied for registration (at least for 1) - which is already supported! and 2).

WDYT?

I think it’s worth expanding the discussion/investigation to ways of reducing spam rather than focusing just on captcha which are far from enough IMO. BTW solution 2) will fix human spam too, something captcha will never be able to do by definition! :)

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

Thanks -Vincent

On 26 Jan 2015 at 19:10:59, Eduard Moraru ([email protected](mailto: [email protected])) wrote:

...

Hi devs,

We have been getting reports recently of people getting a lot of SPAM in their public XWiki instances, even if they had the CAPTCHA module [1] enabled on their comments/registration pages.

These past 2 days I`ve been investigating the current status of the CAPTCHA module and what is the state of the art in fighting SPAM.

I have produced the following document [2] that I would like you to have a look at and tell me what you think and/or what is your experience with XWiki's CAPTCHA module and with fighting SPAM in general.

TL;DR: I would like to propose that we move to Google's new NO CAPTHA reCAPTCHA as the default CAPTCHA solution and that we implement a configurable back-end that allows admins to easily switch between CAPTCHA engines/services.

Thanks, Eduard

---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Captcha+Module [2] http://design.xwiki.org/xwiki/bin/view/Proposal/CAPTCHAinvestigation70 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs