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

Wed Mar 3 23:15:00 UTC 2021

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.

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.

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/

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.

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

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.

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?

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?

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 :)

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

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?

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?

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.

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.

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.

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

Take care,

-- 
sajolida
Tails — https://tails.boum.org/
UX · Fundraising · Technical Writing

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/ux/attachments/20210303/545b343a/attachment.sig>