Activity
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:1is a dummy address that is ignored by the plugin. The address can be anything; the important part is the
Bridge flashproxypart.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
Bridgelines,LearnCircuitBuildTimeout, andCircuitBuildTimeout. We already have theClientTransportPluginlines 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 obfs2andBridge obfs3lines. For flash proxy, you want the singleBridge flashproxy 0.0.1.0:1line as well asLearnCircuitBuildTimeout 0andCircuitBuildTimeout 60.LearnCircuitBuildTimeoutandCircuitBuildTimeoutneed 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 thatLearnCircuitBuildTimeoutis 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.CircuitBuildTimeoutmight 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
Bridgelines and not any other settings.Replying to dcf:
LearnCircuitBuildTimeoutandCircuitBuildTimeoutneed 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 0workaround.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.
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:
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.
