Adapt Vidalia UI to allow users to avoid connecting to the public tor network

We need a way to avoid touching the public network for both Tails and TBB users, in a way that doesn't clutter the Vidalia UI, scare users, and/or subject users to warning fatigue.

added bridges component::archived/vidalia owner::chiiph priority::high resolution::fixed status::closed type::defect version::vidalia 0.2.10 labels

Trac:
Summary: Adapt Vidalia w.r.t. bug #2355 (moved) to Adapt Vidalia UI to allow users to avoid connecting to the public tor network

Trac:
Parent: N/A to #3307 (closed)
Priority: normal to major

It is possible that we actually don't want this to be a bundle problem at all, and instead just want Vidalia to ask the user "Do you want to use Bridges or use the public Tor Network?" in some descriptive and understandable way before launching Tor regardless of the bundle status.

This way we can avoid adding an entire column to our build matrix (as #3307 (closed) would require).

Yeah, this totally needs to be a first-launch prompt dialog in Vidalia rather than a bundle. Users will inevitably download the wrong bundle and still put themselves in danger.

Trac:
Parent: #3307 (closed) to N/A
Type: enhancement to defect

So, this has been solved (or at least part of this) in #3354 (closed). I think that since this is going to a stable release, it shouldn't change the phrasing. The propoused fix from that other ticket adapts the "auto" part of this option to be as transparent to the user as it can be.

What I'm still not sure is if we should actually ask the user explicitly if he/she wants to use bridges. Do you guys think that the #3354 (closed) fix is enough for this?

Trac:
Milestone: N/A to Vidalia: 0.2.13

Personally I think we absolutely need to ask the user on first run before touching anything wrt the public network.

If we need to preserve existing translations, perhaps this means we are limited to throwing the existing "Network" configuration pane at them on first run before launching tor.

We could add some text in english above the already translated strings explaining that we need them to make a very important decision about how to connect to the Tor network before we attempt anything. Then the effect for non-english users would be some random english followed by three strings they will hopefully be able to understand.

We can then improve the phrasing for 0.3.0, but this is important enough that we need some form of user notification in 0.2.x before we just connect to the public network. We are literally risking people's lives otherwise.

I see your point, but say you have a totally unexperienced user, that wants to report some incident or whatever that may put her life in risk. So she hears about Tor, downloads TBB, opens Vidalia, and a popup shows up saying: "Do you want to use a bridge to access the network?" or "Is Tor banned on your country?" or something else more user friendly. I imagine this will confuse the user.

The problem here is that if the user doesn't know what to do, anything she does to find out more can be viewed as exactly the same as just trying to connect to the tor network directly, so it's kind of the chicken and egg thing here.

And even if there are cases where a user's life might be at risk because of a bad software policy, I wonder how many users don't fit that profile and end up really scared of using tor because they don't want to die.

Replying to chiiph:

Do you guys think that the #3354 (closed) 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 (closed). It seems like this makes it to easy for the user to unset the bridge settings by mistake and thus get revealed.

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.

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

Replying to anonym:

Replying to chiiph:

Do you guys think that the #3354 (closed) 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 (closed). 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?

Replying to chiiph:

Replying to anonym:

Replying to 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 (moved), 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.

Replying to anonym:

"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 tor started and Vidalia was attached to it, it isn't possible (from release 0.2.12 and on) to stop tor, so this is covered.

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.

Yes, that's what's going to happen.

That's the part which seems risky to me.

There's always so much you can do for the user. If you show them the dialog and how to use it, and they don't, well, it's their choice. Right now, the user gets notified about this particular situation, what we can do is make the notification (currently a warning), be a question like: "You haven't added any bridges, if you hit Yes here you will be disabling the use of bridges. Is that what you really want to do?" Yes|No. How does that sound?

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.

To produce the situation where UseBridge=1 with no bridges, yes, the user must "hack" that by editing vidalia.conf, because we don't want the user to be able to produce that situation. And in this case, it's something that you will allow in TAILS and the user doesn't need to edit anything.

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.

Yes, it's something that needs a lot of fixing, there are settings that are kept only in vidalia.conf, and other only in torrc, and some in both.

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 (moved), Tor will not connect to anything, hence it "idles". Sorry if I was unclear.

Yeah, when I hit "Submit" I thought about that state. But thanks for clarifying.

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.

Yes, but what I meant was: the user will need to access some content online in some form (twitter, mail, hit the find bridges button, etc). And that access will be either done through "regular" tor, or by a clean navigation. Either way, if the user is inside a country where using tor is something that risks your life, I don't see any good way of avoiding ringing any bells. On the other hand, if the user has a friend, and he/she gaves the user the bridge, it will be pretty clear that she doesn't have to click "Ok" in the settings panel without adding it first. The problem with anonymity is that the user at some point needs to understand what do to. Otherwise we might aswell consider as risky the situation where the user disables TorButton and clicks on a link in another app that uses Firefox to open it. Anyway, I think I've gotten derailed here :) but what I mean is that we have to find a middle point, no solution will be perfect. Or may be I'm really wrong.

Replying to chiiph:

Anyway, I think I've gotten derailed here :) but what I mean is that we have to find a middle point, no solution will be perfect.

I think you're right. Let's start anew and let me put it this way instead. What's the problem of having the following behaviour instead:

If "My ISP blocks..." is checked but no bridges are configured, then set UseBridges=1 and let Tor be unable to connect. The current prompt you added is changed to a yes/no-prompt that says:

Tor is currently configured to only allow connections through bridges, but no bridges are configured. With this configuration 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?

W.r.t. buttons, "yes" opens the bridge settings, "no" does nothing, so Tor remains unable to connect.

The only problem I can think of is with backwards compatibility: a user that checked the "My ISP blocks..." box without adding any bridge in a previous vidalia version would suddenly have a non-working Tor thanks to the stuff in vidalia.conf that worked previously. Because of this it may be better to show the prompt whenever settings are applied (i.e. ConfigDialog::applyChanges()) since that would show it in all these cases:

• when the user presses save in the settings
• when vidalia imports settings from a running Tor instance
• when loading vidalia.conf (which would give a pointer to the user experiencing this backwards compatibility problem)

That sounds like a good option.

I'd like input from other people too nontheless, since it's a delicate issue.

Replying to chiiph:

I see your point, but say you have a totally unexperienced user, that wants to report some incident or whatever that may put her life in risk. So she hears about Tor, downloads TBB, opens Vidalia, and a popup shows up saying: "Do you want to use a bridge to access the network?" or "Is Tor banned on your country?" or something else more user friendly. I imagine this will confuse the user.

The problem here is that if the user doesn't know what to do, anything she does to find out more can be viewed as exactly the same as just trying to connect to the tor network directly, so it's kind of the chicken and egg thing here.

And even if there are cases where a user's life might be at risk because of a bad software policy, I wonder how many users don't fit that profile and end up really scared of using tor because they don't want to die.

We don't have to scare the user. We only need to inform them and give them an opportunity to avoid connecting directly to the public network. Going back to the TBB use case, at first run, the dialog could be:

"Before Tor attempts to connect, we need to know some information about your Internet connection. Do any of the options below apply to you? If so, check those options for further configuration. If not, just click OK.

[Insert current Vidalia Network config page here]"

This message is not about terrifying the user. It is about simply giving them the opportunity to avoid directly connecting to the Tor network. Right now our TBB users have no way to do this, even if they have been properly trained to use bridges for safety/censorship resistance.

Incidentally, the Vidalia help system has plenty of already translated information on the network settings and bridges, and there is already a hyperlink to the bridge settings section. We can also provide a hyperlink to the entire Network Settings help section to some words in the dialog. For example "the options below" or "further configuration" are good choices for another hyperlink.

Trying to merge both ideas, we could do something like this:

if it's the first time you execute Vidalia:
   show network config dialog with a label that says something like what mikeperry said
elif if usebridges is configured but there are no bridges:
   show network config dialog with a label asking the user to either add bridges, or just disable them
else:
   start vidalia as usual, and if the user checks "My ISP blocks..." but doesn't add bridges, just ignore this with a warning.

Replying to chiiph:

Trying to merge both ideas, we could do something like this:

{{{ if it's the first time you execute Vidalia: show network config dialog with a label that says something like what mikeperry said elif if usebridges is configured but there are no bridges: show network config dialog with a label asking the user to either add bridges, or just disable them else: start vidalia as usual, and if the user checks "My ISP blocks..." but doesn't add bridges, just ignore this with a warning. }}} Is there any reason for why you want to stick with the stuff in the "else:" part (i.e. "if the user checks 'My ISP blocks...' but doesn't add bridges, just ignore this with a warning")? What that suggests is precisely going back to the old behaviour you described in #3354 (closed), which I feel is very confusing and unintuitive. Why should an option that is set when you open the Vidalia settings suddenly revert when pressing Ok even though you haven't touched itm or any related options?

My [comment:12 suggestion] captures both the case when you start Vidalia and when you reconfigure Vidalia in the settings since both of these call ConfigDialog::applyChanges(). My suggestion

• wouldn't add any more complexity to code -- in fact the code would be put in the same place (ConfigDialog::applyChanges()) instead of two places (one for startup, one for when saving settings).
• has only one prompt dealing with this instead of two, which is more consistent for the user.
• does not confuse the user as I think #3354 (closed)'s behaviour does.

Replying to anonym:

Is there any reason for why you want to stick with the stuff in the "else:" part (i.e. "if the user checks 'My ISP blocks...' but doesn't add bridges, just ignore this with a warning")? What that suggests is precisely going back to the old behaviour you described in #3354 (closed), which I feel is very confusing and unintuitive. Why should an option that is set when you open the Vidalia settings suddenly revert when pressing Ok even though you haven't touched itm or any related options?

Right now it warns about the fact that it's disabling the setting, and it can just as easily ask if that's what the user intended to do. I want to keep that behavior because the whole situation where tor "just doesn't work" because there aren't any bridges configured and UseBridges=1 is the non-intuitive behavior to me. I want to avoid making it easy for a user to be in that situation.

My [comment:12 suggestion] captures both the case when you start Vidalia and when you reconfigure Vidalia in the settings since both of these call ConfigDialog::applyChanges(). My suggestion

• wouldn't add any more complexity to code -- in fact the code would be put in the same place (ConfigDialog::applyChanges()) instead of two places (one for startup, one for when saving settings).

This is not about the amount of coding needed.

• has only one prompt dealing with this instead of two, which is more consistent for the user.

It'd need two, one when Vidalia starts and notices the situation, and another when the user opens the settings, click "My ISP blocks..." and doesn't put any bridges in.

• does not confuse the user as I think #3354 (closed)'s behaviour does.

I just don't want the unaware user that clicked wrongly in the settings end up with a non-working tor.

I do think the two prompts idea is a good one. It will be important to keep both consistent (if we ask the user at first launch "are you afraid someone might realize you're connecting to tor" and then later don't explain that same concept in the network options, then that's not very useful).

But then I'm also afraid of making too strong a promise about "they won't figure out you're using tor". Tracking public bridges is not hard atm, so it is not hard to learn who is connecting to tor using a public bridge.