Ah. If you want to run an onion service you'll need to keep at least a
couple circuits open continuously for the introduction points. I'm not
sure where you would meaningfully find time to deep sleep in that
scenario. There will be ongoing obligations from the wifi/wan and tcp
stacks. You need a continuous TCP connection to the guard, and multiple
circuits that are not discarded as idle. Incoming traffic on those
circuits need to be addressed quickly or clients won't be able to connect.
If we were really optimizing for a low power mobile onion service
platform we'd have a different way to facilitate introductions without a
continuously open set of circuits, but that would also be much more
abuse-prone.
-beth
On 1/9/24 05:19, Michael Rogers wrote:
Sorry, I should have said that we're interested in keeping a hidden
service running. Without that requirement, I agree we could just close
the guard connection via DisableNetwork after some idle period.
So the question is about keeping circuits alive, and I guess also
keeping HS descriptors published and the consensus fresh, although
hopefully the timing requirements for those are a bit looser due to
the longer timescales involved.
Cheers,
Michael
On 08/01/2024 21:01, Micah Elizabeth Scott wrote:
A variety of timers are needed on the relay side; on the client side
though, aren't you mostly limited by the requirement of keeping a TCP
connection open?
Really deep sleep would involve avoiding any protocol-level
keepalives as well as TCP keepalives. This seems a lot like just
shutting down the connection to the guard when sleeping; but of
course that's got a latency penalty and it's visible to anyone who
can see network activity.
-beth
On 1/4/24 04:48, Michael Rogers wrote:
Hi,
If I understand right, the C implementation of Tor has various state
machines that are driven by local libevent timers as well as events
from the network. For example, when building a circuit, if there
hasn't been any progress for a certain amount of time then a timer
fires to handle the timeout.
When running Tor on Android, we need to prevent the OS from
suspending so that these timers fire when they're supposed to. This
uses a lot of battery, because normally the OS would spend most of
its time suspended. Unlike a laptop, an Android device with its
screen turned off is constantly dipping in an out of suspension, and
a lot of the platform's power optimisations are aimed at batching
whatever work needs to be done so that the periods of suspension can
be longer.
If we allowed the OS to suspend then the timers would fire with
arbitrary delays, and I don't really know what impact that would
have: I'd speculate that there might be connectivity problems (eg
dead circuits not being detected and replaced) and/or
network-visible changes in the behaviour of circuits that could
affect anonymity.
So I've had a longstanding but not-very-hopeful request that maybe
Tor's reliance on timers could be reduced, or at least clarified, so
that we could either allow the OS to suspend without breaking
anything, or at least know what was likely to break.
And basically I'd just like to renew that request for Arti. Could
anyone give me an overview of how these local timers are handled in
Arti, or any information about what's likely to happen if the timers
are arbitrarily delayed?
Thanks,
Michael
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev