- From: Ben Maurer <bmaurer@andrew.cmu.edu>
- Date: Thu, 12 Jul 2007 05:55:27 +0000
- To: "David Poehlman" <david.poehlman@handsontechnologeyes.com>
- Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org
- Message-ID: <9b20fd650707111053k8b94d64w53edffe679f21d38@mail.gmail.com>
Hello David, On 7/11/07, David Poehlman <david.poehlman@handsontechnologeyes.com> wrote: > > audio alone is not sufficient to provide robustness of accessibility > without > image processing. Javascript should be scrapped and the interface be made > a > simple question and answer interface with a submit button. the question > can > have several forms with a combo box if you will but should be as simple as > possible and should be capale of running on text only browsers. While we'd love to have 100% accessibility, that goal is not achievable with current research. The issue is that we'd need a very large database (maybe 1 million unique questions with 50k new questions every day). Gathering this set of data, getting it in multiple languages, and making sure all the questions worked well is very hard. Right now, we don't think that we can implement a text only CAPTCHA that meets our security requirements. We fully understand that this compromises accessibility. I'd like to ask that we focus on changes we can make to allow the audio interface to be easier to use (as well as the image one, if changes are needed there). It might help to have some background about how reCAPTCHA works to ground this discussion: 1. reCAPTCHA is a service. A website doesn't generate their own CAPTCHAs. They put a little bit of "bootstrapping" html on their website: <script type="text/javascript" src="http://api.recaptcha.net/challenge?k=<your_public_key>"> </script> <noscript> <iframe src="http://api.recaptcha.net/noscript?k=<your_public_key>" height="300" width="500" frameborder="0"></iframe><br> <textarea name="recaptcha_challenge_field" rows="3" cols="40"> </textarea> <input type="hidden" name="recaptcha_response_field" value="manual_challenge"> </noscript> The <script> version of the CAPTCHA is our primary interface. It provides the best user experience. The <script> tag injects HTML in the author's web page -- an <img> for the CAPTCHA, <input> for the solution, and three <a>s for refresh, audio, and help. However, we do support a script free version. In this version, we render the reCAPTCHA in an iframe. When the user has solved the CAPTCHA inside the iframe, they are given a "token" string, (a base 64 encoded, signed, and encrypted message that allows reCAPTCHA to verify they have solved a CAPTCHA). They can paste this string into the <textarea>. The non-html version isn't elegant, but is functional. 2. We can easily change what the <script> writes and what the <iframe> contains. The bootstrapping code is something that we can fix, but is a bit slower to take effect (because individual webmasters apply it) 3. We're implementing reCAPTCHA such that it has a strength sufficient to protect a large site against a skilled attacker. We're not willing to use obscurity as a security mechanism I hope these points can guide the discussion such that we can come out with practical fixes that make reCAPTCHA accessible to as many users as possible.
Received on Thursday, 12 July 2007 23:11:51 UTC