Leaked documents from mobile forensics companies, such as Cellebrite or XRY confirm this. It's impossible to crack a Pixel with GrapheneOS in BFU state. See https://grapheneos.social/@GrapheneOS/112462758257739953 and https://grapheneos.social/@GrapheneOS/112826067364945164

Uh, no? How are you getting this idea?

This is the manifest file for GrapheneOS: https://github.com/GrapheneOS/platform_manifest/blob/17/defa...

It literally contains links to all the AOSP repos or GrapheneOS forks of them. You can clone these exact repos and build the OS from source. GrapheneOS provides instructions for it: https://grapheneos.org/build

> Micay is somewhat Russian-sounding too

Sorry what?

2) The point still stands, desktop operating systems like Windows and desktop Linux distributions are much less secure than Android or iOS. Read https://privsec.dev/posts/linux/linux-insecurities/

[1] https://grapheneos.org/source

[2] https://grapheneos.org/articles/grapheneos-servers

[3] https://github.com/GrapheneOS/infrastructure

It's literally 2018 hardware being sold for 800 bucks. 3 GB of RAM? Seriously? The iPhone XS, also from 2018, has 4 GB of RAM, just saying.

And regarding the security: https://madaidans-insecurities.github.io/linux-phones.html

[1] https://madaidans-insecurities.github.io/linux-phones.html

- Discretionary Access Control, i.e. the standard Unix file permissions

- Mandatory Access Control, implemented in the form of the SELinux and YAMA LSMs (GrapheneOS stopped using YAMA in the 2024031400 release and replaced it with advanced SELinux policies)

- Android permissions which have to be disclosed in the AndroidManifest.xml, and most of the time need to be granted by the user at runtime

Root simply bypasses ALL of these security mechanisms. This is a clear violation of the principle of least privilege, since most of the stuff you are doing with root probably doesn't require access to your entire filesystem, and could easily run within an SELinux context. But writing and deploying a modified SELinux policy would take extra time and effort, and devs are lazy, so they just use root to completely bypass it.

As madaidan points out, only a tiny subset of system processes on Android run as root. [3] And Android has clear guidelines about what root process are and aren't allowed to do. From the AOSP documentation:

> Where possible, root code should be isolated from untrusted data and accessed via IPC.

> Root processes must not listen on a network socket.

> Root processes must not provide a general-purpose runtime for apps (for example, a Java VM).

Desktop systems are very different from Android and iOS. Out of Android's three major security mechanisms, they typically only implement one. This is why ransomware is so insanely successful. Every program has access to all the files and folders of the logged in user, including network shares, etc. Even on systems that implement application sandboxing and a permission system, such as macOS, it's only an afterthought, and isn't enforced properly. (macOS is still miles ahead of Windows and Linux though) For example, when installing a 3rd-party terminal emulator such as iTerm2 on macOS, you have to grant it the permission to access your entire file system (otherwise you will be limited to the home directory IIRC). But this permission also applies recursively to every process started within the terminal, greatly limiting its usefulness.

> I don't understand this. Could someone explain it with more details to me, please?

Android uses Verified Boot to protect against both Evil maid attacks [4], i.e. someone modifying the operating system on the hard drive, and malware persistence. By default, the Android /system partition is mounted in read-only mode, unlike for example your C:\Windows directory, or system directories like /bin on Linux. This prevents malware from modifying the operating system. If you ever get malware on Android or iOS, in most cases you can get rid of it, by simply rebooting your device. Unless of course, the malware has some persistence mechanism. Root obviously provides a great vector for persistence, since the system partition could simply be remounted in a writable mode, and the system could be modified however the attacker wants to.

When you build your own copy of AOSP or GrapheneOS, include your modifications, and sign the image with your own Verified Boot keys, that image can't be modified or tampered with by an attacker. It's perfectly secure to do that (of course only if you can trust the extra code you're including).

[1] https://source.android.com/docs/security/app-sandbox#protect...

[2] https://arxiv.org/pdf/1904.05572

[3] https://source.android.com/docs/security/overview/implement#...

[4] https://en.wikipedia.org/wiki/Evil_maid_attack

The data is cached for roughly 15 minutes. https://grapheneos.org/features#:~:text=It%20caches%20the%20...

GrapheneOS plans to scrape Apple's database and make it downloadable, so Wi-fi positioning could be done fully locally.

> Backing up all app data via Neo Backup

GrapheneOS includes Seedvault by default. https://grapheneos.org/features#encrypted-backups

> High-quality call recording via Call Recorder

Call recording is built into the Dialer app on GrapheneOS. https://grapheneos.org/features#encrypted-backups:~:text=Cal....

> DNS-based ad blocking is possible via apps like AdGuard

DNS-based blocking can also be accomplished by using Android's native Private DNS feature with a resolver that blocks ads. You could even host your own on a VPS if you are more comfortable running name resolution and DNS-level adblocking on infrastructure you control.

The RethinkDNS app also lets you use DNS-level adblocking and a VPN at the same time. https://grapheneos.org/faq#ad-blocking-apps

> I have no experience with GrapheneOS, so I'd be interested to hear if these features are possible on it without rooting.

I recommend giving https://grapheneos.org/features a read.

> If not, can I request these features somewhere?

Check out the issue tracker on GitHub: https://github.com/GrapheneOS/os-issue-tracker/issues

That's only true for microG itself, not the Google blobs it needs to download and execute in order to function. GmsCompat on GrapheneOS is also fully open source.[1]

> For example you can replace the location service with a privacy respecting one.

GrapheneOS literally does that.[2] It's currently not perfect in regard to privacy because they are using Apple's Wi-Fi positioning service, but proxying it through their own servers, so Apple never gets the user's IP address or any unique identifiers, and link the location information to any other data. One thing Apple currently does better than most network location providers is the fact that they don't just return position data for one BSSID, they actually give you the data for hundreds of nearby BSSIDs as well[3], which is more private, and means that much fewer requests need to be made to the service.

Because of this aforementioned aspect, Apple's Wi-Fi positioning system is also incredibly easy to scrape. GrapheneOS plans to build their own database, and let users download it, so Wi-Fi positioning could be performed fully locally.

> It would be amazing if grapheneos would support microG as an option. But they are too much "not invented here" for that to happen.

GrapheneOS doesn't support microG, because it has worse app compatibility than Sandboxed Google Play, and requires elevated privileges, unlike SGP.

[1] https://github.com/GrapheneOS/platform_packages_apps_GmsComp...

[2] https://grapheneos.org/features#network-location

[3] https://github.com/acheong08/apple-corelocation-experiments