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

On Feb 17, 2019, at 8:58 PM, Pete Snyder <psnyder@brave.com> wrote:
> 
> 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.

These are good clarifications. The current PrivacyPass protocol still requires a centralized party (to provide captchas and validate redeemed tokens). It just has the privacy property that you don’t need to log in or provide identity information to the centralized party (as it appears Google is increasingly doing with reCAPTCHA, or which this accessibility document suggests is an advantage). The centralized party could still use IP address or other passive fingerprinting data to do some inferences on who is reading what.

> 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!


It does seem like a relatively straightforward protocol change would be to move the token provider/validator off the path, for cases where a server wants to take advantage of a CAPTCHA service not provided by their CDN or proxy. That is, could the client provide the signed pass (including the token and the request info) to the server (a relying party, in effect) and then the server could check with the “edge” (the PrivacyPass term for the party who provides and validates redeemed tokens) to make sure it’s valid and not double-spent, so that the client doesn’t need to contact the centralized edge provider directly. Whether an organization would be willing to provide that service for free, or what they would need to charge for it, isn’t immediately clear.

It might be that we could provide the feedback to the Accessible Platform Architectures WG that there are protocols under discussion that could provide anonymity, unlinkability or other privacy properties even when relying on a CAPTCHA provider and that further work in that direction could provide a more generalizable solution. That is, we shouldn’t say, “oh, PrivacyPass already solved this, just use that” but clarify that there are potential techniques to use.

I don’t know that any standardization of the PrivacyPass protocol has started, but it seems like we could have plenty of feedback for them.

Cheers,
Nick