GrapheneOS provides much better privacy, stability and app compatibility than /e/ rather than only security. GrapheneOS entirely exists as a privacy project and focuses on security too in order to protect privacy. GrapheneOS is a privacy project aimed at being highly usability. There's a good third party comparison between them here:
/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:
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:
OP has found Graphene to be unusable and my experience has been similar. In contrast, I find /e/OS to be friendly and approachable as a daily driver. 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.
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.
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