[Tails-dev] Please review and test feature/bridge-mode

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!