<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi there, thanks for raising these points!<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">...are there design elements or plans to prevent them from occurring?</div></div></blockquote><div class=""><br class=""></div>The short answer is: to some degree, yes! The longer answer is as follows:<br class=""><div class=""><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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 <i class="">after</i> connecting in 10.0 (i.e. using the menu icon or address bar) <i class="">before</i> connecting in 10.5 – which is useful!</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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):</div><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class=""><ul class=""><li class="">"click Configure if you are in a censored country"</li></ul></div></div></blockquote><div class="">We could potentially add a similar line of copy back in to the description, but I have some thoughts about it:</div><div class=""><br class=""></div><div class="">* 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.</div><div class=""><br class=""></div><div class="">* 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.</div><div class=""><br class=""></div><div class="">* 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).</div><div class=""><br class=""></div></div><div class="">* Regardless of whether we include or exclude this warning, we’re still putting the burden on the user to <i class="">know</i> when they should not connect directly – which is an interesting problem!</div><div class=""><br class=""></div><div class="">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.[*]</div><div class=""><br class=""></div><div class="">* <a href="https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt" class="">https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt</a></div><div class="">* <a href="https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/" class="">https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/</a></div><div class=""><br class=""></div><div class="">Thanks!</div><div class="">Duncan</div><div class=""><br class=""></div><div class="">—<br class="">Duncan Larsen-Russell<br class="">UX Lead<br class="">The Tor Project<br class=""><br class=""><a href="https://www.torproject.org/" class="">https://www.torproject.org</a></div><div class=""><a href="http://expyuzz4wqqyqhjn.onion/" class="">http://expyuzz4wqqyqhjn.onion/</a></div></div></div><div><br class=""></div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 1, 2021, at 23:47, Cover Minerals <<a href="mailto:coverminerals@gmail.com" class="">coverminerals@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Hi,</div><div class=""><br class=""></div><div class="">Does the new UX introduce either of
the following downsides? Or are there design elements or plans to
prevent them from occurring?</div><div class=""><ul class=""><li class="">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'?</li><li class="">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"?</li></ul></div></div>
_______________________________________________<br class="">UX mailing list<br class=""><a href="mailto:UX@lists.torproject.org" class="">UX@lists.torproject.org</a><br class="">https://lists.torproject.org/cgi-bin/mailman/listinfo/ux<br class=""></div></blockquote></div><br class=""></body></html>