[ux] Suggestion to unblock bridges in China

[Philipp Winter]

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>