My only problem with Graphene is the ridiculous low number of supported devices, i know I know, security reasons and so on. But I would accept an lower security hardened version but at least have Graphene instead of Google's junk
However, we're currently working with another OEM and are hoping to have a device of theirs meet our requirements that can be launched in 2026 or 2027. Nothing set in stone, but we're optimistic thus far.
The unfortunate thing is that they make security promises which aren't upheld in practice (such as shipping security updates on time), so it doesn't inspire confidence as an OEM you could trust to properly support a device for multiple years.
We're hoping that there will be people who will enjoy a device from the OEM we're in talks with - we know that there are many people who for various reasons don't want a device from Google, so this will at least offer an option for people who want to use GrapheneOS on a non-Google device.
At the risk of doing their work for them, that seems like a near ideal partnership opportunity for graphene, so it’s extra sad to see.
Google provided resources for the Linux kernel to extent LTS support for 6 years for their 5 year guarantee with the Pixel 6. It ended up not being needed since Pixels began moving to newer Linux LTS branches. The official Linux kernel LTS support is back down to 2 years. The 6 years was meant to benefit all Android devices but it proved to be too difficult to do well and it makes more sense to invest a far smaller amount of resources moving to new LTS branches.
Fairphone presents providing an Android OS release 3 years after it was released as providing 3 more years of extra support compared to an OEM releasing it in the month it was launched as their final update. That doesn't make sense.
They've repeatedly had blatant security flaws such as using publicly available private keys for signing the OS on the Fairphone 4. These issues are downplayed rather than being acknowledged.
There are important security features missing, but the main issues are the lack of proper updates and their approach to security flaws being reported and discussed.
Many Android OEMs are a better fit for a partnership with us and we're working with one.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a better thread about this than the one you linked.
Much like you don't hear the sound of a busy city until you go somewhere truly quiet, you don't remember owning your own brain until you evict all of the entities who have been living rent free in it.
Keep doing the great work you're doing: it's making people's lives better in dramatically more significant ways than most software.
In any case, thank you for all the work so far!
> Hardware memory tagging
I had to Google this. Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag? Or are you only interested in the memory safety benefits? Regardless, why target requirements that even most desktop computers don't meet?
https://discuss.grapheneos.org/d/8439-mte-support-status-for...
> Hardware memory tagging is going to provide a massive increase to protection against remote exploitation for GrapheneOS users. It's the biggest security feature we'll be shipping since we started in 2014.
It provides the ability to tag 16 byte granules of memory with 4-bit tags where only pointers with the correct tag can access the memory. This provides an approximation of memory safety very useful for security.
As an example of how it gets used, our implementation of the system allocators via hardened_malloc tags each allocation with a randomly generated tag excluding the adjacent random tag values and previous random tag value for the slot. It has the standard setup of a single statically reserved tag (zero) used for free memory but adds 3 more dynamic exclusions. This provides deterministic detection of small overflows, linear overflows, many forms of use-after-free and fallback to probabilistic detection of other spatial (bounds) or temporal (use-after-free) memory safety issues. We use a lightly modified variant of the standard MTE integration for PartitionAlloc in our Vanadium browser, but we plan to improve it to match hardened_malloc. We use the standard Linux kernel implementation for the internal Linux kernel allocators which needs a lot of improvement.
> why target requirements that even most desktop computers don't meet?
Desktop computers are far less secure than an iPhone or a Pixel with the stock OS. GrapheneOS exists to provide a higher level of privacy and security than those. GrapheneOS is primarily aimed at mobile devices which are almost entirely 64-bit ARM. Hardware memory tagging (MTE) is a standard ARMv8.5 / ARMv9 feature provided by every standard ARMv9 Cortex core. MTE is only missing with custom CPU cores or cache while cutting this corner.
Pixels are not the only devices providing MTE. Exynos and MediaTek have provided it and Snapdragon should be providing MTE starting at the end of this year. The only reason Snapdragon is late to the party is due to their custom cores/cache.
We're currently working with a major Android OEM towards multiple of their future devices meeting all of our requirements and providing official GrapheneOS support. They view all of our officially listed requirements as completely reasonable and a target they can meet for their next generation of devices.
The purpose of GrapheneOS is providing a high level of privacy and security, not making security less bad for devices people already have. Hardware and firmware security matters quite a lot and software security depends heavily on hardware-based security features including MTE. Nearly all GrapheneOS users buy a device to use GrapheneOS and that would still be the case if we supported several other devices. The vast majority of Android devices lack proper security patches for drivers/firmware, are missing important hardware-based security features and don't provide serious support for using another OS where the security features can be kept intact. Samsung's flagships are closest to meeting our requirements after Pixels but do not allow another OS to use verified boot, important secure element features and more. Samsung permanently cripples their devices if they're unlocked and voids the warranty, unlike Pixels.
The reason we're working with an Android OEM is because existing non-Pixel devices don't provide a base we can use to provide what GrapheneOS offers. It would be missing huge parts of the core features elsewhere and would be worse in significant ways than the stock OS. It would go against what we're trying to achieve to have people buy devices we can't properly secure. Long term support for drivers and firmware is also important because people use devices more than 3 years from launch in practice. Pixels get 7 years of proper support from launch, which is unique. A couple OEMs market their devices as having similarly long support but the updates are significantly delayed and far less complete.
We've had numerous opportunities to work with OEMs where they weren't able to provide our requirements. We simply aren't interested in having a far less secure device with GrapheneOS as the stock OS. We expect our requirements to be met, and we think the OEM we're currently working with is fully capable of providing what we need. It will hopefully be available in 2026 or 2027. The initial goal is not doing better than Pixels, just providing a competitive alternative for people who want to use GrapheneOS on another brand of device.
As far as I'm aware as an outsider, the aim is a device that is compatible with GrapheneOS like the Pixels, yes.
>If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing?
I think to pass this you need to be 'blessed by Google' which means being certified Android by their standards. GrapheneOS have mentioned that their CTS/CDD Android certification process holds back some of the privacy/security features (think things like new Sensors and Internet permissions etc.) implemented so they cannot can't target it.
you got it wrong way around
the CONSUMER criteria is "we want better independent security ON DEVICES WE ALREADY OWN"
complaints like in this thread are symptoms of unfullfilled demand - and they can't be solved by saying "oh gosh, what a stupid demand that doesn't agree with our supply"
vendor: not possible
you: unfulfilled demand
me: the way I see it, you get a product for free if you fulfill certain conditions. If not, you buy these conditions.
vendor: "we present 100% electric car"
we: "that's cool, I always wanted to decrease petrol use. But... can you provide an option for some petrol use? It's called hybrid, iirc?"
vendor: "no, our requirements only support 100% electric car. Hybrid cars use petrol and we can't allow that"
we: "suuure, I get that. But the price of electricity here still hasn't come down, everyone already has personal petrol reserves, and your cars are only provided with batteries from congonese child labor mines. Can we pleeease have the half-way option so that I can use less petrol for e.g. small distance travel, but still using petrol for country-sized movement?"
vendor: "no, we only support 100% electric car. Everything smaller is outside our requirements"
Real economics would've provided competition to fullfill demand - but currently Graphene is the only well-known vendor, so complaints will keep coming
I would recommend checking out https://eylenburg.github.io/android_comparison.htm for a third-party comparison of these projects. They're not really similar.
CalyxOS downgrades security compared to the Android Open Source Project, often falls significantly behind on standard Android privacy and security patches as is the case right now (they still haven't ported to Android 16 which is required to have the latest patches) and doesn't provide similar privacy or security features.
Features like Contact Scopes, Storage Scopes and our Sensors permission toggle are some of the privacy features includes in GrapheneOS.
Privacy necessitates security. The security provided by GrapheneOS is in order to be able to protect privacy.
The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
Depends on your threat model. If Google, low-effort scam apps or being profiled by apps are your only adversary, then that's true. If random threats on Internet or APTs pwning your phone, or being forensic-proof are part of your threat model, then Calyx is strictly worse than stock.
The table shows CalyxOS has substantial delays for important privacy and security patches. It currently doesn't provide the 2025-06-05 patch level. It's better than LineageOS and /e/OS in that regard but still reduces privacy and security through significantly delayed patches. CalyxOS also weakens parts of the privacy and security model through the privileged functionality that's added, which simply isn't covered by the comparison table.
> The point of the OP is not that it would be better than your solution anyway; rather, if you have a device unsupported by GrapheneOS, Calyx would be better than nothing.
On Pixels, CalyxOS is missing current Android privacy/security patches. GrapheneOS doesn't support those other devices due to lack of a reasonable level of security. Each of those extra devices has significantly delayed privacy/security patches and lacks important hardware-based security features. Despite all the marketing about long term support, Fairphone 5 uses Linux 5.4 which is end-of-life in December 2025 with no plans on their part to move to a supported kernel branch afterwards. Earlier Fairphones are stuck on older end-of-life kernel branches. Those devices are missing basic updates and security protections. Those don't provide proper long term support, so if someone does have one it won't be long before it's time to buy another device.
But there is still no way to reset/spoof android device ids, and the apps can reliably identify the user after reinstalls.
I agree that GoS did a lot in order to improve privacy (scoping) and it provides unmatched security, but you shouldn't create false expectations.
At the same time, we're in communication with an OEM to have some of their devices have official GrapheneOS support, so we're moving towards redundancy.
So Graphene is actually not limited to the developed/western world. As for not supporting other devices, I believe the reason could be the team size and the fact that the fragmented Android world is known for unique shenanigans of every OEM. Besides Google's update/upgrade cycle is another reason it is an appropriate choice.
You can have the best alarm system in the word, if you leave the back door open and anyone can just walk in from the street.
So just give me that alarm system for my tent, please. It will do fine for my case.
Our requirements are not at all exotic or outlandish, the fact that most OEMs don't meet them says more about how far behind most OEMs are, rather than our standards being unrealistic. We've also been told that they're not unrealistic in practice from numerous OEMs who want to build a device that meets our requirements.
It is also important to note for Pixels specifically that since the 8th gen Pixels, they receive 7 years of support. Additionally, they partner with iFixIt to provide official replacement parts for the duration of the device's life. I'd say that's pretty sustainable, especially when you consider that the Fairphone doesn't actually provide proper support for the amount of years they claim, since they have consistent delays in providing patches.
As for the requirements, I will take your word for it. And I do appreciate that you put the emphasis on security as it is often overlooked. I guess what I'm saying is that having control over my phone (as opposed to BigTech or apps having the control) is for me a much higher priority goal than just security by itself. Hardware reparability is (again, for me) a close second.
Anyway, I hope you find a good partner for the phones, and I'm curious to see what you come up with!
Is this really that big of an issue? It's like a couple dollar fee every 4-5 years or so.
You could just have some disclaimer on the grapheneOS site that says something like "Works best with pixel phones" or have some long password requirement on non-pixel phones
Yeah, that's completely how security works...
But this is unnecessary if your encryption password has enough entropy in the first place, because it cannot be brute forced. This is the security model of most linux distros that use full disk encryption with LUKS. And android already lets you do this, it is just less convenient.
I use grapheneOS with a high entropy BFU password and a low entropy biometric AFU fingerprint. My linux setup works in the same way. The BFU password is the only "real" password that secures you and encrypts your data. The AFU password is a just temporary screen lock that is vulnerable to side channel attacks because the decryption keys are still in memory.
If the hardware is not done properly, then the whole thing is broken. E.g. you are useless with your encryption keys if your modem sucks and leaks data, or if the CPU can trivially be made to run custom code (and you just entered your encryption key into a software that just looks like the prompt you were looking for)
It's a catch 22. Support other devices, the software won't work as well or reliably or maybe buggy - users get pissed off.
Spent the time to make it not buggy on other devices = now you're doing mor dev work than even Google.