[ux] Suggestion to unblock bridges in China

[Philipp Winter]

On Tue, Dec 17, 2019 at 02:00:21AM +0000, soncyq47 wrote:
> > "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.

The problem I see is that even if a user gets a bridge before the GFW,
it would still end up blocked once the GFW gets it too.  Or did I
misunderstand?

> 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!

We see occasional crawling attempts in BridgeDB's logs: many email
addresses that look similar are requesting bridges at the same time.
Unfortunately, one can buy plenty of gmail addresses online, which can
then be used to crawl BridgeDB's email interface.

Google's reCAPTCHA is an interesting suggestion.  We would have to
self-host it though (if that's even possible) because we don't want to
expose our users to Google.  There are additional considerations in this
ticket: <https://bugs.torproject.org/24607>

> You could also utilise SMS based distribution.

I'm afraid that phone numbers are similar to email addresses: it's just
too easy to get your hands on many of them :(

> 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.

What prevents a censor from extracting this fingerprinting algorithm,
feeding it made-up device information, and using the resulting IDs to
fetch bridges?  Hiding encrypted IDs in Tor Browser sounds similar to
copyright protection in video games, which is a fight you ultimately
cannot win given a sufficiently motivated adversary.

> 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.

I don't think I follow.  Do you mean that there should be multiple
bridge distribution entities (perhaps running their own BridgeDB) that
charge money and therefore have an incentive to try hard to distribute
unblocked bridges?

> Anyway, those are my ideas.

Thanks for sharing your thoughts.  Don't get me wrong, these are all
good ideas, but the critical questions to ask are "how much effort does
it take us to build this?" and "how much effort does it take our
adversary to break this?".  Our adversaries have significantly more
resources than we do, so we need to be smart about what distribution
strategies to invest in.

Cheers,
Philipp