Hi,
We've
been defining an improved user flow for starting Tor Browser
and connecting to Tor, with particular attention in censored
contexts. The aim is making Tor Browser proactive in detecting
censorship and improve the bridge's acquisition by making it
easier for users to use them.
We'd be
interested in hearing thoughts from folks bootstrapping Tor in
their clients about these improvements.[0]
The
target of this proposal is Tor Browser 10.5 (Q22021).
Have a
lovely weekend!
A
-----
Filename:
xxx-quickstart.txt
Title:
Tor Browser Quickstart
Author:
antonela
Created:
09-Sep-2020
Status:
Draft
Target:
Tor Browser 10.5
1.
Introduction
This
proposal aims to improve the user experience of Tor Browser
when connecting to the Tor network.
2.
Motivation
Tor
Browser is opened more than 2 million times a day. In the last
years, we have been working on qualitatively improving the
entire Tor browser user journey: from discovering, finding,
downloading, installing, starting, and browsing, we released a
seamless and familiar experience for our largest set of users.
But, launching the Tor Browser for the first time is still
being a frictional experience.
Tor
Launcher has been confusing for users. Past research exposed
those pain points and how that confusion delays the decision
making flow by cognitive overloading [0]. Also, known issues
around Tor Launcher like the time gap between Tor Launcher and
the main browser windows opening on first-time installers have
made Tor Browser starting even more disappointing for
first-time users.
This
proposal aims to improve the bootstrapping flow for first-time
and recurrent users by removing Tor Launcher UI, making Tor
bootstrapping automatic, and relying on a better UI embedded
in the main browser screen as visual progress feedback. We
will also consider the censored user's experience by informing
detected censorship and suggesting and providing bridges to
connect to the Tor network successfully.
3. The
case of the censored user
Around 2% of daily Tor users need bridges to reach the Tor
network [1]. In any case, this small percentage doesn't enable
us to de-prioritize the need of these users. Instead, this
proposal will also provide a user experience that contemplates
censored users' need to access the network by making Tor
Browser proactive to detect censorship and suggest Bridges.
3.1
Bridges
It is
difficult for a user to select between a different bridge
option relying on its name if they don't know what that bridge
does for them. A usual flow for users requesting bridges is
trying in-build Tor Browser bridges and failing to connect
until they work. As well, users with specific needs are
pointed to specific bridges by trusted community members, and
they pick the recommended choice without a technical
background.
Over
the years, Bridges' technology has been improving as how the
censorship arms race has been developing. OBSF3, OBSF4, Meek,
Snowflake, and more proxy techniques are available for
successfully reaching the Tor network. Regular users cannot
differentiate between the technologies under the construction
of Bridges.
I
suggest attaching the name **"bridge"** to any intermediate
node that allows users to reach the network. By unifying the
vocabulary in the interface and our user manuals, we will
simplify the complexity behind all this technology by warning
and educating users about bridges uses.
This
strategic decision will allow the community to continue
developing technology for bridges without moving the attention
to the technical name but the conceptual solution [2].
3.2
Detecting censorship
As
discussed in the past, it is plausible for us to use
retrospective data or a Tor reachability test in any fashion
to detect network interference in the user's NAT and act upon
that [3][4][7].
Most
of the time, users get aware of a kind of network interference
when they try to connect to the network, and the bootstrapping
fails. But even in those cases, most users have not the
technical background to understand nor explain that censorship
experience.
Within this proposal, the Tor Browser will be able to detect
censorship for users and suggest the best bridge available to
connect.
3.3
Suggesting Bridges
With
this iteration, we aim to make Tor Browser proactive on
detecting censorship, respectful on asking user consent to use
a Bridge and smart enough to open the best bridge available.
Advanced users will be able to configure custom bridges,
private bridges, friends bridges, and any tunnel they want via
`about:preferences#Tor` -
Bridges.
Once
censorship has been detected, Tor users will be able to opt-in
for a Bridge connection to reach a successful connection [5].
4.
Proposal
Specifically, this proposal will handle this issues:
4.1
Requirements
R1
Remove Tor Launcher UI from the entire starting flow
R2
Allow users to give consent on the first time use of automatic
connection
R3
Implement a new UI integrated with the main windows that
provide visual feedback during tor bootstrapping.
R4
Allow advanced users to customize their bootstrapping
experience using an extra startup parameter. [8][13]
R5
Develop a detecting network interference that allows users to
request a bridge if it is needed. Users under controlled
networks are detailed in section 3.
R6
Continue keeping Tor Launcher repository for 3rd parties using
their controllers or UI.
4.2
User flow
The
user opens the Tor Browser and automatically connects. If
interference is detected, then an explainer error page
appears, and a Use a Bridge is offered.
4.3
Quickstart
Previous experiences of clients bootstrapping Tor without
asking to Connect have been successful. Onionshare, the
popular Tor sharing files app, doesn't request user action to
bootstrap Tor. Instead, a minimal UI progress bar is shown
during the 1 or 2 seconds bootstrapping happens. OnionBrowser,
the Tor Browser for iOS also bootstrap automatically. Brave's
Tor startup is transparent to the user and the bootstrapping
visual progress feedback happens at the URL bar.
Quickstart is the feature that enables an automatic Tor
connection in Tor Browser.
As a
first step in introducing this feature, we may want to make
this Opt-In by allowing users to give consent and save this
setting in our persistent configuration.
*
Phase One - Userflow
The
user opens the app; the connecting screen appears. Like the
current flow, user needs to click in the Connect button to
connect to Tor. On first time users, we ask consent for
automatic connections. [9, IMG 0.0]
Opted-in recurrent users will go directly to `about:tor`. We
will disable the URL bar and we will rely on a loading bar UI
to render immediate visual feedback.
A
work in progress user interface for desktop [9] and mobile
[10] is attached to the main ticket [12].
*
Phase Two - Userflow
The
user opens the app; Tor bootstraps automatically. To enable
phase two, we need a Tor reachability test in place as part of
the Tor bootstrapping. If there is network interference, the
interference detected screen appears and Use a Bridges is
offered.
4.4
Customizing Tor connection
Specific use cases, as in users who want to hide the fact that
are using Tor or users aware of censorship in their network,
should be able to start Tor Browser offline, be directed to `about:preferences#tor` and
configure their connection before Connect. A startup parameter
should allow this option.
4.5
Recovering from error
During our product iteration cycles in this flow, there may be
the case where the bridge that is being suggested does not
work. We will allow users to try a Bridge again, and then we
will move them to the manual configuration in `about:preferences#Tor` -
Bridges.
General Tor bootstrapping errors handling will not be covered
in this proposal.
5. User
research
Our
ongoing user research over Tor Browser Start pain-points and
bridges' use is being tracked in its corresponding ticket
[14][15].
--
Antonela Debiasi
UX Team Lead
@antonela
E2330A6D1EB5A0C8
https://torproject.org
