[tor-bugs] #31283 [UX]: O3.2 - Design the flow of how our users can bypass the scenarios of O3.1.

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu May 28 16:50:09 UTC 2020


#31283: O3.2 - Design the flow of how our users can bypass the scenarios of O3.1.
---------------------+--------------------------------
 Reporter:  gaba     |          Owner:  antonela
     Type:  project  |         Status:  new
 Priority:  Medium   |      Milestone:
Component:  UX       |        Version:
 Severity:  Normal   |     Resolution:
 Keywords:           |  Actual Points:
Parent ID:  #31269   |         Points:
 Reviewer:           |        Sponsor:  Sponsor30-must
---------------------+--------------------------------

Comment (by antonela):

 **Proposal** - Tor Browser 10

 What if we plan Tor Browser 10 as the "anti-censorship/circumvention"
 release?

 I want to make Tor Browser proactive in detecting censorship. Most of the
 time, users get aware of a kind of network interference when they wish to
 access specific content. But even in those cases, most users are not aware
 of the technical background under that censorship experience.

 Using retroactive OONI data or an OONI vanilla test,  can we make Tor
 Browser proactive on safety detect interference in the user's NAT and act
 upon that?

 With this iteration, I aim to make Tor Browser smart enough to 1. detect
 interference, 2. ask for user consent to use bridges, and 3. open the best
 bridge available. Advanced users will be able to configure custom bridges,
 private bridges, friends bridges, and any tunnel they want via Advanced
 Options.

 Also, this iteration will improve the ''no censored'' users launching
 experience by making it similar to any other browser.

 We thought a bit about this flow back for TBA in #28329.

 Out of scope?
     - Tails use case: people who want to hide the fact that they are
 connecting to Tor

 **User Flow**

 Current flow to access bridges:

 1. Open the browser
 2. User click "Configure"
 3. User click "Tor is censored in my country"
 4. User click "Select a built-in bridge"
 5. User select a bridge from the menu
 6. User repeat 4. until some chosen option works
 7. Gets connected

 **Proposed flow to access the Tor network**
 1. Open the browser
 2. Wait for connecting
 3. If the connection failed, Tor Browser prompts users for consent to
 request a bridge
 4. User gives consent.
 > Does user solve a puzzle? Does user disclose sensitive information eg.
 location?
 5. User gets connected

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/31283/S30.png, 700px)]]


 **Wireframes**

 [[Image(https://trac.torproject.org/projects/tor/raw-
 attachment/ticket/31283/wireframes.png, 700px)]]


 ----


 **Questions**

 - What do you think? Do you see it doable?
 - Do you see we can plan middle releases in alphas for testing this?
 - If we need to plan middle releases, which are the middle steps you would
 like to take before going to stable?
 - Do you feel comfortable with picking the best bridge for users instead
 of asking them to find one?
 - Given our short capacity for browser development, can this team provide
 the needed patches to tor browser devs for making this happen?
 - Can we still offer Tor Launcher to 3rd parties without an interface?

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


More information about the tor-bugs mailing list