Many companies and individuals are trying to mislead people about the future of GrapheneOS to promote their insecure products and services. GrapheneOS is not going anywhere. We’ve made it clear we’re shipping Android 16 soon and that the supported devices will remain supported.
Pixels remain the only devices providing a high level of security combined with proper secure support for using another OS. We hope to have more options by the end of 2026 based on contact with an OEM interested in meeting our requirements but there’s no specific timeline.
Our very reasonable hardware requirements are listed at https://grapheneos.org/faq#future-devices. We expect industry standard security patches/features, not anything exotic. Multiple OEMs have indicated they should have no issue meeting these requirements with the next generation Snapdragon SoC.
In 2017, Pixel 2 added an off-the-shelf secure element (SE) with Weaver and insider attack resistance. Weaver provides aggressive throttling to make disk encryption work without a strong passphrase. Insider attack resistance means SE firmware updates require Owner user unlock.
Weaver has a key-value mapping with a slot for each profile on the device where providing the correct authentication token gets back a stored random token needed as an extra input for disk encryption. It’s a few hundred lines of code. It’s what makes a random 6 digit PIN work.
Most Android devices still lack a secure element providing Weaver, a StrongBox KeyMint and other standard functionality. Weaver was shipped by the Pixel 2 (2017) and StrongBox by the Pixel 3 (2018). It’s not a high expectation for devices to provide these features in 2025.
Most Android devices similarly lack proper privacy/security patches for drivers/firmware from day 1 and don’t provide long term support. It’s not a high expectation. OEMs get 1 month early access and should always ship Android Security Bulletin (ASB) and similar patches on time.
Pixel 8 and later provide 7 years of proper updates. Our minimum requirement is 5 years which has been the case since the Pixel 6. This requirement eliminates most devices despite us keeping it at 5 years. Getting security patches on time for 5 years isn’t a high expectation.
ARM provides standard exploit protections used by firmware and software to defend attack exploitation.
Pointer Authentication Codes (PAC) and Branch Target Identication (BTI) are near universal with ARMv9. Memory Tagging Extension (MTE) is more important and often omitted.
All of the standard ARM Cortex cores provide PAC, BTI and MTE. SoC vendors simply need to keep the security features intact and provide basic integration for them. OEMs need to do the same. We greatly expand usage of all 3 of these and were the first to use MTE in production.
MTE support launched with the Pixel 8 when it moved to ARMv9, but the stock OS still doesn’t use it by default. In GrapheneOS, we always use it for the Linux kernel and nearly all base OS processes including apps. We provide a toggle to enable it for all user installed apps.
We use it for known compatible user installed apps by default but it’s incredibly good at detecting memory corruption and uncovers a lot of bugs. Due to this, we integrated it into our user-facing crash reporting system and per-app exceptions can be made for user installed apps.
With Android 16, Pixel stock OS uses MTE for the small subset of users enabling Advanced Protection. It doesn’t use it for the kernel or most of the OS, only a small portion of the OS and a tiny number of apps marked compatible. The implementation is also much weaker than ours.
Our MTE integration is one of the biggest security features we offer. Qualcomm still hasn’t added MTE support, but it’s supposed to be available with their 2025 SoC launch. Exynos and MediaTek added it for flagships. Samsung integrated support for it as a development feature.
Snapdragon provides solid overall security. It includes a basic secure element for the flagships. Our expectation is Snapdragon will add MTE this year and OEMs willing to do the work of providing proper security features and patches can make devices meeting our standards in 2026.
The most secure non-Pixel devices disallow using another OS or don’t allow another OS to use important hardware-based security features. Samsung flagships would be the next best option if they didn’t do this. Our expectation is we need to work with an OEM, so we’re doing that.
GrapheneOS will continue supporting the current devices we support until their end-of-life dates. We’ll also add support for new Pixels as long as they meet our requirements. We’ve tried to make that clear, but recent posts about changes to AOSP have been widely misrepresented.
Prior to Android 16, Pixels had first class support in the Android Open Source Project as the official reference devices. This was never one of our requirements and no other device provides it. Many people are promoting hardware and software with atrocious security based on this.
A device without proper privacy/security patches or the hardware-based security features we expect didn’t become a better option due to Pixels losing something no other device has ever provided. There isn’t a non-Pixel device providing Android 15 QPR2 device trees let alone 16.
GrapeheneOS failed to save you from meta? how?
https://discuss.grapheneos.org/d/22889-meta-and-yandex-are-de-anonymizing-android-users-web-browsing-identifiers
Ok, so your issue isn’t with GOS… this attack method exists all all known phones. IPC and specifically localhost connections are part of the general model of computers.
For instance this is exactly how discord hijacks clicks on computers (windows, apple, and linux)
There are mitigations for this specific type of attack, that you can implement on GOS (using a sockv5 enabled web browser, or blocking localhost connections) for instance.
And the second post in your own link:
So GOS out of the box is already hardened against the meta attack…
My issue is that someone who say they do everything they can to harden your device and improve security, fail at simple things. Like blocking such traffic at the OS level for all untrusted apps, or allowing installing untrusted apps at all. It’s like they can’t decide who their product is for. And users thinking they are getting more protected just because they switched to another OS, as a result.
Making security measures irrelevant is easy for police officers, for app makers, and for users too.
and what ecosystem does better? this attack impacts EVERY KNOWN PHONE
GOS OUT OF THE BOX isn’t vulnerable. That is not failing at simple things. That is good decision making.
GOS lets you decide what apps to trust… your in control, that is the whole point.
GOS is EXTREMELY clear about who their product is for
I’m not implying there are better ones. I mean that ways how “better” systems are being built, updated by developers, and how are they viewed by users, should make everyone question whether those are actually useful.
But not what vendors to trust…
Clear… but apparently not loud enough because all I know is “for Google Pixel owners”.
It’s not like I even want to use GOS. I want to use something that cares about me as a user, more than the default experience with limited and forced aspects. It just happens that most people say Pixel is the best phone overall for now, and I can’t ignore that.
Okay, you’ve lost me. What is your core objective?
Grapheneos aims to be the most secure phone out of the box. That means the least amount of risk surface out of the box. That means all the control to the user.
To accomplish this mission, graphene OS uses Pixel phones. Because they give the most control.
If you want to encourage other developers to make other phones, that’s great. I actually support that. I’m looking forward to postmark os becoming mature.
For you to determine what vendors to trust, you have to have a good understanding of your personal risk model. What your threats are, and what you’re willing to trade to mitigate those threats. By default, out of the box, there is no trust for any vendor in gos.
You as the user have a blank slate, a locked down phone, with minimal risk surface, and no preconceived notions. If you want to install the Google store, you can. If you want to use f Droid, you can. If you want to install apps directly from GitHub from developers that you trust you can. You have total control. That is what GOS gives you, total control
GOS will not become a phone. Relying proprietary hardware to achieve security of your own product is not optimal.
I know what you mean but it sounds like you’re describing basically all of Android OS derivatives.
I don’t see how realistically every requirement of GOS is really needed, given it is still very vulnerable to users’ unawareness, stupidity and other easy exploits. It’s like people advocating secure communication via Signal while participating in huge public groups. It’s like you’re building a house from the top - from the premise that the device is secure and therefore great for user. You prepare user for a rain and a storm, but the building will crumble due to an earthquake, or a fire started by the user. But what can you do? Earthquakes are inevitable and crush every other building, and users can’t be educated properly, right? That’s on top of relying on Google to provide materials and warranty for the house…