> Pixels shipped a massive hardware security feature (MTE) they aren't enabling for the OS to save 3.125% memory/cache usage. It's silly. Heap MTE has near 0% perf overhead in async mode and is cheaper than increasingly ineffective legacy mitigations like SSP in asymmetric mode.
I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to disable such a significant security feature for negligible performance gain.
AOSP engineer here; I don't have a deep knowledge of the issue at hand as I don't work on the bluetooth part of the OS, but I did just want to call out that GrapheneOS (while a really cool project!) supports ~11 total device types, and changes in AOSP have to keep a much larger context in mind.
I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
> AOSP engineer here; I don't have a deep knowledge of the issue at hand as I don't work on the bluetooth part of the OS, but I did just want to call out that GrapheneOS (while a really cool project!) supports ~11 total device types, and changes in AOSP have to keep a much larger context in mind.
AOSP also only directly supports the phones/tablets we support. We were only talking about 2 of the devices supported by AOSP. Pixels enabling MTE is not connected to other devices. App compatibility is also not an issue because it can be enabled for the base OS with user installed apps excluded until they opt into it. It can be made opt-out in a future target API level (Android 15) and then the opt-out can be removed in the next target API level. This is entirely doable.
> I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
We're not ignoring it. We're talking about the Pixel 8, Pixel 8 Pro and future Pixels. It's a request for Pixels to enable it, not AOSP to enable it for all devices.
> I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
Performance and memory usage are definitely the only blocker to enabling it for the base OS. It would already be enabled if the security team was in charge of these decisions. It's not enabled because they likely have to prove it's fast enough. Our specific recommendation was enabling it in asynchronous mode for all cores for the base OS and user installed apps explicitly opting into it. We do not think it's a good idea to start automatically opting apps into using it until more Android devices support it. Google could require that ARMv9 devices support MTE as a developer option for Android 15 onwards in the CDD in order to make sure developers have it available for testing. App developers can't be expected to have a Pixel so it's unrealistic to have it forced on app developers via target API level until more devs have devices available to test it. We understand all that and what we are pushing for takes that into account.
The tradeoff isn't just memory use or performance -- it's also user-facing crashes that weren't present before. That is likely the bigger factor in deciding whether or not to enable the feature.
> The tradeoff isn't just memory use or performance -- it's also user-facing crashes that weren't present before. That is likely the bigger factor in deciding whether or not to enable the feature.
We're only proposing enabling it for the base OS and user installed apps opting into it. Google has already fixed nearly all the crashes due to testing with HWAsan and MTE. They don't test enough with real world usage yet because they haven't deployed it for all the dogfooding devices. To do that, they need to set up enabling it for the base OS without enabling it for all user installed apps because that's not currently very practical. Google has already done most of the work for enabling it for the base OS, not us. We have to fix some bugs, but they're almost all regressions which don't live past the next quarterly releases since they do find and fix them. Google is 100% capable of enabling MTE for the Pixel stock OS within the base OS without a significant increase to crashes for users. In fact, it will significantly decrease user-facing crashes once it matures. It will result in so many memory corruption bugs being fixed. Testing internally with MTE doesn't do the same thing as deploying it to production in terms of bug fixing and also doesn't provide hardening against the bugs not occurring during regular usage.
I don’t understand your argument here. Google has been working on fixing the their own crashes with the data they have right now. Why would they turn it on for everyone else while they do that?
They have already fixed nearly all the crashes in the base OS. The issues we face are almost entirely regressions in new versions. They fix them consistently but they aren't stopping the regressions getting into releases because they don't use MTE in production.
Regressions in Android because they aren't doing enough real world testing with MTE or HWASan builds. They're clearly testing them via CI and fixing those issues but in real world usage more issues are uncovered which often slip into releases then get fixed in another release a few months later.
I think their accusation that the decision was made to save 3% memory usage is too presumptive. They also claim that no other OS is shipping with MTE enabled right now. The decision to enable is likely more nuanced.
It's based on communication with them. We've had it directly communicated to us. There are also multiple Google security engineers/researchers who liked/retweeted our posts. Google has stated the Pixel 8 is the first platform with MTE available in production devices, so it's not a large jump to the hardened alternate OS available for it being the first to deploy it in production. We have ~250k users on Pixels, and the userbase on the latest generation with MTE is quickly growing. People on 4th/5th generation Pixels need to move on due to them being end-of-life (other than the Pixel 5a, which will be soon) and we're encouraging moving to the ones with the biggest hardware security improvement since we started. We're not making things up.
They could enable it for the whole base OS and apps opting into it. They have already fixed nearly all the bugs uncovered in regular usage. They did nearly all the work but didn't take it over the finish line due to performance and memory/cache usage concerns. Their security engineers did their job already. They have very talented people working for them. Our ability to ship this feature before them is because the performance and memory concerns are not significant enough to matter to us. We're more than willing to lose 3.125% memory/cache and we accept the performance overhead of asymmetric MTE which is in the ballpark of a few percent overhead in most cases rather than near 0% like asynchronous MTE. There are cases where asymmetric MTE has a larger overhead than a few percent, but it's not common. Async mode is nearly free. MTE may not be as low overhead on future Pixels. It depends on them deciding to prioritize MTE performance in their future custom CPU design. If they do not ship it in production, it's unlikely that they'll prioritize the performance. The overhead may increase from 0% for async and a few percent for asymm to a far more significant cost.
The performance argument against MTE being deployed in production and against supporting MTE at all is the argument that's relevant. There is no other significant reason not to ship it for the base OS and enable it for all their own apps in their manifests. Getting it enabled for the whole app ecosystem is a much bigger problem requiring multiple steps: 1) broad availability of MTE capable devices for app developers, 2) making it opt-out instead of opt-in for a future target API level so developers get around a year and a half to either opt-out or deal with it, 3) removing the opt-out for a future target API level so that developers cannot simply opt-out. We know that part is hard. We know that part involves documentation, developer relations, concerns about giving app developers too much to deal with too quickly, etc. It isn't what we expect them to do short term. What we want them to do is enabling the near 0 overhead sync MTE for Pixels by default, with it used in the base OS and Google apps opting into it. They already did most of the work, even years earlier via HWAsan testing.
We don't expect them to enable asymmetric MTE or keep track of tags to provide more deterministic guarantees as we're doing. We understand they don't want to sacrifice 5% overall performance, and don't expect them to, but they could provide an opt-in for asymmetric mode + better deterministic guarantees. Google can could do it for Android 15 if they make the decision to do it now. A reasonable prediction is that in a couple years Apple ships MTE support in hardware with async mode by default and asymm in lockdown mode, and then Google does the same. They have a chance to be a leader on a hardware security feature far more valuable than the PAC feature where iOS is years ahead.
I feel like you're complaining, but it seems like Google has made historic advancements simply by pushing this technology to the point it's available and fixed most of not all crashes it finds. Stopping short of the goal by not enabling it on prod is likely a well reasoned choice. Google is highly committed to the underlying technology. It doesn't seem like the door to having it enabled in prod is forever closed and perhaps one day it'll happen. You don't have access to all of the information, so you're naturally going to jump to conclusions that might not actually be the best choice.
We have active communication with many people at Google about the areas we're heavily working on such as this and are not basing this on assumptions. You're talking about what you think happened based on your assumptions about it from lightly reading about it.
Most of the crashes were fixed via HWAsan before MTE existed in hardware. Their security people want MTE enabled in production. These issues were fixed before MTE and would have been fixed whether or not MTE was available in the standard ARMv9 cores/cache used by Pixels. MTE would likely already be enabled in production for the base OS (not user installed apps) if there weren't performance concerns. They clearly integrated it with that intention. We're more than capable of reading the commit messages and talking to engineers who worked on it along with other contacts there. They aren't keeping it a secret that there's a clear goal to enable MTE in production.
ARM provided MTE in their standard ARMv9 Cortex core designs. That's why MTE is available on the Pixel 8 and Pixel 8 Pro, because Tensor currently uses the standard core/cache designs. That's why MTE is not available for Snapdragon, and it's why it is theoretically available for MediaTek and Exynos.
The current availability of a high performance MTE implementation doesn't mean Google is highly committed to it. Pixels will be moving from standard Cortex core designs to their own core designs. There's an open question about whether MTE will be supported in the same way it is now. You're assuming that they're heavily committed to it and going to keep providing an extremely low overhead implementation. We have concrete reasons to be concerned.
TL;DR I would not assume they are not using it, or that this is about 3.125% memory/cache usage.
Longer answer:
Google folks were responsible for pushing on Hardware MTE in the first place - It originally came from the folks who also did work on ASAN, syzkaller, etc.
They are not in Android, but it was done with the help and support of folks in Android. That's the Google side, it was obviously a partnership with ARM/etc as well.
I was the director for the teams that created/pushed on it, way back when - this was years ago at this point because of the lead times on a hardware/architecture feature like this.
So i'm very familiar with the tradeoffs.
It is more than just the memory usage or cache. The post is correct that it was designed to be able to be enabled/disabled dynamically, and needed to have expected perf cost ~0, but the main use case at the time was sampling based bug finding.
That is, if you turn MTE on (whether servers, phones, whatever) for 1% of the time for your entire fleet, and you have a large enough fleet, you will find basically all bugs very quickly. You can do this during dogfooding, etc.
Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it.
Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead.
For example, you will suddenly cause tons of user-visible crashes. But not even consistently.
You will crash on phones with MTE, but not without it (which is most of them).
This is probably not the experience you want for a user.
For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1 of them. This is not likely to make developers happy.
Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable.
Are there harmless bugs it will catch? Yes.
But keep in mind what i said at the beginning - i would not assume they don't use it.
I would instead assume they don't necessarily use it in production on all the time.
Anyone who has experience on hardware feature bringup of this kind will tell you the fact that they can boot and run the system and only when they do this one thing does it crash under MTE is actually a very good sign they do use it.
Otherwise it would have probably crashed a million times :)
As an aside - It's also not obvious it's the best choice for run-time mitigation.
We didn't propose enabling MTE for apps not opting into it any time soon. We proposed enabling it for the base OS by default. Pixels are already testing with HWASan and MTE so there are few issues found by it in the base OS. Enabling it for the base OS and apps opting into it would be a great start. Requiring working MTE support for ARMv9 in the CDD is entirely doable, and then devs will have devices with it, and it can be made into a default for apps at a new target API level with opt-out instead of opt-in. It can then be made into a mandatory feature at a future target API level. Android makes dramatically more aggressive backwards incompatible changes via target API levels than detecting memory corruption without false positives.
We know they're actively testing HWASan and MTE builds, but not with enough real world usage. If they tested it a lot on actual devices used by Google employees, they'd have fixed this Bluetooth LE audio issue before the release.
Stock Pixel may not ship with it on by default for end users, but anyone can enable developer options and enable Memory Tagging Extensions - either until toggled off, or for a single session if you're trying to test a specific app - if you do want the feature on.
That's not the same as what's being used on GrapheneOS. It also excludes a significant portion of Bluetooth. Enabling support for memory tagging in the stock Pixel OS via developer options only makes it available for usage but doesn't actually use it. You also need to enable heap memory tagging via the Android Debug Bridge (ADB) shell via setprop. It provides no value through simply being enabled without using it to tag allocations. You can fully enable userspace heap MTE for the stock OS via the standard allocator implementation (Scudo) which is currently not particularly hardened. You can also use KASan via the MTE backend using setprop, but that's not designed for hardening right now and it's not clear it will ever be. There likely needs to be a separate MTE implementation for the kernel that's not part of KASan, which we haven't done yet for GrapheneOS either so MTE hardening is currently a userspace feature.
GrapheneOS uses our own implementation of hardware memory tagging for hardened_malloc with stronger security properties. In order to enable it by default for the base OS, we had to fix or work around various issues including this one. We use MTE in asymmetric mode across all cores rather than using asynchronous MTE for the main cores. Asymmetric mode is asynchronous for writes but synchronous for reads, which blocks exploitation properly rather than having a window of opportunity to succeed with exploitation. It gets checked on system calls and io_uring (another potential source of bypasses) is only available to 2 core system processes on Android via SELinux restrictions (fastbootd which is only used during installation and snapuserd used by the core OS after applying updates).
GrapheneOS always uses heap MTE for the base OS and apps known to be compatible with it. For user installed apps which are not in our compatibility database and which do not mark themselves as compatible, we provide a per-app toggle for enable MTE. Users can also toggle on using MTE by default for user installed apps which may not be compatible and can instead opt-out for incompatible apps. In order for this to be usable, we had to implement a user-facing crash reporting system. We did this in a way that users can easily copy a useful crash report to provide developers.
For my Pixel 7a, I searched the Developer Options menu three times and couldn't find it. Searching for Memory Tagging Extensions in Settings says it's there. Is it hidden somewhere?
Enabling it via developer options is only the first step. You also need to enable it via setprop using ADB in the desired mode. The official documentation for using MTE on the stock Pixel OS is available at https://developer.android.com/ndk/guides/arm-mte. We strongly recommend this for app developers. It's a really easy way to find heap memory corruption in your apps, but you can use stack MTE without building the OS and your app with it.
We provided a user facing crash report system for memory corruption detected by MTE. MTE has no false positives. We strongly recommend users use the feature we provided for copying the crash report to report these bugs to app developers. App developers can replicate many of the bugs reported this way using either MTE on a Pixel 8 or a smaller subset by building their app with HWASan support.
Since many apps have latent memory corruption, we only enable it for the base OS, base OS apps and known compatible user installed apps by default. Users can opt-in to heap MTE for all user installed apps via Settings > Security and can then opt-out for apps with memory corruption occurring during regular use. Over time, we plan to add more apps like Signal/Molly known to be compatible to it into our app compatibility database so that it's force enabled for them by default without users enabling it in Settings > Security. The option to opt-out is only available for apps not known to be compatible with it, which is part of dealing with the issue of users potentially allowing it after an exploit attempt.
We're trying to convince Google to at least enable asynchronous MTE by default for the stock Pixel OS with user installed apps excluded from it unless they opt-in to it. The memory overhead is 3.125% and asynchronous heap MTE is near 0 performance overhead. Asymmetric heap MTE provides much better security but is more comparable to the overhead of a feature like legacy stack smashing protection. Stack MTE adds more overhead but SSP could be disabled to partly make up for it and deterministic protection of stack spills, return value, etc. can be provided through MTE instead since by not being tagged they have the 0 tag and everything tagged will be a random non-0 tag.
Taken from the projects official Twitter they offer more than what is available by said toggle on stock:
They provide a nicer MTE implementation as part of hardened_malloc which uses the standard random tags with a dedicated free tag but adds dynamic exclusion of previous tag and current (or previous) adjacent tags. We also fixed Chromium's integration and will improve PartitionAlloc.
They also use it for their browser too using PartitionAlloc. Other Chromium-based browsers including Chrome don't use MTE since they don't really use the system allocators and have PartitionAlloc MTE disabled.
They are also continuing work on integrating more ARMv9 security features. MTE having the highest impact and being the most interesting of these features, but they're expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful.
GrapheneOS is so far ahead in terms of security than anything else that it makes chosing anything but pixel hardware really questionable. But I REALLY want replaceable batteries. Why does everything have to suck nowadays?
Pixels are currently the only devices meeting our security requirements. Other Android devices don't even come close. Hardware memory tagging support is one of many major security advantages of Pixels. Our official list of hardware requirements is available here: https://grapheneos.org/faq#future-devices. These requirements are fully provided by 8th generation Pixels. 6th/7th generation Pixels are only missing MTE, BTI and PAC but MTE is the most valuable feature on the list of hardware requirements. Proper security patches are even more important, which are not available in the same way outside Pixels.
Android has monthly, quarterly and yearly releases. Other Android OEMs only ship the monthly security backports with only all of the Critical/High severity fixes, not most of the Moderate/Low severity fixes including most privacy fixes. This is PARTLY addressed by using an alternate OS shipping these patches, but every alternate OS available for those devices rolls back security in a lot of ways. Firmware and a lot of the device support code comes from the OEM in practice. Running Android 14 QPR2 on top of Android 12 kernel / drivers is possible but will be missing the security improvements for a huge portion of the OS.
The batteries in Pixels aren't trivial to replace without damaging the device, but it's officially supported and there are official parts available:
We simply can't support insecure devices without the basics. Our hardware requirement list includes very basic things not provided by most Android OEMs along with more advanced features such as MTE which we now consider basic requirements for decent security. We want to support other devices, but those devices must meet these requirements. Memory tagging is a baseline feature supported by standard Cortex ARMv9 cores. It's unfortunate that Qualcomm is not implementing support for it and that OEMs using an SoC supporting it are not bothering to set it up. It's sad having a feature available in the CPU architecture that's not usable due to the SoC or OEM.
Thanks for the detailed explanation and i totally agree, it's not something i expect from graphene os, it's something that annoys me from googles pixels. I hope the new EU requirements to make reasonable battery swaps a thing means i get the best of both worlds.
Not exaxtly grapheneOS but close enough CalyxOs has started supporting Fairphone 5 and it has replaceable batteries AFAIK: https://calyxos.org/news/2024/03/05/fp5/
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches. CalyxOS does not have features like this. It does the opposite of this.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
Looking into that as an alternative for my dying pixel 3a but CalyxOS is to GrapheneOS what OpenBSD is to fedora when it comes to security. Both are good for updates and common security features but grapheneos has implemented security features that are a decade ahead of other Androids. Hardened Malloc, Playstore Sandbox instead of MicroG, Memory Tagging extensions, Selinux, bootloader Security, etc.
CalyxOS is a great alternative to GrapheneOS. The way I see it is that CalyxOS is much better for privacy but not as good for security, whereas on GrapheneOS security is always the main priority, whilst privacy and usability are second thoughts.
GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.
GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.
GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
Security isn't something you have or not. There's nuances. CalyxOS makes a few trade-offs which I'm happy to accept in order to be able to use several banking apps, Google pay, wallet etc.
GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.
GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
Agreed but they do drop support for older pixel devices very very quickly which is kinda of PITA. At least the Pixel 8 is supposed to be supported 7 years.
GrapheneOS provides extended support for end-of-life devices but we strongly discourage using our extended support releases. You can see we do that from https://grapheneos.org/releases and https://grapheneos.org/faq. We set an accurate Android security patch level field and do not downplay it with inaccurate claims about it. We do not do what other alternate operating systems by splitting out a Vendor security patch level field and claiming to provide all open source patches which is fundamentally not possible especially considering that a lot of the firmware is based on open source projects.
Our hardware security requirements are listed at https://grapheneos.org/faq#future-devices. Pixels are the only devices providing the requirements we set for updates and the list of security features. They also provide proper alternate OS support where all those security features work correctly. Samsung has most of the expected features and provides a similar length of support and number of major yearly updates but is missing the proper alternate OS support, MTE and the monthly/quarterly updates.
Each month, there's a new Android release which are distinct from the partial backporting of privacy/security patches to older versions. It's not monthly security releases but rather monthly performance/security/feature releases with separate backports of all Critical/High severity patches to older versions. Android 14 and Android 14 QPR1 are older versions of Android, and there are security backports to Android 14 separate from the monthly releases. This is currently fairly exclusive to Pixels. Samsung is getting much better at doing the security backports and are reducing delays for major updates but they're still acting as if the monthly/quarterly releases don't exist.
I understand that from a security perspective, but from an e-waste perspective even the current 7 years support is disastrous let alone the previously 3-5 years that vendors.
Not everybody has the same security needs, I often gift my older phones to my family members and if I have the choice to leave them on a fully unpatched device vs a GrapheneOS that is a "best effort" patch I will happily choose GrapheneOS.
I am super glad for all the work you guys do in any case, you can only love from me and I am honestly not buying an phone that doesn't support GrapheneOS at this point.
Extended support is very difficult to provide in a way that fits into the expectations we have for robustness, app compatibility and security beyond the lack of incomplete patches. For example, it would be easiest for us to move the Pixel 4a (5G) and Pixel 5 to Android 14 QPR2 to avoid having a separate legacy Android 14 QPR1 branch where we need to apply backported AOSP patches which sometimes don't apply cleanly. However, the Pixel 4a (5G) and Pixel 5 do not officially supported Android 14 QPR2 but yet had a bunch of changes related to it done to their repositories. We also build the vendor image ourselves rather than using a prebuilt one, so it always gets built with the latest SELinux policies, HALs, etc. available in AOSP. Quarterly releases are now trunk-based so it's similar to the major yearly releases. Moving Pixel 4a (5G) and Pixel 5 to Android 14 QPR2 is entirely possible. We could revert the QPR2 changes for them and use a QPR1 vendor build. The issue is that we know there are going to be regressions, and we do not want to ship dozens of serious bugs to users which we then have to invest substantial time in resolving. It's all time taken away from our focus on privacy features, security features, trying to have perfect app compatibility beyond apps forbidding using a non-Google-certified OS, etc.
We're very happy that support increased to 5 years for 6th generation devices and then 7 years for 8th generation devices because we will no longer feel the need to do harm reduction via extended support. It will save us a huge amount of time and concern about people continuing to use these insecure devices.
7 years for a phone that's used as a main personal phone is a long time. Most people aren't going to use it that long, particularly a flagship phone. It mostly benefits people buying it used. It would be quite strange to buy a Pixel 8 Pro and use it for all 7 years. The audience for using a phone that long is probably going to buy a cheaper phone. The main benefit is to someone buying a used device where it still has 4 years of support after someone replaces it after 3 years. We aren't a fan of people unable to afford new phones getting insecure used devices. This is a big step towards that not happening anymore. 7 years is longer than iPhones have been getting full support updating them to the new major OS releases with full security patches.
We worry a lot that we're encouraging people to keep using insecure devices by providing extended support but we feel we have to provide it with how many people are clearly still using the end-of-life devices. However, how much of the amount of people still using them is because they think they are fine due to continued GrapheneOS support? This bothers us.
Just a point of clarity, GrapheneOS has the same support window that Google does, so they're not dropping support earlier than the vendor. The reason they drop support is because the burden of supporting an EOL device is way, way higher, especially for a security-oriented OS.
GrapheneOS provides extended support for end-of-life devices but we strongly discourage using our extended support releases. You can see we do that from https://grapheneos.org/releases and https://grapheneos.org/faq. We set an accurate Android security patch level field and do not downplay it with inaccurate claims about it. We do not do what other alternate operating systems by splitting out a Vendor security patch level field and claiming to provide all open source patches which is fundamentally not possible especially considering that a lot of the firmware is based on open source projects.
Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.
Taking the "vendor security patch level" into account, it is impossible in some situations.
If a critical vulnerability is found in a Qualcomm modem, wifi, or bluetooth firmware, there may be scenarios where this cannot be fixed at the OS level.
We have extended support for end-of-life devices but discourage using it and make it clear that it's insecure. We dislike needing to provide it and many people don't realize we do because we make sure not to hype it up and instead try to get people to move to secure devices with full patches available. 6th gen Pixels moved to 5 year minimum support from launch and 8th gen moved to 7 years so we do not think extended support will make sense after the Pixel 5a. For now, we reluctantly provide it. There's a good chance we'll port the end-of-life Pixel 4a (5G) and Pixel 5 to Android 14 QPR2 to keep providing what we call "extended support" with all AOSP/GrapheneOS changes instead of "legacy extended support" with just backported patches. It's very unfortunate they didn't just extend the 4a (5G) and 5 to match the 5a lifetime despite it having the same SoC. It makes our life harder.
Android doesn't have a separate vendor security patch level. It has a single security patch level covering all of the Android security bulletin and OEM security bulletin patches. Most alternate operating systems set an inaccurate Android security patch level where they redefine it to mean AOSP patches. They added a separate Vendor security patch level to put the real patch level. The whole thing is strange because the whole point is having a simple overall patch level and being honest about it. The standard Android security patch level only includes Critical/High severity vulnerabilities now, not Moderate/Low severity, and it doesn't include a lot of things that are deemed optional or out-of-scope. Can see this by looking at the Pixel bulletins where there are tons of patches that are clearly generic AOSP patches for all devices and patches tied to components like the Exynos radio clearly used by other devices. Android Security Bulletin (ASB) and the patch level derived from it does cover a LOT of drivers/firmware, but far from all or even most.
The missing patches for end-of-life devices include a lot more than outdated firmware in practice since drivers stop being updated and maintenance doesn't get taken over by others. The kernel drivers are open source but it doesn't mean someone takes over maintaining them. It's often mistaken as having all patches to open source code and missing patches to proprietary code but that's not accurate since updating AOSP is not updating all open source code. Lots of device specific code including even large parts of firmware is open source. As an example, Pixels use Trusty OS for the TEE and secure core, littlekernel for the boot chain firmware, etc. Security patches to those open source projects are security patches requiring new signed firmware updates to be released despite being open source patches.
They can have up-to-date AOSP but a significant portion of the OS consists of the driver, HALs, non-GKI kernel tree, etc. Android security patch level is meant to cover all of that. They're using it in a way that's not permitted for Android OEMs by redefining it to mean AOSP patch level for the parts of AOSP they build. Some things get built from AOSP for vendor executables and that are built into vendor executables. As an example with firmware, it will use the AVB library in the bootloader firmware. It also gets built into userspace driver libraries which are often proprietary, etc. Updating the portion of the OS they build via AOSP is not quite updating all the code from AOSP, and even if it was, the Android security patch level is not only for AOSP code. It covers firmware, drivers, etc. Check the recent Android Security Bulletins. The split Vendor security patch level shown in Settings is a LineageOS invention to show the REAL patch level for the overall device including firmware, drivers, HALs, kernel, etc. The whole point is meant to be that it's an overall patch level though. We just set the real patch level for extended support devices while providing the AOSP releases/backports. The only problem is the other alternate OSes making it look as if they're providing something more, but we aren't going to stop using it the official way. We're just not going to need extended support after the Pixel 5a since devices moved to 5 years and then 7 years of proper support.
Pixels largely use open source code for the parts specific to Pixels (TEE, secure core, secure element, boot chain) but unfortunately they don't publish all the Pixel specific changes yet. They committed to publishing the firmware and hardware sources for the Titan M but provided no timeline and clearly didn't mean they would publish the sources for the current revisions but rather future ones. There's the OpenTitan project which they seem to use as a base since the Pixel 6 but that isn't what they committed to doing. We're still waiting for this and hoping they do it soon so that we can help audit this and report better bugs when we run into issues.
I can't imagine the threat model that leads you to trust Google but not Apple, but you do you: Maybe you're a Google hardware engineer and the expensive secret is blueprints for the next generation of Google Glass.
I'm not worried about being targeted by Pegasus, but I am worried about getting targeted for adshit by Google, or them selling all my info to databrokers, or having them disable all my accounts for arbitrary reasons. I think we have different threat models.
Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.
These phone cases with an integrated battery pack goes a long way towards replaceable batteries if you keep a stack of them. They probable put less strain and wear on the built-in battery too.
> They probable put less strain and wear on the built-in battery too.
Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.
This is false. It's true that staying at 100% is harder on lithium ion batteries than staying at 40%. However, the wear due to charge cycles is way, way more significant. Your battery will see much less wear if you keep it at 100% for some time vs discharging and recharging it a few times between (e.g.) 40% and 80% during that same time.
No, that's not at all the case. We made our own MTE implementation for our hardened_malloc project with significantly stronger security properties. We had to fix multiple bugs in the OS and with Chromium's MTE integration to enable it for Vanadium in PartitionAlloc. We do currently simply use the standard implementation in PartitionAlloc but we plan to improve that since it's missing security properties we have in hardened_malloc. We also had to implement a system for per-app MTE control and an MTE crash reporting system. The current kernel KASan MTE backend is inadequate for usage of MTE as a hardening feature so we either need to make our own implementation there too or convince others to do it and it's likely not going to be the latter.
ARM did the work of designing it and integrating it into their standard ARM Cortex core/cache designs. Google/Samsung did the work of preserving standard ARM functionality, unlike Qualcomm which currently loses it. Google/Samsung also had to integrate it into the boot chain. They'd already previously done most of the bug fixing work via testing with HWASan. It is certainly true that Google paved the way to use MTE with HWASan and did a lot of the bug fixing work in the OS but external security researchers did a lot of this work too.
GOS's limited device support is disappointing, but I understand their reasoning. I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
As an alternative to replaceable batteries you could consider installing something like acc[1] to mitigate stress on your battery. My phone is 7 years old and the original battery still holds a charge like the day I bought it.
> GOS's limited device support is disappointing, but I understand their reasoning.
Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking.
> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).
Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
In newer pixel models, everything is glued together. The Backplate is glued to the front, the battery is glued in so hard you can barely remove it and on top of it there's a graphene pad glued ontop of it for cooling reasons.
Wow. I genuinely thought that the replacement process was maybe a little more complicated than on the Samsung Note from 8 years ago that I did myself. That if you just ripped out the backplate you could have an ugly phone (not water resistant either) with a replacable battery.
This complicated, time consuming and requiring specialized equipment process is not what I expected. Especially the part where you have to replace the screen you've just broken.
Now I concur with the original poster in his lament on lack of new and fancy, yet fully owned by the user, phones that can cooperate with Graphene OS
> GOS's limited device support is disappointing, but I understand their reasoning.
Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking.
> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).
Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
> The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced.
You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.
Hope somebody using Graphene OS could answer:
1. Is it very challenging to install Graphene OS? Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions?
2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?
It's easy to install and for 99% of use-cases the OS is just as convenient as any other Android phone.
However, recently my wife and I travelled to Orlando Florida to visit Disney World and Universal Studios. While their apps mostly worked with sandboxed Google Play Services, I did have some annoying issues. The My Disney Experience app gave me a lot of glitches related to Location (it was intermittent but I would occasionally be told I need to be in US or Canada to do something important and we had to use my wife's phone as a workaround) and I found myself unable to log in to my account on the Universal App (again, worked fine on my wife's stock Samsung Galaxy so pretty sure it was GrapheneOS).
Another limitation is that if you use Google Wallet to make credit card payments, this is unsupported since Google will not certify GrapheneOS. Wallet does work otherwise.
Uber works just fine for me. Other than that, I don't use any proprietary apps.
If you intend to stick mostly to FOSS apps you shouldn't have any issues. Most proprietary apps will work with sandboxed Google Play Services, but if any of those are mission critical for you then be warned that you might run into some annoying issues like I did with Universal Studio & My Disney Experience.
Try disabling rerouting for Geolocation requests to GrapheneOS, because I personally found the gps provider integrated in it to be almost unusable, since it doesn't implement Bluetooth/wifi scanning at all.
Yes that means google will get your location, but it's still better than going back to stock which is also better than any other third party skin in terms of privacy/security.
We're going to provide other network location providers including local ones. The existing ones aren't up to our standards which is why we didn't simply bundle them. In theory, we could also support toggling on the less privacy SUPL mode which leaks your location to the SUPL server but can get location without GNSS satellite reception.
It's possible that there was something I didn't figure out how to configure correctly, but I spent a good chunk of time on our vacation mucking with various settings, including disabling re-routing location to the OS :/
I had the same experience with the Disney parks app not working properly at all on Graphene. Otherwise I haven’t had issues, even with other fitness/map apps that require GPS.
1. No, it was very easy. I used a normal USB cable and adb on the Linux command line, but the recommended method involves using Web USB in Chromium which is meant to be easier for non-technical people but I couldn't get it to work.
2. No, it is very convenient. It has a sandbox for Google Play Services, which IMO is the best of both worlds as it means you can install all the proprietary crapware apps that make modern life tolerable, but Google Play doesn't have unfettered access to everything on your phone. If you want even more isolation you can set up a separate user and run all the Google Play stuff in a separate user account, which I did briefly try but personally I can't be bothered switching user all the time.
FWIW, I've used the Web USB installer probably a dozen times without issue, so I would definitely recommend that route if adb is intimidating. I've done it both ways, but the web installer is so easy it feels magical.
As for it not working, were you running a Flatpak/Snap version of the browser? Apparently those are problematic with Web USB. I personally haven't tried on Linux yet (just Mac O's) but now that I've switched to Fedora I might encounter the same issue you did.
Tip: The GrapheneOS Web installer doesn't work for me with the Chromium in Debian Stable.
I always try the Web installer, to see whether it works now, but then end up doing the command line method (which is also pretty easy, compared to historically how Android phone flashing used to work).
> the recommended method involves using Web USB in Chromium which is meant to be easier for non-technical people but I couldn't get it to work.
There's a bug on many Linux distributions which was fixed in fwupd but is still present because they haven't updated it to a recent version. It interferes with reconnecting to the device when it reboots into fastbootd mode as part of the install. We cover it in our install guides now. fwupd usually loses the race to connect to the device to the CLI install tool but wins the race against Chromium's implementation, which is why it impacts web install more. This is likely what you experienced before we documented this fwupd bug and got them to fix it upstream. The problem is that even though fwupd fixed it a while ago, Debian and even the latest Ubuntu still have the bug.
Since you seem to be on the Graphene team, may I piggyback on this: I've been wanting to make the switch over from iOS for some time but it bothers me a bit that I have to buy a Google phone. Are there any plans to support non-Google devices? I know this has been discussed and the answer I've seen is that Google devices are the best fit, but at least one more option would be nice.
Pixels are the only Android devices meeting these requirements at the moment. Other devices do not currently come close to meeting these standards. This post is about MTE which is essentially a Pixel exclusive feature.
Simply receiving monthly and quarterly updates is essentially a Pixel exclusive feature and using an alternate OS providing them still leaves major parts of the firmware/OS without those improvements.
2 of the features on the requirements list are proposals we made to them which were accepted / implemented. There's another one of these pending for protection against data extraction via physical access through exploiting firmware boot modes on After First Unlock devices. Supposed to ship in April, and then we can add it to the list. The non-truncated key fingerprint display (we reported truncating it as a vulnerability) and the fantastic pinning-based hardware attestation support used by our Auditor app are the existing 2.
We've tried working with other OEMs but it hasn't panned out yet. We're often quite frustrated by Google but you'd probably be surprised at how much they have done based on our requests.
(not on the team) I believe the project are open to supporting other devices that meet the criteria, or collaborating with hardware partners to that effect.
As I understand, the way it works is that the project first has to scope out a hardware target that meets their security requirements before support can be considered and funded for. Just that right now there are no other phones that meet the requirements specified in https://grapheneos.org/faq#future-devices
If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.
> (not on the team) I believe the project are open to supporting other devices that meet the criteria, or collaborating with hardware partners to that effect.
Yes, we want GrapheneOS devices meeting the same security standards we've set based on the baseline provided by Pixels while also including additional features we want to have. Pixels are not the best possible hardware but rather the best available hardware by far. There are no other devices even coming close to the current requirements. iPhones come close but are missing major things like MTE which we expect and of course don't have any alternate OS support and their security APIs are the ones needed by iOS which wouldn't work for what we need.
> meets their security requirements
Worth noting that there are privacy requirements listed there too including this one:
> Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
We could list a lot of other privacy, security and performance requirements which we take for granted. We're trying not to be overly strict with the requirements and are trying to keep it simple.
> If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.
This is a factor in us advocating for MTE and other features even if they exist in a form we can use today. We do not take it for granted that future Pixels will continue providing what we expect. We push them to continue doing it and to keep important features we need. We know they're moving away from ARM Cortex cores to their own cores and we want them to provide an equally good MTE implementation. This means we need to advocate for MTE and get other people to advocate for MTE. If people eventually want to have CHERI and other more aggressive memory safety features, please advocate for what they've already shipped. Google enabling asynchronous MTE in production for their own code would be a huge security boost for Pixels and would also help assure that it has a future instead of being treated as a debugging feature they don't need to support on all their devices.
> Just that right now there are no other phones that meet the requirements specified
And that highlights the main goal of GrapheneOS - a security hardened mobile OS. (Note that better 'security' doesn't necessarily also mean better privacy protection).
Our work on security is entirely in service of privacy. Security is not the main goal of GrapheneOS. Highly usable privacy is the main goal of GrapheneOS and security is part of providing it.
The goal of GrapheneOS is providing a highly private, secure and usable mobile OS. It's not specifically focused on security above all else and we work on security in order to protect privacy. A huge portion of our work is on privacy features. We add many significant privacy features including Contact Scopes, Storage Scopes, per-connection MAC randomization, per-connection DHCP state, per-app Sensors toggle, per-app Network toggle doing more than blocking direct network traffic and much more. We have in-progress work on many privacy features including App Communication Scopes, improved state partitioning for Vanadium (privacy/security hardened Chromium) and a lot of other things.
We do a massive amount of work on usability including the whole sandboxed Google Play compatibility layer. We recently made an entirely new setup wizard and plan to replace all the legacy AOSP sample apps with better implementations. Our priority is the OS itself so replacing apps with multiple existing alternatives available simply isn't as high of a priority as improving the privacy, security and compatibility of the base OS. People can simply use another Contacts app so we don't heavily prioritize replacing the AOSP Contacts with our minor changes over focusing on important privacy and security features such as App Communication Scopes, 2-factor biometric unlock and a proper duress PIN/password without bypasses like existing implementations which are 3 current high priorities.
Pixel Camera works fine. It doesn't require Google Play, but the functionality dependent on Google Play and AR Services does work fine on GrapheneOS via sandboxed Google Play.
You can install it via the sandboxed Play Store. Trying to install it via Aurora Store won't work properly unless you set the proper device model.
Google Pay doesn't allow NFC payments on an OS that's not certified by Google. It checks via Play Integrity. You can use a Pixel Watch with GrapheneOS to work around this since the Pixel Watch with the stock OS can make NFC payments itself without the OS on the phone needing to be Google certified. This is not a technical issue but rather a regulation issue. Play Integrity is absolutely not a real security feature but rather part of enforcing Google's licensing system which is presented as a way to defend against tampering with apps. In reality, it's very easy to bypass the device integrity mode via spoofing but not in a way that's suitable for a production quality OS which needs to keep working. It serves the purpose of stopping people using Google Pay and a subset of banking apps with a more secure OS but doesn't stop people using it with a much less secure OS where they're using one of the implementations of spoofing the checks. It's unfortunate. We support for Android's more meaningful hardware-based attestation but app developers need to whitelist GrapheneOS. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu... for app developers, but we haven't yet made a big push to get some of them to do this. It's highly unlikely that Google Pay would do it without the EU saying they must.
Some banks have their own contactless payment app, which can be set as default in GrapheneOS (or any Android). Most banking apps work, as long as they use AOSP's hardware attestation feature instead of Google's SafetyNet, which requires the same Google device certification as GPay.
The Google Camera app can be made to work fairly easily. Google Pay's NFC payment will not work in a useful way because the environment signature differs.
You can buy a device with it, but nearly anyone can use the web installer. It's particularly easy to use from Android, ChromeOS and macOS. Windows is a bit trickier since you need to install a driver. Desktop Linux requires installing udev rules, and some distributions with frozen software versions have a buggy service which interferes.
> Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions?
Non-technical people can do it. You only need a browser with WebUSB. You don't need any special software.
> Is it very inconvenient to use as a daily driver?
Nearly the same as the stock Pixel OS with nearly as broad app compatibility if you use sandboxed Google Play.
> How often phone just crashes and requires a few days of debugging?
You likely won't experience significantly more crashes. It has user-facing crash reporting not existing in the stock OS so you'll notice crashes you wouldn't have known about it. Buggy apps with memory corruption may crash until you enable the per-app compatibility mode, ESPECIALLY if you opt-in to forcing MTE for all user installed apps.
> Will my bank app work on it?
If your bank allows a non-Google-certified OS, which most still do. Banks are gradually disallowing using a non-Google-certified OS and this essentially needs to be addressing as an anti-competition regulation issue. We're working on convincing banks to use https://grapheneos.org/articles/attestation-compatibility-gu... in the meantime.
> Is it very inconvenient to use as a daily driver?
No but it is not the most convenient thing either. The Security Additions, Sandboxing Setup and a bit of slowness due to the hardened memory allocator are more annoying than just using plain android and clicking ok for whatever data it wants from you. Initial Setup and understanding what makes grapheneos different and how to use it's security features takes a bit though.
> How often phone just crashes and requires a few days of debugging?
Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
> Will my bank app work on it?
Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
I guess there's also a chance that a banking app will initially work but then fail after a forced update at a very inconvenient time. Is there a possibility that some use of "integrity signals" (in SafetyNet Attestation API and Play Integrity API) will be banned in the EU out of antitrust concerns? https://developer.android.com/privacy-and-security/safetynet...
> The Security Additions, Sandboxing Setup and a bit of slowness due to the hardened memory allocator are more annoying than just using plain android
You can opt-out of secure app spawning if you deeply care about the small latency added to initial cold start app spawning time. You can opt-out of hardened_malloc with a per-app toggle if you find an app that's incompatible (memory corruption bugs caught by it) or which has bad performance with it.
There's no noticeable performance impact in regular usage. The only thing that was noticeable is the secure spawning (exec-based spawning) taking longer for initial app spawning time but that's entirely covered up by the animation time on current generation devices. There's a toggle for this for people who absolutely cannot cope with it, but we strongly recommend using secure spawning because many other security features depend on each app getting their own initial memory instead of being clones from the same template process (zygote) with a shared memory layout. It's not only about ASLR. It impacts PAC, MTE and any other partially or fully probabilistic mitigations.
> Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
GrapheneOS has user-facing crash reporting not present in the stock OS so users will definitely notice system process crashes they wouldn't have otherwise noticed. This helps us find issues like the Bluetooth crash the thread we posted was about fixing. We make all MTE detected crashes user facing since they tend to be serious issues and the crash reports tend to be useful for app developers or to us. We don't report all crashes by default but rather have a toggle for enabling that for the base OS in Settings > Security because it's too noisy. For example, sometimes hardware fails to fully wake up in the initial second of boot which automatically restarts the OS. It ends up reported as a kernel crash despite the fact that people wouldn't normally notice it. We got flooded with reports about this and had to reduce the scope of the user-facing reporting by default with opt-in to the rest.
Our features do find memory corruption bugs which were often not causing breakage in the stock OS but we believe this Bluetooth bug DOES often cause breakage in stock OS. It shows the other side of it which is that by finding the bugs, you can fix them, and you have fewer bugs remaining. GrapheneOS has dozens of fixes for upstream bugs. We try to report the security bugs upstream but their handling of non-security bug reports is awful so we don't bother for those.
> Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
At this point, it's nearly just the apps that are deliberately trying to prevent using an alternate OS which don't work. Apps using Play Integrity API to forbid using an alternate OS is nearly anything that doesn't work. Some apps also have older implementations of manually detecting an alternate OS. For example, a tiny number of apps look at the call stack leading to starting their app and purposely crash it doesn't match the stock OS which happens with exec-based spawning enabled, which we could add a per-app toggle to work around but an alternative without more complexity would be making it show the same call stack. It's quite silly that this is a problem. Play Integrity API is replacing most of these custom hacks to detect tampering with apps, hooking apps, etc. Play Integrity API COULD allow using GrapheneOS by verifying it using hardware attestation but of course doesn't. Apps can use hardware attestation themselves to do this, but they don't currently do it. We're working on convincing at a few major apps to do that. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu....
It's extremely easy to install. The hard version of the installation is just plugging your phone in Via usb, doing some things with the power and volume rocker buttons, and copy pasting like two or three terminal commands. The easy version is just plugging your phone into your computer and using the single click installer button that works in any Chrome browser.
As for how it works, it's been my daily driver OS on my Google pixel 6 nearly since the pixel 6 came out, and I've never once had it crash on me. Ever. It's never bugged out or needed me to debug or fix or maintain it in any way either. Every app I've ever tried just works on it too, as if I was using stock android, I literally don't even notice the difference honestly. Like sometimes I even forget this isn't what my phone came with. Personally my banking app, discover, works, but I don't know if others would, although I think they probably should since it has Google Play services and the bootloader is locked once you're done installing.
- There's no Google cloud backup, it uses Seedvault instead. It was a bit of a pain setting up some apps from scratch again (those that didn't have other backup mechanisms), but if I ever reinstall or switch to another phone running GrapheneOS I can copy over the backups and presumably restore them. It also supports some remote storage providers, but I haven't bothered with those yet.
- There's no Google Digital Wellbeing, which I used to track screen time and set limits for some apps. There are some limited alternatives on F-Droid, but I just ended up using Tasker to give me reminders when I'm staring at the screen for too long.
Other than that I didn't have any problems, and really enjoy the privacy features. Especially the ability to block network access per app, and set up custom storage scopes.
You can backup more via the OS backup system using the device-to-device toggle. This should really be the default and perhaps the only way to do it. We have a new backup app planned with initial research work into that started.
> and set up custom storage scopes
There's also Contact Scopes now. We've started work on adding App Communication Scopes for controlling that within profiles and we'd like to do similar features for Camera, Microphone and Location (the standard mock location feature is not great).
It's extremely easy to install. You download a couple things and copy/paste a terminal command or two.
It's nearly indistinguishable from stock Android. It seriously Just Works. You may have to enable sandboxed Google Play Services to get some apps but other than that it's basically perfect.
You don't even need to download anything - if you're using a supported browser you can just use the web installer (you can even use another Android phone!): https://grapheneos.org/install/web
Any Chromium-based browser works including Edge included with Windows, Brave or our own Vanadium browser. Firefox may be gradually changing their mind about WebUSB. They added similar features they said they wouldn't such as MIDI. We would make some minor changes and test each revision in Firefox if we could, but they don't provide a way to do it.
It's pretty easy to install using the web installer. Even the "manual" command-line install is really not bad. If you've never used adb before there might be some snags, but there's tons of places online to get help.
As a daily driver, it's very mature and stable. The only downside for me is just a discovery of how much of the Google apps I use and how much they improve the stock experience. The biggest example for me was the keyboard (including speech to text). Thankfully (and something I give credit to Google for as they could make this hard or impossible), you can install most or all of those apps, including the Pixel Camera app, so you don't really have to give up much.
One important thing to note with Graphene is that they prioritize security, which is a little different than many ROMs in the past. For example, they highly discourage rooting due to its security implications, whereas in the past many ROMs came with root out of the box.
1. Not at all, but the install guide is lengthy, and it's worth to read it first, so that you don't end up in pitfalls. Other than that, I plugged it in, clicked buttons on a website, waited between button clicks, and after 10 minutes, the phone was good to go.
2. Not for me, but this highly depends on the use case. Graphene has good, honest documentation regarding this[0]. Banking is a pain point, because to the phone, GrapheneOS is an unverified third party system. Other than this, I have never seen a single crash, and I even use the YouTube apps with the Play store that it lets you install.
As a former user: 1. Installation is easy, assuming your phone is supported, you can even install it via Chrome-based browser with regular USB cable. 2. Great for daily use, no crashes. Bank app might or might not work, depends on the bank.
Because the pixel I got suffered from connectivity loss (even on official ROM, not a GrapheneOS problem) and I needed a reliable phone for holding on-calls. :/ It is a shame, I really liked the system.
I'll agree with all these other answers. It's fairly easy to set up and I've been using it with no more issues than I would expect on stock Android for years. I don't use bank apps though, I just log in to their website.
The only major inconvenience I've heard of is that Google Pay won't let you enroll contactless payments via NFC, apparently because GrapheneOS isn't approved/certified by Google Play SafetyNet.
Google Pay doesn't allow using a non-Google-certified OS. It checks this with the Play Integrity API. It won't be possible to spoof in the long term, so we don't pretend to be an insecure old device without hardware attestation to trick the checks in the short term.
You can use a Pixel Watch or Galaxy Watch paired with GrapheneOS and make payments from the Pixel Watch.
The only issue is that GrapheneOS doesn't provide a built-in way to have root privileges and if you want root on your phone securely you will have to implement that yourself or use some third-party solution (e.g. building a userdebug build, using https://github.com/chriswoope/resign-android-image, using Magisk, etc.).
We simply have far bigger priorities than dedicated the enormous resources to having a whole separate set of releases with userdebug features and an on-device root terminal which requires a special boot mode and isn't persistent. It's theoretically possible to do it in a way that doesn't throw away a lot of security, but isn't being done by anyone right now. Resigning the OS doesn't avoid the major security loss from having it integrated in the way these projects are doing. It gives the false perception of having the verified boot and other OS isolation security intact despite totally ruining verified boot by trusting persistent state and hurting OS security a lot beyond that. It is possible to do it without those problems by having it limited to the user using it, but that means preventing apps hijacking it in any way such as accessibility services.
Super easy install via USB cable to laptop, running Windows and Firefox. Read through the instructions once. (For - example they suggest turning phone on with stock Os, and activating all important features on the phone.
Then it's a few clicks, and about 10-20 minutes it's all installed.
We have a Pixel 4xl and a 5, and everything just works. No crashing. And all updating.
Inconveniences are predicated on whether you use sandboxed Google Play or something else. With sandboxed Google Play it is an identical experience. Everything works.
If not and you use something called the Aurora Store, prepare for nightmares. Or at least that has been my experience as far as inconveniences are concerned with the Aurora Store.
Very easy and solid as a daily driver. I have a Pixel 6a that I've been running it on from when I got it (≈1.5 years), I've never needed to debug anything. My banking apps have worked without issue. The only issue I've encountered is one dual factor authentication app not working on it.
And Netflix can't be installed (at least through the Play store) because of restrictions from Netflix' side (I suppose). But that's okay, I can just stop my subscription through the web interface.
You can use Netflix on GrapheneOS. They incorrectly configured their Play Store listing for the app as needing a Google certified OS but in reality the app doesn't currently check the Play Integrity API. You can install it another way such as Aurora Store and will will work. We do recommend using the sandboxed Play Store as the main way to install apps because it's the most secure (verifies Play Store signing metadata and doesn't trust every WebPKI CA) but unfortunately in this case Netflix did something silly. Do not know why they did it and do not know why they haven't simply stopped marking that way. They use Widevine, not Play Integrity API. Perhaps they intend to use it and did this prematurely, but it would be silly to block non-Google-certified operating systems using it. It doesn't achieve anything.
Pixels only support digital USB-C audio output. USB-C also has a lot of compatibility issues beyond this from non-spec-compliant cables, peripherals, chargers, ports, hubs, etc. Google and Apple have a perfectly good USB-C DAC which is far higher quality than the DAC included for the analog jack on older Pixels, which are known to work well.
Check different cables. I bought a cheap one, didn't work. I bought a Google one it worked. But it broke soon. I bought another different brand and it works great.
As long as the hardware is supported (so, a pixel phone), installing is a breeze and it is not any different from a normal android to use as a daily driver. I never had any trouble whatsoever and my banking apps work fine. AMA :)
We provide a concrete list of requirements at https://grapheneos.org/faq#future-devices which we're trying to extend with as much of the unstated requirements as possible. Quality of implementation matters though.
This is 2024. We need formally-verified operating systems, applications, and tools in the spirit of seL4 but going beyond it in rigor. Cobbling together lightly tested, over-engineered, heaving codebase systems with fragile, dangerous languages in this day and age is asking for users dying when foreign actors hack them, annoying bugs for many, and attack surface for malware and hacking generally.
On top of that, clean and unified UX and usable features must be provided or the engineering is all for naught.
MTE is an optional feature for ARMv8.5 and is only available via ARMv9 in practice. Snapdragon doesn't provide it but they told us they're likely going to add it by 2025/2026.
Pixel 8 and Pixel 8 Pro are the main option with it. MediaTek and Exynos have theoretically added support for it but that doesn't mean any device with their latest flagship SoC theoretically supporting it actually has it available and working.
We want to support other devices and consider this the main blocker because Exynos is not widely used outside Samsung and Snapdragon is better at overall security than MediaTek. Qualcomm dropped the ball on MTE but they're quite good at security overall. It doesn't matter outside our perspective because MTE is not being used in production by others yet, which is why Qualcomm didn't prioritize it.
CHERI provides actual hardware enforced protection. MTE exists to find potential security bugs but no real protection. You've got a 4 bit tag, which an application can forge so if some attacker needed to forge the correct tag they could choose randomly and be right 1/16th of the time. The idea is when MTE is employed you'll get bad accesses occurring occasionally that aren't due to an attacker and don't actually cause anything bad to happen (imagine a typical buffer overflow, it may well be the words immediately beyond the end of the buffer aren't being but to any other purpose so using them actually works). MTE will detect these and they can be investigated and patched before they can get turned into a weaponised exploit.
MTE is actual hardware enforced protection, but simply doesn't have enough bits to reliably detect memory corruption in the general case. It's able to provide a lot of useful deterministic security properties via reserved tags. Normally, the 0 tag is reserved since that's what's used for untagged memory so the random choice never chooses 0. You can also exclude other values, statically or dynamically. This means you can leave things untagged but with PROT_MTE enabled to prevent any tagged pointer accessing them. For example, if you leave register spills, return pointer, etc. untagged then if all stack allocations with potential overflows / use-after-scope are tagged they cannot access that data. As another example, you typically use 0 as the value for currently free allocations which protects them until being allocated again. You can dynamically exclude the adjacent allocations to catch 100% of small/linear overflows along with excluding previous allocation tags. We do this in hardened_malloc with the most recent tags for the 2 adjacent allocations (i.e. current tag if allocated, previous tag if freed already) and the previous tag for the same slot. In the general case, MTE normally provides a 1/15 chance to bypass the protection if you don't statically reserve other tags. Dynamically reserving previous and adjacent random tags doesn't really weaken that.
It's unfortunate that MTE is only 4 bits rather than at least being 8 bits. 1/15 is much worse than 1/255. It could be larger. MTE paves the way for tagging with a larger number of bits, including via a future iteration of MTE with 8 bits or more supported.
It's not specifically a bug finding feature. You can build very useful deterministic exploit protections out of reserved tags, even by simply using the standard 0 reserved tag. 1/15 chance of catching memory corruption in the general case is also nothing to sneeze at especially when combined with other features. If an exploit uses both an arbitrary read vulnerability and then an arbitrary write vulnerability that's 2 opportunities to catch it. It also gets combined with other features which make those exploits less reliable and harder to write. It doesn't exist in isolation. In hardened_malloc, it's just one part of what it does, but it's a huge advancement for it. Tagging the subset of stack allocations with possible overflows or use-after-scope will be another huge step forward.
It would of course be much nicer having massive tags ruling out inter-object memory corruption nearly completely. That doesn't mean MTE is not a good exploit protection and only good for finding bugs. MTE is a lot stronger than most existing exploit mitigations like SSP. SSP provides probabilistic protection against stack buffer overflows by moving the safe variables to the other side and checking a canary on return. If the attacker can leak the canary which is global to the process in userspace, they can write that out as part of it. It also only works against linear or very small (simply by adding padding) overflows. It only has deterministic protection against certain types of C string overflows via a 0 byte if the libc puts one at the start of the canary.
Ideally, but it's not realistic to convince them to do that yet. It is very realistic to convince them to use asynchronous MTE for the base OS and their own apps. The more secure asymmetric MTE is a much harder sell, but would be way nicer for security.
MTE an CHERI use a similar approach but MTE doesn't have large enough tags to provide strong security in the general case. MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
Much lower overhead, currently shipping, able to detect some forms of heap corruption but not nearly as reliably as CHERI. No protection on tags and small (2^4) space for them.
MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
None of what you said is wrong but the point I was making largely centered around tags being architecturally visible, which is quite different from how CHERI operates.
I can hardly wait until mainstream hardware catches up to Solaris SPARC in 2015, or previous memory tagged architectures, to finally tame all those memory corruption issues, only written by bad skilled developers.
I'm aware people may downvote the hell out of this, but if they do they're the ones writing the bugs: it's not "bad skilled developers" it's everyone. Memory corruption is basically a language feature of C/C++.
It's best to not perpetuate the belief that it's dumb people because very few people think they're dumb and I've seen some absolutely amazing coders write some hilarious memory bugs. It just comes with the territory of those languages. It's not "if" it's "when".
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
After 50 years of the Morris worm, only C Machines can fix the non existence of the mythical high skilled developer, and as Hoare predicted it is finally becoming a liability not to care about security.
Great quote. Nice to have memory tagging to help with the debug process these days. Not surprising to see these mistakes being made about 50 years later, as the fundamentals have not changed. Doing the same thing and expecting different results is, well, you know...
HWAsan is semi-hardware-accelerated memory tagging usable on most arm64 devices. MTE makes it much lower overhead for the debugging-oriented synchronous mode but also provides the asynchronous/asymmetric modes aimed at production usage. Asynchronous mode is near 0% overhead and asymmetric mode is overall comparable to the overhead existing barely useful legacy mitigations like SSP. MTE provides both bug detection in production for resolving the bugs and also hardening against exploitation. It would be nice if it had more bits, but it can already provide a lot of deterministic protections.
Highly recommend that any Android developer with a single native library shipped with their app gets a Pixel 8 or Pixel 8 Pro to use MTE for finding and debugging memory corruption bugs. One of the major advantages of MTE is that you can use heap MTE with instrumentation only added to the allocators (such as malloc) without building all the code with it. Stack allocation MTE of course requires instrumenting those stack allocations.
The person who made the mistake leading to the Bluetooth memory corruption bug we found is not at all at fault and neither is whoever reviewed it. It's a hard to spot race conditions leading to use-after-free. It was not immediately obvious what was wrong to us, but we suspected that it was a use-after-free since it usually is and then suspected that it was caused by a race after seeing what looked like a concurrent task being passed data without being passed ownership over the data with the responsibility to free it It's not clear that the function they called runs code concurrency without blocking until it completes, and the language makes writing safe code in extremely complex areas like Bluetooth near impossible. Google is doing a lot of the right things but not going far enough. It's mostly not a developer knowledge or skill issue. It's a tooling issue and we know how to fix these problems in a systemic way. It's viable to secure a small amount of memory unsafe code that's highly audited and receives special attention. It's not viable to write millions of lines of standard C++ without exploitable memory corruption bugs. The in-progress C++ safety guidelines, etc. are highly inadequate and presented as doing more than they actually provide. It's also too inflexible and highly unlikely to be broadly adopted. Rust is also a more usable, more production language that's a lot easier to learn. Rust developers can focus more on avoiding logic vulnerabilities and using the type system to prevent more of those, since there's underlying type/memory safety to build on. C++ doesn't have the foundation to build higher tiers of safely, since it's all built on sand.
> Android has ported a lot of the Bluetooth code to Rust. This is a demonstration of why they need to put more resources into porting the rest of the code into Rust.
I like how they snuck that in there :-D
As someone who spent years writing C and C++, but no experience with Rust, with this porting from C to Rust, how much refactoring is required? That might should be two different questions:
1. How closely does C translate directly over to Rust? Does Rust require some reorganization/refactoring?
2. How is Google approaching this? Are they trying to closely "translate" it as much as possible, or is this an opportunity for major rewrite/refactor?
Also very curious if anyone knows, will the Android Bluetooth stack ever be usable on a standard Linux distro desktop system?
I was recently trying to port a PIC microcontroller simulator from C++ to Rust as an (unfinished) experiment. Because there were lots of cyclic references (modules talking to each other over "signal busses" with callbacks,) I think I ended up fighting Rust more than it helped. It ended up requiring a lot of Box (pointers to heap) for things where I could store the data inline in C++.
My conclusion is that if you're writing a simple CLI or request-response thing, Rust is probably an easy port. More generally, if your code structure could work well with arena allocations, moving to lifetime-tagging of references isn't a big deal.
But if you're writing (admitted ugly) code with cyclic references the way a C programmer would :), Rust will feel like an uphill battle and is not the place to start. I need to start by restructuring the C++ code, moving ownership to a common parent. I think that'll make things better. Iteratively learning more about Rust, but continuing to work in C++ until the code has a better correspondance to Rust.
Edit: forgot the word simulator, and changed RefCell to Box.
It's all good. For what it's worth, I agree with you generally that a lot of the C code I see is like, "differently shaped" than the Rust, so it's not super simple to port directly over.
It's likely pretty far from a 1:1 port, you'll be rearchitecting a lot of what you are writing. It's unavoidable due to the way Rust guarantees memory safety.
Pixels with the stock OS have comparable security to iPhones already. This thread is also about MTE which doesn't exist in Apple's hardware yet. The whole point of GrapheneOS is providing far better privacy and security than that baseline with features like hardened_malloc, Contact Scopes, hardware level USB-C port control, etc.
Daniel Micay himself said that iphones are one of the best choices from a security perspective, GrapheneOS closing the gap. The reason is the close working together of hardware and software, which is very seldom done in case of Android devices - pixels being the sole exception that care about it, that’s why they are the only supported device.
Not much point in buying some fancy lock to your door, if there is a window open next to it.
Also, ios has a very locked down secure mode for the ultra paranoid.
No, that's not correct and what you're stating about my views or what I have said is not correct.
> Daniel Micay himself said that iphones are one of the best choices from a security perspective, GrapheneOS closing the gap.
I haven't said this about current era GrapheneOS. You're referring to outdated comments from 4 years ago. Pixels, AOSP and GrapheneOS have all massively improved since then. Pixels with the stock OS have competitive security with iOS. GrapheneOS is not closing a gap with iOS on security. It is closing a gap on privacy and also surpassing it with features like Contact Scopes.
> The reason is the close working together of hardware and software, which is very seldom done in case of Android devices - pixels being the sole exception that care about it, that’s why they are the only supported device.
AOSP is developed largely with and for Pixels, but that is not why they're the only supported devices for GrapheneOS. They're the only supported devices because they're the only devices meeting the security requirements listed at https://grapheneos.org/faq#future-devices. If you ignore the differences in APIs between iOS and Android while pretending that the iPhone supported alternate operating systems, it does not meet that full requirements list either. The lack of MTE is a simple example.
It's presented as being for the ultra paranoid but what it does is mainly reducing huge amounts of attack surface created by default enabled Apple services. They're basic security measures rather than something super advanced and niche. It's all grouped together into one setting with some aspects impacting usability a lot without being able to get most of the features without that, which was their choice, and is what makes it into way more of a niche feature than it has to be.
These Apple services/features don't exist for GrapheneOS in the first place. People use Signal or the hardened Molly fork on GrapheneOS, not iMessage/Facetime, etc. Android already takes a more cautious approach to media handling in the stock OS. Lockdown mode mainly disables the permissive defaults of Apple services/features and provides attack surface reduction for Safari. GrapheneOS has Vanadium features that are similar such as JIT being disabled by default but beyond that those browser parts of it there isn't a lot that's applicable.
You're correct that it was my position at one point, but it was around 4 years ago and a lot has changed. We did used to say iPhones were more secure from 2014-2019 but it started shifting in 2020 and then especially in 2021-2022 as AOSP, Pixels and GrapheneOS got to the point where we were confident what we provide is better overall for security. It's the same for privacy now overall, but there are areas where iOS does better on privacy and we're prioritizing fixing that by doing better than iOS in those areas such as clipboard privacy where Android is still weaker.
The problem with the iOS ecosystem is that it's not safe from manufacturer spying? This is the much larger issue than 3rd parties. Does lockdown mode prevent this?
Please read https://news.ycombinator.com/item?id=39672701. My actual position is that current Pixels with the stock OS and iOS have comparable security. iOS has overall better privacy including privacy from apps. It's not strictly more private and Pixels with stock OS do have areas where they do better. AOSP on a Pixel doesn't have the heavily integrated Google apps and services which gives it more advantages than the stock OS usually has compared to iOS, so it's hard to say which has better privacy. A major focus for GrapheneOS is addressing the biggest privacy weaknesses such as providing Contact Scopes, Storage Scopes and a per-app Sensors toggle which not only close the gap with iOS in those 3 areas but go significantly beyond what it provides. There are still a few areas where iOS does better on privacy, but GrapheneOS definitely does better overall. Security is a clearer picture where it's clearer more secure overall and there aren't a lot of areas where it's worse since the Pixel stock OS / AOSP starting point has very strong security. Suggest that people look through https://grapheneos.org/features which explains what we provide compared to standard Android 14 QPR2, although it's missing a lot of minor features and some recent major features.
GrapheneOS gets to focus on the weak points in Android and can make a bigger performance and memory usage sacrifice to achieve privacy and security. We can also add more user-facing features and toggles than either Apple or Google is willing to provide. This allows us to do many things they can't do. We care a lot about preserving app compatibility but we're willing to have opt-in features which break some apps, and we're willing to break apps with severe memory corruption bugs by default with an opt-out toggle to get them working. GrapheneOS aims to be nearly as easy to use as the stock Pixel OS once we do more work on the out-of-the-box experience and bundled apps, but we're willing to have more complex privacy and security options available for people who can deal with it. We see the starting point of AOSP as an already very good base relative to other modern operating systems.
I might have not caught that he tried to kill graphene os. Didn't he just say that he decided to not use gOS anymore because he thinks that the developer of gOS might have something against him personally?
Anyway, I don't know a single person who stopped using gOS because of the feud between these two
Gladly I might add since I have been enjoying gOS so far
I suggest to not care about this stuff so much. Can you imagine what sorts of people take part in your daily life, preparing your food, adjusting legislation, providing services like driving the bus, serving your request as a clerk, ringing up your items in a shop, designing and creating your clothes, and so on? We are surrounded with all sorts, and being very selective with a very few makes no difference. If you're interested in the system, I suggest to give it a whirl, your life will be richer with the experience.
Anyway, I don't know a single person who stopped using gOS because of the feud between these two
I'm looking into leaving the iOS ecosystem because the new devices are forcing faceID, and Rossman's experience with Graphene has made me very, very wary of buying into it.
This kind of response is part of the problem. OP was downvoted to oblivion and yet you still feel the need to group Rossman and your swatters together.
I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to disable such a significant security feature for negligible performance gain.