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.
