[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #2905 [Vidalia]: Adapt Vidalia w.r.t. bug #2355
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs