[ux] collaborating on the redesign of the connection to Tor in Tor Browser and Tails

[Antonela D]

Hello! going inline

On Wed, Mar 3, 2021 at 8:16 PM sajolida <sajolida at pimienta.org> wrote:

> Hi,
>
> In February, we did a UX design sprint to redesign the process of
> connecting to Tor from Tails.
>
> Since Tor is working on something similar in S30 and #40004, I wanted to
> start a discussion to see how we could benefit from each others' design
> work.
>

Thanks for sharing your process with us!


> I'm identifying below a couple of opportunities where our design could
> be more similar. I would make it easier to understand by people using
> both Tor Browser and Tails and also to reuse some of our UX work.
>

Indeed. That is one of the reasons I shared our proposal with devs back
last year. For the records, the proposal is here

https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/ideas/xxx-quickstart.txt


> Our developers also have implementation questions but that's for later.
>
> The 2 designs
> -------------
>
> You can find background information and the mockups of our new design on
> this blueprint:
>
> https://gitlab.tails.boum.org/tails/blueprints/-/wikis/network_connection
>
> The blueprint doesn't specify the UX flow in much details, please ask
> for clarification if needed.
>
> For the record, the upcoming quickstart in Tor Browser is here:
>
> https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/
>

I don't think we have the same end product design goal here. For Tor
Browser, automatically connecting to Tor aims to be the default in the
short future. In Tails, I see a resistance to make it happen.


> Methodology
> -----------
>
> Our design came from a design sprint between developers and myself early
> February. We then tested our design using remote moderated usability
> tests using paper prototypes. We observed 6 test participants using our
> design during 2 hours individually.
>
> You can read more about this methodology here:
>
> https://simplysecure.org/blog/formative-testing
>
> So our mockups have already been tested with potential users already and
> work pretty well.
>
>
> Consent
> -------
>
> Both designs include a step when the user gives their consent before Tor
> Browser or Tails tries to connect to Tor automatically, and detect if
> bridges are needed for example.
>
> Tor Browser:
>
>
> https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/designs/desktop-IMG_0.0_-_Quickstart_Consent.png
>
> Tails:
>
>
> https://gitlab.tails.boum.org/tails/blueprints/-/wikis/network_connection#the-million-dollar-question
>
> As you can see, the way that Tails will ask for this consent is much
> more explicit. This difference already exists somehow in the current
> implementations so maybe it's a deeper product design choice.

For us, it is very important to allow our users to hide the fact that
> they are using Tails to their local network (at least as much as
> possible). This can be critical for people in places where using Tor is
> criminalized or only rarely used, but also for people who might be using
> Tails from their workplace or trying to avoid domestic surveillance,
> parental controls, etc.
>

Maybe you wanted to say Tor in the first line. Yeah, given the dynamic
development ideas for bridges, it may be the case that different kinds of
bridges offer different types of obfuscation, and users may not be aware of
that distinction. I'm curious about what the community thinks about
featuring the obfuscation nature of the circumvention method. How joining
the narrative that criminalizes users will help in encouraging mainstream
adoption? If Tor is criminalized in some country, do we trust _just_ in a
bridge to keep the user safe? Are you oversimplifying the threat model or
offering technical solutions to social problems?


> Bridges are not only good to avoid censorship but also to avoid being
> identified as a Tor user.
>

We are focusing on circumvention here, tho.


> The fact that this question is not as explicit in the design of the
> upcoming Quickstart procedure of Tor Browser makes me think that this is
> not so much of a design goal for Tor Browser.
>
> Did I understand correctly?
>
> Otherwise, if we share the same goal, then I think that our design
> should look more alike in order to best serve this class of users.
> I'm happy to discuss this more in depth.
>
> In your consent screen, I also see an option to "Enable Quickstart".
> It looks like a radio button but with a single option to choose from,
> but maybe that's a glitch on the wireframe.
>
> What's the difference between "Connect" with "Quickstart" and "Connect"
> without "Quickstart"?
>
> I couldn't understand this from the flowchart.
>

We organized this project in two parts: 1. Automatic Tor bootstrapping 2.
Censorship detection. You can find more details in the proposal.
The flowchart illustrates 2.

OONI vanilla test and interference
> ----------------------------------
>
> Slightly related, I failed to understand 3 things in your design.
>
> I'm referring to this flowchart:
>
>
> https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/designs/S30.png
>
> 1. When is the OONI vanilla test run?
>
> In the flowchart, the consent step (labelled as IMG 0.0 elsewhere) is
> not referenced. Do I understand correctly that the consent is asked
> before doing the OONI vanilla test?
>

Yes.


> 2. Why a OONI vanilla test?
>
> That's more of an engineering question but what is the advantage of
> doing a OONI vanilla test over trying to connect to Tor direct and see
> if it fails? Is it quicker? More reliable?
>

That is exactly what is happening now and the browser does not read network
feedback about why the connection fails. The test will help on a. reach
feedback about the current NAT 2. offer a solution.


> How are you going to implement this test? Integrating OONI probe in Tor
> Browser? Reimplementing the test?
>
> So far we haven't considered including a OONI vanilla test in the Tails
> autoconfig but maybe we should :)
>

Here is the referred ticket
https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/23838


> 3. Why are you pausing the flow in case of interference in autoconfig?
>

We are not. If quickstart is enabled, the bridge wants to autoload and the
bootstrap starts again.


> That's:
>
>
> https://gitlab.torproject.org/tpo/anti-censorship/trac/-/issues/40004/designs/desktop-IMG_3.0_-_Offline_-_Detected_Interference.png
>
> In the flowchart, I understand that if the user choose "Use a bridge",
> then Tor Browser would try to connect to the default bridges.
>
> Did I understand correctly?
>

No. That is not defined yet.


> If so, why ask this question and not try the default bridges
> straightaway if the OONI vanilla test fails?
>
> Also, what happens if using the default bridges are blocked?
>

AFAIK that is not defined yet. We planned to use Salmon here, but I'm not
up to date with the last month's meetings on what has been decided on the
technical side. Matt/Geko/Cecylia can provide Tails more details about our
plans on it.


> In our design:
>
> - If the user chooses to autoconfig, then we're not asking any
>    additional question before trying the default bridges:
>
>
> https://gitlab.tails.boum.org/tails/blueprints/-/wikis/network_connection#connecting-to-tor-with-default-bridges
>
> - If the user chooses to hide that they are using Tor, then we're never
>    offering to use the default bridges because they are public
>    information.
>
> If that sounds important to Tor Browser as well, you might consider only
> using the default bridges as part of the autoconfig but not offering
> them as an option in about:tor. When a user doesn't give their consent
> for autoconfig, they should rather get a bridge using Moat.
>

Right. It seems a good use of Moat if Moat is still being the thing for
promoting your feature ("hiding the fact that I'm using Tor").


> UI strings
> ----------
>
> I see a couple of places where both designs could use similar UI strings.
>
> To describe the Tor network, you have in about:tor:
>
> « Tor Browser connects you to the Tor Network run by thousands of
> volunteers around the world. »
>
> We have in the first screen of our connection assistant:
>
> « Tor encrypts and anonymizes your connection by passing it through 3
> relays. Tor relays are servers operated by different people and
> organizations around the world. »
>
> - "Encrypts and anonymizes" tells more than "connect" and relates better
>    to what people care about (security and anonymity).
> - "Passing it through 3 relays" was useful for people to start
>    understanding how Tor works.
> - "People and organizations" sounded more trustworthy to test
>    participants than than "volunteers", which sounded less reliable.
>

Lovely. I like the idea to highlight "Encrypts and anonymizes". Some
connections don't have 3 relays, though. Also, I feel "volunteers" is
stronger and renders a better statement of the infrastructure ownership.



> To describe bridges, you have in about:tor:
>
> « Bridges help you to access the Tor network in places where Tor is
> blocked. [...] »
>
> We wrote:
>
> « Bridges are secret Tor relays that hide that you are connecting to
> Tor. Use a bridge as your first Tor relay if connecting to Tor is
> blocked or criminalized, for example in China, on some public or
> corporate networks, or parental controls. »
>
> - It makes it clear that using a bridge is also good to hide that you
>    are connecting to Tor.
>
> - It helps building an understanding of the bridge being only the first
>    relay. Since bridges.torproject.org returns several lines, some test
>    participants thought that these were the 3 relays. They are not.
>

Right. But, some bridges are public and not all bridges hide the fact that
you are using Tor. Also, I'd avoid naming countries as examples since the
political narrative moves faster than our UI updates :)


> Sorry for dumping all this in a email. Tell me if you'd like me to move
> some of these discussions to GitLab.
>

Yes, a gitlab issue is a way more agile method to have these discussions.
Especially when the feedback comes on time!


> Take care,
>

Thanks for this review! It's critical for us to understand the needs of
users in different apps across the entire ecosystem.


> --
> sajolida
> Tails — https://tails.boum.org/
> UX · Fundraising · Technical Writing
>
> _______________________________________________
> UX mailing list
> UX at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ux
>


-- 
Antonela Debiasi
UX Team Lead
torproject.org

@antonela
E2330A6D1EB5A0C8
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ux/attachments/20210305/9321959d/attachment-0001.htm>