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

Thanks for pointing us to this Nick, much appreciated!

One thing to keep in mind about the Privacy Pass solution, is that it still requires a large centralized party, just substituting someone like Cloudflare for Google (since, the PP work envisions someone on path, at least in its initial described implementation).  Otherwise, the usability benefit from the returned tokens goes way down.

Not in anyway trying to knock the PrivacyPass work (which I think is really terrific) but just bounds on its generalzeabiltiy.

A possible middle / third way could be (and apologies if this is what Nick and Mike were suggesting from the git-go) some PP-as-a-service model, where the token checking party wasn’t on path, but a “is this a currently valid token for X set of domains” service.  I’m not aware of anyone spinning something like this up (it would require the site owners trusting the service provider) but it’d be a very worthwhile effort!

Pete



 


> 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
> 
> 
>> Begin forwarded message:
>> 
>> From: Notifier <sysbot+notifier@w3.org>
>> Subject: WD: Inaccessibility of CAPTCHA (Call for Wide Review)
>> Date: February 14, 2019 at 2:28:47 PM ET
>> To: public-review-announce@w3.org
>> Resent-From: public-review-announce@w3.org
>> Archived-At: <https://www.w3.org/mid/80c669c4-e8f9-c7cd-f937-420f172b2bf1@w3.org>
>> 
>> Inaccessibility of CAPTCHA
>> 
>> https://www.w3.org/TR/2019/WD-turingtest-20190214/
>> 
>> Abstract
>> 
>> Various approaches have been employed over many years to distinguish human users of web sites from robots. While the traditional CAPTCHA approach of asking the user to identify obscured text in an image remains common, other approaches have also emerged. These approaches commonly require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the nature of the task inherently excludes many people with disabilities, resulting in an incorrect denial of service to these users. Research findings also have indicated that many popular CAPTCHA techniques are no longer particularly effective or secure challenging providers to deploy alternative approaches to block robots, yet support access for people with disabilities. This document examines a number of approaches that allow systems to test for human users, and the extent to which these approaches adequately accommodate people with disabilities. We have grouped these approaches by two category classifications: Stand-Alone Approaches that can be deployed on a web host without engaging the services of unrelated third parties, and Multi-Party Approaches that engage the services of an unrelated third party.
>> 
>> Status of the Document
>> 
>> This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/. 
>> 
>> This is a Working Draft of Inaccessibilty of CAPTCHA by the Accessible Platform Architectures (APA) Working Group. It is a draft update to the Inaccessibilty of CAPTCHA Working Group Note published in 2005. A draft was previously published in July 2018; comments on that draft have been incorporated and this draft is being published for wide review. If public review is favorable, the Working Group plans to advance this document back to Note status. 
>> 
>> The APA Working Group particularly seeks feedback on the following questions: 
>> 
>>  * Does this document fully capture current problems with CAPTCHA and related systems? 
>>  * Are there other CAPTCHA approaches that should be added? 
>>  * Are there concerns for certain categories of persons with disabilities that remain unaddressed or insufficiently addressed in this document? 
>>  * Are you aware of relevant research or technological development in this area we missed? 
>>  * Have we sufficiently addressed CAPTCHA’s problems with I18N? 
>>  * Are issues of privacy and security appropriately addressed? 
>>  * Have we mis-characterized any technology we discuss?  
>> 
>> To comment, file an issue in the W3C apa GitHub repository. If this is not feasible, send email to public-apa@w3.org (comment archive). Comments are requested by 15 March 2019. In-progress updates to the document may be viewed in the publicly visible editors&#x27; draft. 
>> 
>> This document was published by the Accessible Platform Architectures Working Group as a Working Draft.
>> 
>> Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
>> 
>> This document was produced by a group operating under the W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
>> 
>> This document is governed by the 1 February 2018 W3C Process Document.
>

Received on Monday, 18 February 2019 01:58:29 UTC