GrapheneOSJul 18, 2025

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
Show threadGrapheneOSJul 18, 2025
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.

Show threadGrapheneOSJul 18, 2025

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.

Show threadGrapheneOSJul 18, 2025
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.
Show threadGrapheneOSJul 18, 2025
/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.
Show threadGrapheneOSJul 18, 2025
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.
Show threadGrapheneOSJul 18, 2025
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.
Show threadGrapheneOSJul 18, 2025

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
Show threadGrapheneOSJul 18, 2025
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.
Show threadGrapheneOSJul 18, 2025
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
Show threadDemi Marie Obenour

@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.

    Jul 18, 2025 at 6:24pmWeb
    Show threadDemi Marie ObenourJul 18, 2025

    @GrapheneOS To be clear, please do not use this post as an excuse to shame package maintainers. They are doing their best given very limited resources. That said, I myself use proprietary Google Chrome precisely because I can count on it to update promptly.

    The proper solution is to make distro-agnostic packaging possible without losing security, and then to make a distro-agnostic package. Snap does not count because many people dislike Snap for legitimate reasons, such as being tied to a store with a proprietary implementation.

    Show threadGrapheneOSJul 18, 2025
    @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.
    Show threadGrapheneOSJul 18, 2025
    @alwayscurious /e/OS has regularly taken many months to ship Chromium updates. This is far more important than Linux distributions shipping it because people cannot simply use another browser engine. Even if users don't use the browser provided by /e/OS, their Chromium builds are providing the WebView used by many other apps. On Android, apps don't use Electron or an equivalent to it except in rare cases but rather the system WebView. On /e/OS, that's almost always outdated by at least weeks.
    Show threadDemi Marie ObenourJul 18, 2025
    @GrapheneOS Fair! I was thinking of Fedora and Debian, which have stricter packaging standards but which have problems keeping Chromium up to date.
    Show threadGrapheneOSJul 18, 2025
    @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.
    Show threadGrapheneOSJul 18, 2025
    @alwayscurious Debian has huge delays for security updates and misses a huge portion of them through only backporting patches with CVE assignments. They do eventually ship the Linux kernel LTS releases now and gave up on trying to backport Chromium or Firefox patches but in other cases they still don't even attempt to provide backports of patches with CVE assignments. In reality, most of the projects they're packaging do not actively seek CVE assignments so the approach doesn't actually work.
    Show threadGrapheneOSJul 18, 2025
    @alwayscurious For the Linux kernel, they invalidate correct CVE assignments for security issues in areas where the maintainers don't care about security and claim basic threat models most people have aren't valid including ext4. For most projects packaged by Debian, no one is even attempting to get CVEs assigned and there are often active efforts to push back against it. Linux kernel is assigning a huge number of valid and invalid CVEs with the goal of getting downstreams to ship LTS updates.
    Show threadDemi Marie ObenourJul 19, 2025
    @GrapheneOS Is rolling release the best way to run a distribution?
    Show threadGrapheneOSJul 19, 2025
    @alwayscurious It doesn't need to be called or considered a rolling release but either stable or long term support releases should be shipped in some reasonable period of time. Android moving to quarterly major releases is a very big improvement in this regard for updating external projects, etc. such as how they only ship the actual LTS revisions for the Linux kernel in those. We're just doing that ourselves since they aren't doing it well but rather quite similarly to Debian and others.
    Show threadDemi Marie ObenourJul 19, 2025
    @GrapheneOS Would building system packages with CFI be possible, or should Chromium be statically linked against bundled dependencies?