Bug #11290
Inconsistent state between Tor status icon and Onion Circuits
10%
Description
Steps to reproduce:
- Connect to Tor, Onion Circuit is happy.
- Switch to airplane mode.
What happens:
- The Tor status icon is marked as disconnected (onion logo greyed and with a cross).
- Onion Circuits doesn’t display error messages about not being connected to Tor.
- Onion Circuits continues displaying circuits.
I understand that Tor itself doesn’t realize that it has been disconnected from Internet and keeps it circuits state. But this is inconsistent in terms of UX: when you are disconnected from the network, both the Tor status icon and Onion Circuits should make this clear. Otherwise people might wonder why circuits are still visible as before and whether or have problems troubleshooting a disconnection for example.
I suggest going to the same state as in connection_closed_cb as the difference between loosing connection to the Tor daemon and loosing connection to the Tor network probably doesn’t make sense to the user.
Subtasks
History
#1 Updated by intrigeri 2016-04-01 17:04:07
- Assignee deleted (
alant)
#2 Updated by intrigeri 2016-05-18 08:45:58
Maybe we should shut down the Tor daemon when we go offline (if /etc/NetworkManager/dispatcher.d/10-tor.sh gets a “down” action), and then Onion Circuits will notice that its connection to Tor is off.
#3 Updated by sajolida 2016-05-18 17:27:46
Woh! I thought we had a good reason not to do this and didn’t dare to
propose it. I would be up for this as it would also make other apps
behave more consistently. For example loading a page in the browser
right now when the Wi-Fi goes off goes into a very long timeout. Whereas
if Tor is shutdown, I get an instantaneous error message (“Proxy
refusing connection”), it’s a bad error message but at least I’m not
waiting for nothing if I didn’t realize that my Wi-Fi connection went off…
Would this ticket be the right place to discuss and implement this or do
we need a different one?
#4 Updated by intrigeri 2016-05-19 09:57:32
> Would this ticket be the right place to discuss and implement this or do we need a different one?
I think we can either have this discussion here, or ask on tails-dev@ what would be the problems with stopping Tor when we’re disconnected from the network.
#5 Updated by sajolida 2016-05-19 11:09:55
- Assignee set to anonym
- QA Check set to Info Needed
- Type of work changed from Code to Discuss
Marking this as discuss. Adding anonym as watcher (and temporary assignee) as he is our NetworkManager spaghetti master!
What do you think? Is this something easy to discuss or shall we ask tails-dev@?
#6 Updated by anonym 2016-09-28 08:00:22
- Assignee changed from anonym to sajolida
sajolida wrote:
> Marking this as discuss. Adding anonym as watcher (and temporary assignee) as he is our NetworkManager spaghetti master!
Woah… I had no idea I had this title. :)
> What do you think? Is this something easy to discuss or shall we ask tails-dev@?
I think it’s suitable here. IMHO it’d be nice if Tor was running iff at least one network interface is up. It would be more consistent with when you start Tails — before the network is up, tor is not started. Eliminating the “offline + tor is running” state seems like a worthwhile simplification.
It could be achieved with an NM hook that on down checks if any other interface is still up, and if not, then kills tor. Or we just convert our hooks to systemd targets etc. with proper dependencies so this would happen automatically. I can commit to the former, bon’t dare to the latter (out of lack of experience with systemd unit file writing).
Sounds good?
#7 Updated by sajolida 2016-09-28 09:22:17
- Assignee changed from sajolida to anonym
- Priority changed from Normal to Low
- QA Check deleted (
Info Needed) - Type of work changed from Discuss to Code
Ok, so I’m marking this as:
- “Code”, now that we reached an agreement.
- “Assignee: anonym”, because you said “I can commit to the former”. But feel free to deassign this from you.
- “Priority: Low”, it would be nice but we shouldn’t feel a strong commitment to make this happen any time soon.
anonym: would this fit as an “Easy” task. “Easy” as in “someone with the right skills but not familiar with Tails can do it as a first task without having to learn tons of internals”?
#8 Updated by anonym 2016-09-29 00:56:02
- % Done changed from 0 to 10
- Feature Branch set to bugfix/11290-tor-status-vs-onioncircuits
- Starter set to Yes
sajolida wrote:
> Ok, so I’m marking this as:
>
> * “Code”, now that we reached an agreement.
> * “Assignee: anonym”, because you said “I can commit to the former”. But feel free to deassign this from you.
> * “Priority: Low”, it would be nice but we shouldn’t feel a strong commitment to make this happen any time soon.
Thanks! Note, though, that I only commit to the NM part, not any changes needed to Tor status/OnionCircuits (which perhaps isn’t needed any way).
> anonym: would this fit as an “Easy” task. “Easy” as in “someone with the right skills but not familiar with Tails can do it as a first task without having to learn tons of internals”?
Yes, changes to the NM hooks could be tested easily by just making the same changes inside a running Tails session. However, I’m not sure if making changes to Tor Status and make them apply are very obvious how to do (IIRC you must run some command from a terminal to disable + re-enable the extension).
Any way, I pushed something untested. Let’s see what Jenkins thinks.
#9 Updated by intrigeri 2016-10-27 11:43:24
FWIW the branch currently fails to build.
#10 Updated by Anonymous 2018-08-17 16:01:56
Do we still want to fix this? Is this an issue at all, 2 years later?