anonym: > 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.
We should be careful here, seeing that this feature raises issues on the
general configuration for Tor, we should be sure to find an UI that
doesn't have to be rolled back any time soon. I'm confident we can do
that in time for 0.23 :)
> # 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?
I think that was fixed already. I built from commit 7d0ea0b and after
configuring bridges I got a Vidalia as badly working as before: I had to
wait to 5-10 minutes to get the green icon and the map :)
> # 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 didn't like the old explanation, so I won't mourn its loss.
> 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.
Yes, this Tor Launcher UI is quite new so we should get involved in
refining it and push our suggestions upstream.
> # 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 realize 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?
I think I prefer the "run only once at first connection" approach. I
doubt we want to support people changing from "proxy" to "bridge" for
example. But being able to reconfigure bridges might be useful.
Note that my current experience is problematic. I tried that several
times, but if I disconnect using NetworkManager and connect again I
don't get the Tor Launcher again, neither do I get connected back to the
previous bridges :(
> # 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.
Well, that is the interface that is proposed to the TBB users: either
direct connection of Tor configuration. I'm not sure that we can
consider our users as going through a conceptually different task.
> 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:
So indeed, we could have the Greeter option map more directly the
options of the launcher which are either direct connection either Tor
configuration. And not call that option "bridges" in the Greeter anymore.
Furthermore, calling that option "bridges", and forcing our users to go
through 3 dialogs (1. direct or configure, 2. proxy, 3. firewall) before
actually getting to the bridge configure might be problematic instead.
We could even take advantage of that same Greeter option to propose an
offline mode. I understood that this is pretty much implemented in
branch greeter:feature/disable-networking. So we could have 3 radio buttons:
1. Offline mode, disable all networking
2. Direct connection to the Tor network (default)
3. Tor configuration: proxy, restricted firewall, and bridges
> 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.
Then it is even more problematic to force our users through the proxy
configuration screen if it doesn't even work to configure a proxy! We
should spend some time trying to see if we can solve that issue before
deciding on a possible workaround in terms of UI...
> The best would be if Tor Launcher was improved to automatically add an
> appropriate `ServerTransportPlugin` line when a bridge using some TP is
> added.
That might be of interest to upstream Tor Launcher as well.
> 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".
Yeap, we have the same idea.
> 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.
Let's investigate a bit more the 'ServerTransportPlugin line' vs 'proxy
configuration screen' a bit more before we confirm the UI in the Greeter.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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.
