[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21951 [Applications/Tor Launcher]: Helping censored users boostrap to Tor: Tor launcher improvements and automation
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs