Description

• The CAPTCHA problem and state of the art
  • Requirements
  • Conclusion
• Proposal: Google's NO CAPTCHA reCAPTCHA
  • Proof of concept
• XWiki Integration

The CAPTCHA problem and state of the art

There are many articles on the topic, but we have listed below 2 recent (2014) ones that present the problem we are trying to solve with CAPTCHAs and what is the current state of the art.

• Think Your Site Needs CAPTCHA? Try These User-Friendly Alternatives.
• A Better CAPTCHA: Are We There Yet?

Requirements

The second article extracts some requirements:

1. It must be accessible.
2. It must be non-disruptive and transparent to the end user.
3. It cannot detract or distract from the primary purpose of the page.
4. It must be automated or require very little moderation on a large scale.
5. It cannot be a 3rd-party service.
6. It shouldn’t put a huge strain on the server/browser.
7. It must have a low percentage of false positives and false negatives.

Note: Point 5 may not be so important/useful in our case, since the only place where CAPTCHAs are needed is public websites. By definition, public websites are... public so there should be no problem in using/accessing a 3rd-party service for retrieving and solving CAPTCHAs, even for an enterprise-oriented product as is XWiki Enterprise. Also, a remote service it compensates at point 6, since there is no more work to be done on the server (XWiki instance) for generating random images (which is not really a negligible performance penalty).

Conclusion

Out of all the available solutions until now (text, images, games, honeypots, checkboxes, drag&drop, etc.), the one that pretty much takes care of all the problems, including accessibility concerns, and does not suffer from the general problem of random generated algorithms (i.e. is not easily reversible) seems to be Google's recently introduces NO CAPTCHA reCAPTCHA. 

Proposal: Google's NO CAPTCHA reCAPTCHA

Proof of concept

This is just a demo of how to directly use the NO CAPTCHA reCAPTCHA service inside XWiki, without any integration work done. You need to fill in the public and secret site keys from your Google reCAPTCHA account.

XWiki Integration

We already have a generic CAPTCHA Module that defines a CaptchaVerifier component interface that can have multiple implementations, however this is not enough, since the task of actually displaying a CAPTCHA is left to the caller who has to do a different thing, depending on the implementation he uses.

We could improve this by adding a CaptchaDisplayer component interface that would have 2 methods:

• display()
  • Displays the CAPTCHA challenge in HTML format.
  • Maybe pass the output syntax as a parameter?
• String getAnswerRequestParameterName()
  • Returns the name of the request parameter where the challenge expects the user to enter the answer. Used on the form handler by the caller to feed the answer to the CaptchaVerifier.

Ultimately, we could also consider an entire refactoring of the CAPTCHA Module and have just a component interface of CaptchaService:

• String getChallenge(String outputSyntax)
• String getAnswerRequestParameterName()
• boolean verify(String answer)

...and a CaptchaServiceManager component interface:

• List<String> listAvailableCaptchaNames()
• CaptchaService get()
• void set(String serviceName)

This way, we are able to write an administration UI similar to what we have for Search Administration, where we select the implementation/engine we want to use and we are then presented with the configuration specific to the selected option.

All clients of the CAPTCHA module would just use a script service to display a CAPTCHA challenge in their app's form and then, on the form handler, validate the CAPTCHA's answer to validate the form. Whenever the implementation is changed, all the clients of the new CAPTCHA module will still function correctly, without having to change their code.