/e/ has extraordinarily poor privacy and security. Extremely delayed privacy and security patches including years of delays for kernel, driver and firmware updates or complete AOSP patches is not compatible with privacy.

/e/ rolls back privacy and security far more than LineageOS and /e/ includes their own invasive services. Murena services even send data to OpenAI without user consent.

https://discuss.grapheneos.org/d/24134-devices-lacking-stand... is a detailed post covering the lack of privacy and security of /e/ with a bunch of linked sources including other detailed posts by third party privacy and security researchers. It also touches on the lack of security of Fairphone hardware including end-of-life Linux kernel branches not getting LTS updates and delays for driver/firmware patches, but it's much worse with /e/.

You post something similar almost every time /e/OS is mentioned.

I recognize that GrapheneOS has a different threat model in mind (journalists, activists, etc.), but /e/OS is a big improvement over OEM Android for most regular people. I tend to agree with your linked article that for users happy to live in Apple's locked-down glass box, iOS is a more secure, more usable system than either Graphene or /e/OS.

/e/ isn't a safe option for regular people. It doesn't provide the most basic privacy and security patches or protections. Multiple years of important privacy and security patches being missing is terrible for a personal computer with tons of sensitive data. Replacing the stock OS on a Pixel 7 with an OS multiple years behind on important privacy/security patches and protections with different service privacy issues is not an overall privacy upgrade. /e/ has their own privacy invasive services including sending sensitive user data to third parties without consent and user tracking via unique identifiers.

/e/ claiming a voice-to-text service is private while it actually sends the audio data to OpenAI is not the approach of a privacy project. Falsely claiming the data sent to OpenAI is anonymized when it's brought up makes it worse. That's one representative example.

I didn't mention GrapheneOS in my reply above, but it's not aimed at a niche audience or specifically for people who need advanced protections as your claiming. It provides much broader app compatibility, stability and usability than /e/ despite their inaccurate claims about it. GrapheneOS is a privacy project providing both privacy protections and also security protections to avoid exploits compromising privacy. iOS is certainly far more private and secure than /e/. It's definitely less secure than GrapheneOS against remote attacks on browsers, messaging apps, etc. iOS having a more secure kernel than the current status quo of hardened Linux doesn't mean it's more secure overall.

I think your threat model is wildly backwards if you believe that average users are concerned about threats from bugs in old kernel versions. In all of your posts, you carelessly (or deliberately?) conflate privacy and security. This is the same shell game that Google themselves play in their marketing https://www.tomsguide.com/phones/google-pixel-phones/the-pix...

Your idea of a super-secure phone is a modern kernel with all the security patches running trusted, official signed Google Play spyware in a sandbox and all the apps collecting personal data in the same sandbox. There's an XKCD meme about this: https://xkcd.com/1200/ You are worrying about the printer drivers.

/e/ lacks privacy without taking exploits of unpatched security vulnerabilities into account due to having severe unpatched privacy vulnerabilities, lack of modern Android privacy protections and lack of important privacy features filling major gaps in Android privacy covered by iOS such as Contact Scopes and Storage Scopes. Some major gaps in privacy aren't covered by either Android or iOS such as a Sensors toggle, especially with how the sensors can be used to do rough recording of audio.

Taking advantage of privacy flaws in older versions of software is the norm and not treated as malware by most platforms, app stores, news sites or the public at large. Many widely used apps abuse privacy flaws in older Android versions. That happens both in the form of privacy bugs which were fixed in newer versions and weaknesses in the design addressed by newer OS versions. Only privacy patches for issues considered bugs which are assigned a High or Critical severity are backported. The severity is very subjective and they try to avoid adding a large number of backported patches since some OEMs struggle to keep up with it and adding more patches would make it harder. As an example, VPN leaks are only considered Low or Moderate severity issues by Android and don't get backported. Many other kinds of privacy issues are similarly only fixed for the latest OS releases. As another example, many important privacy improvements are not considered bug fixes at all and aren't candidates for being backported regardless of importance. Many privacy improvements require changing the APIs used by apps with new target API levels which can't be backported without breaking compatibility.

A large portion of the missing patches in /e/ we're referring to are privacy patches, not security patches. However, security patches are also needed to protect privacy. Many apps and services abuse the privacy vulnerabilities. The patches being referred to are a mix of both. A large subset are privacy patches, especially the Moderate and Low severity patches due to how they assign severity. Only certain particularly awful classes of privacy vulnerabilities can get considered High or Critical severity to be candidates for Android's backporting to older releases.

Apps exploiting security vulnerabilities to get code execution would be considered malware and is rare, but apps abusing many privacy flaws in older Android is the norm among mainstream apps. You're wrongly interpreting the regular stream of patches for vulnerabilities as only being for security issues when many are for privacy issues. With /e/, you aren't getting the bare minimum to protect privacy and security. Privacy also depends on security and is not an entirely separate thing as you're portraying it. We're not conflating them but rather they're very closely related. You're also disregarding privacy vulnerabilities and the steadily improving standard Android privacy protections.