A false narrative is being pushed about GrapheneOS claiming we're ending operations in France due to the actions of 2 newspapers. That's completely wrong. If both newspapers and the overall French media had taken our side instead of extreme bias against us, we'd still be leaving. We're ending operations in France and ending our use of French companies (mainly OVH) to provide services because of direct quotes by law enforcement in dozens of French news publications. Their inaccurate claims about GrapheneOS and thinly veiled threats were our sign to leave.

We no longer have any active servers in France and are continuing the process of leaving OVH. We'll be rotating our TLS keys and Let's Encrypt account keys pinned via accounturi. DNSSEC keys may also be rotated. Our backups are encrypted and can remain on OVH for now.

Our App Store verifies the app store metadata with a cryptographic signature and downgrade protection along with verification of the packages. Android's package manager also has another layer of signature verification and downgrade protection.

Our System Updater verifies updates with a cryptographic signature and downgrade protection along with another layer of both in update_engine and a third layer of both via verified boot. Signing channel release channel names is planned too.

Our update mirrors are currently hosted on sponsored servers from ReliableSite (Los Angeles, Miami) and Tempest (London). London is a temporary location due to an emergency move from a provider which left the dedicated server business and will move. More sponsored update mirrors are coming.

Our ns1 anycast network is on Vultr and our ns2 anycast network is on BuyVM since both support BGP for announcing our own IP space. We're moving our main website/network servers used for default OS connections to a mix of Vultr+BuyVM locations.

We have 5 servers in Canada with OVH with more than static content and basic network services: email, Matrix, discussion forum, Mastodon and attestation. Our plan is to move these to Netcup root servers or a similar provider short term and then colocated servers in Toronto long term.

France isn't a safe country for open source privacy projects. They expect backdoors in encryption and for device access too. Secure devices and services are not going to be allowed. We don't feel safe using OVH for even a static website with servers in Canada/US via their Canada/US subsidiaries.

We were likely going to be able to release experimental Pixel 10 support very soon and it's getting disrupted. The attacks on our team with ongoing libel and harassment have escalated, raids on our chat rooms have escalated and more. It's rough right now and support is appreciated. It's not possible for GrapheneOS to produce an update for French law enforcement to bypass brute force protection since it's implemented via the secure element (SE). SE also only accepts correctly signed firmware with a greater version AFTER the Owner user unlocks successfully.

Please listen to this podcast about ANOM:



The FBI ran a string operation in Europe where they created their own 'secure' phone and messaging platform. Their OS used portions of our code and was heavily marketed as being GrapheneOS or based on GrapheneOS.darknetdiaries.com/transcript/146/ Through this operation, the FBI provided criminals in Europe with a communication network they heavily trusted. It gave them much more confidence to coordinate and commit crimes. The vast majority of this crime was ignored for years to avoid exposing ANOM as being a honey pot.

We were contacted by a journalist at Le Parisien newspaper with this prompt:

> I am preparing an article on the use of your secure personal data phone solution by drug traffickers and other criminals. Have you ever been contacted by the police? Are you aware that some of your clients might be criminals? And how does the company manage this issue?

Absolutely no further details were provided about what was being claimed, who was making it or the basis for those being made about it. We could only provide a very generic response to this.

Our response was heavily cut down and the references to human rights organizations, large tech companies and others using GrapheneOS weren't included. Our response was in English was translated by them: "we have no clients or customers" was turned into "nous n’avons ni clients ni usagers", etc...

GrapheneOS is a freely available open source privacy project. It's obtained from our website, not shady dealers in dark alleys and the "dark web". It doesn't have a marketing budget and we certainly aren't promoting it through unlisted YouTube channels and the other nonsense that's being claimed.

GrapheneOS has no such thing as the fake Snapchat feature that's described. What they're describing appears to be forks of GrapheneOS by shady companies infringing on our trademark. Those products may not even be truly based on GrapheneOS, similar to how ANOM used parts of it to pass it off as such.

France is an increasingly authoritarian country on the brink of it getting far worse. They're already very strong supporters of EU Chat Control. Their fascist law enforcement is clearly ahead of the game pushing outrageous false claims about open source privacy projects. None of it is substantiated.

iodéOS and /e/OS are based in France. iodéOS and /e/OS make devices dramatically more vulnerable while misleading users about privacy and security. These fake privacy products serve the interest of authoritarians rather than protecting people. /e/OS receives millions of euros in government funding.

Those lag many months to years behind on providing standard Android privacy and security patches. They heavily encourage users to use devices without working disk encryption and important security protections. Their users have their data up for grabs by apps, services and governments who want it.

There's a reason they're going after a legitimate privacy and security project developed outside of their jurisdiction rather than 2 companies based in France within their reach profiting from selling 'privacy' products.

discuss.grapheneos.org/d/24134-device…

Here's that article:

archive.is/AhMsj There's another article posted at . We don't have a subscription to access it so we can't evaluate whether the coverage is fairer. Need our community to check. There's an ongoing attempt to smear GrapheneOS by French government agencies so there will be more articles.lefigaro.fr/secteur/high-t…

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



The founder of /e/OS has responded with misinformation promoting /e/OS and attacking GrapheneOS.discuss.grapheneos.org/d/24134-device… 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 for several examples such as /e/OS having unique user tracking in their update client not communicated to users.kuketz-blog.de/e-datenschutzf…

European authoritarians and their enablers in the media are misrepresenting GrapheneOS and even Pixel phones as if they're something for criminals. GrapheneOS is opposed to the mass surveillance police state these people want to impose on everyone.

xatakandroid.com/sociedad/cada-… There are ongoing coordinated attempts at misleading people about GrapheneOS and Signal in multiple European countries. A consistent pattern are completely unsubstantiated claims about exploits with no evidence. These are contradicted by actual evidence, leaks and their behavior.

@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ is what we recommend for a comparison but it does not compare to iOS. iOS has a lot more substance behind the privacy and security marketing than nearly any niche products/projects though. iOS does get targeted more right now but that's not all bad.

https://x.com/GrapheneOS/status/1935410250716479532

@Don_Angelo_ @Aazadi_e_Afkaar @richimedhurst @Mehdi_14_ You can see from that GrapheneOS is not only on the radar of companies developing exploits but they put work into trying to support it. If there's something successfully protecting people and it's gaining adoption, effort will be put into exploiting it.discuss.grapheneos.org/d/14344-celleb…

We're going to be moving forward under the expectation that future Pixel devices may not meet the requirements to run GrapheneOS () and may not support using another OS. We've been in talks with a couple OEMs about making devices and what it would cost.grapheneos.org/faq#future-dev… In April 2025, we received leaked information about Google taking steps to strip down the Android Open Source Project. We were told the first step would be removal of device support with the launch of Android 16. We didn't get details or confirmation so we didn't prepare early.

In May, we began preparing to port to Android 16 despite our most active senior developer responsible for leading OS development being unavailable (). Android 16 launched today and porting is going to be significantly more difficult than we were expecting.

https://x.com/GrapheneOS/status/1913252270654783506

We did far more preparation for Android 16 than we've ever done for any previous yearly release. Since we weren't able to obtain OEM partner access, we did extensive reverse engineering of the upcoming changes. Developers also practiced by redoing previous quarterly/yearly ports.

Our Contact Scopes and Storage Scopes features provide essential privacy functionality that's missing on standard Android. Scopes are a replacement for the standard contacts, storage and media permissions. We offer these as an alternative when apps request access to any of those. When you enable Contact Scopes or Storage Scopes, GrapheneOS makes the app believe you've granted the requested permissions. However, it doesn't receive access to any more additional data not created by itself. Most apps work by simply enabling these without doing anything more.

Similar to iOS lockdown mode, Android 16's Advanced Protection feature is misguided. It adds security features exclusive to it which require using all of the other features. This prevents people using new security features if they need to avoid 1 feature.

security.googleblog.com/2025/05/advanc… Most of the features already existed. The new ones are cloud-based intrusion logging, inactivity reboot (hard-wired to 72 hours), a new mode of USB protection and disabling auto-connect to a small subset of insecure Wi-Fi networks. Production MTE support is also essentially new.

@MishaalRahman Android 12 API for this will stop most of Cellebrite's current attacks since they target Linux kernel USB peripheral drivers. However, they could switch to targeting the Linux USB-C protocol implementation which doesn't get disabled by the Android 12 API, only high level drivers. @MishaalRahman By default, our feature blocks new connections in both software (similar to the standard toggle) and hardware but allows existing connections established while unlocked to continue. Once those end, it disables USB-C and pogo pins data (USB-C is more than USB) at a hardware level.

@matthew_d_green Signal itself is not hardened against attacks. It doesn't use sandboxing for media or WebRTC. Chromium-based browsers run those in the renderer sandbox, Signal simply runs them unsandboxed as part of the rest of the app. It doesn't use more than basic exploit protections, etc. @matthew_d_green Signal for Android is at least almost entirely written in memory safe code (Kotlin and Java) with lots of dependencies not having memory unsafe code, but media handling and especially WebRTC are not particularly secure. Signal is not currently putting much effort into this area.

Our 2025030900 release currently in the Beta channel is the first one with support for managing hardware-based virtual machines via the Terminal app in Android 15 QPR2. Since then, we've backported massive improvements to the feature for an upcoming new release, maybe even today. Backports include terminal tabs, GUI support with opt-in GPU hardware acceleration (ANGLE-based VirGL until GPU virtualization support is available), speaker/microphone support and fixes for a bunch of bugs including overly aggressive timeouts. We're working on VPN compatibility.

This post is needed to debunk misinformation from a charlatan (@hackerfantastic) masquerading as being a legitimate security researcher. They used to be quite successful at duping people into believing they were legitimate by taking credit for other people's work and fabricating vulnerabilities, which hasn't held up for them in the long term. They have historical follows from actual researchers from before their credibility disintegrated which is part of why people still fall for it. They are not a legitimate researcher and many of their past claims of exploits including phony systemd exploits have been debunked. Lennart Poettering is one of several people to debunk their made up vulnerabilities and had their replies hidden along with being blocked, which is the same approach they just took with us (see the hidden posts at x.com/hackerfantasti… for an example). The many unsubstantiated claims they make should not be believed. We can't reply at all within those threads anymore due to the new way blocking works so we're replying here instead.

Their main attempt at attacking us is making the ridiculous and downright desperate false claim that somehow the only purpose of GrapheneOS is using OpenBSD heap allocators, which it hasn't even used since before we made hardened_malloc in 2018:

x.com/hackerfantasti…
x.com/hackerfantasti…
x.com/hackerfantasti…

Our hardened_malloc project is an important sub-project protecting very well against the majority of remote code execution exploits in the userspace part of the OS. However, it's a tiny portion of our overall work and only one of many major privacy and security features we provide. Even if we did still use OpenBSD malloc for 32-bit apps on older devices still supporting them, that wouldn't be a significant part of the project at all.

They're promoting that people use a highly insecure device without the most basic hardware, firmware and software security features where data can be trivially extracted from the device without even using exploits and where far more vulnerabilities are exposed with negligible protection against them being exploited:

x.com/hackerfantasti…

GrapheneOS is a Linux distribution based on the Android Open Source Project (AOSP). Compared to a traditional desktop Linux distribution, AOSP is already very hardened and provides dramatically better privacy and security. It's a night and day difference. Traditional desktop Linux distributions struggle to deploy exploit protections from the early 2000s and lack proper app sandboxing. They lack systemic privacy and security work throughout the OS as a whole. They're really a bunch of largely anti-security projects glued together into a frankenstein OS with the development direction set by these individual projects, not the distributions. They ship what's provided to them, and the result is not a particularly secure OS. iOS and AOSP are far more secure than these operating systems. A bunch of companies having badly maintained forks of AOSP does not reflect on AOSP itself, but even those are far more secure than traditional desktop operating systems if they're doing the bare minimum of providing security patch backports.

Android Open Source Project without our improvements is far more secure than desktop Linux distributions. It already has a far more hardened kernel with a huge amount of attack surface reduction via the kernel configuration, very advanced use SELinux and to a lesser extent seccomp-bpf. The differences in userspace are far more dramatic. It has a well designed mandatory app sandbox and sandboxing heavily used throughout the OS. It has strict full system SELinux MAC/MLS policies which the OS is developed around rather than being added on afterwards. The majority of new code is being written in memory safe languages (Rust, Java, Kotlin). It was always focused on memory safety, sandboxing, etc. from the start. Privacy and security are a major focus throughout it and many design compromises are made for them rather than being an afterthought. Backwards incompatible privacy and security changes are made to the app sandbox on a yearly basis.

Our features compared to the latest release of the standard Android Open Source Project are documented at grapheneos.org/features. This page only covers our improvements and does not cover the standard AOSP privacy and security features. The subset of our features which have been landed upstream by us such as FORTIFY_SOURCE for the Linux kernel string library have been removed from our features page.

Our hardened_malloc project provides great protection against heap corruption vulnerabilities in userspace but that's just one small part of the overall GrapheneOS project. Prior to making our hardened_malloc project in 2018, we used our own fork of OpenBSD malloc ported to Linux and extended with significant additional security features. This had to be replaced as a whole to provide substantially better security against heap vulnerabilities.

This charlatan (@hackerfantastic) is spreading misinformation about GrapheneOS because they had a business deal with Copperhead after the failed takeover attempt on GrapheneOS. They were trying to sell devices with their insecure, closed source fork of legacy GrapheneOS versions. They hold a grudge against us based on their business venture failing and are trying their best to spread misinformation about it. Unfortunately for them, they don't have the faintest clue about what we work on and what we provide in current generation GrapheneOS. They responded to us responding with polite, accurate information by hiding our posts, blocking us and doubling down on blatant misinformation which we already pointed out.

If you want to go down a deep rabbit hole, look into how the company they co-founded, Hacker House, got money through government corruption. If they keep going down the road of supporting harassment content targeting our team, we can make a post about this. Pinephone Pro is closed source hardware with closed source firmware. The components it uses have incredibly poor security. It lacks very basic privacy and security features from hardware through software. It's not open hardware, it's just false marketing.

https://x.com/hackerfantastic/status/1888241083882086890

Revolut is specifically banning GrapheneOS by checking for the build machine hostname and username being set to grapheneos. We've changed these to build-host and build-user. Combined with another change, this allow our users to log in to it again until they roll out Play Integrity API enforcement.

There's no legitimate excuse for banning using a much more private and secure operating system while permitting devices with no security patches for a decade. Meanwhile, Revolut's shoddily made app tells users they're banning GrapheneOS because they're "serious about keeping your data secure".

Revolut's app will stop working against once they start enforcing having a Play Integrity API result showing it's a Google certified device. This is not a security feature but rather anti-competitive behavior from Google deployed by apps like Revolut wanting to pretend they care about security.

Revolut uses a bunch of shady closed source third party libraries in their app and it's one of these libraries banning GrapheneOS. These libraries are a major security risk and put user data at risk of being compromised. Revolut is not taking user security seriously at all and is cutting corners. There's no legitimate reason for any app to ban GrapheneOS users. It has the full standard security model and massive security improvements. There's no logic in banning GrapheneOS. It makes no sense for them to ban anything when they permit a device with no patches for 10 years. It's performative.

GrapheneOS fully supports standard Android hardware attestation for verifying the hardware, firmware and operating system along with the app that's using it. See grapheneos.org/articles/attes…. If apps insist on checking device integrity, that's the only way they should do it.

Play Integrity API checks that Google's monopolies are supported through devices licensing Google Mobile Services and integrating their browser, search engine, advertising, etc. It's anti-competitive and clearly illegal. Multiple governments are taking regulatory action and are in contact with us.

@weare_unplugged @fndr76 Unplugged's hardware, firmware and software is highly insecure relative to an iPhone or Pixel and doesn't meet our basic security requirements:



Unplugged are making incredibly false claims about how what they provide compares to GrapheneOS on a Pixel.grapheneos.org/faq#future-dev… @weare_unplugged @fndr76 An iPhone is legitimately a far better option for privacy and security than an Unplugged device. Unplugged has been repeatedly attacking GrapheneOS unprovoked with false claims about it along with false claims about iPhones and Pixels. That's their approach to marketing.

Android 15 QPR2 is moving 6th/7th/8th generation Pixels to the Linux kernel's 6.1 LTS branch already used for 9th generation Pixels. This will reduce the kernel branches we need to support down to 6.1 and 6.6. There will likely need to be a yearly migration for all the devices. Linux kernel increased official support time for the Long Term Support (LTS) branches from 2 years to 6 years, mainly for Android devices using Generic Kernel Image (GKI) releases. However, it was recently reduced back to 2 years. Pixels will need to start migrating every year.

IMEI is not the only hardware identifier for the device available to the cellular network. Changing the IMEi alone isn't enough to hide the device identity from the network. It will only hide one commonly used ID rather than making the device not uniquely identifiable. Carriers often detect device model via IMEI and multiple other ways as part of their standard operating procedure. They change how things work based on the detected capabilities but also hard-wired quirks for device models, etc. Devices send a lot of info on capabilities.

@LysolPionex @Authy Sandboxed Google Play compatibility layer does not require using a work profile, user profile or Private Space for the apps to be sandboxed. They're sandboxed if you use them in your main Owner profile too. Putting it in a separate profile just keeps it a bit more separate. @LysolPionex @Authy SafetyNet Attestation API was deprecated a while ago and is nearly entirely phased out. It was replaced by the Play Integrity API. Both of these things work fine with sandboxed Google Play. The issue is they largely exist to support services banning any non-Google-ceritifed OS.

There's a highly inaccurate article about Pixels from Cybernews making the rounds everywhere in privacy communities. It gets the details nearly completely wrong and thoroughly misrepresents things like the optional network-based location used nearly everywhere as Pixel specific. Any non-Pixel device with the standard Google Play integration has similar Google service integration doing the same things. You don't avoid it at all by using a non-Pixel, but you do end up with a device that's far less secure and adds OEM services with their own privacy issues.