[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3354 [Vidalia]: tor's auto bridge default and unintended Vidalia side effects
#3354: tor's auto bridge default and unintended Vidalia side effects
---------------------+------------------------------------------------------
Reporter: erinn | Owner: chiiph
Type: defect | Status: needs_review
Priority: blocker | Milestone: Vidalia: 0.2.13
Component: Vidalia | Version: Vidalia: 0.2.12
Keywords: | Parent:
Points: | Actualpoints:
---------------------+------------------------------------------------------
Comment(by anonym):
[sorry for the long post, but at this point I really want to be clear and
avoid further misunderstandings...]
Replying to [comment:16 arma]:
> C) Is the proposed Vidalia hack described in this ticket actually going
to be compatible with the hack that the Tails people intend to do? I'm
adding anonym to the cc list. I don't actually remember how they intended
to deploy their hack. But if Vidalia auto unsets usebridges when it's set,
no bridges are listed, and you click save, can the user accidentally
bypass the Tails hack by changing something else in Tor's config, clicking
save, and having Vidalia set usebridges to 0, thus allowing the user to
start talking to the network?
I described what we want in (the forgotten?) #2905. As I said there, I
thought fixing the new UseBridges behaviour in Vidalia was Tails' job as
part of our 2011 contract with you, so I wrote a patch (not published)
implementing it which handled backwards compatibility just fine. It seems,
though, that most agree the Auto option should be hidden in Vidalia, so my
designs and patch are moot now.
So what we would like for Tails is something that is not a hack. We've
already had a hack giving us what we want for quite some time, and the
whole idea of "fixing" UseBridges in Tor was to have a clean solution
without any hacks at all that is 100% consistent with normal Tor+Vidalia
(and preferably also TBB) behaviour. We also thought that such
functionality is highly usable outside the Tails context (like in TBB).
Hence it is a bit frustrating and surprising, at this late stage, to see
that during all this time this "fix" has been considered as something that
will turn out as a hack. If that's the way it will end up we don't care
about the resent change of UseBridges behaviour, so you can revert it and
we can continue to patch Vidalia to use our current hack (although that
truly would suck).
Below I suggest something that would suit us, that is backwards-compatible
and AFAICT doesn't screw anyone:
As soon as Vidalia *notices* that UseBridges=1 and no bridges are
configured, the user is prompted about the problem with this situation.
With "notices" I mean either when Vidalia loads vidalia.conf on start, or
imports Tor's settings from a system-wide instance of Tor through the
control port, when the settings just was changed by the user in the
Vidalia settings. Vidalia's ConfigDialog::applyChanges() is called in all
these situations, so throwing the prompt from there would work. The prompt
in question would be:
Title: Tor needs a bridge
Text:
Tor is currently configured to only allow connections through bridges,
but no bridges are configured. With "My ISP blocks..." checked, Tor will
need at least one working bridge configured in order to work. Do you want
to open the network settings to resolve this issue?
Buttons:
* Yes: opens the bridge settings. As you will see below, the problem
would be clearly highlighted in the bridge settings, so the user would
know what to do.
* No: does nothing, so Tor will remain unable to connect to the Tor
network until a bridge is added by the user. As you will see below,
Vidalia will make it pretty clear why Tor isn't working, and on a restart
the user would get this same prompt again.
To prevent a user from unknowingly creating the situation where Tor cannot
connect and is waiting for a bridge to be added, we can:
* show a warning *in* the bridge settings to the right of/below/near the
"My ISP blocks..." label that would be shown only when it is checked
without any bridges listed. The warning could be composed of a warning
sign icon (you know, the usual yellow triangle + exclamation mark that
just about everyone groks) with an appropriate label ("You must specify at
least one bridge if you want Tor to work with this configuration").
* set the Vidalia control panel status to something appropriate ("Tor
needs a bridge"), as well as making the status onion yellow (including the
systray icon).
* reword "My ISP blocks..." to something more fitting as it currently
only covers half of what bridges can do, i.e. it says nothing about "Tor
is illegal in my country". Perhaps it should be renamed "Use Tor bridge
relays", and some informative text above that label and the checkbox can
explain when to use it + link to the bridge help.
For backwards compatibility the prompt and the other behaviour can be
suppressed for Tor versions <0.2.2.28. I think we'd need ~3 such version
checks in the code in total, so I guess it's acceptable(?).
To include this in TBB, the installer asks the relevant question (i.e. "is
Tor illegal in your country?") and, if yes, adds UseBridges=1 to the
vidalia.conf it installs. This would give the exact same experience to
users of TBB and Tails that need a bridge only mode.
Of course, my solution still allows the user to put Tor in the state where
Tor cannot connect and waits for a bridge, which many seem to have a
problem with. I don't understand why that is a problem, and I'm strongly
against a solution which is not exposed to the user as such inconsistent
behaviour is highly confusing. If we are going to provide this (arguably
important) feature in a clean and safe way, the user must be able to
request that *only* bridges should be used, and this is exactly what is
delivered in my solution. It's only if the user is so clueless that it
won't read any warnings/prompts that it can mess up, but the harsh truth
is that such a user is likely a lost cause. Also, some other options can
set Tor in a non-working state, like adding a non-working bridge. In that
situation the user has no help from Vidalia to determine the error (Tor
will just not work, so hopefully the user will understand that s/he must
try another one), but with my solution the warning signs are everywhere
and the user is guided to return Tor to a working state, either by adding
a bridge or by disabling UseBridges.
I'm not sure if I've missed something, but if everyone thinks this is a
good solution, but no one feels like implementing it (as it requires some
work) I'm willing to implement it (ETA: 2 weeks).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3354#comment:19>
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