> Samsung Flagships and Iphones seem to have similar level of security engineering in them (Pixels use Samsung CPUs essentially) but aren't open to the required degree for third party roms.
Samsung has devices providing all of the major security features listed at https://grapheneos.org/faq#future-devices and they could easily add the couple things they may be missing such as reset attack protection. The issue is that they don't allow another OS to use a bunch of the hardware-based security features.
Samsung devices aren't on the same level as Pixels in terms of quality of implementation for security, but they would meet our security feature requirements if they let us use the security features.
Whether Samsung's security update approach meets our requirements is a different story. They do provide long term support but it isn't necessarily what we expect. There are often long delays even from the beginning and they tend to switch to doing the security updates with months in between for older devices. Huge delays for yearly updates and not shipping the monthly/quarterly updates is an issue too since we'd be running a newer OS version on top of components from an older one, relying on Treble for compatibility, which is likely to cause issues and therefore delays. We can accept having to use Treble that way but it would be significantly harder to provide the OS updates as quickly as we expect.
As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.
> The GrapheneOS guys are working with someone one a potential custom phone to get the required level of hardware security but nothing has materialized.
The current OEM we're working with started working with us in June 2025 so it hasn't been a long time. The previous OEM went bankrupt, but this is a larger and more established company.
GrapheneOS has no specific requirement for the Titan M2. It requires a secure element providing the standard AOSP secure element features which are provided by other devices such as recent Samsung Galaxy devices. Fairphone doesn't provide a secure element. Snapdragon provides a basic secure element in the flagship SoC but not every SoC, and it doesn't necessarily provide all the required features without the OEM doing work. There are more requirements than a secure element. It's best to look at the official list of requirements at https://grapheneos.org/faq#future-devices.
GrapheneOS is actively working with a non-Google Android OEM towards their devices officially supported GrapheneOS and it's certainly something we're interested in providing. Existing non-Pixel devices with proper support for using another OS don't meet our hardware security and update requirements.
As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.
GrapheneOS has no specific requirement for the Titan M2. It requires a secure element providing the standard AOSP secure element features which are provided by other devices such as recent Samsung Galaxy devices. Fairphone doesn't provide a secure element. Snapdragon provides a basic secure element in the flagship SoC but not every SoC, and it doesn't necessarily provide all the required features without the OEM doing work. There are more requirements than a secure element. It's best to look at the official list of requirements at https://grapheneos.org/faq#future-devices.
> Doesn't the ASB get published at the same time as pixel updates? So by definition it's up to date.
Android Security Bulletin are standalone backports of High and Critical severity security patches to older initial yearly releases. Those older releases are currently Android 13, 14, 15 and 16. They're not the full security patches. Many backports included in the ASB were often included in the stable OS updates a month or two earlier.
There are 2 officially supported paths for updates:
1) The path taken by Pixels of shipping each monthly, quarterly and yearly OS release in the month they come out, which they always do unless something goes very wrong and an update is pulled without them having a replacement ready. It's extremely rare for them not end up rolling out the latest OS release to users.
2) The path taken by most non-Pixel OEMs where they stick with an initial yearly release and apply Android Security Bulletin backports, eventually moving to a new initial yearly release. Pixels have never really used this, with the exception of the Pixel 8a and Pixel 9a launching on a branch of the previous quarterly release and then moving to the regular OS releases with the next quarterly/yearly release. That's a special case at launch from them saving resources.
GrapheneOS follows the Pixel path and would need to make that work on hardware not doing it if we supported it. That would mean dealing with issues created by relying on the forward compatibility system (Treble) and not having improvements to the device support code tied to newer Android releases. Our hardware requirements require that this would work and that they would be providing the OS updates for the lower level code without a huge delay.
Using older code below the OS layer would also mean not building it with the OS but rather separately, and would imply that it's probably a lot more closed source than Pixels were.
Fairphone no secure element, no hardware memory tagging and lack the expected security patches. It's missing some of the other features too. Our list is about hardware requirements and firmware/driver requirements, not the AOSP portion of the OS.
> The "Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)" part isn't even true for Pixels.
That's not correct. Pixels also ship the monthly, quarterly and yearly OS updates rather than the Android Security Bulletin backports to older releases. Android Security Bulletins are backports of High and Critical severity patches to the initial yearly releases from the past several years. Stock Pixel OS and AOSP have a new release each month and often ship those patches before they're backporting.
Android Security Bulletins also include a small subset of SoC vendor patches, but the remaining SoC vendor patches and other hardware component patches also need to be provided as part of meeting our requirements.
The vast majority of Android apps work on GrapheneOS. There are tap-to-pay apps including PayPal, Curve Pay and many European banking apps which work on GrapheneOS.
> that is after installing the optional play services, reducing the privacy benefits of graphene.
The only way to use Google Play services on GrapheneOS is via sandboxed Google Play. Sandboxed Google Play are regular apps with zero special access or privileges. They cannot do anything more than any other regular user installed apps. They do not have any access to user data, app data or more control over the device than other apps. They only have what other apps explicitly choose to implement through Google services, which apps can do without Google Play services too. Apps do not need Google Play to use Google services, and Google services are far from the most privacy invasive third party services used by lots of mainstream apps. Privacy from invasive apps is provided through features like our Contact Scopes, Storage Scopes, Sensors toggle, etc. Avoiding 1 particular set of services depended on by privacy invasive apps wouldn't solve that. Users need to carefully choose what to share with apps/services and take advantage of the provided privacy model improvements such as those features if they care about this but still want to use those apps.
> The solution must be social-legislative.
The solution to the anti-competitive Play Integrity API has to be regulatory/legislative but providing privacy and security almost entirely depends on technical improvements rather than laws/regulations which will be largely ignored and cannot solve an international issue without borders.
> niche enthusiast projects
GrapheneOS is a production quality OS made by a non-profit organization. It has a team of full time developers paid to work on it. It's very easy to install, can be purchased preinstalled on devices and has compatibility with the vast majority of Android apps. For most people, they don't have to make any major sacrifice to use it. Using a different app for tap-to-pay or using regular credit cards for it instead isn't really a big deal. There are only a few non-financial apps impacted. Several financial apps have recently explicitly permitted using GrapheneOS via hardware attestation and Block (Cash App, Square, etc.) is in the process of doing so.
GrapheneOS is sold preinstalled on devices. People do not have to install it themselves. It's also far easier to install than a desktop OS via https://grapheneos.org/install/web.
The post from Purism is highly inaccurate and is inventing issues which are not real issues along with presenting a product which massive reduces security and app compatibility as somehow solving those things. Dropping mainstream app compatibility and support for the main open source app ecosystem entirely hardly solves a tiny number of apps enforcing using the stock OS.
Apps have to choose to block using a non-stock OS and only a tiny minority of them do it. GrapheneOS bypasses it for many of them and we intend to get it fully resolved. Regulatory action is in progress for this in Europe already and it will be solved. GrapheneOS users can currently use nearly all Android apps with the exception of a subset of banking/financial apps and a tiny number of other apps. Google trying to crack down further will greatly increase the already incoming consequences in multiple countries for the existing Play Integrity API.
I appreciate you sharing, but right now this is a bit too much for the average person.
I don't think it is too much for a motivated average person, but right now people give up pretty easily and people are a bit scared of it. Maybe it is a self-fulfilling prophecy though.
Samsung has devices providing all of the major security features listed at https://grapheneos.org/faq#future-devices and they could easily add the couple things they may be missing such as reset attack protection. The issue is that they don't allow another OS to use a bunch of the hardware-based security features.
Samsung devices aren't on the same level as Pixels in terms of quality of implementation for security, but they would meet our security feature requirements if they let us use the security features.
Whether Samsung's security update approach meets our requirements is a different story. They do provide long term support but it isn't necessarily what we expect. There are often long delays even from the beginning and they tend to switch to doing the security updates with months in between for older devices. Huge delays for yearly updates and not shipping the monthly/quarterly updates is an issue too since we'd be running a newer OS version on top of components from an older one, relying on Treble for compatibility, which is likely to cause issues and therefore delays. We can accept having to use Treble that way but it would be significantly harder to provide the OS updates as quickly as we expect.
As a side note, GrapheneOS has always avoided using the term ROM to refer to any Android-based OS. They're not actually ROMs and it leads to misconceptions.
> The GrapheneOS guys are working with someone one a potential custom phone to get the required level of hardware security but nothing has materialized.
The current OEM we're working with started working with us in June 2025 so it hasn't been a long time. The previous OEM went bankrupt, but this is a larger and more established company.
reply