[ux] Suggestion to unblock bridges in China

[soncyq47]

Philipp Winter, I've seen your presentation on active probing. It's an honour to talk with you.
>>"I'm afraid that the GFW is more efficient at getting bridges from BridgeDB than our users are. We believe that the GFW has code to solve BridgeDB's CAPTCHAs and it's clearly outperforming users."<<

Of-course the GFW can get one bridge faster than a user. The point I was trying to make was that users should be able to get one before the GFW gets all of them.

Also you didn't address the gmail bridges at torproject.org approach. Google uses more than just captchas to prevent someone from mass creating gmail accounts. But just in terms of captcha, it is known that people have programmed bots to solve text based captchas but I would be surprised if any bot today could solve Google's picture based re-captcha. And even if a team of humans at the GFW gets all of them, their dynamic IPs would get them unblocked again, so they would have to constantly get new accounts for months/years in which case Google would certainly respond. Keep in mind this applies to every distribution method!

You could also utilise SMS based distribution.

I have another idea. Each install/first launch of tor browser fingerprints your device and converts that into an arbitrary ID that can't be traced back into anything meaningful. The ID should be encrypted or otherwise hidden so that users can't see/have no control over it. Then that ID is sent to bridges.torproject.org and it answers the same ID the same way. When BrdigeDB decrypts the ID it proves knowledge of a secret that prevents adversary clients from sending many random fake IDs.

Here's another idea. Why do you think ExpressVPN works in China? It's the pay-wall. If many bridge publishers charged for reachability details, that could help decentralise distribution and get a working bridge using an already working method.

Anyway, those are my ideas.

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, December 16, 2019 5:46 PM, Philipp Winter <phw at torproject.org> wrote:

> On Mon, Dec 16, 2019 at 02:06:17AM +0000, soncyq47 wrote:
>
> > I heard in some of Roger Dingledine's talks that for Tor
> > bootstrapping, if an Obfs4 bridge is on a dynamic IP, so long as one
> > bridge is still working, it will automatically find the new IP of that
> > bridge when the IP changes.
>
> I think you're talking about the UpdateBridgesFromAuthority feature. In
> practice, this feature doesn't work very well:
> https://lists.torproject.org/pipermail/tor-relays/2014-June/004823.html
>
> > That means when the Great Firewall requested all the IPs of the
> > bridges one by one at https://bridges.torproject.org/ (same as the
> > request button on tor browser) and the gmail bridges at torproject.org
> > bucket, and added them to the blacklist, they automatically get
> > updated when the dynamic IP changes. (Remember the Obfs4 protocol
> > works in China, it's just the bridge distribution that's the problem)
>
> We do have bridges with dynamic IP addresses but I believe that the
> majority still has a static address. One could determine the exact
> numbers by processing the data at https://collector.torproject.org.
>
> > The seemingly simple answer is to not update tor users during
> > bootstrapping when the bridges dynamic IPs changes. That would get the
> > massive list of bridge IPs at https and gmail pools out of the nasty
> > hands of the Great Firewall. So many Obfs4 bridges would start working
> > again in China! I am aware that users will have to find a bridge IP
> > again, but it requires a massive resource for the Great Firewall to
> > find them all again, and only a short time for a user to click
> > 'request a bridge from torproject.org' (which works through meek). I
> > assume it would have to be implemented at the rely/directory side
> > rather than the client side for it to work. Implementing my idea
> > should be as easy as removing a harmful feature.
>
> I'm afraid that the GFW is more efficient at getting bridges from
> BridgeDB than our users are. We believe that the GFW has code to solve
> BridgeDB's CAPTCHAs and it's clearly outperforming users. See the
> following ticket for more background:
> https://bugs.torproject.org/32117
>
> CAPTCHAs are a dead end and we need new methods for distributing
> bridges. One alternative is snowflake, which relies on the assumption
> that many ephemeral proxies will be too costly for a firewall to block.
> Another alternative are social network-based bridge distributors like
> Salmon: https://censorbib.nymity.ch/#Douglas2016a
>
> UX mailing list
> UX at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ux