<div dir="ltr">Hello UX list, I'm relatively new to the Project's inner workings, as a matter of fact it's the first time I have seen a proposal page, how cool? Anyway, I'll keep this to the point.<br><br>Cover Minerals raises a crucial question. One which I think frames an underlying theme: who is the primary user or critical user of Tor Browser? And I find the response of the team... in the product that was shipped: everyday user. But... one could challenge this view with two perspectives: (i) a Privacy by Design philosophy or a human design approach, broadly speaking, say that if it works for one population or one complex scenario then it works for everyone else as well. Is the reason why ramps, subtitles/captions, etc. all improve our ways of experiencing the world. We could also challenge it by (ii) the goal of building a tool like this. In the end, aren't we all doing this because of censorship? And isn't it one of the main reasons the design of the technology is tailored the way it is? <br><br>Having this view in mind, seeing the work and having read the proposal, I'm still confused and would love to understand more.<br><ul><li>The proposal states an ideal mechanism of recognizing an interference in the network, and so I can't help to ask: are we sure it works 100%? I think it is a fascinating idea, it would definitely improve and reduce the friction a user might have, but should we rely on it to the point of not having a way to choose?</li><li>Is this something that is working now? As in, did we ship the whole proposal including the mechanism? I'm not sure from Duncan's response.</li></ul>At the beginning I say the answer of who is the primary user or critical user, is found in the product as: everyday user. But I'm assuming that the answers to these questions are specifically: (i) we don't know 100% and we are relying on the mechanism. (ii) we don't have it currently, but it will be built. And is the reason why I think the answer to the underlying theme it's: an everyday user... As we would be prioritizing their needs. But I'm not sure if my assumptions are correct and would like to know more about it and what else I'm missing.<div><br><i>pd: I have to say, I love this open space. Thank you all.<br></i><br>Pura vida,<br>j<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 2, 2021 at 11:01 AM Duncan Russell <duncan@botany.studio> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Hi there, thanks for raising these points!<div><br></div><div><blockquote type="cite"><div dir="ltr"><div>...are there design elements or plans to prevent them from occurring?</div></div></blockquote><div><br></div>The short answer is: to some degree, yes! The longer answer is as follows:<br><div><br></div><div><div>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><br></div><div>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>after</i> connecting in 10.0 (i.e. using the menu icon or address bar) <i>before</i> connecting in 10.5 – which is useful!</div><div><br></div><div>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><br></div><div>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><blockquote type="cite"><div dir="ltr"><div><ul><li>"click Configure if you are in a censored country"</li></ul></div></div></blockquote><div>We could potentially add a similar line of copy back in to the description, but I have some thoughts about it:</div><div><br></div><div>* 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><br></div><div>* 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><br></div><div>* 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><br></div></div><div>* Regardless of whether we include or exclude this warning, we’re still putting the burden on the user to <i>know</i> when they should not connect directly – which is an interesting problem!</div><div><br></div><div>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><br></div><div>* <a href="https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt" target="_blank">https://gitlab.torproject.org/tpo/applications/tor-browser-spec/-/blob/master/proposals/106-quickstart.txt</a></div><div>* <a href="https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/" target="_blank">https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/</a></div><div><br></div><div>Thanks!</div><div>Duncan</div><div><br></div><div>—<br>Duncan Larsen-Russell<br>UX Lead<br>The Tor Project<br><br><a href="https://www.torproject.org/" target="_blank">https://www.torproject.org</a></div><div><a href="http://expyuzz4wqqyqhjn.onion/" target="_blank">http://expyuzz4wqqyqhjn.onion/</a></div></div></div><div><br></div><div><br></div><div><br><blockquote type="cite"><div>On Jul 1, 2021, at 23:47, Cover Minerals <<a href="mailto:coverminerals@gmail.com" target="_blank">coverminerals@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div>Hi,</div><div><br></div><div>Does the new UX introduce either of
the following downsides? Or are there design elements or plans to
prevent them from occurring?</div><div><ul><li>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>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>UX mailing list<br><a href="mailto:UX@lists.torproject.org" target="_blank">UX@lists.torproject.org</a><br><a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/ux" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/ux</a><br></div></blockquote></div><br></div>_______________________________________________<br>
UX mailing list<br>
<a href="mailto:UX@lists.torproject.org" target="_blank">UX@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/ux" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/ux</a><br>
</blockquote></div>