Re: [tor-bugs] #16665 [Tor Browser]: Circuit visualizer needs a cue about guards

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16665: Circuit visualizer needs a cue about guards
-------------------------------------------------+-------------------------
 Reporter:  lunar                                |          Owner:  tbb-
     Type:  enhancement                          |  team
 Priority:  Medium                               |         Status:
Component:  Tor Browser                          |  needs_revision
 Severity:  Normal                               |      Milestone:
 Keywords:  tbb-usability, tbb-circuit-display,  |        Version:
  TorBrowserTeam201602                           |     Resolution:
Parent ID:                                       |  Actual Points:
  Sponsor:                                       |         Points:
-------------------------------------------------+-------------------------

Comment (by Spencer):

 Hi,

 Been following the entry guard and circuit visualization work for some
 time and would like to share some thoughts.

 People often come to me confused that the first Tor node in the circuit
 was always (often) the same, as well.  However, their intention is to
 change that.

 >
 > getting the UX right is a non-trivial thing
 >

 Not true.  People expect the circuit path to change, so let them change it
 at will, through the interface.

 >
 > Like a âChange Guardâ button?
 >

 This is a wonderful resolution, and resolves issues with another related
 topic, persistent vs non-persistent guards, that is best resolved here up-
 stream.

 >
 > Forcing a new guard is bad .. such feature would do more harm than good
 >

 It is unclear how being able to control the separation of identities is a
 bad thing.

 Location correlation is a real issue.

 >
 > patch avoids the confusion described in this ticket
 >

 It feels like the goal is to resolve, not avoid.

 >
 > There should be an easy way for users to determine their guard node.
 >

 The circuit visualizer (:

 Controlling it from here could be useful, too.

 >
 > hard to tell the user that there is something to hover in the first
 place
 >

 Discoverability is quite underusable.

 >
 > (?)
 >

 This is very unclear.

 >
 > most people who ask why .. are not going to click an extra link to learn
 more
 >

 Not true.  If the text is more descriptive than 'Learn More', then people
 who want to know more about circuits have a quick link to do so.

 'Learn about Tor circuit selection' or something short but sweet could
 work quite well.

 >
 > A short text message that shows up when hovering over a (?)
 >

 The strings currently consist of a bullet, a descriptor, and an IP
 address.  Adding a (?) and some resulting text, even on hover, becomes
 quite cluttery.

 The 'Learn More' context of one clear link seems like the most suitable
 resolution, given the stated concerns, though a more verbose descriptor is
 needed.

 >
 > I don't like the âLearn moreâ approach as it's quite far from the Guard
 itself
 >

 It isn't about learning about the individual guards as much as it is about
 understanding the intended functionality of the circuit; why is the first
 node staying the same, or, how do exits work, for example.

 How can the interface inherently educate about these things.

 >
 > send people to a new page just for a short message
 >

 This seems like the biggest issue with a link.

 Overall, the guard selection algorithm is fine but the theoretical
 equation (c/n)2 ignores that if the entry guard is malicious then it
 becomes more harmful than having one or two connections deanonymized.

 Easy access to both the information and the ability to control the
 experience is valuable.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16665#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs