The difference between GrapheneOS and iOS is that it is 100% open source, replicable, able to self-sign, and only <1% of the part has dynamic code loading, which is incredibly low compared to any major OS.
You are still having to trust a pile of binary blobs even if you built and self signed every release yourself, which I used to do, but at 240gb of source code it is not practical for most individuals even if you do trust all those dozens of blobs from random vendors, which I do not.
This one is not really a fault of GrapheneOS, and more a reality that Android is not actually an open platform and never will be. I require a lot more control of a device I need to be able to trust than anything in the android ecosystem can offer anymore.
Replicant was the right approach but sadly never got the resources to pursue it at the required scale to support new devices.
GrapheneOS is open source with reproducible builds. Android key attestation isn't specific to GrapheneOS and is OS independent. It mainly exists to check that a key was generated in a hardware keystore. There's no pass or fail based on having an official or unofficial build of GrapheneOS. The hardware can sign public key certificates with metadata on device security including verified boot state (green, yellow or orange), verified boot key hash, verified boot hash (hash of the core OS) and patch levels. That's not nefarious and is useful to end users. Our Auditor app uses it to help users protect their devices. GrapheneOS doesn't use it to require people to use an official build for any purpose. Some banks have regulations requiring them to verify the hardware, OS and app which means they need to specifically allow each non-Google-certified OS. There are only around 3 banking apps are known to permit GrapheneOS that way and without it they'd ban using any non-Google-certified OS.
Software doesn't stop being open source because the releases are signed to be able to verify those. Any OS can be installed on the supported device. The verified boot key hash shown at boot will be different for an unofficial build and so will a query to the hardware asking it to provide it. Auditor and AttestationServer are open source. Those work fine with unofficial builds and forks of GrapheneOS after making builds of those with the correct key.
It's ludicrous to claim software with signed releases isn't open source. Having private keys used to generate the signatures for APKs, updates and the vbmeta image doesn't somehow make it not open source. Every APK is signed and the software isn't somehow not open source because the signature requires the private keys. There are standard tools to compare APKs with different signing keys to ensure the build is reproducible and the same thing exists for the OS as a whole which contains many signed APKs and a signed vbmeta image with verified boot metadata.
The signatures enable the update client to verify the releases and the firmware to verify the OS with the public key flashed by the user as part of installing the OS. Signed updates and verified boot fully work with any build of GrapheneOS following our build instructions. Auditor and AttestationServer also work once they're rebuilt with the new verified boot hash included.
GrapheneOS actually feels just like LineageOS, except that it has faster upstream updates, better security, and greater usability...
I don't understand why it took LineageOS so long to update to AOSP 17, while GrapheneOS managed to update to 17 in just 3 days. LineageOS really should be based directly on GrapheneOS.
> I don't understand why it took LineageOS so long to update to AOSP 17, while GrapheneOS managed to update to 17 in just 3 days.
Here's a hint: GrapheneOS has paid developers working on it full-time, while LineageOS is done by people in their spare time. Also, GrapheneOS has a collaboration with Motorola and through that gets for instance early access to security patches, and probably other things as well. And lastly, LineageOS supports roughly 10x the number of devices. It's significantly easier if you restrict yourself to Pixels.
Also, GrapheneOS has a collaboration with Motorola and through that gets for instance early access to security patches, and probably other things as well.
Just for clarification (your points are very valid): the GrapheneOS developers have stated on several occasions that they getting embargoed patches from another OEM than Motorola.
GrapheneOS doesn't receive early access to security patches via Motorola. We receive those through a different partner. We were already doing security preview releases prior to Motorola giving us access to their repositories which don't contain those.
LineageOS code can update pretty fast, but the problem is they want to do refactors, and also that bringing up a hundred outdated devices is difficult.
> LineageOS really should be based directly on GrapheneOS
I get the point you're trying to make, but in reality, it wouldn't be very useful. Many security features of GrapheneOS could easily be bypassed, due to flaws in LineageOS, such as the fact that they ship userdebug instead of production builds, don't really allow for bootloader relocking, etc. High-level improvements like the GrapheneOS hardened memory allocator, Auditor app (hardware-based remote attestation/device integrity monitoring), etc. are pretty useless, when the entire system has an unlocked bootloader and thus no verified boot, weakend SELinux policies due to the use of userdebug builds, etc. GrapheneOS also purposely narrows the list of supported devices for security reasons. They mandate a high-quality secure element, hardware memory tagging, etc. whereas LineageOS tries to support as many devices as possible. Those two very different philosophies simply aren't compatible.
LineageOS definitely doesn't have most of the privacy and security of GrapheneOS. It lags significantly behind the standard Android Open Source Project (AOSP) updates which means not having all the standard patches and protections. Many of the patches aren't backported to older releases. It also doesn't use all the standard security features. LineageOS doesn't reduce privacy and security nearly as much as many of the operating systems based on it, but it's not as good as a production build of current AOSP on an up-to-date device. GrapheneOS makes massive improvements to the privacy and security of AOSP including providing many important protections missing in AOSP such as Contact Scopes, Storage Scopes and secure paste. It also fixes many privacy and security vulnerabilities not yet addressed in AOSP. They're not at all in the same space for privacy and security.
Linage can hide as much as graphene. Graphene just throwing silly features at you that are basically useless. If you wanna hide from tech companies Lineage works perfectly. If you wanna hide for from government agencies get a flip phone. Only thing grapehene can currently do over lineage is get you an easy felony.
LineageOS doesn't keep up with very important standard privacy/security patches and protections. This post is a clear example where it took until October 2026 to ship crucial privacy/security patches and protections from June 2026.
GrapheneOS greatly improves upon the increasingly inadequate privacy and security provided by Android. It fixes many privacy and security vulnerabilities along with adding important missing privacy and security protections.
Traditional cell phones lack any form of secure communication and are entirely dependent on cellular. Those lack basic updates and security protections in practice too. Those are the opposite of a more private and secure device. A smartphone with GrapheneOS or iOS is far more private and secure than any traditional desktop/laptop computer at a hardware, firmware and software level.
> This post is a clear example where it took until October 2026 to ship crucial privacy/security patches and protections from June 2026.
I don't think that's true (although I see how that could be inferred from the post), I think the post is saying what has been done in the last few months, not at the time that the post has been released.
You can find the changes where the security strings were updated on Gerrit, including in the commit message which were implemented, previously implemented, not implemented (empty for the ones I checked) or not applicable. https://review.lineageos.org/q/subject:%22release:+Bump+Secu...
Images are built weekly, so it should take up to 7 days after the change is merged for it to be available for a device via the updater.
I think they are referring to that LineageOS by and large (there are probably exceptions) does not have support for relocking the bootloader. Some apps refuse to work with an unlocked bootloader (but there are ways around it).
It has drastically lower privacy and security. That includes apps getting far more data, VPN leaks, many serious privacy and security vulnerabilities being unpatched for many more months or years and not having greatly improved exploit protections mainly protected against apps and remote attacks. Protecting against data extraction is a small part of where security matters and there's much more to privacy than protecting against security vulnerabilities.
It's quite the other way around. GrapheneOS is definitely more secure and private, see https://eylenburg.github.io/android_comparison.htm, and also more usable, because Sandboxed Google Play has better app compatibility than microG.
Once KDE 6.8 is released, Valve must add Wayland support for Steam client and Proton/Wine. Also, they should drop 32-bit dependencies for Steam client on Linux, which has been done for Windows and macOS long ago.
+1. Most games, once shipped, completely disband their development team.
If you require game developers to even so much as recompile their game, they simply cannot do it. If you want the game to keep working, you have to guarantee ABI compatibility in perpetuity.
I'm in favor of removing 32-bit dependencies from steam-the-application, except that you still need 32-bit libraries to run 32-bit games in Wine.
Having steam depend on those libraries directly means that when you install you get all the libraries you'll need and you won't run into issues later on when you go to run a 32-bit game and it can't load the appropriate 32-bit system libraries for you. It's annoying for sure but it simplifies the user experience dramatically (especially if you're just installing Steam directly on Ubuntu or something).
Porting traditional Linux desktop distributions to Android devices is meaningless, all you get is more instability, more unsafe and more trouble. Waydroid is a bad implementation on security and compatibility, just running Android in VM is better.
Waydroid disables most of the Android privacy and security model through not having functional SELinux. SELinux is not simply an additional layer of security on Android but rather deeply integrated into the OS. The app sandbox and isolation throughout the OS are heavily built on SELinux. It also heavily depends on it for kernel attack surface reduction combined with internal kernel hardening via exploit protections.
Waydroid uses an outdated fork of LineageOS running with namespaces and a compatibility layer on top of a much less private and secure base OS without similar kernel or userspace security protections. Running up-to-date AOSP in a virtual machine would at least be able to preserve the internal Android privacy and security model for apps to protect apps from each other and the OS from apps. It would also contain the overall OS within it too. Using the much less private and secure OS as the host OS with full access is quite backwards from a privacy and security perspective but would be a huge improvement.
AOSP is much more private and secure than traditional desktop Linux distributions. Moving to that software stack is inherently going to be moving much further away from competing with the privacy and security of iOS. The direction taken by GrapheneOS is to start from AOSP and greatly improve the privacy and security it provides to compete with and exceed the industry standard privacy and security provided by iPhones. That requires more than only software. Hardware and firmware security are very important too. Software security also increasingly depends on hardware-based security features such as hardware memory tagging, hardware control flow integrity protections, hardware-based virtualization and much more.
Keeping user data safe from access via encryption also depends on hardware security features for the vast majority of users not using a very strong passphrase. People take it for granted that they're going to have secure data via disk encryption with a random 6 digit PIN but that's not the case without a good secure element and OS integration with it. The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
This is a meta comment, but I just wanted to thank you for your engagement and insight that you've shared throughout these threads. I personally get a ton of value out of it and really appreciate it!
> The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
Interesting. Could you elaborate? I always thought that Secure Boot is reasonably secure (provided you can set it up in the first place).
The standard UEFI Secure Boot used with traditional Windows and traditional desktop Linux is an incomplete and insecure implementation of secure boot. It doesn't verify the vast majority of the OS, nearly always lacks an unbroken chain of trust from the hardware, does not verify all of the firmware and lacks downgrade protection for both most of the firmware and the OS. In the typical setup, it trusts an enormous number of keys and software. It barely provides any useful security properties.
Secure boot was widely used as a term prior to the UEFI usage of the term including many much more meaningful implementations. The term verified boot refers to the same concept but avoids it being confused with solely verifying a late stage bootloader and OS kernel from UEFI firmware.
Ah yes, so if I understand correctly, you're referring to the fact that, e.g., on Linux a typical Secure Boot setup will verify the kernel (if at all) but not the rootfs. Yes, that's of course a huge issue (as is mutability of the rootfs in the first place). I think what I had in mind is indeed more akin to the "verified boot" setup you described.
Our duress PIN/password feature doesn't pretend that it can stealthily wipe the device. It properly implements what people expect it to do and does it safely. It isn't our role to choose how to use the feature including how to use it in a situation where there are potential consequences to it. We haven't implemented any features which are in any way specific to situations involving law enforcement. We aren't going to give people any legal advice on how to handle situations involving law enforcement. It isn't our role and does not make sense particularly since laws vary so much based on jurisdiction, context and how they're interpreted on a case-by-case basis. If people want legal advice, they should ask a lawyer for it.
It's not possible to provide anything close to plausible deniability for wiping profiles. A deleted profile leaves behind metadata proving it existed in the device encrypted and Owner profile encrypted storage. There are a whole bunch of different ways it can be shown that it existed. ADB can be easily used to identify a wipe occurred and when it occurred. The standard approach used by forensic tools is connecting via ADB and they can easily add support for detecting this. It would be easy for non-experts to figure out how to do it especially with the guidance of a decent LLM. It would put users at risk who believe they can perform a stealthy wipe despite it not being possible. We do not want to provide a feature which cannot come close to working properly.
Android's Private Space has a half-baked feature for hiding that the Private Space is enabled in the user interface for someone without access to the relevant unlock methods or ADB. There are multiple publicly known ways to identify a Private Space is enabled. These aren't treated as significant security vulnerabilities and fixes for it aren't backported to older releases. It isn't practical to cover all possible ways of detecting it even with the limited scope of only attempting to hide it in the user interface and not ADB. We don't plan to remove the feature but don't think it should have been implemented and wouldn't have done it ourselves.
If we implemented a half-baked deniable wiping feature then the flaws would be discussed in this forum, our issue tracker and elsewhere on the internet. It would quickly become known to LLM models, which would be able to assist with detecting it. It would be incorporated into standard forensic tools and guides. This is not an approach we want to take with GrapheneOS.
Our features need to work against adversaries aware those features exist. An adversary aware of the duress PIN/password existing doesn't have a way to tell it apart from a real PIN/password. They'll have to consider if a PIN/password provided to them could be a duress PIN/password even for users who don't use the feature. The feature is now going to be widely known about due to the news coverage and it's still going to work.
On future devices, we want to add duress PIN/password support to the secure element as part of the Weaver rate limiting so it can't even be bypassed with an OS exploit.
