Comment by mbananasynergy
1 month ago
GrapheneOS community manager here. Google's devices are currently the only ones that meet our requirements (https://grapheneos.org/faq#future-devices).
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.
Extremely happy GrapheneOS user here. Thank you so much for the work you and your colleagues do. Speaking for myself, the adoption of a mobile communication and computing choice that both put me in control of what information I interact with and respects my agency enough to present me with the hard choices about what I do and don't want for myself has been a life-altering upgrade in something midway between "peace of mind" and "outright mental health".
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.
We really appreciate the kind words!
I can only attest to that. Been using it for 3 years on a Pixel 6a. The only thing I'd wish for, is a scrolling PDF viewer.
In any case, thank you for all the work so far!
1 reply →
I can understand the GOS' rationale in choosing only the most secure phones. However, I'm more concerned about privacy, and not so much about security. It'd be great to have something like a "GOS-Lite" which accepts some security compromises in order to bring privacy to more people. (And yes, I understand that lower security means less privacy from targeted attacks but even GOS depends on OEM blobs, right?)
If it's a repairable phone like the Fairphone, that would be fantastic. Otherwise, I'm already very satisfied with what you offer. Thanks for you work.
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.
I got curious and found this: https://discuss.grapheneos.org/d/7208-8y-security-updates-on...
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.
4 replies →
Why would their OS patches effect your different OS? It would be hardware you're supporting, no?
I'm working my way down your requirements.
> 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?
MTE is an Arm v9 feature subset of CHERI, 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.
I really hope it's the Nothing Phone you're talking to.
About the OEM, are you working on having devices ship with GrapheneOS, or devices be GOS compatible (i.e. same as the Pixels)? If you're thinking of devices shipping with it, would this fix the issue of Play Integrity/SafetyNet failing? That's the main reason I am running the android on my phone, as my banks don't work with Play Integrity failing and I have to use the app for 3DS. The ability to run GOS without this issue would be huge.
>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.
This is great to hear. I hope the ORM has a budget model graphene can run on.
that is great but i hope it is not a small run with a 200+ price as happens with the various linux phones.