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

@GrapheneOS It's a good reason to not use distribution Chromium packages. Linux distributions often fail to keep up with Chromium releases. I expect that this is due to three factors:

  • Not having people who are paid to do the job.
  • Having to build on infrastructure that is weaker than what GrapheneOS has.
  • Having to add a bunch of patches for various reasons, sometimes related to software patents.
  • I strongly hope that a Flatpak-based sandbox gets upstreamed to Chromium. This would allow Chromium to be shipped as a distribution-agnostic flatpak, so many distro-specific packages could be retired.

    @alwayscurious Chromium package in Arch Linux follows along with the Stable and Early Stable releases of Chromium at a similar pace as GrapheneOS. Those go through a [testing] repository similar to our Alpha and Beta channels first. They take a similar amount of time to move it through there due to the importance of browser security patches. There are likely other Linux distributions doing a similarly good job shipping Chromium updates. There are downsides to the Arch package but that's not one.
    @GrapheneOS Fair! I was thinking of Fedora and Debian, which have stricter packaging standards but which have problems keeping Chromium up to date.
    @alwayscurious Debian if anything has far lower standards and allows maintainers to make all kinds of misguided changes to packages. Fedora at least started making changes to their Chromium build options based on feedback from our community members to enable the production security features such as CFI like the Arch package. Neither Fedora or Arch has the intended scale of CFI deployment because they're enabling using distribution libraries for tons of things without building those with CFI.
    @GrapheneOS Would building system packages with CFI be possible, or should Chromium be statically linked against bundled dependencies?