[ux] Suggestion to unblock bridges in China

[soncyq47]

Let me just clear up some misunderstandings...

>>"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?"<<

You did misunderstand. 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!

>>"Google's reCAPTCHA is an interesting suggestion."<<

I meant in order to create a gmail you would have to pass Google's reCAPTCHA. But I guess you answered my question about the gmail method not working. You can still go with my unintended suggestion.

>>"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 know of a way to get a bunch of phone numbers, but this would be mostly mitigated by separating area codes into different pools.

>>"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?"<<

I'm talking about the already existing feature where you can choose to give out the bridge yourself and tor project doesn't even have to know. Tor project could encourage bridge operators to charge money for their own address through SubscribeStar, or even for free through their own social network. If operators do charge though, it incentives them to distribute the bridge themself, hence more decentralised. And as information spreads online, users will become interested in which bridges work in China.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, December 18, 2019 5:35 PM, Philipp Winter <phw at torproject.org> wrote:

> 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
>
> UX mailing list
> UX at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ux