Re: WD: Inaccessibility of CAPTCHA (Call for Wide Review)

As of this week, the Accessible Platform Architectures group has published a new draft of the Inaccessiblity of CAPTCHA document for further wide review. Their blog post notes changes made in this version, including a couple of sections on “Turing Tokens”, which is the new name they suggest for the blinded verification tokens that we discussed on this list during our review in February/March.
https://www.w3.org/blog/2019/06/captcha-wide-review-draft/

Here’s the new Working Draft:
https://www.w3.org/TR/2019/WD-turingtest-20190626/

My first take is that the new sections do consider these potential architectural alternatives/additions to CAPTCHAs, but that the explanations are not very clear — I find the paragraphs hard to read and some of the examples included seem confused or extraneous. They are recommending the creation of more federated verification token models, which may be a response to our on-list discussion about privacy-preserving mechanisms for validation of humanness without persistent identifiers. There is an expanded section on the “multi-device environment”, but I’m not sure it’s an accurate or up-to-date description of multi-factor authentication.

None of the Github issues we opened previously have been closed and few have responses, although my impression is that the changes in the document are intended to respond to most or all of the issues we opened. The issues list is available here, although we don’t have the privacy issues labeled as privacy (which I would like): https://github.com/w3c/apa/issues

—Nick

> On Feb 15, 2019, at 12:10 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> Would any experts be willing to provide advice on this draft regarding CAPTCHA accessibility? There is a particular request for feedback on privacy and security and I think help is needed if this is going to be widely used analysis.
> 
>> The APA Working Group particularly seeks feedback on the following questions:
>> […]
>>  * Are issues of privacy and security appropriately addressed?
> 
> It’s good that privacy and security are at least being mentioned already in the draft, but from my quick read the general advice doesn’t seem especially promising.
> 
> Biometrics are prominently listed as an easy-to-use and hard-to-defeat authenticator. While the caveat is in place that a biometric identifier is inconsistent with anonymous use of the Web, I think this also misstates the security properties of biometrics — since you leave fingerprints everywhere you go and it’s much harder to change fingers than it is passwords. And access to biometric identifiers is typically not available over the Web and there would be serious privacy concerns about adding such access, given the permanent and global scope of such identifiers.
> 
> Privacy is also mentioned in this draft in Google’s reCAPTCHA, which is using Google account information as well as browser fingerprinting techniques for the “I am not a robot” checkbox. The concern is noted that relying on everyone to be logged in to Google while browsing the Web could have implications for user privacy, and that users with disabilities often have privacy concerns themselves. The privacy concerns could be noted more specifically in these sections: relying on large, centralized parties for embedded CAPTCHAs specifically gives the provider information about which site (and often, action on that site) is being used. Additinoally, the burdens are increased on users who aren’t logged in to the large identity providers, or who use techniques to inhibit browser fingerprinting.
> 
> That federated identity, single-sign on and PKI certificates are listed as alternatives seems to directly conflate proving humanness with revealing a specific identity or identifier.
> 
> Not mentioned are any proposed techniques for blinding tokens so that completing a CAPTCHA can be separated from use of the site.
> I don’t know the current progress on “Privacy Pass” or where that’s going, but that seems like an especially relevant alternative to relying on centralized third-parties.
> https://privacypass.github.io/
> If anyone involved with Tor Browser development could give advice, I think that would be especially helpful for this group.
> 
> —Nick