CAPTCHA

CAPTCHAs (short for "Completely Automated Public Turing test to tell Computers and Humans Apart") are utilized on Wikimedia wikis, via the ConfirmEdit extension, as a means of ostensibly preventing spam and deterring spammers. In most wikis, a user might hit a CAPTCHA when trying to create an account, create a new page, or add an external link to a page.

On pt.wiki, in 2008–2013 the CAPTCHA was also "temporarily" shown on every edit of unregistered and new users, allegedly to reduce vandalism (see discussion and 41745).

There are a number of problems with the current CAPTCHA implementation.


 * They are only available in English (5309): the words used by our CAPTCHAs, however they are created, should be in the user's language. An unknown number of new users and edits are lost from non-English speaking people.
 * They violate accessibility principles (4845).
 * They don't effectively prevent bots from spamming.

Image CAPTCHAs
Captcha images do not require text input which helps for mobile and internationalisation issue. Some ideas based on images:


 * Find the different one (view prototype). Several images from the same category (e.g., people) are shown mixed with one image from a different category (e.g., cat). Humans should be able to recognise which is the different one. Note that in this case, the question is always the same (find the different one) and the categories used are not exposed to the user.
 * Find all images of a kind (view prototype). Images from two or more categories are presented together. The user is explicitly asked to find all the images of a given type (e.g., all images of people wearing glasses).
 * Tag images (view prototype). The user is presented with images that contain some tagged elements and options to pick he correct tag (e.g., is it a bird? is it a plane?).

The hard part here is how to create images and verify data in a way that is not exploitable to spambots. You need a very large set of CAPTCHAs (hundreds of thousands, ideally), otherwise an attacker can just map your CAPTCHA database. If you use a public image repository (such as Commons) or a public data source (such as Commons categories), chances are an attacker can match the CAPTCHA to the source and figure out the solution from that.

Replacing CAPTCHA with a honeypot
One possibility for avoiding localizations issues with the CAPTCHA is simply to remove it and replace it with a honeypot.

A homegrown reCAPTCHA clone
Write a version of reCAPTCHA that uses document images that have been processed by MediaWiki's ProofreadPage extension for Wikisource: WikiCAPTCHA. In other words, a CAPTCHA that feeds data to ProofreadPage to augment its OCR processing. You might build on [//github.com/CristianCantoro/wikicaptcha existing code]. It is worth noting that "reCAPTCHA hold no specific patents for the technology behind their text CAPTCHA algorithms (At least none they discuss on their website or are able to be found on the US Patents & Trademark Office site)", according to one blogger.

Filed as bug 32695.

Also discussed at Wikimania 2012 with the presentation Wikicaptcha: a ReCAPTCHA-like solution for Wikisource

Accessibility
The accessibility of our current CAPTCHA is extremely bad. If the user has impaired eyesight or uses a screenreader the text-based CAPTCHA is almost entire inaccessible to them. A handful of our larger wikis solve this via a volunteer-run account request system. Alternatives like image CAPTCHAs still violate accessibility principles (4845), so an alternative such as an audio CAPTCHA should be considered.