Some ideas for discussion

[vincent-163]

Is this project still active? Is it likely that the mechanism will be adopted in the future? Looking forward to it.

Here are some of my considerations for this protocol:

• Deanonymization potential with public keys: Maybe we should make sure that a very limited number of public keys may be coded into the plugin, and let the users verify the signature of these keys with some custom browser that is outside control of the plugin itself? Or sign the public key with CloudFlare's key and distribute it via Tor so anyone may check the public key multiple times for consistency, and any CloudFlare's attempt to deanonymize via this approach would be easily discovered and verified?
• Token stockpiling: Maybe you could generate just 20~30 tokens and use a token for one single browsing session, and let the plugin obtain a new token if CloudFlare decides that the session didn't introduce malicious activity. Set a expiry date, say 24 hours for each token issued, and sign the token with another key to verify its creation time so the stockpiled tokens can't last long. The creation time date itself may introduce fingerprint itself, but you could let the client pick a random creation time within 12 hours in the future. The idea is, we need only one token for each identity, not each request.
• Double-spend prevention: Using the expiry date techniques described above we could limit the hash table to keep entries for only 48 hours. This way the hash table's size can be limited. From my point of view the fixed size replacement hash table is badly designed: using birthday attack if an attacker gets just 10^6 tokens he can find a collission in a hash table of size 10^12, and if we need a hash table of 10^12 size why not just store all tokens? A queue for each hash table entry may have been a better approach though I don't see a need for it.

Apart from the protocol itself, Tor's blog post https://blog.torproject.org/trouble-cloudflare seems to say that a malicious activity happens once in about 30 days. Without whitelisting Tor nodes maybe we could try to reset the reputation of Tor exit node IPs faster and see the effects?

[vincent-163]

Oh, I missed something. The creation timestamp still contains enough fingerprint even if randomized. Looks like we need a ZKP system to prove the timestamp. Don't know if it's possible.