Opened 2 years ago

Last modified 5 weeks ago

#21951 new project

Helping censored users bootstrap to Tor: Tor launcher improvements and automation

Reported by: linda Owned by: linda
Priority: Medium Milestone:
Component: Applications/Tor Launcher Version:
Severity: Normal Keywords: ux-team
Cc: isabela, mikeperry, mcs, isis, nickm, gk, brade, catalyst, iry, adrelanos, intrigeri, anonym, phw Actual Points:
Parent ID: Points:
Reviewer: Sponsor: Sponsor4

Description (last modified by linda)

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:

  1. design changes: we're going to make interface-only changes that will help the users.
  2. 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.
  3. 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.

Child Tickets

TicketStatusOwnerSummaryComponent
#22232closedbradegather info on how Tor Launcher uses bootstrap status messagesApplications/Tor Launcher
#22399closedbradeTor launcher third-party censorship circumvention tools supportApplications/Tor Launcher
#23261closedbradeimplement configuration portion of new Tor Launcher UIApplications/Tor Launcher
#23262closedbradeimplement integrated progress bar for new Tor Launcher UIApplications/Tor Launcher
#23971newbradeimplement multi-step progress bar for new Tor Launcher UIApplications/Tor Launcher
#24200closedbradeimprove bridge and proxy help textApplications/Tor Launcher
#24371closedbradeQA of Tor Launcher new UIApplications/Tor Launcher
#24516closedphoulUpdate Tor Browser manual + support pagesCommunity/Tor Support

Attachments (1)

main.pdf (951.9 KB) - added by linda 2 years ago.
a research paper assessing the usability of tor launcher

Download all attachments as: .zip

Change History (20)

Changed 2 years ago by linda

Attachment: main.pdf added

a research paper assessing the usability of tor launcher

comment:1 Changed 2 years ago by gk

Cc: gk added

comment:2 Changed 2 years ago by mcs

Cc: brade added

comment:3 Changed 2 years ago by catalyst

Cc: catalyst added

comment:4 Changed 2 years ago by iry

Cc: iry added

comment:5 Changed 2 years ago by iry

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.

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.

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

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.

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.

comment:6 Changed 2 years ago by iry

Keywords: ux-team added

comment:7 Changed 2 years ago by adrelanos

Cc: adrelanos added

comment:8 Changed 22 months ago by gk

Sponsor: Sponsor4

comment:9 Changed 22 months ago by isis

Component: WebpagesApplications/Tor Launcher

Putting this in Applications/TorLauncher. If this was in error, please excuse and move back to component Webpages.

comment:10 in reply to:  9 Changed 22 months ago by linda

Replying to isis:

Putting this in Applications/TorLauncher. If this was in error, please excuse and move back to component Webpages.

Oops. You're right! It should be in Applications/TorLauncher.

comment:11 Changed 22 months ago by linda

Description: modified (diff)
Summary: Tor Launcher improvements and automationHelping censored users boostrap to Tor: Tor launcher improvements and automation

comment:12 Changed 22 months ago 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/

comment:13 Changed 21 months ago by gk

Keywords: TorBrowserTeam201709 added

Adding to our September 2017 tickets.

comment:14 Changed 20 months ago by gk

Keywords: TorBrowserTeam201710 added; TorBrowserTeam201709 removed

Items for October 2017

comment:15 Changed 19 months ago by arma

Summary: Helping censored users boostrap to Tor: Tor launcher improvements and automationHelping censored users bootstrap to Tor: Tor launcher improvements and automation

comment:16 Changed 19 months ago by gk

Keywords: TorBrowserTeam201711 added; TorBrowserTeam201710 removed

Moving tickets over to November.

comment:17 Changed 19 months ago by gk

Keywords: TorBrowserTeam201711 removed

Taking this off of our November items. We are done here for now as we need icons first to move forward with #23971.

comment:18 Changed 18 months ago by intrigeri

Cc: intrigeri anonym added

comment:19 Changed 5 weeks ago by phw

Cc: phw added
Note: See TracTickets for help on using tickets.