Opened 8 years ago

Closed 7 years ago

#2905 closed defect (fixed)

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

Reported by: anonym Owned by: chiiph
Priority: High Milestone:
Component: Archived/Vidalia Version: Vidalia 0.2.10
Severity: Keywords: bridges
Cc: amnesia@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by mikeperry)

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.

Child Tickets

Attachments (1)

xxx-no-public-network.txt (3.6 KB) - added by mikeperry 8 years ago.
The solution!11

Download all attachments as: .zip

Change History (35)

comment:1 Changed 8 years ago by mikeperry

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

comment:2 Changed 8 years ago by mikeperry

Parent ID: #3307
Priority: normalmajor

comment:3 Changed 8 years ago by mikeperry

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

comment:4 Changed 8 years ago by mikeperry

Parent ID: #3307
Type: enhancementdefect

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.

comment:5 Changed 8 years ago by chiiph

Milestone: Vidalia: 0.2.13

So, this has been solved (or at least part of this) in #3354. 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 fix is enough for this?

comment:6 Changed 8 years ago by mikeperry

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.

comment:7 Changed 8 years ago by 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.

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

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

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

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

Replying to anonym:

Replying to 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?

comment:10 in reply to:  9 ; Changed 8 years ago by anonym

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

comment:11 in reply to:  10 ; Changed 8 years ago by chiiph

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

comment:12 in reply to:  11 Changed 8 years ago by anonym

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)

comment:13 Changed 8 years ago by chiiph

That sounds like a good option.

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

comment:14 in reply to:  7 Changed 8 years ago by mikeperry

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.

comment:15 Changed 8 years ago by mikeperry

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.

comment:16 Changed 8 years ago by 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.

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

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, 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 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's behaviour does.

comment:18 in reply to:  17 ; Changed 8 years ago by chiiph

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, 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 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's behaviour does.

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

comment:19 Changed 8 years ago by Sebastian

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.

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

Replying to chiiph:

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

Sure. All I want is that the prompt does not force the 'My ISP blocks...' option off no matter what. If it asks whether the user want to revisit the bridge settings to add bridges, or disable the option so Tor can start working without bridges, that's fine.

comment:21 Changed 8 years ago by mikeperry

Ok, after some discussion on IRC, I think we have a consensus. Both TAILS and TBB will share a first-run dialog that reads something like:

"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 pane here]"

The text should have hyperlinks to the Vidalia network config help text.

The Network Config pane should have some additional logic that prevents the user from leaving the pane or clicking OK if the "My ISP blocks..." checkbox is checked, but the user has not entered any bridges. In this case, it should present a popup like:

"You have told us that your ISP blocks the Tor network, but you have not entered any bridges. If your ISP does in fact block the Tor network, you must find some Tor Bridges and enter them into the Bridge Settings box to circumvent this block. If your ISP does not block the Tor network (and you do not need bridges), you must uncheck that checkbox before proceeding."

This text should have hyperlinks to the "Obtaining Bridges" section of the Vidalia help.

This logic should always apply to the network config pane, regardless of first-run or if the user is just navigating to it.

How to govern the display of the first-run network config pane is a different matter. It is likely that we want to default to displaying the first-run dialog until vidalia has saved a conf file with "FirstRun off" or something similar. This way, we can handle the backwards compatibility issues by displaying the first-run dialog to both new users and upgrade users.

comment:22 Changed 8 years ago by chiiph

I'm implementing this in my branch chiiph/bug2905_firstrun, but it needs some kind of suspended state to actually work.

I'm not entirely sure we want upgrade users to see a first-run dialog. What would be the benefit? If we stay with the tri-state UseBridges that will lead them to get out of the inconsistent state, was that what you intended to be?

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

Replying to chiiph:

I'm implementing this in my branch chiiph/bug2905_firstrun, but it needs some kind of suspended state to actually work.

I'm not entirely sure we want upgrade users to see a first-run dialog. What would be the benefit? If we stay with the tri-state UseBridges that will lead them to get out of the inconsistent state, was that what you intended to be?

Yes, it was to provide the opportunity to resolve inconsistencies.

However, even with a suspended mode, I suspect there may be some upgrade users with UseBridges set to 1 without any bridges entered. I actually did this the first few times I attempted to test bridges because I didn't know to click the + sign after putting the bridge in the edit box. It looks like the Vidalia UI now unsets the pref if I do this, but was this always the case?

comment:24 in reply to:  23 ; Changed 8 years ago by chiiph

Replying to mikeperry:

Replying to chiiph:

I'm implementing this in my branch chiiph/bug2905_firstrun, but it needs some kind of suspended state to actually work.

I'm not entirely sure we want upgrade users to see a first-run dialog. What would be the benefit? If we stay with the tri-state UseBridges that will lead them to get out of the inconsistent state, was that what you intended to be?

Yes, it was to provide the opportunity to resolve inconsistencies.

Ok.

However, even with a suspended mode, I suspect there may be some upgrade users with UseBridges set to 1 without any bridges entered. I actually did this the first few times I attempted to test bridges because I didn't know to click the + sign after putting the bridge in the edit box.

Sure, but if Tor ignores the UseBridges=1 and no bridges case, then it isn't a problem.

It looks like the Vidalia UI now unsets the pref if I do this, but was this always the case?

Depends on what you mean by "now". I think that current Vidalias (0.2.12 and 0.3.0) set it to 1 regardless of the amount of bridges.
I agree it isn't the most consistent thing to have UseBridges 1 and no bridges and Tor running like nothing happened.

comment:25 in reply to:  24 ; Changed 8 years ago by mikeperry

Replying to chiiph:

Replying to mikeperry:

However, even with a suspended mode, I suspect there may be some upgrade users with UseBridges set to 1 without any bridges entered. I actually did this the first few times I attempted to test bridges because I didn't know to click the + sign after putting the bridge in the edit box.

Sure, but if Tor ignores the UseBridges=1 and no bridges case, then it isn't a problem.

It looks like the Vidalia UI now unsets the pref if I do this, but was this always the case?

Depends on what you mean by "now". I think that current Vidalias (0.2.12 and 0.3.0) set it to 1 regardless of the amount of bridges.
I agree it isn't the most consistent thing to have UseBridges 1 and no bridges and Tor running like nothing happened.

Hrmm. I think this is enough of a reason to warrant doing the first-run dialog for upgrade users too.. Or at least for upgrade users with this weird option combo. They made a mistake somewhere in their config due to confusing UI and they think they are getting a security property they really aren't. This is bad. We should fix that situation.

comment:26 in reply to:  25 Changed 8 years ago by chiiph

Replying to mikeperry:

Hrmm. I think this is enough of a reason to warrant doing the first-run dialog for upgrade users too.. Or at least for upgrade users with this weird option combo. They made a mistake somewhere in their config due to confusing UI and they think they are getting a security property they really aren't. This is bad. We should fix that situation.

So may be leaving the users with a new Tor that suddenly just doesn't work, because they checked the usebridges box but didn't added any, is a good way of saying "update your Vidalia too".

I guess if we consider this a security issue, we can ignore backward compatibility.

comment:27 in reply to:  24 ; Changed 8 years ago by anonym

Replying to chiiph:

I agree it isn't the most consistent thing to have UseBridges 1 and no bridges and Tor running like nothing happened.

There's actually a very valid reason for users of Vidalia to set this. Let me quote the Vidalia network settings help:

My ISP blocks connections to the Tor network: [...] Even if you do not know any bridge relay addresses, checking this checkbox may still be helpful. Tor will encrypt its directory requests [...]

Sure, it is only relevant for clients using Tor <0.2.0.22-rc, since TunnelDirConns and PreferTunneledDirConns are set to 1 by default from that Tor version and on. But for users who actually read the help I would expect some of them to set "My ISP blocks..." but add no bridges.

comment:28 in reply to:  27 Changed 8 years ago by arma

Replying to anonym:

There's actually a very valid reason for users of Vidalia to set this. Let me quote the Vidalia network settings help:

My ISP blocks connections to the Tor network: [...] Even if you do not know any bridge relay addresses, checking this checkbox may still be helpful. Tor will encrypt its directory requests [...]

Sure, it is only relevant for clients using Tor <0.2.0.22-rc, since TunnelDirConns and PreferTunneledDirConns are set to 1 by default from that Tor version and on. But for users who actually read the help I would expect some of them to set "My ISP blocks..." but add no bridges.

Somebody should fix the Vidalia help text to stop mentioning the tunnel dir conn stuff. It's been on-by-default in Tor for years, and now will just confuse users.

comment:29 Changed 8 years ago by chiiph

Milestone: Vidalia: 0.2.13

comment:30 Changed 8 years ago by mikeperry

Description: modified (diff)

Ok! We have a solution. I will attach the outline that is the result of a discussion between Nick, chiiph, anonym. I believe everyone is on board with this plan, finally.

See #4290 for a related Vidalia UI issue that caused some snags in the discussion of this feature.

Changed 8 years ago by mikeperry

Attachment: xxx-no-public-network.txt added

The solution!11

comment:31 Changed 7 years ago by intrigeri

Did anyone start implementing this solution?

comment:32 Changed 7 years ago by chiiph

I've just implemented a wizard to handle these cases according to the document. The code is in my branch chiiph/bug2905_disablenetwork, it's against alpha. In this case, UseBridges=1 is not valid anymore, so just setting DisableNetwork=1 triggers the wizard in the first run.

Do we want this on stable too? (the alpha branch is planned to go stable in the next couple of months).

comment:33 in reply to:  32 Changed 7 years ago by intrigeri

Replying to chiiph:

I've just implemented a wizard to handle these cases according to the document. The code is in my branch chiiph/bug2905_disablenetwork, it's against alpha. In this case, UseBridges=1 is not valid anymore, so just setting DisableNetwork=1 triggers the wizard in the first run.

Great, thanks! I guess anonym will want to try it soon.

Do we want this on stable too? (the alpha branch is planned to go stable in the next couple of months).

As far as Tails is concerned, as long as 0.4 is out before Debian Wheezy is frozen (that is, before June), then we don't need it in the 0.2 branch.

Given our release schedule and relationship with Debian, I think it's much more important for us to see 0.4 released in time for Wheezy, than to get a 0.2.x release with this feature in.

comment:34 Changed 7 years ago by chiiph

Resolution: fixed
Status: newclosed

Great then, sounds like a plan.

This has been merged agains alpha, and will be out with 0.3.2.

Note: See TracTickets for help on using tickets.