[tor-bugs] #24309 [Applications/Tor Browser]: Activity 4.1: Improve how circuits are displayed to the user

Wed Apr 18 05:46:08 UTC 2018

#24309: Activity 4.1: Improve how circuits are displayed to the user
-------------------------------------------+-------------------------------
 Reporter:  isabela                        |          Owner:  tbb-team
     Type:  defect                         |         Status:
                                           |  needs_revision
 Priority:  High                           |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  ux-team, TorBrowserTeam201804  |  Actual Points:
Parent ID:                                 |         Points:
 Reviewer:  antonela                       |        Sponsor:
-------------------------------------------+-------------------------------

Comment (by dmr):

 Long comment, so breaking it up into chunks...

 ==== Educating users, color, additional info?

 Replying to [comment:33 isabela]:
 > I like the idea to add the Exit label. I would change the whole thing
 though, and by that I mean I would have label for each node (going back to
 the idea of using every moment to educate our users). I would have
 'Guard', 'Middle', 'Exit'.
 I like the idea of educating the users, but I fear that introducing
 //all// of these terms //AND// that their guard node shouldn't change
 //AND// giving them a button to click //AND// giving them a link to click
 //AND// providing the existing 'Secure Connection' Firefox info* //AND//
 providing the existing Permissions info... would be overload.
 I would encourage that we validate this, however, but I could see it as
 easily overwhelming.

 ^^* which I believe could be, for an HTTPS mixed-content page, saying
 [[span(style=color: #FF0000, Connection is Not Secure)]] and itself having
 clickable UI elements to learn more.

 I really like the color tie-in of the **[[span(style=color: #7D4698,
 Guard)]]** label at the guard node and in the explanation text - that
 visually connects the two together. I see it as a major strength to the
 design. Similar to overload above, I don't think we can add much more info
 here and tie it all together visually - that use of color would be
 difficult to scale up.

 Since we're talking about mock-ups that have `.onion` sites, I'd like to
 point out that the "Exit" concept doesn't exist there, so if we're trying
 to educate users on the purpose of the various relays, that would be even
 tougher. We'd need to identify the client's 3rd relay as something other
 than an exit ("Rendezvous" might be too confusing) and they'd wonder
 further about the unmarked `Relay` nodes from the Onion Service.

 Lastly, since we have a Guard node `Learn more` link to the manual, maybe
 we can consider education holistically, by presenting layered info for
 them to follow if it interests them. That is: if a user follows this link,
 we could potentially:
 * first present them with the direct info they want to know - why doesn't
 the Guard node change?
 * either below that or with another "Learn more" link (maybe "Learn more
 about other types of Tor relays"), teach them a bit more related info

 ==== Display IP addresses? (imo: yes)

 Replying to [comment:33 isabela]:
 > The IP addresses are something people sometimes want to know so I would
 try to keep them to make it convenient for the user. That said, I wonder
 if it will be indeed too crowed, for some reason I don't think it would.
 But I leave this to Antonela to decide :) if having it there is ok or if
 its better to put it in tooltip or something.

 I agree - it's really nice to get a peek into what Tor is doing under the
 hood.

 It's especially helpful to have the exit IP as confirmation to a
 nontechnical user that "hey, this new circuit button thing actually did
 something", since sometimes it gives you another exit in the same geoip
 country.

 It's similarly especially helpful when multiple relays in the path are
 from the same geoip country.

 ==== Hiding info for user protection? (this is probably orthogonal - move
 to another ticket?)

 Replying to [comment:5 arthuredelstein]:
 > We might also consider hiding the Guard IP address so that users are
 less likely to leak their Guard information.

 I reviewed this ticket and don't see any responses to that. Maybe a
 decision was made in a meeting?

 Anyway: how big of a concern is leaking this info? and what can we
 realistically do about it, without impacting the other goals of this
 display?
 I imagine that //lots// of info in this display + surrounding context is
 potentially risky. We see:
 * the Guard's IP address
 * the Exit's IP address
 * the target website
 * potentially further portions of the website URL or page, if the user
 took a screenshot

 I could see the Guard info as being particularly important to hide, since
 Guards change much less frequently, and some other data like screenshot
 timestamp (if the file was obtained/shared/etc.) could be used to further
 reduce the anonymity set of that person.

 Perhaps the discussion for design and threat modeling on that should be
 moved elsewhere?
 Hiding guard info isn't currently done by Tor Browser //(except for
 bridges perhaps?)//, and I don't think it needs to be part of the first
 iteration. I'd place it under the **Things I am suggesting to be left for
 a second iteration or not doing and why** category in the Description.

 I just brought it up because I wanted to make sure it didn't slip through
 the cracks.

 ==== Wording - //may//, educating: protection mechanism, prop!#291,
 future-looking

 Some comments on the English wording.

 > Your Guard node may not change. Learn more
 I think the word `may` is misleading. It makes it sound like an infrequent
 occurrence, akin to "Your Guard node //might// not change." or "Your Guard
 node probably will change but //may// not.".

 It also may be helpful to use some words here to indicate not just the
 //result// of the Guard-selection, but that it is a //protection//
 mechanism.
 So possibly something along the lines of:
 > For your protection, your Guard node changes very infrequently. Learn
 more

 Of course, we also have to balance this with
 [[https://gitweb.torproject.org/torspec.git/tree/proposals/291-two-guard-
 nodes.txt|prop#291]] and come up with wording that won't scare people when
 they see this change for different circuits, or eventually
 [[https://tails.boum.org/blueprint/persistent_Tor_state/|different
 locations]].

 ==== ending comments

 Overall, I am extremely glad to see this work being done!

 I think the Guard-not-changing concept is extremely unintuitive to users -
 including technically minded security researchers I've spoken with - and
 this is one of the most important things that we can educate users about
 through this design. I know I was confused myself when I first started
 using Tor.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24309#comment:52>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online