We published this response to a recent article promoting insecure devices with /e/OS with inaccurate claims, including inaccurate comparisons to GrapheneOS:

https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

The founder of /e/OS has responded with misinformation promoting /e/OS and attacking GrapheneOS.

Devices lacking standard privacy/security patches and protections aren't private - GrapheneOS Discussion Forum

GrapheneOS discussion forum

GrapheneOS Discussion Forum
We made a post with accurate info on our forum in response to inaccurate information, that's all. There's a lot more we could have covered. See https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6/ for several examples such as /e/OS having unique user tracking in their update client not communicated to users.
/e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6

/e/ punktet beim Datenschutz, aber hinsichtlich der Sicherheit bestehen erhebliche Bedenken.

The founder of /e/OS responded to the post we made on our forum here:

https://mastodon.social/@gael/114874688715085353

Gaël Duval has repeatedly personally targeted the founder of GrapheneOS in response to us posting accurate information responding to misinformation from /e/OS and their supporters.

Contrary to what's claimed in this thread, /e/OS does not improve privacy. /e/OS massively reduces privacy compared to the Android Open Source Project in multiple ways. /e/OS is consistently very far behind on shipping important privacy improvements in new major Android releases.
/e/OS regularly lags many weeks, months and even years behind on shipping important privacy and security patches. They roll back various parts of the privacy and security model, add a bunch of privileged Google service integration and their own privacy invasive services too.
The link posted at https://mastodon.social/@gael/114875028964272029 shows /e/OS shipping the previous round of Chromium privacy/security patches a couple weeks late. It regularly takes them months instead of weeks. They take far longer to ship many of the important driver, firmware and AOSP patches.
The link also shows they're using the wrong Chromium tags for Android and frequently results in missing Android-specific privacy/security patches. Chromium 138.0.7204.97 was a June 30th release for Windows, not Android. The Android tag for June 30th was 138.0.7204.63.

https://chromereleases.googleblog.com/2025/07/stable-channel-update-for-desktop_15.html
https://chromereleases.googleblog.com/2025/06/chrome-for-android-update_30.html

Patches in Chromium Stable channel updates for Android are often only in the Android tags, not the Windows ones.

The current Android release is 138.0.7204.157, with security patches beyond 138.0.7204.63:

https://chromiumdash.appspot.com/releases?platform=Android

Stable Channel Update for Desktop

The Stable channel has been updated to 138.0.7204.157/.158 for Windows, Mac and 138.0.7204.157 for Linux which will roll out over the coming...

Chrome Releases
These were minor releases of Chromium. It's trivial to incorporate the changes and ship them on release day within hours. Even major releases of Chromium every ~4 weeks are easy to ship on release day because major releases are open source for weeks in advance, unlike Android.
As can be seen by looking back through https://github.com/GrapheneOS/Vanadium/releases and comparing it to the Android release dashboard linked above, we ship the Chromium Stable and Early Stable releases on release day. This is not impressive. Shipping privacy/security patches is the bare minimum.
Releases · GrapheneOS/Vanadium

Privacy and security enhanced releases of Chromium for GrapheneOS. Vanadium provides the WebView and standard user-facing browser on GrapheneOS. It depends on hardening in other GrapheneOS reposito...

GitHub
Our forum post and this thread were both posted in response to inaccurate info about GrapheneOS posted to promote /e/OS. Once again personally targeting our founder with fabricated stories and harassment from their community is what /e/OS has done before and continues doing.

@GrapheneOS He is posting the same stuff about you, as you about them. You are both creating long threads, how childish the other one is.

This makes everyone, no matter if they are using Graphene OS, /e/OS or something else, trust both of you less. There are enough people using an insecure OS just because they don't trust you because of this kind of bullshit behavior. Please stop it. It's more damaging than their posts about you.

@jak2k /e/OS is an extraordinarily insecure and non-private OS. If people avoid it and use an iPhone instead, they'll have far better privacy and security.

The information we've provided in this thread and on our forum is accurate and verifiable. We've included a link to a post by Mike Kuketz, a neutral third party privacy/security researcher, where he covers many of the issues with /e/OS. We can include additional third party sources about it.

/e/OS is not safe and SHOULD be avoided.

@GrapheneOS Yes, I know that, but these threads are still destroying trust into you.

(Besides, I don't think Apple offers better privacy. They do a lot more tracking that just a single ID and a single request to Google.)

@jak2k /e/OS lacks basic privacy and security patches. Users are left vulnerable to critical, remotely exploitable issues for many weeks, months and even years. Users are sold end-of-life devices without driver/firmware patches or devices where /e/OS doesn't keep up with them. For example, they sell Pixels where they are not on the current OS release and can't provide the current driver/firmware updates so users are left vulnerable for a year or more to serious issues patched in updates.
@jak2k Android Open Source Project has weaker privacy from apps than iOS. /e/OS further weakens it by lagging far behind the current releases and rolling back the standard privacy/security model/features in multiple ways. iOS has rough equivalents to our Contact Scopes and Storage Scopes features. /e/OS has an enumerating badness approach of DNS filtering which can't block most privacy invasive connections and is not only easily bypassed but actively bypassed by Facebook and others in practice.
@jak2k Listing our domains which are solely used for things users don't want and blocking their DNS resolution does not stop apps connecting to those via IPs or their own DNS resolution, which are both widely used approaches now. It's also only usable for blocking functionality not required for apps to work. They can do all the privacy invasive stuff via the allowed connections and arbitrarily communicate with third parties server side which is better for them due to not leaking API keys anyway.

@jak2k There are better implementations of DNS-based filtering including RethinkDNS.

> Yes, I know that, but these threads are still destroying trust into you.

You're claiming to speak for others and you don't. The vast majority of responses to us posting accurate information correcting inaccurate claims about GrapheneOS and products being marketed by attacking us is support for it. Many people are thankful we provide this information educating people and linking to others doing the same.