Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  closed
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:  implemented
 Keywords:  tor-dormant   |  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:  dgoulet   |Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * status:  merge_ready => closed
 * resolution:   => implemented


Comment:

 Squashed and merged!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  merge_ready
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tor-dormant   |  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:  dgoulet   |Sponsor:  Sponsor8-can
--+
Changes (by dgoulet):

 * status:  needs_review => merge_ready
 * keywords:   => tor-dormant


Comment:

 lgtm!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:  dgoulet   |Sponsor:  Sponsor8-can
--+
Changes (by nickm):

 * sponsor:   => Sponsor8-can


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:  dgoulet   |Sponsor:
--+

Comment (by nickm):

 Replying to [comment:10 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.
 >
 > > 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (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.  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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by eighthave):

 * cc: eighthave (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  accepted
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * owner:  (none) => nickm
 * status:  new => accepted


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  nickm
 Type:  enhancement   | Status:  needs_review
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:  1
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * status:  accepted => needs_review
 * actualpoints:   => 1


Comment:

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (by nickm):

 Replying to [comment:4 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+

Comment (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?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by mcs):

 * cc: brade, mcs (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:  Tor: 0.4.0.x-final
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:  2
 Reviewer:|Sponsor:
--+
Changes (by nickm):

 * points:   => 2
 * milestone:   => Tor: 0.4.0.x-final


Comment:

 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.
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal| Resolution:
 Keywords:|  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+

Comment (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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #28624 [Core Tor/Tor]: Should we remember dormant state on restart?

[Tor Bug Tracker & Wiki]

#28624: Should we remember dormant state on restart?
--+
 Reporter:  arma  |  Owner:  (none)
 Type:  enhancement   | Status:  new
 Priority:  Medium|  Milestone:
Component:  Core Tor/Tor  |Version:
 Severity:  Normal|   Keywords:
Actual Points:|  Parent ID:
   Points:|   Reviewer:
  Sponsor:|
--+
 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs