[tor-bugs] #2905 [Vidalia]: Adapt Vidalia w.r.t. bug #2355

[Tor Bug Tracker & Wiki]

#2905: Adapt Vidalia w.r.t. bug #2355
-------------------------+--------------------------------------------------
 Reporter:  anonym       |          Owner:  chiiph        
     Type:  enhancement  |         Status:  new           
 Priority:  normal       |      Milestone:                
Component:  Vidalia      |        Version:  Vidalia 0.2.10
 Keywords:  bridges      |         Parent:                
   Points:               |   Actualpoints:                
-------------------------+--------------------------------------------------
 If bug #2355 gets implemented (I have written a patch that is up for
 review, so hopefully it will ''soon'') Vidalia will need to take this new
 bridge behaviour of Tor into account. With
 [https://trac.torproject.org/projects/tor/search/opensearch?q=ticket%3A2355
 #2355] implemented UseBridges is a tristate with possible values:

  * "auto": use bridges iff any bridges are configured (so this is
 essentially the old behaviour of
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges] set to "1"). This is the default value.

  * "1": strictly use bridges, so if none are configured, Tor won't connect
 to the Tor network at all.

  * "0": strictly do not use bridges, only use direct connections to the
 Tor network.

 I am willing to implement this as part of the Tails sponsorship contract
 we have with the Tor Project, but first I think we need to decide what
 the right design is.

 First of all, the current "My ISP blocks connections to the Tor network"
 checkbox (let's call this the "bridge checkbox" from now on)  for
 activating bridges is not enough for handling all these cases, so some GUI
 change is necessary.

 Furthermore, the idea about this new behaviour of UseBridges is that some
 users may want to strictly use bridges in order to avoid their
 ISP/government/adversary to learn that they are using Tor, not only to
 avoid blocking. The strictness (or "stealthyness") aspect changes the
 semantics of this option, so the bridge checkbox (or its replacement)
 label needs to be rephrased to accommodate this change. However, I think
 it will be impossible to succinctly and unambiguously explain the new
 options in just the labels given their limited space, but that can be
 accounted for with a "More about Tor bridges" label in the bridge settings
 linking to the bridge section of the help (which must to be updated) and
 tool-tip help pop-ups.

 There is also the question about backwards compatibility with older Tor
 clients using the old boolean
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridge
 UseBridge]. I assume this is a must, although it likely will litter the
 code with additional checks against torVersion. Right?

 Below I present two design proposals which takes all of the above into
 account. Comments and other proposals are welcome. All phrasings are of
 course up for debate.

 '''Proposal 1.''' Change the bridge checkbox to a drop-down list that
 exactly corresponds to the new UseBridges values, e.g.

  1. "Try using Tor bridges to connect to the Tor network", corresponding
 to
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges] set to "auto".

  1. "Only allow connections to the Tor network through Tor bridges",
 corresponding to
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges] set to "1".

  1. "Do not use Tor bridges", corresponding to
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges] set to "0".

 Only 1 and 2 would show the bridge settings. Its tool-tip pop-up could say
 something like: "Tor bridges makes it harder for your ISP to detect that
 you use Tor and makes it possible to circumvent blocking of the Tor
 network".

 For backwards compatibility, drop-box list item number 2 would be
 removed/greyed with older clients.

 '''Proposal 2.''' Keep the bridge checkbox, but rephrase its label to "Try
 using Tor bridges to connect to the Tor network". Like before, the the
 bridge settings are shown if it is checked. Then we add a new strictBridge
 checkbox in between the bridge list and the "Find bridges now" button,
 with the label "Only allow connections to the Tor network through Tor
 bridges". Their behaviour would be the following:

  * If only the bridge checkbox is set, that means
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges] is set to "auto".

  * If both the bridge and strictBridge checkboxes are checked, that means
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges] is set to "1".

  * If the bridge checkbox is __not__ set, that means UseBridges is set to
 "0" (the strictBridge checkbox is ignored in this case).

 The bridge checkbox could have tool-tip: "Tor bridges makes it harder for
 your ISP to detect that you use Tor and makes it possible to circumvent
 blocking of the Tor network". The strictBridge checkbox could have tool-
 tip: "Checking this prevents direct connections to the Tor network which
 makes it harder for your ISP to detect that you are using Tor".

 For backwards compatibility, the strictBridge checkbox would be
 removed/greyed for older clients.

 '''Note.''' Since Tor's default behaviour will be
 [https://trac.torproject.org/projects/tor/search/opensearch?q=wiki%3AUseBridges
 UseBridges]  set to "auto", both proposals will have the bridge settings
 (bridge list  etc.) shown by default. This is a change from previous
 Vidalia  behaviour, but probably it will be of little importance, or could
 this  add to user confusion? And is "''Try'' using Tor bridges..." for the
 options that causes the "auto" behaviour clear enough to make users
 understand that direct connections will be used if the bridge list is
 empty?

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