Separate user or work profile for "risky" apps?

published Jan 04, 2022, last modified Jan 17, 2022

What should I use, and what are the advantages / disadvantages of each, to sandbox untrustworthy apps in GrapheneOS?

Separate user or work profile for "risky" apps?

One of the questions that comes up often in GrapheneOS chat forums is related to running untrustworthy, "mystery meat", or other proprietary apps in GrapheneOS.  The operating system has great sandboxing capabilities, which (at least in principle) should be useful to run these kinds of apps in a confined space.

One thing that most everyone agrees on, is never to install or run these kinds of applications directly in your main user profile — as doing so would allow these applications to request or have access to your main user profile's data.  Also, profile data access is not the only problem; in addition to that, any two arbitrary apps can in fact communicate between each other (e.g. by using intents) without your knowledge, when both are running in the same profile.

All of this raises the question: if you should avoid running untrustworthy apps in your main user profile, then how do you run them?  Here are the two other ways.

Using a work profile

Android (and GrapheneOS) supports work profiles — the most common way to use them is through the app called Shelter, and many report success with Insular.  Once you create your work profile, you can install apps (including the Google Play Services suite) within.

The main advantage is that apps sandboxed this way blend seamlessly with the user experience of your main profile, and they are always running without you having to take any extra steps.  Of course, they are sandboxed in such a way that they cannot request data from your main profile — in this security sense, it is much like running apps as a separate user.

The main disadvantage, of course, is that you don't have a good degree of control as to whether and when these apps are running.   You can't easily shut them down when you are done with them, as you could with a separate user profile.  So, if an app in a work profile is leaking e.g. metadata when you are not actively using it, you can't easily control that.

It is worth noting that work profiles aren't intended for this use case:

It's using an OS feature (work profiles) to make separate groups of apps. Work profiles don't provide additional sandboxing but rather it's a workspace of apps with separate app data and shared (profile) data. It's the same app sandbox either way. User profiles are similar.

User profiles are more isolated and have their own encryption keys based on their lock method. Apps can't see apps in other user profiles or communicate with them. Work profiles have a weaker form of those properties. Work profiles require device management app which isn't ideal.

Using a separate user profile

Installing apps in a separate user is obviously more inconvenient — you have to enable multiple users, create a new user, and set it up... only to then install the apps you want, and perhaps you'll have to install some app stores to even install those apps.  Furthermore, to switch between one of these untrustworthy apps, and your regular main profile, you have to switch users — which is much more clumsy and slow than just using apps in a work profile.  What's more: you don't receive notifications and you can't interact with apps on your main profile, while you are logged on as a secondary user.

So those are the disadvantages.

The key advantage of separate user profiles is this: when you lock your screen, and select End session on the lock screen, your secondary user profile is truly shut off.  No application from that profile continues to run.  No encryption keys specific to the user are loaded in memory anymore.  You truly control when the apps are active — and thus when they can potentially leak metadata — and when you are done with them, you truly are done with them.

A further advantage is that you can, from your main user profile, completely disallow installation of applications by any app of the secondary user profile.  This way, not even you (as the secondary user) can accidentally enable installation or install more applications on the secondary user profile.  You would normally enable this prohibition after you are done setting up the secondary user.  This is probably a prudent thing to do, given that applications are installed system-wide, but made available to each profile on a per-user basis.

The future: nested user profiles?

From the GrapheneOS developers, we hear that nested user profiles will be implemented in the future (at the time of writing, they are unavailable):

We'll be adding proper nested profile support in the next year to replace needing to use a device management app to use work profiles. The feature isn't really designed for the use case of a user isolating apps. It'll be better with an implementation not using work profiles.

I hope this article has clarified the differences between using user profiles and work profiles.  Consider subscribing (see  bottom of page) if you want more information.