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
[0] https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/merge_requ...
-----
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:
- Remove gap between Tor Launcher window and main browser window https://bugs.torproject.org/27476 - Improve user visual feedback on bootstrapping connection https://bugs.torproject.org/23486, https://bugs.torproject.org/23971 - Show Tor log in Tor Browser https://bugs.torproject.org/9516 - Firewall option is visible behind Tor Network Settings... but not during start-up https://bugs.torproject.org/24452 - "Tor is censored in my country" does not cover some scenarios https://bugs.torproject.org/25431 - Tor Launcher should suggest the use of bridges if Tor is dangerous in user's area https://bugs.torproject.org/11132 - Inform users in Tor Launcher of which settings are best for them based on their country https://bugs.torproject.org/24527 - Make it easier to add a bridge in network settings https://bugs.torproject.org/14638 - Use OONI to inform Tor Launcher user workflow https://bugs.torproject.org/23838
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].
[0] https://github.com/lindanlee/PETS2017-paper [1] https://metrics.torproject.org/userstats-relay-country.htmlvs https://metrics.torproject.org/userstats-bridge-country.html [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/8 [3] https://gitlab.torproject.org/tpo/community/outreach/-/issues/28531 [4] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23839 [5] https://gitlab.torproject.org/tpo/applications/tor-launcher/-/issues/34343 [6] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/design... [7] https://gitlab.torproject.org/tpo/core/tor/-/issues/30477 [8] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345 [9] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/design... [10] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/design... [11] https://trac.torproject.org/projects/tor/ticket/31286 [12] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004 [13] https://tails.boum.org/blueprint/network_connection/ [14] https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40003 [15] https://gitlab.torproject.org/groups/tpo/-/milestones/7
Hi,
Antonela Debiasi (2020-10-23):
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.
Thanks for this detailed proposal! I could not check the details since GitLab is not responding at the moment, but what you wrote looks great to me :)
FTR, in the context of Tails, since we don't allow the browser to control the Tor daemon's configuration, currently we're running Tor Launcher separately from the browser, as a XUL application. Once Tor Launcher is gone, presumably we won't be able to use the new in-browser UI. So in order to adjust to this change, likely we will need to:
1. Disable the new UI that configures & starts little-t-tor
Currently we do this with the TOR_SKIP_LAUNCH=1 environment variable. It would be great if we were still able to toggle the whole thing off in 1 single place with the new implementation :)
2. Find, or write for scratch, another UI to configure & start little-t-tor.
I believe Whonix may be in a similar situation.
Does this make sense to you? Did I miss or misunderstand anything?
Cheers!
Hi,
I've been working Ricochet, and we also will need something like this in the long term (for instance, adding support for the various pluggable-transports). Ideally I'd like to have a lightweight library (with C abi) which we can all use for launching/configuring/managing a tor process (without any dependency on a particular UI toolkit). We all (tor-browser, tails, ricochet, etc) potentially need to do the same things in our various backends, so it'd be great if we had a common codebase for doing so.
best, -Richard
On 10/24/20 9:31 AM, intrigeri wrote:
Hi,
Antonela Debiasi (2020-10-23):
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.
Thanks for this detailed proposal! I could not check the details since GitLab is not responding at the moment, but what you wrote looks great to me :)
FTR, in the context of Tails, since we don't allow the browser to control the Tor daemon's configuration, currently we're running Tor Launcher separately from the browser, as a XUL application. Once Tor Launcher is gone, presumably we won't be able to use the new in-browser UI. So in order to adjust to this change, likely we will need to:
Disable the new UI that configures & starts little-t-tor
Currently we do this with the TOR_SKIP_LAUNCH=1 environment variable. It would be great if we were still able to toggle the whole thing off in 1 single place with the new implementation :)
Find, or write for scratch, another UI to configure & start little-t-tor.
I believe Whonix may be in a similar situation.
Does this make sense to you? Did I miss or misunderstand anything?
Cheers! _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
On Sat, Oct 24, 2020 at 09:31:39AM +0200, intrigeri wrote:
Hi,
Antonela Debiasi (2020-10-23):
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.
Thanks for this detailed proposal! I could not check the details since GitLab is not responding at the moment, but what you wrote looks great to me :)
FTR, in the context of Tails, since we don't allow the browser to control the Tor daemon's configuration, currently we're running Tor Launcher separately from the browser, as a XUL application. Once Tor Launcher is gone, presumably we won't be able to use the new in-browser UI. So in order to adjust to this change, likely we will need to:
Disable the new UI that configures & starts little-t-tor
Currently we do this with the TOR_SKIP_LAUNCH=1 environment variable. It would be great if we were still able to toggle the whole thing off in 1 single place with the new implementation :)
I think this is reasonable and we will continue supporting this feature.
- Find, or write for scratch, another UI to configure & start little-t-tor.
Yes, and I think the Tor Project and the Tor community should keep this in mind. As Richard said, a configuration flow like this is needed for many different applications and we should think about providing drop-in solutions for this (instead of everyone developing their own).
I believe Whonix may be in a similar situation.
Does this make sense to you? Did I miss or misunderstand anything?
Cheers! _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Matthew Finkel:
On Sat, Oct 24, 2020 at 09:31:39AM +0200, intrigeri wrote:
- Find, or write for scratch, another UI to configure & start little-t-tor.
Yes, and I think the Tor Project and the Tor community should keep this in mind. As Richard said, a configuration flow like this is needed for many different applications and we should think about providing drop-in solutions for this (instead of everyone developing their own).
Allow me to brainstorm a bit to see if we can avoid this extra implementation: what if Tor Browser can be told (perhaps with a --configure-tor-only parameter) to become essentially what Tor Launcher is now?
In other words, it lock itself down by disabling most of Firefox UI (menu, url and tab bar, etc) and functionality (in particular, no browsing!), and only display the Tor bridge configuration bits. If we had this, 3rd parties like Tails, Ricochet etc could just depend on Tor Browser to act as a "Tor Launcher", and no extra implementation is needed.
You also talk about censorship detection: it is a bit unclear if Tor Browser will try to detect it itself with some background work, or it this detection is reactive, e.g. by looking at what sites the users tries to visit; if it's the former, that would also fit with my proposal. If it's the latter, well that sucks, but at least 3rd parties would get something with the same power as the current Tor Launcher.
How crazy does this sound?
Cheers!
On Wed, Oct 28, 2020 at 04:54:56PM +0100, anonym wrote:
Matthew Finkel:
On Sat, Oct 24, 2020 at 09:31:39AM +0200, intrigeri wrote:
- Find, or write for scratch, another UI to configure & start little-t-tor.
Yes, and I think the Tor Project and the Tor community should keep this in mind. As Richard said, a configuration flow like this is needed for many different applications and we should think about providing drop-in solutions for this (instead of everyone developing their own).
Allow me to brainstorm a bit to see if we can avoid this extra implementation: what if Tor Browser can be told (perhaps with a --configure-tor-only parameter) to become essentially what Tor Launcher is now?
In other words, it lock itself down by disabling most of Firefox UI (menu, url and tab bar, etc) and functionality (in particular, no browsing!), and only display the Tor bridge configuration bits. If we had this, 3rd parties like Tails, Ricochet etc could just depend on Tor Browser to act as a "Tor Launcher", and no extra implementation is needed.
I think we should have a different solution than "include a full web browser for configuring Tor". This may be a short- or medium-term solution, but there isn't a good reason for ricochet bundling Tor Browser only for configuring Tor.
You also talk about censorship detection: it is a bit unclear if Tor Browser will try to detect it itself with some background work, or it this detection is reactive, e.g. by looking at what sites the users tries to visit; if it's the former, that would also fit with my proposal. If it's the latter, well that sucks, but at least 3rd parties would get something with the same power as the current Tor Launcher.
In the beginning this will likely be a hard-coded list of known regions where censorship is implemented based on prior knowledge (such as OONI reports). In the next iteration of this feature, we will likely try detecting censorship via automatic probing. We don't know exactly how we'll do this at this time.
How crazy does this sound?
Slightly crazy :) but not too crazy
Cheers! _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
Matthew Finkel:
On Wed, Oct 28, 2020 at 04:54:56PM +0100, anonym wrote:
Matthew Finkel:
On Sat, Oct 24, 2020 at 09:31:39AM +0200, intrigeri wrote:
- Find, or write for scratch, another UI to configure & start little-t-tor.
Yes, and I think the Tor Project and the Tor community should keep this in mind. As Richard said, a configuration flow like this is needed for many different applications and we should think about providing drop-in solutions for this (instead of everyone developing their own).
Allow me to brainstorm a bit to see if we can avoid this extra implementation: what if Tor Browser can be told (perhaps with a --configure-tor-only parameter) to become essentially what Tor Launcher is now?
In other words, it lock itself down by disabling most of Firefox UI (menu, url and tab bar, etc) and functionality (in particular, no browsing!), and only display the Tor bridge configuration bits. If we had this, 3rd parties like Tails, Ricochet etc could just depend on Tor Browser to act as a "Tor Launcher", and no extra implementation is needed.
I think we should have a different solution than "include a full web browser for configuring Tor". This may be a short- or medium-term solution, but there isn't a good reason for ricochet bundling Tor Browser only for configuring Tor.
Fair enough! To have something for the "short- or medium-term", while we are developing/waiting for the proper solution would be very relieving. My hope is that my proposal would be cheap to leave room for in your design/implementation, otherwise I don't think it is worth it and we should aim for the long-term solution directly, whatever that is.
You also talk about censorship detection: it is a bit unclear if Tor Browser will try to detect it itself with some background work, or it this detection is reactive, e.g. by looking at what sites the users tries to visit; if it's the former, that would also fit with my proposal. If it's the latter, well that sucks, but at least 3rd parties would get something with the same power as the current Tor Launcher.
In the beginning this will likely be a hard-coded list of known regions where censorship is implemented based on prior knowledge (such as OONI reports). In the next iteration of this feature, we will likely try detecting censorship via automatic probing. We don't know exactly how we'll do this at this time.
Ok! This first iteration sounds like it would work in my proposal too, great!
How crazy does this sound?
Slightly crazy :) but not too crazy
Oh, yeah! :) So what is the proper way for me to formally suggest to add my proposal to the larger Tor Browser Quickstart project? Sending a merge request against tor-browser-spec.git:proposals/ideas/xxx-quickstart.txt?
Cheers!
Thanks folks for the feedback on the proposal! All your comments are appreciated and express a real need from our ecosystem while embedding tor in your apps.
I'll summarize a few takeaways here:
- To be clear, Tor Launcher will not be removed. Tor Browser will have its own UI for connecting, giving us more flexibility to develop censorship detection and provide bridges to reach the internet. You can sneak peek and comment here: https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004
- No bootstrap mode is a must-to-have for advanced users or users trying to debug their connection. We should include this ticket in the scope. https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345
- I don't think it should be a priority for us to provide a GUI for Tor Launcher. With a good developer experience for embedding Tor in applications, apps can have the freedom to implement tor in the way they consider it convenient for the use case. Perhaps Tails as an OS wants to have a Network Settings panel, but Ricochet or Cwtch as messaging apps want to hide the user's connecting flow and provide safe defaults.
- That said, I'd love to collaborate with Tails on guiding apps on connecting to Tor in a way that is usable and respectful for end-users.
- Starting Tor Browser just for the launcher is an over-engineering IMO. I agree with Richard that the need for a lite way (call it API or library) to embed tor is a real need. It is a whole topic and is a latent need from the entire ecosystem.
During the Demo days, we got the chance to see the multiple ways developers are embedding tor in their applications, how diverse this ecosystem is and how painful it is for devs to find a healthy way to do it. A useful side-effect of this project could be planning a way to improve that developer experience on implementing tor.
We have the chance to look beyond Tor Browser and think where Tor can be embedded by listening to the community and providing cool state of the art tools for implementing tor in their apps.
Again, thank you for your feedback! I'll go back to this thread once we have an alpha release so you can test it early.
A
On Thu, Nov 5, 2020 at 7:00 AM anonym anonym@riseup.net wrote:
Matthew Finkel:
On Wed, Oct 28, 2020 at 04:54:56PM +0100, anonym wrote:
Matthew Finkel:
On Sat, Oct 24, 2020 at 09:31:39AM +0200, intrigeri wrote:
- Find, or write for scratch, another UI to configure & start little-t-tor.
Yes, and I think the Tor Project and the Tor community should keep this in mind. As Richard said, a configuration flow like this is needed for many different applications and we should think about providing drop-in solutions for this (instead of everyone developing their own).
Allow me to brainstorm a bit to see if we can avoid this extra
implementation: what if Tor Browser can be told (perhaps with a --configure-tor-only parameter) to become essentially what Tor Launcher is now?
In other words, it lock itself down by disabling most of Firefox UI
(menu, url and tab bar, etc) and functionality (in particular, no browsing!), and only display the Tor bridge configuration bits. If we had this, 3rd parties like Tails, Ricochet etc could just depend on Tor Browser to act as a "Tor Launcher", and no extra implementation is needed.
I think we should have a different solution than "include a full web browser for configuring Tor". This may be a short- or medium-term solution, but there isn't a good reason for ricochet bundling Tor Browser only for configuring Tor.
Fair enough! To have something for the "short- or medium-term", while we are developing/waiting for the proper solution would be very relieving. My hope is that my proposal would be cheap to leave room for in your design/implementation, otherwise I don't think it is worth it and we should aim for the long-term solution directly, whatever that is.
You also talk about censorship detection: it is a bit unclear if Tor
Browser will try to detect it itself with some background work, or it this detection is reactive, e.g. by looking at what sites the users tries to visit; if it's the former, that would also fit with my proposal. If it's the latter, well that sucks, but at least 3rd parties would get something with the same power as the current Tor Launcher.
In the beginning this will likely be a hard-coded list of known regions where censorship is implemented based on prior knowledge (such as OONI reports). In the next iteration of this feature, we will likely try detecting censorship via automatic probing. We don't know exactly how we'll do this at this time.
Ok! This first iteration sounds like it would work in my proposal too, great!
How crazy does this sound?
Slightly crazy :) but not too crazy
Oh, yeah! :) So what is the proper way for me to formally suggest to add my proposal to the larger Tor Browser Quickstart project? Sending a merge request against tor-browser-spec.git:proposals/ideas/xxx-quickstart.txt?
Cheers! _______________________________________________ tbb-dev mailing list tbb-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tbb-dev
On 10/28/20 4:54 PM, anonym wrote:
Allow me to brainstorm a bit to see if we can avoid this extra implementation: what if Tor Browser can be told (perhaps with a --configure-tor-only parameter) to become essentially what Tor Launcher is now?
This is essentially what Tails currently does with tor-launcher. And seconding Matt, depending on shipping an entire copy of Firefox et al is a non-starter.
I suspect Tails, Tor Browser and Ricochet all have overlapping but not identical requirements. Off the top of my head, Ricochet depends on:
- launching and taking ownership of a new instance of the tor daemon - reading the tor log and other bits of tor state, version number, etc - setting proxy configuration info for the tor daemon - setting up bridge info - creating and/or restarting an onion service
We don't currently package any bridges so the only bridges we currently support are unpublished vanilla tor guard nodes (so no snowflake, obfs4, etc). It would be great if there was a way to programmatically get back from the tor daemon which bridges it supports.
Vanilla Tor Browser obviously has additional requirements surrounding the control port for the circuit display (and probably other things I don't recall). Tails' Tor Browser needs to be able to use an existing running tor instance that's launched by the OS on login.
Just some thoughts on the matter.
best, -Richard
Matthew Finkel:
Yes, and I think the Tor Project and the Tor community should keep this in mind. As Richard said, a configuration flow like this is needed for many different applications and we should think about providing drop-in solutions for this (instead of everyone developing their own).
Richard Pospesel:
On 10/28/20 4:54 PM, anonym wrote:
Allow me to brainstorm a bit to see if we can avoid this extra implementation: what if Tor Browser can be told (perhaps with a --configure-tor-only parameter) to become essentially what Tor Launcher is now?
This is essentially what Tails currently does with tor-launcher. And seconding Matt, depending on shipping an entire copy of Firefox et al is a non-starter.
I suspect Tails, Tor Browser and Ricochet all have overlapping but not identical requirements.
Exactly. I think that it might not be a realistic goal to provide a "drop-in solution" for all Tor applications. For example, different tools use different GUI kit: Tails uses Gtk and OnionShare uses Qt, etc.
It seems to me than a better approach might be to:
- Share GUI guidelines: describe screens and interactions for such a configuration tool after thorough usability tests. Tails is interested in working on this UX work together with Tor.
- Make it easier for such a GUI to get the information it needs from the Tor daemon. That's the part that Tor would have give technical support to, in collaboration with the affected projects.
This would also allow different tools from slightly diverging according to their needs instead of redesigning and rewriting something from scratch if the drop-in solution doesn't work for them.
But I know pretty much nothing about what is planned for the Tor Browser quickstart, both in the GUI and the backend, so maybe this doesn't make sense or would be over-engineering.
On Fri, Oct 23, 2020 at 09:58:33AM -0300, Antonela Debiasi wrote:
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].
One usability issue that remains is which mechanism we provide to users such that they can *disable* quickstart at some time in the future without needing to open (and bootstrap) Tor Browser [0]. With this feature, the user "does something" and is presented with the Connect screen where they can configure tor before bootstrapping begins. Ideally the mechanism should be cross-platform.
One suggestion is adding a hotkey shortcut and Tor Browser looks for those keys being pressed at startup. This unfortunately creates a race condition between starting Tor Browser and the user pressing those keys on the keyboard, but this is a common solution for other similar problems.
Another possible solution may be adding an option on the context menu of the launcher (icon), and add a new command line flag.
Discoverability is a concern for all of these options, as well.
If you have any ideas or suggestions, please let us know!
[0] https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/34345
-
anonym -
Antonela D -
Antonela Debiasi
-
intrigeri -
Matthew Finkel -
Richard Pospesel -
richard＠torproject.org
-
sajolida