Tom Ritter <[email protected]> writes: > This is a specific question more about Android and iOS dev than tor. > > Tor's got the new experimental in-process API: > https://gitweb.torproject.org/tor.git/tree/src/feature/api I'm > working with someone who is developing a mobile app, and they want to > bundle tor. We don't know if it would be better to make tor a > separate process (I'm assuming this is possible, I know next to > nothing about mobile dev) or have it as its own thread using the API. > > I was wondering from an OS point of view, under memory pressure would > the OS kill the tor process but not the app? Or would it kill both? > Has anyone thought about this? Is there a general consensus or > informed opinion?
[I think this a question abut iOS and one about Android. The details
are so different that I don't see any reason to expect the same answer.
This is only about Android, and I only consider myself semi-informed.]
Android is tricky because there are the mechanisms in AOSP and stock
Google Pixel variants, and then various manufacturers add additional
aggressive app-killing. <rant>The root cause IMHO of this increasingly
aggressive killing is that people install apps that are written by
adversaries and then the OS thinks it needs to protect them from the
cycles spent on spyware, harming the ability of peopel to spend
battery/RAM on what they care about.</> These vendor mechanisms are a
huge headache in writing apps that intend to keep running to do
something the useer wants, typically to keep a connection open to
receive notification data not using the proprietary/trackable push
notification services. So your question will have different answers
when posed agains the ensemble of {android versions} x {vendor
variants}.
I think the main point is to have a design and validation that will
cause the app to work right whenever the UI part is successfully
running. That probably means the ability of the app to check if tor is
functional, and to maybe tear it down and launch it if not. I don't
know how process/thread affects that.
One thing to think about is the relative size of the app's background
service and tor. If what you care about is that the background service
can wake up ever hour or so and check for new data by connecting to a
server over tor, then it may be better to let the OS kill tor and not
the smaller service code that just gets a wakeup. Or perhaps use
mechanisms to get woken up even if exited. If the app is huge and
doesn't do background things, I'm not sure it matters, as long as it
doesn't end up persistently non-functional.
I'm really unclear on how Android treats multiple processes from the
same apk (and thus with the same UID ).
It's interesting that you asked this today. I was just about to write
here and say that I've been having trouble with Orbot, and I think that
trouble is exactly on point.
My setup:
Up-to-date CalyxOS
AndStatus firewalled to allow VPN but not direct wifi/cell
Fedilab the same (for debugging; that's not so scary)
orbot to start on boot, VPN mode, both apps opted in
This mostly works. Sometimes, the apps won't load new data, and I don't
see any non-zero rate indications on orbot's persistent notification.
Clicking stop and start in orbot takes tor down and restarts it, per its
output. but it doesn't fix the problem. Clicking exit and then
starting does fix it.
So orbot is getting into a bad state, and I haven't yet tried to capture
on adb, but this is the sort of thing that would be good to detect and
restart automatically.
I am curious if anyone else is seeing this.
Greg
signature.asc
Description: PGP signature
_______________________________________________ List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To unsubscribe, email: [email protected]
