We really appreciate the kind words!

Fairphone do not meet our requirements and haven't really been trending towards meeting them generation-by-generation. It doesn't seem to be something that interests them.

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.

MTE is an Arm v9 feature subset of CHERI, https://news.ycombinator.com/item?id=30007474 | https://armor.ch/mte/hw

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.

> Is this like a fine-grained version of mprotect, i.e. associated permissions with each tag?

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.

>About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)?

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.