Avoiding the inconvenience of user profiles

madduck

Hello,

I am new to GrapheneOS, but I hope I've done my homework thoroughly, reading up on everything I could find.

I am looking into limiting apps from running unless I explicitly use them. I am thinking of something like Slack or Whatsapp, which I'd never want to run in the background. Instead, my use-case is that I make time to open them and then wade through messages and notifications. When I am done doing so, I want the app to die, and not be able to continue collecting data, or listening for events in the background.

User profiles would do this I think, but they are quite inconvenient after all, and I wouldn't be able to e.g. copy from an email some text into a Slack channel, if my email programme is available only in another user profile.

My understanding is that the GOS exec model puts every app into its own sandbox even within a user profile, and thus each and every app is shielded from each other, except for comms via public APIs, and only if consent has been given.

However, apps within a user profile can apparently discover presence of each other, so this is a bit of a privacy leak, for instance if I do not want Untrusted App A to be able to find out that I have App B installed, for whatever value that might be. So if I want to prevent App A from finding out about App B, I need to put them into separate user profiles.

The other benefit of user profiles, as far as I understand, is that switching a user terminates all processes of the previous user, thus preventing apps from running in the background.

So these are two benefits… are there any others?

What is the real danger of App A being able to find out about App B if it cannot talk to it, or access its data anyway?

And finally, is there a way to limit certain apps from ever running in the background, to achieve what I am trying to achieve?

Thanks,
martin

kopolee11

madduck I'm not sure if this achieves exactly what you're trying to do, but it is possible to disable apps when not using them and then enable them when you need then.

lberrymage

madduck

My understanding is that the GOS exec model puts every app into its own sandbox even within a user profile

All apps are sandboxed in all user profiles, but that's true regardless of whether exec spawning is enabled and isn't behavior specific to GrapheneOS (although exec spawning improves privacy and security in other ways and GrapheneOS improves the app sandbox over AOSP).

and thus each and every app is shielded from each other, except for comms via public APIs, and only if consent has been given.

User consent isn't needed for apps to communicate over IPC. They can also theoretically communicate via the Internet or shared data (e.g. files) if they both have access to such.

The other benefit of user profiles, as far as I understand, is that switching a user terminates all processes of the previous user, thus preventing apps from running in the background.

That actually isn't the case. Apps will continue running in other profiles until the OS decides to kill them, you reboot, or you press "End session" for that profile.

So these are two benefits… are there any others?

You can put them at rest individually. You can also grant apps which require it "invasive" access to Contacts, All Files, etc. while really only allowing access to a subset of that information since it isn't shared across profiles.

What is the real danger of App A being able to find out about App B if it cannot talk to it, or access its data anyway?

Depends on what App A does with that information. One theoretical threat is user fingerprinting along with what that enables such as profiling and targeted ads.

And finally, is there a way to limit certain apps from ever running in the background, to achieve what I am trying to achieve?

I don't know what you're trying to achieve besides preventing given apps from running in the background, but you can do that by putting them in a separate profile and pressing "End session" when you want to kill them.

madduck

kopolee11 That would work provided that disabling also kills them, but it's a pretty cumbersome process, which therefore is bound to slip over time.

madduck

lberrymage Thanks, that really helped further my understanding of the functionality.

ayaen

You could remove background network access and restrict battery usage. You can in addition force-stop apps but that obviously can get tedious. But you yourself say this ....

What is the real danger of App A being able to find out about App B if it cannot talk to it, or access its data anyway?

So I am unsure why then you insist on extra ways to stop apps from working in background.

If you do not wish for an app to have a certain kind of data- remove the corresponding permission/Special App access.
Apps that "talk to each other" are usually from the same developer or developers collaborating - you should be aware of those. Most of the inter app communication is really generic and mediated by the OS.

For example an app can ask - Can I find an app to let me have access to a part of the shared storage chosen by the user?
Or can I have the system camera app take a picture for me?
Or can I open the mail app so that the user can share this photo with whoever they want?

Apps declare in manifest files what kind of "questions" that I mentioned above they can answer.

A working operating system that can get some shit done for you requires co-operation of multiple programs.

madduck

ayaen Understood and agreed. But still, there is absolutely no reason why e.g. WhatsApp, Twitter, Slack, etc. should be able to run at all in the background if I don't care about real-time notifications. The same goes for my parking app, weather, car rental, you name it…
There are apps for which background operation makes sense, and some people love the gratification from instant notifications, and that's all good and well, but for those apps that I don't need in the background, and which do not provide cooperative services to the rest of the apps and operating system installed, it'd be swell if I could just prevent them from getting CPU slices.

ayaen

madduck Understood and agreed. But still, there is absolutely no reason why e.g. WhatsApp, Twitter, Slack, etc.

I find mobile.twitter.com works exceptionally well on Vanadium for me.
I would also like to point out that instant notifications for many people is critical - not merely a luxury.
I also pointed out ways in which you could restrict an apps background access. So maybe try those and see how they work for you?

kopolee11

madduck Thanks and agreed it's not a perfect system.

I personally mainly use it for apps I need for work (like Slack) and then I disable them when I'm done work.

junction

Another potential use case for user profiles is isolating more valuable apps / data like banking apps from your normal day-to-day activities.

You can have day-to-day apps in one user profile and put sensitive apps into another user profile. Reboot the phone before opening the sensitive profile. This way Verified Boot ensures that OS wasn't compromised before you type a PIN/password to open the sensitive profile.

malakaa

You can use something like Shelter or Insular (creates a managed work profile in main (owner) user account) so apps can easily be disabled. A quick tile will be added to easily disable or turn off all apps installed in the managed profile. Shelter v1.7 is available here

S9xD2yKV

Just going to add this to the last comment. It's a good comparison between the three options.
I have recently picked up Insular because it doesn't have any proprietary blobs and seems to be better maintained than Shelter. So far I really like it, not quite sure how much better isolated a different user would be though.