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.
I have a quick question about this comment in the spec in Section 8.1: https://github.com/cloudflare/challenge-bypass-specification/blob/master/cap...
"Since Cloudflare controls the origins, it could currently correlate user sessions across multiple circuits using these cookies. This is a gap in the Tor Browser threat model- the design explicitly ignores linking within a session by malicious first parties, but Cloudflare has effectively first-party control over a large proportion of the web."
The Tor Browser threat model actually does cover this. We call this "Cross-Origin Identifier Unlinkability". We isolate all browser state to the first party to prevent exactly this type of tracking.
This *should*[1] mean that even though CloudFlare controls a lot of first parties, it still can't track users from first party to first party simply though cookies/supercookies, etc. So even if CloudFlare controls both abc.com and xyz.com, the cookies, DOM Storage, and even TLS state set on abc.com are not visible on xyz.com and vice versa (even if both abc.com and xyz.com source eachother as third parties on their respective sites).
If, through your research into this work, or elsewhere in CloudFlare, you folks have actually found ways around this tracking protection, we would like to know about them. Any details would be appreciated.
[1]. As far as I know, the only major issue we are aware of is that we currently don't differentiate between fully automated first party redirect loops and user-initiated federated login clicks. We've been thinking about building some mechanism for differentiating these, so we could still support federated login but prevent automated redirect tracking, but first party redirect loops like this are pretty noticeable, and so far we have not seen this abused. If you think otherwise, or if there are other ways to circumvent our tracking protection if first parties cooperate, that would be useful to know.