Hi, This is an early view of bridge mode implemented with the use of Tor Launcher. It also removes Vidalia. The branch has been merged into experimental.
The branch includes the Tor Launcher tree via `config/chroot_local-includes`. It will be packaged in the next few days, and once that's done that part of the history will be removed. Bridge mode currently has no GUI control in Tails Greeter, and is activated by appending "bridge" to the kernel command line, just like before. A Tails Greeter with an appropriate GUI for this will be packaged in the next few days. Here are some things I'd like some feedback on: # Loss of Vidalia's systray icon Since Vidalia is removed, and Tor Launcher doesn't show a systray icon indicating Tor's connection state like Vidalia did, there's no *constant* indication whether Tor is up and running, just the *temporary* notification we recently introduced. I expect that our users are heavily trained by now to look for the Vidalia icon. Any thoughts on this? [For what it's worth, it's a nice improvement in Tails' camouflage mode. :)] # Loss of old bridge mode explanation In our old, Vidalia-based bridge mode, a Tails-specific dialog was shown (thanks to our custom patches), and it mentions the "hide that you're using Tor" use case. This perspective of bridges is completely absent from Tor Launcher's corresponding dialog. Is this an issue? I suppose that we in the short run can settle with only mentioning this use case in our user documentation, even though the Tor Launcher GUI later only talks about "censorship circumvention", which is something quite different. In the long run we probably want to convince upstream that this is a valid use case and have the description changed/complemented. # When to show the Tor Launcher network settings window? The current implementation shows it for each and every successful network connection, and always set's `DisableNetwork` before starting Tor to enforce potentially new settings. This way we support changing the network settings during the same Tails session. I realise that this may be annoying (especially with unstable WiFi connections), and may train users to click through the Tor Launcher network settings wizard without thinking. Hence we probably want to move to some sort of "run only once" approach. I think we should immediately drop the "start directly at Gnome desktop start" approach, as Tor Launcher requires a running Tor process, which has a whole can of worms in the Tails context. What remains is "start at first connection", which is simple to implement. Does this make sense? # What about the non-bridge options, like proxy configuration? Tor Launcher's network settings are not limited to bridge settings but also deals with proxies and firewalls with egress port filtering. These are all relevant things for Tails users, which we supported setting previously through Vidalia. Since "bridge mode" covers some quite different use cases (and actually is incompatible with proxies, see below) we need a separate way to start Tor Launcher's network settings. I think adding an entry in Gnome's menues is sufficient. ## Re-invent or change name of bridge mode? An annoying issue, though, is that Tor Launcher requires that the Tor process is running before it will show the network settings, so users have to connect to a "bad" network before they can configure the option needed to make Tor usable on it, like a proxy. OTOH, this was the case with Vidalia too, so it's not a regression. One way to fix this issue would be to re-invent bridge mode into something that covers all cases where one needs special network settings. However, I suspect that that will be conceptually harder to get for our users. Or would a combo box with something like "None" (default), "Bridge mode", and "Proxy/Fascist Firewall" be ok? All would work essentially the same, with setting `DisableNetwork` before Tor starts, starting Tor Launcher after, with one little difference: Note that only one of `{HTTP{,S},Socks{4,5}}Proxy` and `ServerTransportPlugin` can be configured in Tor at the same time, and since we have to add a `ServerTransportPlugin` line in order to support obfsproxy while in bridge mode, proxies are incompatible with bridge mode, so it wouldn't be added in e.g. the "Proxy/Fascist firewall" mode. The best would be if Tor Launcher was improved to automatically add an appropriate `ServerTransportPlugin` line when a bridge using some TP is added. Then "bridge mode" and "Proxy/Fascist Firewall" would become the same, and we'd only need a single checkbox with some appropriate wording for "I need special network settings". Since it's not a regression I don't think it's important to fix it for the initial release. However, if we eventually want to fix this that means that the UX for this option will change, which would be great to avoid. I don't think there's time for that before the 0.23 release though, so I guess I'll just drop this for now. # "Copy Tor Log to Clipboard" doesn't work Following the nice separation approach we had for Vidalia, I made Tor Launcher execute under dedicated user. The problem is that the clipboard isn't shared to the Live user, so the button in question does nothing from the perspective of the Tails user. One solution is to run Tor Launcher as the Live user, and have it use WinterFairy's Tor Control Port filtering proxy (#6384), but it'd need to be extended quite a bit to support all the commands needed by Tor Launcher. It'd be insecure too as it would allow a compromised Live user to unconfigure bridges, for instance. I strongly oppose this. Do we care about this? Any simple fixes to enable clipboard sharing (preferably only one-way) between different users in the same X session? Cheers! _______________________________________________ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.