Helping censored users bootstrap to Tor: Tor launcher improvements and automation
= Background =
Research has shown that many censored users are not able to connect to Tor if Tor is censored in their country. The ones that are able to succeed usually do after multiple attempts and minutes of their time.
To make this process faster and successful the first time, we need to be able to differentiate people connecting from different countries | people at risk and not at risk | people who are censored and not censored, tighten the window for error notifications and give advice, and generally make the settings easier to configure. One grand vision is to one day not involve users in toggling network settings, and to ask for consent and just give them one button that connects them to Tor safely and reliably.
= Objective =
To make it easier for users to connect to Tor, we're going to make some changes to Tor Launcher. We've broken this effort down into three stages:
- design changes: we're going to make interface-only changes that will help the users.
- naive automation: we're going to automate the connection process, by some sort of behavior. We haven't decided on what that behavior is yet, but there are multiple ways to do this. 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.
- smart automation: this is a "make it work" button that people can relatively safely click, and it will work for people in most environments with minimized risk. We haven't decided on what that behavior is yet either, but one way to do this is to meek-front the connection, work with bridgeDB and/or some way to identify where the user is from, and give them a relay/bridge that works the first time.
Activity
Hi Linda! Thank you so much for opening this ticket!
I will be working on the anon-connection-wizard, which is a python clone of the Tor Launcher. I do find your solid research useful and inspiring. The following is some of my thoughts related to your paper and proposal.
-
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.
-
Currently, BridgeDB 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.)
-
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.
Could you, or anyone else please share your insights or opinions on the problems I mentioned? I am more than happy to have a further discussion on these topic.
-
Trac:
Description: To make it easier for users to connect to Tor, we're going to make some changes to Tor Launcher. Specifically:- design changes: we're going to make interface-only changes that will help the users.
- naive automation: we're going to automate the connection process, by some sort of behavior. We haven't decided on what that behavior is yet, but there are multiple ways to do this. 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.
- smart automation: this is a "make it work" button that people can relatively safely click, and it will work for people in most environments with minimized risk. We haven't decided on what that behavior is yet either, but one way to do this is to meek-front the connection, work with bridgeDB and/or some way to identify where the user is from, and give them a relay/bridge that works the first time.
This ticket is more here so that we remember to do this. I (Linda) don't know when things are happening, or when specific proposals come in to fund each phase of this project.
to
= Background =
Research has shown that many censored users are not able to connect to Tor if Tor is censored in their country. The ones that are able to succeed usually do after multiple attempts and minutes of their time.
To make this process faster and successful the first time, we need to be able to differentiate people connecting from different countries | people at risk and not at risk | people who are censored and not censored, tighten the window for error notifications and give advice, and generally make the settings easier to configure. One grand vision is to one day not involve users in toggling network settings, and to ask for consent and just give them one button that connects them to Tor safely and reliably.
= Objective =
To make it easier for users to connect to Tor, we're going to make some changes to Tor Launcher. We've broken this effort down into three stages:
- design changes: we're going to make interface-only changes that will help the users.
- naive automation: we're going to automate the connection process, by some sort of behavior. We haven't decided on what that behavior is yet, but there are multiple ways to do this. 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.
- smart automation: this is a "make it work" button that people can relatively safely click, and it will work for people in most environments with minimized risk. We haven't decided on what that behavior is yet either, but one way to do this is to meek-front the connection, work with bridgeDB and/or some way to identify where the user is from, and give them a relay/bridge that works the first time.
Summary: Tor Launcher improvements and automation to Helping censored users boostrap to Tor: Tor launcher improvements and automation
iry: thanks for the reply, and sorry that it took so long for me to reply.
- 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.
- Currently, BridgeDB 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.
- 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/
Taking this off of our November items. We are done here for now as we need icons first to move forward with #23971 (moved).
Trac:
Keywords: TorBrowserTeam201711 deleted, N/A addedmentioned in issue #22232 (moved)
mentioned in issue #22402 (moved)
mentioned in issue #23136 (moved)
mentioned in issue #23971 (moved)
mentioned in issue #29590 (moved)
mentioned in issue tpo/applications/tor-launcher#22232 (closed)
mentioned in issue tpo/applications/tor-launcher#23136 (closed)
mentioned in issue tpo/applications/tor-browser#29590 (closed)
