LineageOS, iodé and /e/ are in a much different space than GrapheneOS. They greatly reduce the privacy and security of the Android Open Source Project rather than greatly improving it. They do not provide current privacy/security patches or keep all of the standard protections intact, let alone providing similar privacy and security enhancements to GrapheneOS.

https://eylenburg.github.io/android_comparison.htm is a high quality third party overview comparing them with a focus on privacy and security.

CalyxOS was not a hardened OS either, it just didn't roll back privacy and security quite as much as LineageOS.

> The long-term hope is for a non-Google Linux system with all of Android running in a sandbox (something like Waydroid), but that's not ready for everyday use yet.

GrapheneOS is a non-Google Linux distribution. Google heavily contributes to the Linux kernel and is responsible for a massive portion of the security work upstream. The same goes for LLVM, GCC and many other projects. If you have an issue with using lots Google code including as the biggest driver of security in these projects, you're going to need to avoid Linux too.

Waydroid uses an ancient Android releases and largely disables the privacy and security model. Android apps running in Waydroid are much less sandboxed than in the standard Android app sandbox. It's not a sandbox for running Android but rather a partially working way to run an insecure fork of Android on top of a less private and secure non-Android distribution at a huge cost to privacy and security. It's not a good approach and moving to a much less private and secure OS is not progress in those areas.

▲

jech a day ago | parent [-]

> LineageOS, iodé and /e/ are in a much different space than GrapheneOS.

They have different priorities, granted.

> They greatly reduce the privacy and security of the Android Open Source Project

That's going to depend on your threat model. Many people don't feel that having an unlocked bootloader is a significant threat.

> GrapheneOS is a non-Google Linux distribution. [...] If you have an issue with using lots Google code [...]

https://x.com/GrapheneOS/status/1964561043906048183

Even you seem to agree that we're relying too much on Google's goodwill.

	▲	strcat 10 hours ago \| parent \| next [-]
		> They have different priorities, granted. They do not provide current privacy and security patches. They don't do the bare minimum to protect user privacy and security. > That's going to depend on your threat model. Many people don't feel that having an unlocked bootloader is a significant threat. Not supporting verified boot is a small part of how they reduce privacy and security. Lagging many months and even years behind on basic patches for vulnerabilities is a far bigger problem. Information from the founder of the Divested projects: Issues with /e/: https://codeberg.org/divested-mobile/divestos-website/raw/co... ASB update history: https://web.archive.org/web/20241231003546/https://divestos.... Chromium update history: https://web.archive.org/web/20250119212018/https://divestos.... Chromium update summary: https://infosec.exchange/@divested/112815308307602739 Article from Mike Kuketz about /e/ including covering user tracking in their update client, still using Google services with privileged integration into the OS and major delays for important privacy/security patches: https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nich... Apple and Google both provide support for offline speech-to-text using local models. Apple uses it by default Users can configure it to be fully offline. /e/ sends the user's audio to OpenAI which is hidden away in their terms of service: https://community.e.foundation/t/voice-to-text-feature-using... > Even you seem to agree that we're relying too much on Google's goodwill. That's not what the post says at all, and it's not clear how it relates to talking about other AOSP-based operating systems. GrapheneOS is on the 2025-10-01 patch level and has access to the Android Security Bulletins for October, November and December with the option to ship the patches early via special release channels where sources are published once the embargo ends. We'll also have early access to the quarterly and yearly releases soon, with the option to release previews of those too once that process starts. We didn't have early access to quarterly and yearly releases in time for the Android 16 QPR1 port but should have it for Android 16 QPR2. We're going to be significantly less impacted by AOSP delays than others. We can still complain about a delay in something which was supposed to be pushed on September 3rd not being done yet. It wasn't the topic here.
	▲	hydraraptor81 a day ago \| parent \| prev [-]
		[dead]