[tor-bugs] #21951 [Applications/Tor Launcher]: Helping censored users boostrap to Tor: Tor launcher improvements and automation

[Tor Bug Tracker & Wiki]

#21951: Helping censored users boostrap to Tor: Tor launcher improvements and
automation
---------------------------------------+--------------------------
 Reporter:  linda                      |          Owner:  linda
     Type:  project                    |         Status:  new
 Priority:  Medium                     |      Milestone:
Component:  Applications/Tor Launcher  |        Version:
 Severity:  Normal                     |     Resolution:
 Keywords:  ux-team                    |  Actual Points:
Parent ID:                             |         Points:
 Reviewer:                             |        Sponsor:  Sponsor4
---------------------------------------+--------------------------

Comment (by linda):

 iry: thanks for the reply, and sorry that it took so long for me to reply.

 > 1) You mentioned two different implementation of the Tor Launcher: "One
 way would be to try a bunch of relays/bridges in a specific order, and
 stop when one is reachable. Another way would be to try all the
 relays/bridges at the same time, and return one that works to the user. "
 Since this behavior may be different from the behavior of users who
 connect to the Tor network without the help of Tor Launcher, we need to be
 careful about the risk that an adversary on the user's ISP side to
 distinguish different Tor users behaviors.

 This is a good point. My two suggestions were merely to suggest that there
 is no one way of automating the connection process. There are risks with
 automating this in general, because that would make the behavior
 fingerprintable. I didn't think of your concern about how it looks
 different from other Tor connections, and I don't  know what to
 necessarily do about this. The only thing I think I believe is that
 getting people connected to Tor, even if it is fingerprintable, is better
 than not having them being able to connect at all.

 > 2) Currently, [BridgeDB](​https://bridges.torproject.org/options) use a
 challenge-response test to prevent adversaries from enumerating all the
 existing unlisted bridges. I am not sure if the automation of Tor launcher
 will let adversaries take the advantages of it as well. (I assume by
 saying "all", you mean the built-in bridges options that are already
 available in Tor launcher.)

 This is also a good point. We haven't thought that far into attacks and or
 defense against this scheme. Not because it's not worth doing (it is very
 much doing, and critical before thinking of implementing anything), but
 because we're focusing on phase 1. of the project, where we are sticking
 with the Tor launcher we have now with all the manual user inputs, but
 making design changes to it so that it's easier to use. I'd still be happy
 to have this discussion though.

 > 3) I find neither the current design of the Tor Launcher or the
 suggested revised design of the Tor Launcher take much care about the use
 case where Tor users use third-party censorship circumvention tools to
 bypass the Tor censorship. However, those third-party censorship
 circumvention tools are actually widely used in heavily censored area
 where Tor bridges and puggable-transports are not effective. For example,
 when user use a VPN or a Lantern to help Tot connect to the network, the
 current instruction may not be clear enough to guide them configure the
 Tor.

 I totally agree with you there. I actually think that the revised version
 is quite bad, and would be sad if it got deployed. It is better than the
 deployed version, but that's about it. There was only time for one
 iteration, so I wasn't able to take out features that negatively
 impacted/did nothing, and test again. But we're working on a new design
 here, which I think is better at addressing the issue:
 https://marvelapp.com/3f6102d/

 o/

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21951#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online