Until basic features like cloud backup/restore[1] works on GrapheneOS, they are irrelevant when talking about sophisticated targeted attacks. Your random journa

Until basic features like cloud backup/restore[1] works on GrapheneOS, they are irrelevant when talking about sophisticated targeted attacks. Your random journalist uncovering corruption in Saudi Arabia doesn't have the time to figure out how to flash a new ROM image, sideload Google apps, etc. GrapheneOS is great for privacy conscious technical users who wishes to use Android. For everyone else, iOS is far more secure OOB than popular Android phones and iOS with Lockdown mode beats GrapheneOS and is a single journo friendly toggle. [1]: https://discuss.grapheneos.org/d/15370-restore-from-google-cloud-backup https://discuss.grapheneos.org/d/15370-restore-from-google-c... For all the drones in the replies repeating the same talking point over and over again you fail to address the criticism: GrapheneOS is not usable for non-technical users. Now in terms of security/privacy, anyone who is talking about "look at the public exploits" is missing the point because nobody is attacking GrapheneOS for the same reason why nobody attacks macOS. Yes there is some marginal security difference but it's mostly because nobody who matters uses it. (I'm sorry but you, random SV tech worker who knows about GrapheneOS doesn't count.) If you want some examples of just a _few_ things iOS does that nobody else does: 1. Secure nonvolatile storage[2]: On the most recent iOS devices there is an off chip custom dedicated smart card like device that manages passcode attempts. It's set up in a way that even if you completely hack the storage IC + SEP you cannot get any info on the passcode and still need to brute force on device. The only comparable feature is the StrongBox implemented either with an off the shelf SE (huge attack surface) or Titan M on latest Pixel phones which if hacked + TEE hack (also huge attack surface) gains you offline brute force. 2. Trusted Execution Monitor[3]: Even if you get kernel data rw access via exploit, you cannot kernel code execution because of hardware locks. You cannot even get EL0 userland execution because of the dedicated TXM which monitors the page tables. The only comparable feature is Samsung Knox which does monitor based page table management but done much worse and is full of holes. Pixel has nothing. Neither of them have any hardware locks on kernel code. 3. kalloc_type[4]: in addition to the standard slab based heap isolation that Linux also provides, XNU also promises never to reuse a virtual address for objects of different type completely defeating cross-cache based attacks. Types are also tagged with metadata showing which fields in a struct are pointers and which are numerical data such that the two will never overlap in random cases of slab sharing. There's tonnes more but there's no point listing them all. As someone who've researched both iOS and Android attacks (and you can ask anyone in the industry who've done the same), iOS security is far ahead. GrapheneOS only provides mitigations that bring Android up to par in many areas (caveat: MTE is coming soon on iOS but is current shipped in a performance regressive way in GrapheneOS and a don't-enable-me-but-we-technically-shipped-it developer toggle on Pixels). Also: Android attacks are far and plenty. You don't hear about most of them because they're not newsworthy because they're just dumb vendor bugs and nobody expects Android to be more secure because they don't market it that way. If you want a glimpse of what in-the-wilds are publicly disclosed for both iOS and Android, look at P0's list[5] especially for recent years (2024-2025). Again none of this matters because the bigger argument is that GrapheneOS is not user friendly and therefore it's irrelevant how powerful they defend against the 0.01% attacker who targets specific people. [2]: https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/1/web/1 https://support.apple.com/guide/security/secure-enclave-sec5... [3]: https://support.apple.com/guide/security/operating-system-integrity-sec8b776536b/1/web/1 https://support.apple.com/guide/security/operating-system-in... [4]: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/ https://security.apple.com/blog/towards-the-next-generation-... [5]: https://googleprojectzero.blogspot.com/p/0day.html?m=1 https://googleprojectzero.blogspot.com/p/0day.html?m=1