Project

General

Profile

Bug #11290

Inconsistent state between Tor status icon and Onion Circuits

Added by sajolida over 3 years ago. Updated about 1 year ago.

Status:
Confirmed
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
03/30/2016
Due date:
% Done:

10%

Feature Branch:
bugfix/11290-tor-status-vs-onioncircuits
Type of work:
Code
Blueprint:
Starter:
Yes
Affected tool:
Onion Circuits

Description

Steps to reproduce:

  1. Connect to Tor, Onion Circuit is happy.
  2. Switch to airplane mode.

What happens:

  1. The Tor status icon is marked as disconnected (onion logo greyed and with a cross).
  2. Onion Circuits doesn't display error messages about not being connected to Tor.
  3. 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.

Associated revisions

Revision be326a34 (diff)
Added by anonym about 3 years ago

Stop tor if down:ing the last network interface.

When Tails has booted without network, tor is not started. This change
creates more consistency by making us return to that state when down:ing
the last network interface, instead of entering a third state of
"network is down, tor is running but obviously not working".

Refs: #11290

History

#1 Updated by intrigeri over 3 years ago

  • Assignee deleted (alant)

#2 Updated by intrigeri over 3 years ago

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 over 3 years ago

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 over 3 years ago

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 over 3 years ago

  • 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 about 3 years ago

  • 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 about 3 years ago

  • 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 about 3 years ago

  • % 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 about 3 years ago

FWIW the branch currently fails to build.

#10 Updated by u about 1 year ago

Do we still want to fix this? Is this an issue at all, 2 years later?

Also available in: Atom PDF