Opened 3 months ago

Closed 2 months ago

#28624 closed enhancement (implemented)

Should we remember dormant state on restart?

Reported by: arma Owned by: nickm
Priority: Medium Milestone: Tor: 0.4.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-dormant
Cc: brade, mcs, eighthave Actual Points: 1
Parent ID: Points: 2
Reviewer: dgoulet Sponsor: Sponsor8-can

Description

One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity -- but if you start it again, it'll be active for 24 hours again. So people who restart their computers, or their Tor-including apps, will continue putting load on the Tor network.

So I am opening this ticket to not forget that second piece of it.

The first question is around the engineering side: when we go dormant, do we write that fact into our state file? And when we change our mind, I guess we clear it? Do we also write it when the controller commands us to go dormant? I guess yes.

The second question is about how thorough we want to be. Specifically, if we're expecting that people will restart their Tor, what about people who never leave their Tor going for a full 24 hours? Those people will never switch to a dormant state. Is that ok? The fix would be to record "partial progress towards going dormant" in the state file, which is kind of ugly but also doable.

The third question is around how to handle it when we start up and the state file says we were dormant. Continuing to stay dormant seems like the clear right behavior -- because after all, we can wake up and start bootstrapping if we actually get an application level request. But I guess that means we don't even try to bootstrap? Are there controller apps like Tor Launcher and Nyx that wait for the 100% bootstrap message and tell you that your Tor is broken if it doesn't happen? Is there something we can give those apps instead that will satisfy them that Tor is "acting as intended"? Is there some simple "connect to a relay and do a handshake with it once" thing that we can do instead on startup, to satisfy ourselves that Tor *could* work if we wanted it to? Or should we stay totally isolated from the network when we start up in dormant state?

I think some of these are ux questions, and answering them might be easier if we pick a couple of specific use cases for dormant mode. Here are two:

(1) What if some linux distro includes a Tor client package by default, and users can configure their apps to use it but many users don't. In that case we'd have thousands or millions of Tor clients installed but not usefully using the Tor network. And our primary goal there would be to make those Tors go totally quiet after a while. This was the original motivation for #2149.

(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.

So I think use case (1) is the one to focus on, and that also simplifies the ux questions.

Child Tickets

Change History (15)

comment:1 Changed 3 months ago by arma

Ok, here is a concrete set of steps, to go with the brainstorming above:

(1) When Tor is dormant, and it's writing out its state file, write the one bit ("yes I'm dormant") in the state file.

(We don't have to write that bit if we went dormant via the controller command (on the theory that if you've got a controller that is controlling you, it can do it again next time), but if it makes the implementation easier, it's fine to.)

(2) If Tor starts up and finds that bit set in its state file, it should start up dormant.

(3) We should talk to Damian and Pearl Crescent about how best to help controllers handle the new concept that a Tor could start yet not attempt to bootstrap. It turns out we already have a 'getinfo dormant', but it means the old notion of dormant that only has to do with circuit building, not the new notion that #28335 decided it meant (oops), so we should probably expand and revise that. Another option is to make a controller event called dormant, and issue that event in response to a 'getinfo status/bootstrap-phase' so a controller that knows to listen for the event can always notice. Maybe there are even smoother options.

comment:2 Changed 3 months ago by nickm

Milestone: Tor: 0.4.0.x-final
Points: 2

Thanks for opening this: I've been thinking about it since I saw this email:

https://lists.torproject.org/pipermail/tor-dev/2018-November/013561.html

I've been thinking of the following interface:

   DormantOnStart 1|0|auto

   If DormantOnStart is set to 1, then Tor starts up in dormant mode.

   If DormantOnStart is 0 (the default), then Tor starts up in active
   (non-dormant) mode.

   If DormantOnStart is "auto", then Tor starts up in dormant mode UNLESS
   it was active when it last saved its state file, AND it saved its state
   file no more than DormantClientTimeout seconds ago.

comment:3 Changed 3 months ago by mcs

Cc: brade mcs added

comment:4 Changed 3 months ago by arma

So would that mean that by default, Tor never remembers its dormant state across restarts? (Or more precisely, never reacts to dormancy info in the state file on startup.)

That would seem to not cover the "some linux distro includes a Tor client package by default" use case, right? It's more oriented towards specific Tor installs that know they want to be special?

comment:5 in reply to:  4 Changed 3 months ago by nickm

Replying to arma:

So would that mean that by default, Tor never remembers its dormant state across restarts? (Or more precisely, never reacts to dormancy info in the state file on startup.)

That would seem to not cover the "some linux distro includes a Tor client package by default" use case, right? It's more oriented towards specific Tor installs that know they want to be special?

Right. We could change the default later on, but I thought that for now, we're better off making this an off-by-default feature.

On IRC, you said:

i am a bit suspicious also of the 'auto' choice being 'yes if my state file is from yesterday
because we do have a new bit of info from yesterday, and that new bit is "i just started tor"
and often, when i start tor, it's because now i plan to use it

To clarify, the "auto" choice is "be active if I was active when I shut down, and I shut down recently". Or if you prefer "be dormant if the state file was old, or if I was dormant in the old state file."

I'm also concerned about whether this is the best approach, but I think that other choices won't work for the use cases we have. If every startup makes tor active, then we won't actually have time to go dormant.

I guess another possibility might be to remember the total number of hours Tor has been running without user activity, and let that build up cumulatively over invocations. In this case, "auto" might mean simply "remember if we were active", and we might additionally track in our state file the cumulative number of minutes that Tor has run without seeing user activity.

comment:6 Changed 3 months ago by teor

(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.

Here's the alternative we'll probably end up deploying:
Tor should behave politely by default. If an app breaks that politeness, the app is responsible for managing the breakage. If an app breaks when tor is polite, the app is responsible for managing its own breakage.

comment:7 Changed 3 months ago by nickm

Owner: set to nickm
Status: newaccepted

comment:8 Changed 3 months ago by nickm

Actual Points: 1
Status: acceptedneeds_review

This was comparatively simple. PR in https://github.com/torproject/tor/pull/564

comment:9 Changed 3 months ago by eighthave

Cc: eighthave added

comment:10 Changed 2 months ago by eighthave

One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity

If I'm understanding this correctly, I think Dormant Mode should also consider the time scales of 1 minute, 1 hour and 10 hours. These are very relevant in the mobile context. Reading @arma's description of how this dormant mode idea manages state reminds me a lot about how Android and iOS expect apps/services to do it.

(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.

About mobile apps that embed Tor, we've put the core idea of "wake on use" in NetCipher and Orbot. The core idea is that whenever an app first needs to use tor, it sends Orbot a message to request that Orbot start tor. If that is widely used, then Orbot/tor need only manage going idle/dormant, since there is a clear request to start before each use, and this request will start the receiving app automatically. This idea should really be fully developed and included in both Orbot and embedded Tor, e.g. Tor Proxy Library. I'm not sure that this concept would work as well on Desktop OSes. I guess with things like dbus, inter-app messaging is becoming more common on Desktop as well.

Here's the alternative we'll probably end up deploying:
Tor should behave politely by default. If an app breaks that politeness, the app is responsible for managing the breakage. If an app breaks when tor is polite, the app is responsible for managing its own breakage.

This makes sense to me in the Android context.

Last edited 2 months ago by eighthave (previous) (diff)

comment:11 Changed 2 months ago by dgoulet

Reviewer: dgoulet

comment:12 in reply to:  10 Changed 2 months ago by nickm

Replying to eighthave:

One of the core ideas of #2149 was for Tor to remember its dormancy across restarts. As of the finishing of #2149, Tor will go dormant 24 hours after startup if it's seen no activity

If I'm understanding this correctly, I think Dormant Mode should also consider the time scales of 1 minute, 1 hour and 10 hours. These are very relevant in the mobile context. Reading @arma's description of how this dormant mode idea manages state reminds me a lot about how Android and iOS expect apps/services to do it.

It's configurable: see the option DormantClientTimeout. Right now the minimum is 10 minutes, but we could make that lower if mobile devs want it. Open a ticket if so?

(2) ...I was going to use an example here of Tor bundled with an app, like Brave or Briar, but I think in this case the app should be responsible for making Tor behave politely to the Tor network.

About mobile apps that embed Tor, we've put the core idea of "wake on use" in NetCipher and Orbot. The core idea is that whenever an app first needs to use tor, it sends Orbot a message to request that Orbot start tor. If that is widely used, then Orbot/tor need only manage going idle/dormant, since there is a clear request to start before each use, and this request will start the receiving app automatically. This idea should really be fully developed and included in both Orbot and embedded Tor, e.g. Tor Proxy Library. I'm not sure that this concept would work as well on Desktop OSes. I guess with things like dbus, inter-app messaging is becoming more common on Desktop as well.

Edited to add: you can do that manually with the controller interface by saying "SIGNAL ACTIVE" or "SIGNAL DORMANT". See control-spec.txt.

Here's the alternative we'll probably end up deploying:
Tor should behave politely by default. If an app breaks that politeness, the app is responsible for managing the breakage. If an app breaks when tor is polite, the app is responsible for managing its own breakage.

This makes sense to me in the Android context.

Last edited 2 months ago by nickm (previous) (diff)

comment:13 Changed 2 months ago by nickm

Sponsor: Sponsor8-can

comment:14 Changed 2 months ago by dgoulet

Keywords: tor-dormant added
Status: needs_reviewmerge_ready

lgtm!

comment:15 Changed 2 months ago by nickm

Resolution: implemented
Status: merge_readyclosed

Squashed and merged!

Note: See TracTickets for help on using tickets.