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.

Maybe it's just me but those "very reasonable hardware requirements" look like they can be handled only by huge corporations directly involved with Android development.

If you expect to have stuff patched within a week, it should tell me you expect all those unpatched devices are going to be heavily impacted after a week. It doesn't look like a lot of massive security incidents are happening to Android devices in recent years because some vendor delayed a patch by a week. I understand high standards, but if some user also expects high standards why shouldn't they expect their devices patched within a day? Only explanation is that most people care about privacy risks much more than about security risks.

Security risks are privacy risks.

Privacy risk is like "Google is constantly spying on me".
Security risk is like "a hacker next door is waiting for a next 0day to drop to get my passwords and photos".
Guess which of these is a real threat in most people's eyes?

The friendly police officer wants to look at my phone: they're going to attach it to an industrial device to hack into my phone and take all the data.

Every security risk is a privacy risk. Most people live in places where the police will investigate their phones, it's not even rare anymore. Phones are examined at border crossings, arrests, everywhere.

If you are in such a position, it's only a matter of time for a friendly police officer to stop being friendly as soon as he sees any signs of your phone using encryption, or GrapheneOS, or being Pixel. You will get detained/interrogated/beaten/etc. and you will share all your secrets yourself. If they have those industrial devices and you allow them to take your property from you - an OS will most likely not help you.

Instead of trusting OS to protect your data on your device from unauthorized users owning unknown toolset, it's better to make sure you have no data they might want from you, on your device.

spyware is deployed remotely on journalist and protester phones... security is privacy.

So it's an OS for journalists now? For protesters? I'm not going to trust an OS that failed to save anyone from Meta, to save me from my government.

GrapeheneOS failed to save you from meta? how?

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:

By default our Vanadium browser disables the peer-to-peer aspect by only using server-based (proxied) connections.

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.

GOS lets you decide what apps to trust

But not what vendors to trust...

GOS is EXTREMELY clear about who their product is for

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.