CAPTCHA/fr

Les CAPTCHAs (raccourci de Completely Automated Public Turing test to tell Computers and Humans Apart) sont utilisés sur les wikis Wikimedia, via l'extension, comme moyen d'empêcher le spam autant que possible, et de démasquer les spammeurs. Sur la plupart des wikis, un utilisateur peut rencontrer un CAPTCHA quand il essaie de créer un compte, une nouvelle page, ou quand il ajoute un lien externe sur une page.

Sur le wiki portugais (pt.wiki), de 2008 à 2013, le CAPTCHA a également été temporairement affiché à chaque modification faite par les utilisateurs non enregistrés ou par les nouveaux arrivés, prétenduement pour réduire le vandalisme (voir la discussion et 41745).

L'implémentation actuelle des CAPTCHAs pose un certain nombre de problèmes.


 * Ils ne sont disponibles qu'en anglais (5309): les mots utilisés dans nos CAPTCHAs, s'ils ont été créés, devraient être dans la langue de l'utilisateur. Un nombre inconnu de nouveaux utilisateurs non anglophones et de modifications sont perdues.
 * Ils violent les principes d'accessibilité (4845).
 * Ils n'empêchent pas réellement les robots de spammer.



Alternatives pour une implémentation future éventuelle


CAPTCHAs d'images
Les images Captcha n'ont pas besoin de texte à saisir ce qui est pratique avec les mobiles et les problèmes de traduction. Voici quelques idées de Captchas basés sur des images :


 * Trouver tous les... (voir le prototype). Les images d'une même catégorie... (comme des humains) sont présentées mélangées avec des images d'une autre catégorie (comme des chats). Les humains savent faire la différence. 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.
 * Trouver toutes les images d'un même type (voir le 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).
 * Labelliser des images (voir le prototype). The user is presented with images that contain some tagged elements and options to pick the correct tag (e.g., is it a bird? is it a plane?).

La partie difficile ici est comment créer des images et vérifier les données d'une manière qui ne soit pas exploitable par les robots spammeurs. Vous devez posséder un grand nombre de CAPTCHAs (au mieux des centaines de milliers), sinon il suffit à l'attaquant de calquer la base de données de vos CAPTCHA. Si vous utilisez un dépôt public d'images (tel que Commons), ou une source de données ouvertes (telle que les catégories Commons), il y a des chances que l'attaquant puisse identifier le CAPTCHA et sa source et ainsi trouver la solution.



Remplacer le CAPTCHA par un pot de miel
Une possibilité pour éviter les problèmes dûs aux langues avec le CAPTCHA est simplement de le supprimer et de le remplacer par un pot de miel.



Un clone de reCAPTCHA élevé à la maison
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 ).

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

The advantage of this approach is that we can make the latent work force currently wasted in CAPTCHA into profit for a Wikimedia project (Wikisource); and that we can start with a limited data set. In fact, working the reCaptcha way we could create some sort of bootstrap data set, then show people a mix of captchas with known and unknown solutions, and use the known ones for verification and the unknown ones for generating more data. But that is not easy and should get significant focus in the project if you want a CAPTCHA system which is of any practical use at the end.

Accessibilité
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 entirely 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.



Voir aussi

 * Admin tools development, the field of Wikimedia Engineering responsible for this and other tools
 * Bug 38640
 * Research:Account creation UX/CAPTCHA
 * You (probably) don't need ReCAPTCHA (2019)
 * TEDxCMU -- Luis von Ahn -- Duolingo: The Next Chapter in Human Computation
 * Recent discussions
 * Captchas and non-English speakers part I and part II
 * Wikipedia CAPTCHA repair (2011-11-03): «Now that the Wikipedia CAPTCHA has been comprehensively broken by Burzstein et. al. in their paper "Text-based CAPTCHA Strengths and Weaknesses" [...] I've reworked the 2005-era CAPTCHA-image-generating Python script in the CAPTCHA engine» – code still waiting for reviewers.
 * Suggestion: replace CAPTCHA with better approaches (July 2012)
 * Prominent websites which don't use CAPTCHA
 * UK Parliament petitions website per https://www.gov.uk/service-manual/technology/using-captchas
 * Older resources
 * Asirra: A CAPTCHA that Exploits Interest-Aligned Manual Image Categorization, CCS’07, October 29–November 2, 2007, Alexandria, Virginia, USA. (Contains references to other userful papers on CAPTCHA.)
 * Philippe Golle. 2008. Machine learning attacks against the Asirra CAPTCHA. In Proceedings of the 15th ACM conference on Computer and communications security (CCS '08). ACM, New York, NY, USA, 535-542. DOI=10.1145/1455770.1455838