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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Sun Jun 12 16:14:03 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:  Vidalia: 0.2.13
Component:  Vidalia  |        Version:  Vidalia 0.2.10 
 Keywords:  bridges  |         Parent:                 
   Points:           |   Actualpoints:                 
---------------------+------------------------------------------------------

Comment(by chiiph):

 Replying to [comment:8 anonym]:
 > Replying to [comment:5 chiiph]:
 > > Do you guys think that the #3354 fix is enough for this?
 >
 > I haven't tried your fix yet, but I don't think so. The potential
 problem lies in the "If checked and no bridges added, then uncheck it and
 explain it to the user" part of the new behaviour described in #3354. It
 seems like this makes it to easy for the user to unset the bridge settings
 by mistake and thus get revealed.

 If the user unchecks the option it should be because she doesn't want to
 use bridges. And I don't think it is as easy, you need to find the place
 where to click wrong.

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

 >
 > 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 "creates the situation in the settings" you mean "disables bridges"?
 And say we have all those notifications, how does the user finds bridges?

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


More information about the tor-bugs mailing list