It's hard to say what the battery impact would be because it depends on
what else the device is doing.
The best case for battery savings would be when the device is stationary
with the screen turned off, no apps exempted from doze mode except the
one running the hidden service, and no
Michael, what kind of reduction in battery impact would you expect if you were
able to make these changes?
Also, is anyone aware of any work that has been done within this community or
in academia to consider from first principles what Tor would look like if built
for mobile first? (e.g. built
On 10/01/2024 01:46, Nick Mathewson wrote:
On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott
wrote:
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
Thanks for this information. Android devices are generally able to keep
TCP connections open during deep sleep, as long as there are keepalives
from the other side (which we can request for Tor guard connections via
KeepalivePeriod). The device will wake from deep sleep to handle network
On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott
wrote:
>
> 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
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
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
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
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
