Replace Vidalia's green onion feature
Vidalia’s green onion is buggy in various ways such as:
- It turns green a while after Tor is usable;
- Users (and even Tails developers) mistakenly believe that yellow means “bootstrapping Tor”, and even our doc is wrong about it;
- If Tor gets offline for some reason (e.g. bridge is down), then the green onion stays.
However, once we get rid of Vidalia (
Feature #6841) we still want to keep such a permanent “Tor status” indicator on the desktop.
On the long term, we have ideas to make the green onion better, but that’s not blocking
Feature #6841: simply replacing what Vidalia gives us, with minimal efforts, and possibly with the same bugs, will be enough.
The design we’ve come up with is a minimalistic GNOME Shell extension that learns about Tor’s on/off state by monitoring whether a given file exists. The very same mechanism that currently displays the “Tor is ready” notification in Tails would create that file, that would update this onion.
Note that this green onion should not have an ugly white bar as some people see in Windows Camouflage mode (
Bug #7400). Ideally, it would also use some less conspicuous stock Windows systray icon.
Related to Tails -
#11 Updated by intrigeri 2015-03-15 17:17:31
Left to design: how that Shell applet starts Tor Monitor. Being discussed in the “How to replace the green onion” thread on tails-dev@. Current realistic proposals are to either start it directly upon clicking on the onion icon, or to open a menu when clicking that icon, and add an entry to that menu that will open Tor Monitor.
#17 Updated by intrigeri 2016-02-13 00:53:14
Here is Subgraph OS’ one, that they started working on a few days ago: https://github.com/subgraph/gnome-shell-extension-torstatus
#19 Updated by intrigeri 2016-02-15 12:57:18
- Feature Branch changed from feature/9002-replace-vidalias-green-onion to feature/6841-replace-vidalia
It looks like feature/9002-replace-vidalias-green-onion is obsolete: the exact same commit was reapplied (under a different ID) on feature/6841-replace-vidalia, and later on, on that other branch, some follow-up bugfixes were applied to the Tor Shell extension this is about (e.g. commit:00bc8113431ed9764be5a5e4d6f1001872e7f072 and commit:a00d814e6c1cea0d73afe6269cd186c18cf8bc30).
#20 Updated by intrigeri 2016-02-15 13:10:44
- % Done changed from 90 to 50
Once Tor has bootstrapped once, we’ll forever pretend that Tor is usable, even if we get disconnected from the network. This doesn’t match what the boolean indicator is supposed to do. It looks like
/var/run/tor-is-ready is never deleted, which probably explains the behaviour I’ve observed. I’ll look how we can fix that.
#22 Updated by intrigeri 2016-02-15 14:39:20
I did some preliminary cleanup (commit:43d8c20f4540811f0a6aa09f2e581b09f82c2054) that at least avoids duplicating stuff, but that’s not enough: the flag file is not deleted when we go offline. We can’t delete it with
tails-wait-until-tor-has-bootstrapped.service because it’s a Type=oneshot service, that has to return before other things can continue. So currently, to know continuously if Tor is up, the only reliable indicator is the
tor-has-bootstrapped script (that relies on the status of
tails-tor-has-bootstrapped.target), which I’d rather not use from the GNOME Shell extension. I’ll try to find a systemd way to give us a flag file that is removed when Tor is down, which should be doable e.g. with another service that would be part of
tails-tor-has-bootstrapped.target, would be responsible for managing the flag file, and would not need to be Type=oneshot. Another option would be to use dbus to get notified by systemd when the state of that target changes.
#24 Updated by intrigeri 2016-02-19 20:42:48
- % Done changed from 50 to 60
> I’ll try to find a systemd way to give us a flag file that is removed when Tor is down, which should be doable e.g. with another service that would be part of
tails-tor-has-bootstrapped.target, would be responsible for managing the flag file, […]
Done in commit:60429473036a021f8b228c27df2d39d1954321c9, seems to work. I’ll now run automated tests to ensure this branch doesn’t break anything else, and then I’ll close this ticket so that the parent one (and sibling tickets) can track other blockers for the merge of this branch.