[tor-bugs] #2905 [Vidalia]: Adapt Vidalia UI to allow users to avoid connecting to the public tor network

Wed Oct 26 00:53:25 UTC 2011

#2905: Adapt Vidalia UI to allow users to avoid connecting to the public tor
network
---------------------+------------------------------------------------------
 Reporter:  anonym   |          Owner:  chiiph        
     Type:  defect   |         Status:  new           
 Priority:  major    |      Milestone:                
Component:  Vidalia  |        Version:  Vidalia 0.2.10
 Keywords:  bridges  |         Parent:                
   Points:           |   Actualpoints:                
---------------------+------------------------------------------------------

Old description:

> 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?

New description:

 We need a way to avoid touching the public network for both Tails and TBB
 users, in a way that doesn't clutter the Vidalia UI, scare users, and/or
 subject users to warning fatigue.

--

Comment(by mikeperry):

 Ok! We have a solution. I will attach the outline that is the result of a
 discussion between Nick, chiiph, anonym. I believe everyone is on board
 with this plan, finally.

 See #4290 for a related Vidalia UI issue that caused some snags in the
 discussion of this feature.

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