Yawning Angel:
On Tue, 30 May 2017 20:22:09 +0200 Hans-Christoph Steiner hans@guardianproject.info wrote: [snip]
Android is a very different OS than all the desktops. GNU/Linux, OSX and Windows are much more similar to each other than to Android. Android is also the most popular computing platform in the world, so its worth investing it. More users and more page views than Windows.
Given the desire for stronger sandboxing, it could make sense to keep tor in something like Orbot, which is installed separately. That means its isolated from the browser part with all the Android tricks. Things like CopperheadOS make that sandboxing even stronger.
As for Android apps updating their own code, it is possible, and it is occasionally done. It is considered a bad practice, and Google has been gradually locking that down over time. Android already provides a solid install procedure, at best, I think it would be a waste of time to build a custom in-app updater to replace that. For example, that will break nice security properties like the code being installed read-only even to the app itself.
The general gist I'm getting from this is:
Continue to treat Android like the red headed stepchild that it is, because a tor-launcher deprecation/rewrite doesn't affect the one platform that doesn't really even use tor-launcher in the first place.
Yes, with these exceptions:
* Java/C libs can be easily shared between Android and other OSes
* Libs in languages other than Java/C will be harder to use well
* Daemons can work on Android but often badly and never quite right
* GUI/UX code is almost never worth sharing with other platforms, and vice versa
nb: If there is special code required for Fenec to interact with Orbot, I don't see why that requires it's own launcher process.
Right, Orbot could work fine without a Launcher icon, if you mean Android Launcher. But maybe I don't know what you mean by "launcher process". If tor is included in its own app, separate from Tor Browser, then tor would always be running in a separate process.
There's also no reason why, "Vidalla++" (or whatever it ends up getting called, if it happens) can't support Android, however:
- Downloading/installing/updating the browser - Handled by whatever app store people use (and if people are sideloading apks, it's handled by the person).
We also have a new library suite to make it easy for apps to update themselves in a trusted channel.
* "App Updater" prompts the user to directly install updates
* "Get F-Droid" prompts to install F-Droid as the update channel
https://gitlab.com/fdroid/update-channels
- Configuring/Launching Tor - Handled by Orbot.
Makes sense to me.
- Sandboxing - Handled by the OS. There's probably more that could be done here, but I will profess ignorance to how much kernel support is available in deployed Android installations for any of the mechanisms (And I assume that things like AppArmor that require root fall into the realm of "Not useful in a general case").
Android is built on SELinux. I'm not sure if an app can request additional SELinux restrictions. strcat in #copperhead is a good person to ask about those details.
Here's the official overview: https://source.android.com/security/selinux/concepts
.hc