Opened 8 years ago

Closed 8 years ago

#3354 closed defect (fixed)

tor's auto bridge default and unintended Vidalia side effects

Reported by: erinn Owned by: chiiph
Priority: Medium Milestone: Vidalia: 0.2.13
Component: Archived/Vidalia Version: Vidalia: 0.2.12
Severity: Keywords:
Cc: nickm, anonym Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Tor has this change as of 0.2.2.28-beta:

  • If "UseBridges 1" is set and no bridges are configured, Tor will now refuse to build any circuits until some bridges are set. If "UseBridges auto" is set, Tor will use bridges if they are configured and we are not running as a server, but otherwise will make circuits as usual. The new default is "auto". Patch by anonym, so the Tails LiveCD can stop automatically revealing you as a Tor user on startup.

What this means for Vidalia is that "My ISP blocks connection to the Tor network" is already checked, and bridges will be used by default, which is possibly not a desirable thing for people who have a list of them but do not want to use them for whatever reason.

I played with this a little bit, and it seems like you can merely uncheck the ticky box and have no problems (i.e., your list of bridges remains and you don't need to clear them out, and Vidalia correctly saves the configuration after exiting and restarting), but I think there should be some discussion about how to handle this in Vidalia since Tor just got a little too smart for it. I personally do not feel comfortable shipping Vidalia bundles with this current setup, though I think right now it's okay for TBB, since it has its own torrc & vidalia.conf that users haven't edited.

Child Tickets

Change History (26)

comment:1 Changed 8 years ago by chiiph

For a moment I thought "ok, lets do it like Tor does now", but having an "auto" option will be confusing.

What we could do, as the default in Vidalia, is to don't save the changes to bridges unless the user adds at least one (I think it was katmagic that suggested this). Besides the default, everything else seems to be working as expected, right?

comment:2 Changed 8 years ago by erinn

What do you mean by 'don't save the changes to bridges'? I don't think I understand this idea correctly, could you elaborate?

Everything else works as expected though, yes.

comment:3 Changed 8 years ago by Sebastian

This is a problematic change, in that it has several unintended side effects: If you had bridges configured previously and unticked the checkbox, you'd stop using them for now but keep them saved in your torrc for later use so you didn't have to re-enter them. That's a very useful feature, because it means you can test if bridges aren't required anymore and if they are go back to all the ones you had configured.

The other worry is that for all users who don't configure bridges, the "my isp censors..." option is checked so they will *think* they're using bridges, even tho they didn't configure any. This is bad for people who want to make sure they're using a bridge.

This is a tricky issue, because once again we added an option transition path that breaks users who upgrade. I'm not yet quite sure what we can do to not screw anyone who was using Tor before with bridges configured, but the box unchecked. hrm. We should probably solve this bug before shipping new bundles.

comment:4 Changed 8 years ago by erinn

Priority: majorblocker

Changing this to blocker until I'm confident it is safe to ship as-is or there is a patch that fixes it.

comment:5 in reply to:  2 Changed 8 years ago by chiiph

Replying to erinn:

What do you mean by 'don't save the changes to bridges'? I don't think I understand this idea correctly, could you elaborate?

Say you have a Vidalia+Tor configured without any bridges. You open the settings, check the box for bridges, but you don't add any. Then hit "save", and since you haven't added any bridges, the next time open the settings dialog, you won't see the bridges box checked.

comment:6 in reply to:  3 ; Changed 8 years ago by chiiph

Replying to Sebastian:

This is a problematic change, in that it has several unintended side effects: If you had bridges configured previously and unticked the checkbox, you'd stop using them for now but keep them saved in your torrc for later use so you didn't have to re-enter them. That's a very useful feature, because it means you can test if bridges aren't required anymore and if they are go back to all the ones you had configured.

So, that behavior isn't possible with this new feature in tor?

The other worry is that for all users who don't configure bridges, the "my isp censors..." option is checked so they will *think* they're using bridges, even tho they didn't configure any. This is bad for people who want to make sure they're using a bridge.

If the user checks the option, and doesn't add any bridges, Vidalia could warn with something like: "You haven't added any bridges. This change will be reverted." or something like that.

comment:7 in reply to:  6 ; Changed 8 years ago by rransom

Replying to chiiph:

Replying to Sebastian:

This is a problematic change, in that it has several unintended side effects: If you had bridges configured previously and unticked the checkbox, you'd stop using them for now but keep them saved in your torrc for later use so you didn't have to re-enter them. That's a very useful feature, because it means you can test if bridges aren't required anymore and if they are go back to all the ones you had configured.

So, that behavior isn't possible with this new feature in tor?

Yes it is. Simply set ‘UseBridges 0’, and all ‘Bridge’ lines will be ignored.

The other worry is that for all users who don't configure bridges, the "my isp censors..." option is checked so they will *think* they're using bridges, even tho they didn't configure any. This is bad for people who want to make sure they're using a bridge.

If the user checks the option, and doesn't add any bridges, Vidalia could warn with something like: "You haven't added any bridges. This change will be reverted." or something like that.

My understanding is that once upon a time, ‘My ISP blocks connections to the Tor network’ did something other than simply allow the user to specify bridges (‘TunnelDirConns 1’?). If it still has other effects, we should add a separate tri-state checkbox that only controls ‘UseBridges’, with a hint/tooltip/whatever Qt calls the box that pops up when the mouse is pointed at a control; if ‘My ISP blocks connections to the Tor network’ has no effects other than setting ‘UseBridges 1’, it should become a tri-state checkbox, with the ‘Bridge Settings’ panel visible when it is set to ‘auto’ or ‘1’, and with a note shown when it is set to ‘auto’ and no bridges are specified indicating that because the user has not specified any bridges, Tor will not use bridges.

comment:8 in reply to:  7 Changed 8 years ago by chiiph

Replying to rransom:

Replying to chiiph:

Replying to Sebastian:

This is a problematic change, in that it has several unintended side effects: If you had bridges configured previously and unticked the checkbox, you'd stop using them for now but keep them saved in your torrc for later use so you didn't have to re-enter them. That's a very useful feature, because it means you can test if bridges aren't required anymore and if they are go back to all the ones you had configured.

So, that behavior isn't possible with this new feature in tor?

Yes it is. Simply set ‘UseBridges 0’, and all ‘Bridge’ lines will be ignored.

Ok, then I should force UseBridges 0 when the checkbox isn't checked.

The other worry is that for all users who don't configure bridges, the "my isp censors..." option is checked so they will *think* they're using bridges, even tho they didn't configure any. This is bad for people who want to make sure they're using a bridge.

If the user checks the option, and doesn't add any bridges, Vidalia could warn with something like: "You haven't added any bridges. This change will be reverted." or something like that.

My understanding is that once upon a time, ‘My ISP blocks connections to the Tor network’ did something other than simply allow the user to specify bridges (‘TunnelDirConns 1’?). If it still has other effects, we should add a separate tri-state checkbox that only controls ‘UseBridges’, with a hint/tooltip/whatever Qt calls the box that pops up when the mouse is pointed at a control; if ‘My ISP blocks connections to the Tor network’ has no effects other than setting ‘UseBridges 1’, it should become a tri-state checkbox, with the ‘Bridge Settings’ panel visible when it is set to ‘auto’ or ‘1’, and with a note shown when it is set to ‘auto’ and no bridges are specified indicating that because the user has not specified any bridges, Tor will not use bridges.

I don't think a tri-state checkbox is going to make any sense for the user. I'd rather handle it behind the scenes.

Ok, so I think that the "auto" part should be hidden by the GUI.
Here's the workflow as I see it:

  • If unchecked, then assure "UseBridges 0"
  • If checked and no bridges added, then uncheck it and explain it to the user.
  • If checked and bridges added, then "UseBridges 1" with those bridges.

If noone finds anything really wrong with this, I'll make a patch.

comment:9 Changed 8 years ago by chiiph

Status: newneeds_review

A possible fix for this is in my branch chiiph/bug3354_usebridge.

Here are the commitdiffs:
https://gitweb.torproject.org/chiiph/vidalia.git/commitdiff/3c363a76097b7e088e75fd5f7429f65f8e2a247f
https://gitweb.torproject.org/chiiph/vidalia.git/commitdiff/e42e3de387bee74208da3cd37ada9dd061c54866

I've tested this with 0.2.28-beta, and 0.2.3.1-alpha, and it seems to work as expected. But it would be great if another pair of eyes checks this.

comment:10 Changed 8 years ago by chiiph

Milestone: Vidalia: 0.2.13

comment:11 Changed 8 years ago by erinn

Okay, I was able to test this and it works as intended. However, if check the "My ISP blocks [...]" and try to save it without setting any bridges, it says that the box will be unchecked and immediately exits settings altogether. My suggestion is to have it return back to the checkbox UI and give people a chance to actually add bridges, or uncheck the checkbox but still put them back in the UI.

comment:12 Changed 8 years ago by chiiph

In my branch chiiph/bug3354_usebridge I've just added the question.

It works exactly like before, except now you can go back to set up bridges if you forgot to.

Here's the commitdiff:
https://gitweb.torproject.org/chiiph/vidalia.git/commitdiff/0bb7e76236d9a1310ba4ad64a3d6a6feea73f981

comment:13 Changed 8 years ago by erinn

Okay, this is better, but we're not quite there yet.

  1. The wording is extremely confusing. When you check "My ISP blocks [...]" and try to save it without adding any bridges, a pop-up comes up saying: You haven't added any bridges, this will disable "My ISP blocks connections to the Tor network." Do you really want to do this? Yes / No

I'm not entirely sure what this means. Does the user really have an option here? If not, why provide them the option of saying "Yes"? Should they have the option to save this setting without configuring any bridges? If not, the pop-up should say something like (and I recommend not taking this verbatim): You haven't added any bridges so this setting will not be saved. Then return them to the UI, with the box unchecked.

I am no UI expert, obviously, so I would appreciate if someone else could offer advice about this!

  1. If you say "Yes" to the above question, it kicks you out of the settings entirely. If it's agreed that this should be a yes/no question, saying "Yes" should return you to the settings UI just like "No" does.

comment:14 Changed 8 years ago by erinn

For OSX users, there is a test bundle here:
http://erinn.org/~e/vidalia-bundle-0.2.2.28-beta-0.2.13-git-i386.dmg

sha256sum: 26fd02d9910bb3678180170f0f41a35dc0359ac56bc562aaf50cce24adb1e226

comment:15 in reply to:  13 Changed 8 years ago by chiiph

Replying to erinn:

Okay, this is better, but we're not quite there yet.

  1. The wording is extremely confusing. When you check "My ISP blocks [...]" and try to save it without adding any bridges, a pop-up comes up saying: You haven't added any bridges, this will disable "My ISP blocks connections to the Tor network." Do you really want to do this? Yes / No

I'm not entirely sure what this means. Does the user really have an option here? If not, why provide them the option of saying "Yes"? Should they have the option to save this setting without configuring any bridges? If not, the pop-up should say something like (and I recommend not taking this verbatim): You haven't added any bridges so this setting will not be saved. Then return them to the UI, with the box unchecked.

Ok, we can say this:

You haven't added any bridges. Do you want to add one?
WARNING: If you click "No" the option "My ISP blocks..." will be disabled
Yes|No

Yes: displays the settings.
No: disables "My ISP ..." and saves everything.

I am no UI expert, obviously, so I would appreciate if someone else could offer advice about this!

  1. If you say "Yes" to the above question, it kicks you out of the settings entirely. If it's agreed that this should be a yes/no question, saying "Yes" should return you to the settings UI just like "No" does.

It's a matter of how the question was phrased. But I agree that for the rushed user that just clicks without reading it will be a safer option to make "Yes" return to the settings panel.

comment:16 Changed 8 years ago by arma

Cc: nickm anonym added

Some thoughts:

A) I wonder if there are Vidalia users out there who won't be upgrading their Vidalia when they move to the new Tor. E.g. don't some Ubuntus ship a Vidalia? In that case if they have listed bridges but not checked the box, the box will be surprisingly checked for them.

B) I wonder if we should resolve this issue by backing the "feature" out of Tor, rather than by hacking around it in Vidalia. We sure didn't see this compatibility coming when we merged the feature. Also, if I want to tell Tor not to connect to the network until I do a setconf, the intuitive way to do that is not to setconf usebridges=1 while leaving bridges empty.

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?

comment:17 in reply to:  13 Changed 8 years ago by arma

Replying to erinn:

Okay, this is better, but we're not quite there yet.

  1. The wording is extremely confusing. When you check "My ISP blocks [...]" and try to save it without adding any bridges, a pop-up comes up saying: You haven't added any bridges, this will disable "My ISP blocks connections to the Tor network." Do you really want to do this? Yes / No

I'm not entirely sure what this means. Does the user really have an option here? If not, why provide them the option of saying "Yes"? Should they have the option to save this setting without configuring any bridges? If not, the pop-up should say something like (and I recommend not taking this verbatim): You haven't added any bridges so this setting will not be saved. Then return them to the UI, with the box unchecked.

Right -- I don't see any reason to allow the user to click usebridges to 1 while not setting any bridges. This was intended to be a hack that packagers can use to make Tor not touch the network until the rest of the package is ready to use it. There isn't really any need to expose the innards of that hack to the actual users by letting them enable the hack themselves.

(Speaking of which, I was kind of partial to mikeperry's idea which is a popup question the first time you use Vidalia that asks if you want to configure any bridges before you start Tor. I think that's discussed in a different trac entry.)

As another UI note, if the user clicks on "no I didn't really mean to click usebridges without setting bridges", and then saves, the user is left in an ambiguous state: did the other settings she changed before clicking save take effect or not?

comment:18 in reply to:  16 Changed 8 years ago by arma

Replying to arma:

B) I wonder if we should resolve this issue by backing the "feature" out of Tor

[...]

I don't actually remember how [Tails] intended to deploy their hack.

I'm imagining a config option like DontTouchNetwork=1 that you can stick on the commandline when you launch Tor. Then later you can turn it off when everything is configured as desired.

The benefit there is that you, the packager, can make sure that the config option only gets set when Tor is bundled with other components that know how to do the hack you're doing.

The way we've set it up now, people upgrading from a certain combination of components and configs automatically enable the hack. That's not nice.

comment:19 in reply to:  16 ; Changed 8 years ago by anonym

[sorry for the long post, but at this point I really want to be clear and avoid further misunderstandings...]

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

comment:20 in reply to:  19 ; Changed 8 years ago by arma

Replying to anonym:

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:

I think the problem here stems from the fact that we silently changed behavior for Tor users who have Bridges set but don't have UseBridges set. In the past they wouldn't use the bridges when Tor starts; now they do. It doesn't have anything to do with the proposed Vidalia changes (which sound plausible).

So the reason I was calling it a hack is that in retrospect changing usebridges to a tristate was probably not the right way to achieve the goals you have in mind. I am increasingly thinking we should take out that patch and put out a new Tor 0.2.2, so we don't change behavior for users. At the same time we should ponder how to accomplish the goals you have in mind.

comment:21 in reply to:  20 Changed 8 years ago by anonym

Replying to arma:

I think the problem here stems from the fact that we silently changed behavior for Tor users who have Bridges set but don't have UseBridges set. In the past they wouldn't use the bridges when Tor starts; now they do.

If that's the only real issue, the obvious one-line fix would be to revert back UseBridges=0 as the default value. The rest of the recent changes to UseBridges behaviour could stay without breaking backwards compatibility.

So the reason I was calling it a hack is that in retrospect changing usebridges to a tristate was probably not the right way to achieve the goals you have in mind.

Sure. As you can see #2355, I wasn't the original proponent of the tristate behaviour. All I want is something like AllowTorToWaitForBridgesWithoutConnectingToThePublicTorNetwork, and that it will be cleanly supported in the Vidalia context too.

I am increasingly thinking we should take out that patch and put out a new Tor 0.2.2, so we don't change behavior for users. At the same time we should ponder how to accomplish the goals you have in mind.

I'm not in a rush, and was actually expecting this to hit Tor 0.2.3, so that's fine with me if my above suggestion isn't good enough.

comment:22 Changed 8 years ago by phobos

We should revert the 0.2.2.x change, and release a 0.2.2.29-beta so we can get packages out and keep 0.2.2.x on track for a stable release sometime this decade.

If this problem wasn't affecting TBB, we should release 0.2.2.28-beta TBB's to get this version of tor some more testing.

We can then continue to argue over tri-state or not for 0.2.3.x branch releases.

comment:23 in reply to:  22 Changed 8 years ago by anonym

Replying to phobos:

We can then continue to argue over tri-state or not for 0.2.3.x branch releases.

I don't particularly care for UseBridges being a tri-state, that was nickm's suggestion since he and Sebastian agreed that the old UseBridges option was of questionable value. Tails just needs something that makes Tor not connecting to the public Tor network while waiting for bridges to be configured through Vidalia. If that's done with a new option instead of UseBridges (which was what I originally asked for) that would solve everything.

comment:24 Changed 8 years ago by nickm

See ticket #3419 for a change to tor to revert the UseBridges behavior.

comment:25 Changed 8 years ago by arma

Priority: blockernormal

Ok to close?

I think this issue is moot now that the Tor behavior is reverted.

#3420 remains, but that's different from this bug.

comment:26 Changed 8 years ago by chiiph

Resolution: fixed
Status: needs_reviewclosed

Yes, closing.

Note: See TracTickets for help on using tickets.