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.
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!
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.
> 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.