[tor-access] Specification for bypassing CAPTCHAs using blinded tokens

[Georg Koppen]

Hi,

Alex Davidson:
> Hi everyone,
> 
> I've been interning at Cloudflare for the past 3 months and have been
> working on developing an implementation of the blinded tokens spec that
> George and Filippo developed a while back.
> 
> We've updated aspects of the original spec, the newest spec can now be
> viewed here: https://github.com/cloudflare/challenge-bypass-specification.
> We're happy to hear comments from any of you on the design and on the
> capacity of the solution for preserving anonymity.

Thanks for the update. While I am still mulling over parts of the
specification let me start with an issue I found while reading. I am
wondering about how your specification is supposed to work for users of
Private Browsing Modes in general and Tor Browser with its Disk
Avoidance requirement[1] in particular.

Looking at section 7.1 it seems to me all those tokens (blinded/signed)
are saved somewhere on the user's machine. As far as I can see the
specification does not elaborate on this point further but I guess they
are supposed to be saved on disk. This is not working for us at least.
Thus, the other option would be to have them in memory. But then the
user would be recreating tokens and getting those new tokens signed with
every visit of a Cloudflare guarded site after Tor Browser got started.

Additionally, and in contrast to what your spec is claiming in section
8.1, we have the New Identity feature[2] that is e.g. aimed at dealing
with powerful first party entities and their long-term linkability
capabilities. That feature ensures that by invoking it a user gets a
clean, new browsing session. Thus, new tokens would need to get created,
blinded and signed in this case again. A New Identity is easy to get and
we encourage users to do so regularly: this option is the first one in
our Torbutton menu and got keyboard shortcuts, too, as users over and
over suggested that, to make it easier and more convenient to mitigate
long-term linkability concerns.

And, as a final angle, we plan to get Tor Browser on mobile to feature
parity with the one for desktop rather soon because there are large
regions of the world that access the Internet mainly (or even only) over
the phone. Often this is accompanied by unreliable and slow connections
and it is probably still not uncommon that users in those countries have
to pay for transferred bytes. Moreover, battery power is a scarce
resource on mobile devices and public key cryptography is expensive.
Thus, it seems to me that getting the tokens created, blinded and signed
again and again after New Identity and restart of Tor Browser is
especially problematic for those users.

As a last and more general point in my mail I thought it might be good
to point out that we need to have a discussion about whether your
blinded token idea is actually a good solution to the problem at hand.
That might be the case or it might be a good solution to a different
problem. Personally, I am not sure about that yet and I may have missed
some of the previous discussions outside of this list. Sorry if that's
the case. But I think it is important to get this more fundamental issue
sorted out (in a different thread), especially if we want to implement
and ship a solution in Tor Browser.

Georg

[1] https://www.torproject.org/projects/torbrowser/design/#disk-avoidance
[2] https://www.torproject.org/projects/torbrowser/design/#new-identity

> We've managed to build a test copy of the protocol along with an extension
> that carries out the required operations. The extension is not completely
> finished yet, but we're looking towards making that open source as well
> when it is done.
> 
> Thanks,
> Alex
> 
> 
> 
> _______________________________________________
> tor-access mailing list
> tor-access at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-access/attachments/20161003/65df0d2a/attachment.sig>