[tor-bugs] #3354 [Vidalia]: tor's auto bridge default and unintended Vidalia side effects

[Tor Bug Tracker & Wiki]

#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