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

[Tor Bug Tracker & Wiki]

#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:  Vidalia: 0.2.13
Component:  Vidalia  |        Version:  Vidalia 0.2.10 
 Keywords:  bridges  |         Parent:                 
   Points:           |   Actualpoints:                 
---------------------+------------------------------------------------------

Comment(by anonym):

 Replying to [comment:9 chiiph]:
 > Replying to [comment:8 anonym]:
 > > Replying to [comment:5 chiiph]:
 > > In Tails we use a system wide instance of Tor, and when a user choses
 "Bridge mode" at boot, we put "UseBridges 1" in torrc, but no configured
 bridges, so when Tor starts it gets in an idle state per the new
 behaviour. When Vidalia starts later on, the user can add bridges. S, we
 want Vidalia to be able to start in this idle state of Tor and *NOT* unset
 the bridge settings that Tor currently have (from torrc, i.e.
 UseBridges=1). It's unclear to me how your fix will work in this
 situation.
 >
 > You could set in vidalia.conf the following:
 > RunTorAtStart=false
 > UseBridges=true
 >
 > And that would give you an instance of Vidalia that doesn't try to
 connect to the network, and that has the checkbox activated with no
 bridges set. So the user can go to that part and put whatever bridges she
 wants, and then start tor.

 "Then start tor"? In the Tails scenario, Tor is already started as a
 system wide instance. We really do not want Vidalia to start/stop Tor in
 Tails for a number of reasons.

 If by "then start tor" you meant that Vidalia will feed the bridges to Tor
 so it can connect, ok. But what if the user instead opens the Vidalia
 settings and just presses save without adding a bridge? My understanding
 is that UseBridges will be set to 0. That's the part which seems risky to
 me.  It also seems inconsistent that the user cannot achieve those
 settings her/himself through by using vidalia's settings, but must hack
 them via vidalia.conf.

 In any case, to me it seems fragile that both torrc and vidalia.conf has
 to be configured in order to get what we want.

 > > The optimal solution from my perspective would be that Vidalia is
 allowed to set Tor in the idle state, but that it should prompt the user
 whenever this is discovered (i.e. when importing settings from Tor through
 the control port on a fresh start, when loading them from vidalia.conf and
 when the user creates the situation in the settings -- I think
 ConfigDialog::applyChanges() is called in all relevant cases). The prompt
 should include an explanation of the situation, and ask if the user wants
 to fix it (which opens the network settings) or if nothing should be done
 (Tor's idle state is kept).
 >
 > I'm not aware of how to start tor in an idle state, could you elaborate?

 With "idle state" I meant the state that occurs when Tor has UseBridges=1
 and no bridges configured. Per the new behaviour in Tor from #2355, Tor
 will not connect to anything, hence it "idles". Sorry if I was unclear.

 > With "creates the situation in the settings" you mean "disables
 bridges"?

 No. The user checks the "My ISP blocks..." box but do not add any bridges.
 That situation.

 > And say we have all those notifications, how does the user finds
 bridges?

 Since the network settings will be opened and the bridge part will be
 shown, there's the "How else can I find bridges" link to the relevant part
 of the help.

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