[tor-dev] Upcoming Tor change with application impact: "Dormant Mode"

Nick Mathewson nickm at alum.mit.edu
Thu Dec 20 14:59:48 UTC 2018

On Thu, Dec 20, 2018 at 9:51 AM Mark Smith <mcs at pearlcrescent.com> wrote:
> On 12/13/18 3:56 PM, Nick Mathewson wrote:
> > ...
> > In 0.4.0.x, Tor will begin supporting a new "dormant" mode in which it
> > does not initiate network activity, and tries to avoid CPU wakeups.
> > ...
> >
> > == Compatibility issues
> >
> > I see two issues here: one minor, and one major.
> >
> > Minor issue: some applications periodically make requests to the tor
> > network on their own -- for example, Tor Browser's update requests.
> > These requests prevent Tor from becoming dormant.  If this is
> > undesired, we can add some way around this.
> Tor Browser's update requests happen twice per day (and only for desktop
> browsers). I am not 100% sure, but I don't think any other timer-based
> requests occur more frequently in Tor Browser, so I don't think this
> will cause too much activity.

This is enough activity to make sure that under the (current) default
schedule, Tor will never become dormant. We should think of a
workaround if this is not the intended behavior.

> > Major issue: some applications expect that Tor will always bootstrap
> > when it starts, and delay presenting their own UI until Tor is ready.
> > But if Tor starts as dormant, then it will not bootstrap until it
> > receives a request from the client or a "SIGNAL ACTIVE"  command from
> > the controller. This could lead to breakage as the application waits
> > for Tor to tell it that it's ready, and Tor waits for somebody to tell
> > it that it's needed.
> Since most users will use their browser very soon after they start it,
> for Tor Browser we will probably need to do "SIGNAL ACTIVE" each time
> during startup.  For us it would be convenient if there was a way to do
> that on the command line or equivalently via a torrc option.

We could add an option like that, sure.

> > Are all application developers okay with the issues above, and okay
> > with working around them?  If not, we may need changes in Tor before
> > 0.4.0.x is released.  Let's talk!
> I am sure I can find out somewhere, but what is the approximate schedule
> for 0.4.0.x?

We're planning to put the first alpha out in mid-January, and aim for
a stable in mid-April.  Our alpha plans usually run on schedule; our
stables seem to be happening late.


More information about the tor-dev mailing list