I personally don't use the separate user profiles at all. I agree they are clunky, due to how segregated they are. though with a work profile, and if needed (I don't use it atm) the newly added android feature, a private space, I feel there are plenty of compartmentalisation/sandboxing options available within a single user profile.
https://eylenburg.github.io/android_comparison.htm
/e/ regularly lags many weeks and months behind on essentially privacy and security patches for Android, the browser engine used by many apps, the Linux kernel, drivers and firmware. It doesn't preserve the standard Android privacy and security model either. It isn't safe from a privacy or security perspective for those reasons. It doesn't take a nation state attacker to exploit not having patches for many known browser/OS privacy and security vulnerabilities.
Despite the misleading marketing, /e/ always uses multiple Google services and integrates them into the OS with privileged access unavailable to other services. They automatically download and run Google code with privileged access along with giving privileged access to certain Google apps when they're installed including Android Auto.
Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches:
https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nich...
Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service:
https://community.e.foundation/t/voice-to-text-feature-using...
Information from the founder of the Divested projects:
Issues with /e/: https://codeberg.org/divested-mobile/divestos-website/raw/co... ASB update history: https://web.archive.org/web/20241231003546/https://divestos.... Chromium update history: https://web.archive.org/web/20250119212018/https://divestos.... Chromium update summary: https://infosec.exchange/@divested/112815308307602739
A lot of the rest of this post reads as hostile FUD: /e/OS ships with microg (https://en.wikipedia.org/wiki/MicroG) that provides FLOSS reimplementations for some Google services - users can optionally choose to log in with their Google account. Providing this choice out of the box is controversial for people who want a complete and total break from Google.
No, they're describing heavily using user profiles as not being usable. User profiles are a standard Android feature. GrapheneOS provides small improvements for user profiles as a tiny part of what we do. Using user profiles is in no way required to benefit from what GrapheneOS offers. They're describing a specific way they chose to use the device that's not GrapheneOS related as not being usable. What does any of what they said about user profiles being inconvenient and painful to heavily use for isolating groups of apps have to do with GrapheneOS specifically?
> my experience has been similar
Your reply shows you lack experience with GrapheneOS.
> In contrast, I find /e/OS to be friendly and approachable as a daily driver.
This is the direct opposite of nearly everyone's experience who has tried both, which you do not appear to have done.
> To be honest, I don't care if it's a few weeks behind on ASOP patches, it's still far better than the average OEM Android distribution.
/e/ lags many months and even years behind on privacy and security patches, not a few weeks. The amount it's behind depends on the device. On the Pixel 7, they're multiple years behind on kernel, driver and firmware security patches.
> A lot of the rest of this post reads as hostile FUD
No, it's your inaccurate claims about GrapheneOS privacy and usability which are accurately described that way. Everything in my posts about /e/ here is accurate and verifiable information. People should check the third party sources I linked and do research on it.
> /e/OS ships with microg
Our sandboxed Google Play compatibility layer is also open source. Both microG and sandboxed Google Play exist to provide compatibility with closed source code running on the device. microG receives substantial privileged access and the closed source code which it downloads/runs as part of itself and which runs in the apps using it has much more access to your data than it does on GrapheneOS. The Google services themselves don't become any more open source and neither do the Google Play libraries within apps, which often don't require Play services to function.
> users can optionally choose to log in with their Google account
GrapheneOS has no Google services built in and installing/using sandboxed Google Play does not require an account.
> Providing this choice out of the box is controversial for people who want a complete and total break from Google.
GrapheneOS provides the option to use Google apps and apps depending on them but doesn't bake in privileged Google services to the OS which are always enabled like /e/. On /e/, there's no way to avoid connecting to multiple Google services or to avoid how they're baked in with privileged access. A subset of these are covered in https://eylenburg.github.io/android_comparison.htm but not the ones added by /e/, only the ones present in AOSP which are not replaced by it.
You are a partisan. I'm sure all your points are correct in some narrow technical sense, but I agree with OP: Graphene is an OS for geeks who want to geek out about security, not for normal people who want to use a smartphone without surrendering all their digital privacy.
Independent researchers have confirmed that /e/OS leaks very little data, and that's good enough for me https://www.tcd.ie/news_events/articles/study-reveals-scale-...
If you're a security nerd, live in an authoritarian state, or you're a targeted activist, Graphene is a better choice – although, really, you should be using a burner phone or staying offline.
I provided accurate and verifiable information. You are yourself clearly here to promote /e/ and attack GrapheneOS, which you're doing with objectively false claims about both.
/e/ has far lower app compatibility and stability. It lags many months and years behind on critical privacy and security patches. Their services were down for many months recently. It has major issues with stability and functionality across devices. Those are facts.
People can verify that what I've said is accurate along with looking at the third party sources from actual experts, contrary to the phony inaccurate study from 2021 done in coordination with /e/ that you've provided.
> I'm sure all your points are correct in some narrow technical sense
They're all accurate and not only in a narrow sense.
> Graphene is an OS for geeks who want to geek out about security, not for normal people who want to use a smartphone without surrendering all their digital privacy.
GrapheneOS objectively provides far better app compatibility and stability than /e/. It's far better tested and provides the current generation Android functionality and usability rather than being based on old versions.
> Independent researchers have confirmed that /e/OS leaks very little data
The paper doesn't claim any such thing and /e/ has added multiple kinds of invasive telemetry and services since 2021. You should check the much more up-to-date and better researched information from Mike Kuketz and Divested. Your claim that they're independent researchers is unsubstantiated and contradicted by information which has come out about the motivations and methodology behind what they published. /e/ was involved in it.
> If you're a security nerd, live in an authoritarian state, or you're a targeted activist, Graphene is a better choice – although, really, you should be using a burner phone or staying offline.
/e/ isn't safe to use due to lack of current privacy and security patches. It should be avoided by anyone who cares the slightest about privacy or security. Going years without receiving important patches for serious privacy and security issues is a severe problem.
Contrary to what you're claiming, GrapheneOS provides much better app compatibility and stability.
Murena's services were recently down from early October 2024 through March 2025, for an idea of what people can expect from the OS and services:
https://community.e.foundation/t/service-outage-announcement...
Your argument boils down to "Graphene is so secure that it's like having two phones in one: one that has a cool greyscale theme but doesn't do anything, and a sandboxed Google phone with all your apps, Google Play services, and personal data on it."
It is completely the user's choice to put sandboxed google play in a private space or secondary user profile. It is completely the user's choice to put sandboxed google play services in the owner profile and not use multiple profiles at all. It is completely the user's choice to source apps from outside Google Play.
The goal of /e/OS is to provide a more-private degoogled OS that is usable out of the box by normal people: an app store, maps, etc.
This whole conversation reminds me of talking to Slackware users in the early 2000s: "I don't understand what you mean, it's compatible with everything you just have to recompile it. It's 100% secure, it comes with zero services running."
(I googled this, cannot attest to the accuracy of these rebuttals)
This just isn't true. Switching profiles is nothing like rebooting the phone. It takes about 8 seconds to go thru the entire procedure. That's including about 3 seconds to load the 2nd profile (even an unloaded profile). The procedure on my Pixel 7 goes:
- Swipe down to open the Notification Panel
- Swipe down again to expand the Quick Settings
- Tap the User icon at the bottom
- Select the user profile you want to open
- Wait 3 seconds
- Enter the 2nd user's PIN to log in
That's 4 taps + 3 seconds of load time.
Google Play and associated services are not bundled with GrapheneOS, they are completely optional.
> I found the profile feature to be only slightly more convenient than having two physical devices.
User Profiles is a feature inherited from AOSP. This is what AOSP says about the feature: "Android supports multiple users on a single Android device by separating user accounts and app data. For instance, parents might allow their children to use the family tablet, a family can share an automobile, or a critical response team might share a mobile device for on-call duty."
In the community it is popular to use multiple profiles to compartmentalise personas or group apps with hard google service dependencies together, but this is all completely optional. GrapheneOS as a project gently suggest keeping everything in the same initial owner profile and then moving things around to suit your comfort level.
> It's my device, not google's, and certainly not Graphene's.
You've clearly endured a lot of frustration when using the OS. Are there any specific things you remember trying to do that were blocked or prevented by GrapheneOS? It's not a project with unlimited resources, but actionable information about limitations and bugs can potentially be addressed if known.
There are no restrictions on what people can do added by GrapheneOS compared to the Android Open Source Project / stock Pixel OS.
> Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
GrapheneOS doesn't come with Google Play. You would have had to install it yourself and those run as regular sandboxed apps with no special access. It doesn't make sense to turn it off and on which will break apps set up to depend on it. If you only want to use it with specific apps when needed, the right approach is using a dedicated profile for it. By turning it off, you were breaking apps installed in the same profile with it which use it.
Using a single profile with sandboxed Google Play is perfectly fine and doesn't ruin the privacy and security provided by GrapheneOS. Putting it into a separate profile is optional. Sandboxed Google Play are regular apps in the regular app sandbox with zero special access or privileges. Using multiple profiles to split things up is a more advanced approach.
> I found the profile feature to be only slightly more convenient than having two physical devices.
That's the purpose of secondary users. There are also the more convenient work profiles and Private Spaces. All 3 of these features are standard Android features. GrapheneOS enhances user profiles and Private Spaces in various ways but they're not at all mandatory and there's nothing pushing people to use them more than the stock OS. There's a widespread misconception that the sandboxing of sandboxed Google Play is tied to profiles but it's not.
> The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
GrapheneOS deeply cares about user experience including app compatibility. We have limited resources so we haven't been able to replace or overhaul all of the AOSP apps yet, which is the main weakness of the out-of-the-box experience. Those can all be replaced by the user's choice of apps.
> Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
No, not at all.
> Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Profiles are an Android feature, not a GrapheneOS feature, and only a tiny portion of our features have to do with them. The features page at https://grapheneos.org/features covers most of the features added by GrapheneOS, and very little of that has to do with profiles. It sounds like you chose to heavily use secondary users and didn't like that, which has little to do with GrapheneOS specifically.
> Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices. > > I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.
GrapheneOS did not create Android's user profile feature. It makes enhancements to it but it's not a major focus of what we work on. You aren't missing many of the GrapheneOS features if you don't use user profiles. Enabling more standard user profile functionality, notification forwarding, allowing more user profiles and a few other minor things are all we do with those. We have a substantial set of privacy and security features and nearly none of it has to do with profiles. Adding clipboard control to Private Space and enabling making Private Spaces in secondary users are how we improve those. Many GrapheneOS users only use an Owner user or Owner with a Private Space and/or work profile. Secondary users are a much more specialized thing. It's not expected that people split things across a bunch of secondary users, that's an advanced power user approach.
#!/data/data/com.termux/files/usr/bin/bash
PACKAGE="com.google.android.gms com.google.android.gms.policy_sidecar_aps com.google.android.gsf com.android.vending"
PATH="/data/data/com.termux/files/usr/bin:$PATH"
command=$(echo "$0"|cut -d: -f2)
pman () {
action=$1
shift
for package in $@; do
sudo pm $action $package
done
}
case $command in
disable|enable)
pman $command $PACKAGE
;;
*)
echo "command '$command' not supported"
;;
esac
exit 0
Notice that the script can enable/disable multiple packages by adding package names to the $PACKAGES variable.
I enable and disable things like Google Services manually but the scheme can be extended as much as you wish, eg. by creating spin lock files to indicate whether a specific package is needed as a dependency for another package. This is left as an exercise for the reader.
Shizuku helps normal apps to use system APIs without root. You can enable it with from a computer with adb or from the phone itself using wireless debugging. Hail uses Shizuku's API access and lets you select apps to freeze. You can then unfreeze / refreeze apps with a quick tap in Hail.
If you already have root, all this becomes easier. If you do the wireless debugging method, Shizuku's API access won't survive a reboot. You'll have to go thru the wireless debugging procedure again before you can use Hail. https://shizuku.rikka.app/guide/setup/
Disabling Google Play apps as you're describing will heavily break other apps and will cause lots of issues. It will not reduce what they can do or access. It's not an alternative to the privacy or security features provided by GrapheneOS. What the person above is describing has little to do with GrapheneOS specifically and doesn't make sense as an approach to using it.
Recommend reading https://grapheneos.org/features and looking at https://eylenburg.github.io/android_comparison.htm for an understanding of what GrapheneOS provides.
Apart from having to tweak some location permissions for when I wanted to copy the BankID credentials from my old phone I haven't had to any tweaking or anything to get it to just work.
Sure it's cool you can turn off google play, but I found myself having to go into the menus and through the six or seven clicks to turn google play back on at least daily.
I found the profile feature to be only slightly more convenient than having two physical devices. I could not find any real use for it. I thought I'd set up a work profile to attach to my work gsuite account. Nope, unsupported. I can't attach my work google account at all. Maybe I can just put all my google play dependent apps in a profile? Sure, but to get to them is just about as convenient as rebooting the phone from cold. And notifications are not forwarded to other profiles. If an event happens in another profile, you get a notification that there is a notification. You still have to drop everything to reboot into the other profile to check that you got an emote reaction to your Discord message. Great use of my time.
The entire thing seems like theater designed to show everyone that they're doing absolutely everything to be Secure, and user experience is a tertiary concern at most.
Graphene is not an OS for normal people to use. It's designed as an OS for nerds who want to nerd about how "secure" and "private" their device is, irrespective of how usable it is.
Again, I tried for months to like it. Once I realized the security features were really only one step removed from having two devices, I just gave up. I'd rather be able to use my device the way I want than to be "secure" and only use my phone the way Google wants. Sorry, I meant Graphene.
Given the choice between two third party entities dictating to me how I'm allowed to use my own device, I'd rather just use lineage and make my own choices.
I don't want my OS to coddle me and lock me into padded playpens, I want it to get the hell out of my way and do exactly what I tell it to, even if that action is not in line with what some unknown third party thinks is in my best interest. It's my device, not google's, and certainly not Graphene's.