Make a "Use Default Bridges" Radio button in the Tor Launcher Bridge UI

Tor Launcher should include a radiobutton to use a set of bridges that it pulls from prefs that we can include from extension-overrides.js.

We should set these bridge lines to a set of default PT bridges that will work in most places out of the box.

added MikePerry201402R component::applications/tor launcher owner::brade priority::high resolution::fixed status::closed type::enhancement labels

The list of default bridges that were included in the 2.x pluggable transports bundles is here: https://gitweb.torproject.org/pluggable-transports/bundle.git/blob/HEAD:/bundle-torrc-gnulinux.

The funny address 0.0.1.0:1 in the line

Bridge flashproxy 0.0.1.0:1

is a dummy address that is ignored by the plugin. The address can be anything; the important part is the Bridge flashproxy part.

Trac:
Cc: dcf1 to dcf1, mcs

I don't think it will be too difficult to add radio buttons to allow use of a default set of bridges. Will the other non-bridge configuration options be pre-configured in torrc-defaults? Or will Tor Launcher need to configure other parameters?

Replying to brade:

I don't think it will be too difficult to add radio buttons to allow use of a default set of bridges. Will the other non-bridge configuration options be pre-configured in torrc-defaults? Or will Tor Launcher need to configure other parameters?

From my point of view, it would be great for the button to effectively uncomment the commented lines in https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/blob/901eab38b929ba1f3784437f2a16ca94aa7fc22e:/Bundle-Data/linux/Data/Tor/torrc-defaults. That is, the Bridge lines, LearnCircuitBuildTimeout, and CircuitBuildTimeout. We already have the ClientTransportPlugin lines uncommented because we have a patch for #5018 (moved).

If you want to separate the transports, separate buttons for obfs2/obfs3 and flash proxy, then for obfs2/obfs3 you just need to turn on the Bridge obfs2 and Bridge obfs3 lines. For flash proxy, you want the single Bridge flashproxy 0.0.1.0:1 line as well as LearnCircuitBuildTimeout 0 and CircuitBuildTimeout 60.

LearnCircuitBuildTimeout and CircuitBuildTimeout need some explanation. Without these settings, a flash proxy bridge will fail almost exactly 20% of the time--Tor will refuse to use it, even if it is the only bridge configured, and even if you got a connection to a browser proxy, which is the hard part. The reason is that LearnCircuitBuildTimeout is designed to learn a timeout that excludes the lowest 20% of circuits. When you connect over flash proxy, you are connecting through someone else's browser, so you never know how fast it will be. 20% of the time it will be too slow and leave you with a broken connection. There's a little writeup of the problem in this commit message. CircuitBuildTimeout might not be necessary since we are shipping Tor 0.2.4 (see #6304 (moved)), as it's set to the default value.

That said, I think this ticket is worth doing even if it is only setting new Bridge lines and not any other settings.

Replying to dcf:

LearnCircuitBuildTimeout and CircuitBuildTimeout need some explanation. Without these settings, a flash proxy bridge will fail almost exactly 20% of the time--Tor will refuse to use it, even if it is the only bridge configured, and even if you got a connection to a browser proxy, which is the hard part.

I just created #10429 (closed) which may allow us to get rid of the LearnCircuitBuildTimeout 0 workaround.

A tor-level alternative to this ticket is comment:22:ticket:5018 (don't start ClientTransportPlugins until UseBridges is set). I think I prefer this ticket, because it would make it easier to enable and disable individual transports.

Do users need to be able to see and possibly edit the list of default bridges after they choose to use them? Or can the UI be as simple as a set of radio buttons that allows for No Bridges, Use Default Bridges, and Custom Bridges?

One thing that I don't see mentioned so far is updates. Users who chose “Use Default Bridges” should probably see their bridge list updated when a newer TBB comes with an updated set of default bridges.

Cross referencing #10538 (moved), which is more generally about configuring pluggable transports.

mcs, brade: I don't think we should support editing the default bridge set. At least not via UI. You have it right, I think. "No Bridges", "Use Default Bridges", and "Custom Bridges".

If we store these bridge lines as torlauncher prefs in https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/extension-overrides.js, will they get updated properly?

I am thinking the most straight-forward way to provide this behavior is to create a pref branch like 'extensions.torlauncher.default_bridges', and create a number of subprefs like extensions.torlauncher.default_bridges.bridge1, extensions.torlauncher.default_bridges.bridge2, and so on to arbitrary bridgeN. That way, if the "Use Default Bridges" radiobutton is selected, Tor Launcher can just enumerate this pref branch, and enter all of the values of those prefs directly as bridge lines. Otherwise, we ignore them entirely. Does that sound like it could work?

Replying to mikeperry:

If we store these bridge lines as torlauncher prefs in https://gitweb.torproject.org/torbrowser.git/blob/HEAD:/build-scripts/config/extension-overrides.js, will they get updated properly?

Updating extension-overrides.js will not be a problem. But once the user chooses "Use Default Bridges" the settings will be fed to tor by Tor Launcher and thus written to torrc. The current plan is to not update torrc as part of any automated update process. That means that, if "Use Default Bridges" is active, Tor Launcher would need to replace all of the old settings with new ones (pulled from the preferences). That would work OK if the only config items that need to be set are bridge lines. But I am not sure how Tor Launcher will detect that a new set of preferences has arrived (thereby triggering a refresh of the bridge settings via the control port). Setting them every time TBB starts up would work but is kind of ugly.

I am thinking the most straight-forward way to provide this behavior is to create a pref branch like 'extensions.torlauncher.default_bridges', and create a number of subprefs like extensions.torlauncher.default_bridges.bridge1, extensions.torlauncher.default_bridges.bridge2, and so on to arbitrary bridgeN. That way, if the "Use Default Bridges" radiobutton is selected, Tor Launcher can just enumerate this pref branch, and enter all of the values of those prefs directly as bridge lines. Otherwise, we ignore them entirely. Does that sound like it could work?

Yes, that should work, with the caveats I mentioned above.

Another idea (from Kathy) is to ship a second torrc-defaults that has the default bridge settings. If someone enables the "Use Default Bridges" setting, Tor Launcher would tell tor to load the alternate torrc-defaults. But I think transitioning from one torrc-defaults to another will require a complete restart of the tor process (which is not something Tor Launcher knows how to do yet).

I think completely resetting bridge settings to use the values from the prefs every startup (and also every time that pref is selected) is a fine option. Another edge case this will cover is if the user enters manual bridges at one point and then decides to try switching to the defaults at a later date. Tor launcher should wipe their current bridge settings in that case, too.

Trac:

Proposed first run panels

Trac:

Proposed network settings dialog

Please review and comment on the attached screenshots. For the first-run wizard, Mark and I decided that it makes sense to insert a new panel that asks a Yes/No question. This is more consistent with the other parts of the wizard and it also allows us to introduce the concept of bridges.

I don't know if it's worth mentioning here but I have seen a couple messages on the help desk from users requesting bridges… because they could not reach some hidden services. Maybe replacing “hidden relays” by “unlisted relays” or something close enough could prevent some confusion?

Replying to lunar:

I don't know if it's worth mentioning here but I have seen a couple messages on the help desk from users requesting bridges… because they could not reach some hidden services. Maybe replacing “hidden relays” by “unlisted relays” or something close enough could prevent some confusion?

Thanks. We replaced "hidden relays" with "unlisted relays" as you suggested.

We finished the UI and backend changes and committed everything:

https://gitweb.torproject.org/user/brade/tor-launcher.git/commit/5a9a0c2699110e6b6b0f2267b71aefacbdba74ce

Currently this is only on a bug10418 branch in the .../user/brade/tor-launcher.git repo. Also, we did not add any default bridges to the preferences yet.

Next we will test with the TBB 3.x-based PT bundles. We also need to check on a couple of localization issues.