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 to only run when an app is in the foreground, or when a notification wakes up the app.) This seems like a discussion worth having once Arti settles and it's easier to build new things again!

On Wed Jan 10, 2024, 11:26 AM GMT, Michael Rogers wrote:
On 10/01/2024 01:46, Nick Mathewson wrote:
On Tue, Jan 9, 2024 at 12:58 PM Micah Elizabeth Scott
<beth@torproject.org> 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 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

Hm. Do you know, is it possible to make network-driven wakeup events
relatively prompt? (Like, within a second or so if a TCP stream we're
waiting on wakes up). If so, then onion services have a decent chance
of being made to work.

Fantastic! Yes, the response to network events should be reasonably
prompt. I'll try to get some measurements.
As for the original question about timers, it would be good to know if
the variance between scheduled wakeup and actual wakeup can be
bounded, or if there's any way to mark a timer as high-priority vs
low-priority or something.

This is unfortunately one of those things that's constantly changing on
Android and varies between manufacturers. In theory we should be able to
set a periodic alarm that fires within fifteen minutes of the last
firing, although not all manufacturers honour this.

When the alarm fires the device will come out of suspension and the app
will be able to grab a temporary wake lock, which we can hold for some
amount of time (say a minute, for the sake of argument) to let Tor do
whatever it needs to do.

As far as I know these alarms can only be scheduled via a Java API, so
Tor would either need to signal to the controller that an alarm was
needed, or the controller could just assume this whenever hidden
services were published, and wake the device every fifteen minutes
without explicitly communicating with Tor about alarms.

Cheers,
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