[ux] Automatic bootstrapping comments

Fri Jul 2 19:17:05 UTC 2021

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.

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?

Having this view in mind, seeing the work and having read the proposal, I'm
still confused and would love to understand more.

   - 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?
   - 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.

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.

*pd: I have to say, I love this open space. Thank you all.*
Pura vida,
j

On Fri, Jul 2, 2021 at 11:01 AM Duncan Russell <duncan at botany.studio> wrote:

> 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/anti-censorship/trac/-/issues/40004/
>
> Thanks!
> Duncan
>
> —
> Duncan Larsen-Russell
> UX Lead
> The Tor Project
>
> https://www.torproject.org
> 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
>
>
> _______________________________________________
> 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/386d6f1b/attachment-0001.htm>