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

Thu Mar 4 14:35:15 UTC 2021

Hey sajolida,

Thanks for sharing what you and the team have been working on at Tails! The paper prototyping session in particular sounds really interesting and I’d love to know more about it. I may have more questions once I’ve had the chance to digest your email and Tails’ new connection blueprint properly.

Antonela, the original author of the proposal and UX planning work for S30, is on leave at the moment – however I’m sure she’ll spot your email soon. Otherwise I’ll do my best to respond to some of the specific points about Tor Browser's proposed quickstart UI :)

Best,
Duncan

Duncan Larsen-Russell
UX Designer

duncan at torproject.org
—
FE1C 49AF 9B7C BB9C CE85  C3BB 8A70 4FEA 598B 7DDB

> On Mar 3, 2021, at 18:15, sajolida <sajolida at pimienta.org> wrote:
> 
> Signed PGP part
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/ux/attachments/20210304/86a99e99/attachment.htm>