[ux] Automatic bootstrapping comments

[Duncan Russell]

Hi there, thanks for raising these points!

> ...are there design elements or plans to prevent them from occurring?

The short answer is: to some degree, yes! The longer answer is as follows:

In both of these scenarios, a Tor Network Settings button is now available on the connection screen, allowing users to open the Tor Settings directly before connecting and add a bridge or a proxy.

This effectively replaces the “Configure” button in the previous Tor Launcher window. You can also navigate to Tor Settings using all of the means previously available to after connecting in 10.0 (i.e. using the menu icon or address bar) before connecting in 10.5 – which is useful!

Additionally, users can prevent Tor Browser from bootstrapping automatically on subsequent launches by choosing not to opt-in to the “Always connect automatically” setting, which is present on both the connection screen and now in Tor Settings too.

However, you’ve raised an interesting point about the line of copy that was previously featured on Tor Launcher (and is now omitted from Connect to Tor):
> "click Configure if you are in a censored country"
We could potentially add a similar line of copy back in to the description, but I have some thoughts about it:

* It's only applicable to a small (although important) subset of Tor Browser users – in your example, a relatively new user in a censored location, who is aware that Tor is blocked but is content to attempt a regular connection nonetheless – and it’s difficult to estimate the impact here.

* As you can imagine, there’s always a balance to be struck when designing a screen for 100% of Tor Browser users, while keeping it as applicable as possible for day-to-day users, highly technical users, censored users and each possible overlap between these groups.

* I expect that when warned, this user-group likely gravitate to built-in or publicly distributed bridges – which wouldn’t eliminate the hypothetical risk here (although bridges are a useful tool to circumvent censorship in general).

* Regardless of whether we include or exclude this warning, we’re still putting the burden on the user to know when they should not connect directly – which is an interesting problem!

So, I think the best solution here is to continue to make Connect to Tor smarter, which is part of our future plans for Tor Browser – including developing new connection flows for censored users that automatically detect network interference during bootstrapping.[*]

* https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt <https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt>
* https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/ <https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/>

Thanks!
Duncan

—
Duncan Larsen-Russell
UX Lead
The Tor Project

https://www.torproject.org <https://www.torproject.org/>
http://expyuzz4wqqyqhjn.onion/ <http://expyuzz4wqqyqhjn.onion/>



> On Jul 1, 2021, at 23:47, Cover Minerals <coverminerals at gmail.com> wrote:
> 
> Hi,
> 
> Does the new UX introduce either of the following downsides? Or are there design elements or plans to prevent them from occurring?
> A new, unfamiliar user is in a location where Tor is blocked and attempting to connect to an entry relay alone is suspicious. Previously, the launcher guides the user away ("click Configure if you are in a censored country"). Now, are they more likely to 'incur their ISP's wrath'?
> A familiar user in the same situation needs to install a fresh copy of Tor Browser. Will it be easy for them to re-enter their bridge lines, or (accidentally or not) are they more likely to fall into the flow of "attempt direct connection, fails, new automatic bridge UX kicks in"?
> _______________________________________________
> UX mailing list
> UX at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ux

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ux/attachments/20210702/23d8f122/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/ux/attachments/20210702/23d8f122/attachment.sig>