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.
/e/OS targeted the founder of DivestOS in a similar way and /e/OS supporters directed a massive amount of harassment towards him. It played a significant role in DivestOS being discontinued. /e/OS will not achieve the same thing targeting our founder and should stop doing it.
/e/OS is extraordinarily insecure and non-private due to lagging so far behind on patches and crippling Android Open Source Project privacy/security protections. Selling many devices many months or even years of missing Critical severity patches and hiding it in the UI is wrong.

Murena's services are not nearly as private as claimed and not at all on the same level as serious options such as Proton's software suite. Many of their services recently went down from early October 2024 through March 2025:

https://community.e.foundation/t/update-on-murena-io-service-outage/61781

It's somehow a paid service.

Update on murena.io service outage

Since Oct 6 19:50 CET, most murena.io services have been unreachable. Affected services all murena.io services including drive, calendar, notes and email (@murena.io / @e.email) Over the air (OTA) /e/OS updates App Lounge All other websites including e.foundation, gitlab.e.foundation, community.e.foundation and murena.com remain unaffected. Context The reason behind this outage is related to our storage infrastructure that is getting old while the number of murena.io active users ha...

/e/OS community
@GrapheneOS Tad is a great Dev, always showed respect to the GrapheOS project and loved working on open source projects . Why not try to bring him to the team?
@ejim @divested That's who we're referring to. They have a lot of information published about the insecurity and non-privacy of /e/OS. Some of it isn't updated or available anymore but most if still relevant. There were pages tracking the update delays for /e/OS including for their browser/WebView. /e/OS of course had a major issue with accurate info being available about their OS and tried to silence that.

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

Thank you @jak2k for saying this. I wish @GrapheneOS would realize that and be more mature online. It's a pity such a good developer devaluates himself with these attacks.

@xav @jak2k GrapheneOS is an open source project with 10 developers paid by the non-profit GrapheneOS Foundation. It is not one person's project and not a hobby project. Duval participates in misrepresenting it as such because it serves his interests including encouraging /e/OS supporters to engage in further harassment.

Contrary to your misrepresentation of what's happening, each of our threads about this has been in response to misinformation about GrapheneOS and attacks on our project/team.

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

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

    @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.
    @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.
    @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.
    @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.
    @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.
    @GrapheneOS Is rolling release the best way to run a distribution?
    @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.
    @GrapheneOS Would building system packages with CFI be possible, or should Chromium be statically linked against bundled dependencies?
    @GrapheneOS what the heck!
    @f4grx See https://grapheneos.social/@GrapheneOS/114880528716479708 for a very good example of how it doesn't provide what's claimed. Their Murena Voice to Text service really just sends user audio data to OpenAI without informing users. Both Apple and Google support offline speech-to-text. In Gboard, it's enabled with the "Faster voice typing" toggle for downloading a local model and using that instead of the service. Contrast that with this OS marketed as a private alternative to those always sending the data to OpenAI.
    GrapheneOS (@[email protected])

    Apple and Google both provide support for offline speech-to-text using local models. Users can configure it to be fully offline. The Murena Voice to Text service in /e/OS 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-open-ai/70509

    GrapheneOS Mastodon