[ux] Continue discussing proxy distribution

soncyq47 soncyq47 at protonmail.com
Sat Feb 29 04:05:43 UTC 2020


Sadly no-one replied to my last post even though I made (good) points. Let's continue discussing proxy distribution.

Remember when I said >"Even if the GFW eventually blocks the bridge, once their dynamic IPs change they all would get unblocked again and again each time the IP changes. The GFW would have to constantly pull down bridges for years, some users would slip through the cracks, and if the GFW stops for a month they all automatically get unblocked again. It gets exponentially harder the more people volunteer to run relays because the quantity of bridges that need to be blocked over and over again increases, which applies to every distribution avenue!"< My question is why not therefore 1. remove UpdateBridgesFromAuthority feature and 2. get bridge operators to switch to dynamic IPs to reap these lovely benefits. I remember hearing an analyst at Psiphon say their most important part for Psiphon proxy distribution for being blocking resistant is dynamic IPs.

Remember when you said >"What prevents a censor from extracting this fingerprinting algorithm, feeding it made-up device information, and using the resulting IDs to fetch bridges?"< My answer is the fingerprint ID is encrypted with a secret key that the client doesn't know. So even if an adversary knows the fingerprinting algorithm, his bridge requests will fail because he doesn't know the key. This key is not revealed to users.

A similar idea, instead of first launch of Tor browser doing the fingerprinting, how about the web page from which you download Tor uses browser/device fingerprinting and different identities are separated into many different pools of bridges.

Less important but wouldn't the too many phone number problem be mostly mitigated by separating area codes into different pools?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ux/attachments/20200229/145c7fa9/attachment.html>


More information about the UX mailing list