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
Straight up conspiracy theories you're spreading here. Daniel Micay is Canadian, Dmytro Mukhomor is Ukrainian (he was literally conscripted into the Ukrainian army last year), and Khalykbek Yelshibekov is from Kazakhstan.
It's open source [1], and they're pretty transparent about everything. You can ask the devs anything, and they will probably give you a really useful and informative answer. They have extensive documentation, and they're pretty open, even about stuff like their servers [2], configurations [3], everything.
Of course the topic as a whole is much more complex than that, but I'll try to summarize it. Android has 3 systems of access control [1][2]:
- 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).
Rooting is a very bad idea. https://madaidans-insecurities.github.io/android.html#rootin... But GrapheneOS is fully open source and provides great build instructions, so you can always make your own build and add whatever features or privileged apps you like within the standard AOSP frameworks for privileged apps with system integration.
> 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.
Definitely wouldn't be unheard of in the Fintech industry. But I don't know, because I don't use the service. My bank thankfully offers their own implementation of NFC payments within their own app, so I don't need to rely on any third-party services. Many banks in Europe actually do this. Here's a German article about Google-free mobile payments on GrapheneOS: https://www.kuketz-blog.de/nfc-datenschutzfreundlich-bezahle...
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.
GrapheneOS doesn't support face unlocking right now, but they have a useful two-factor unlock option that requires both a PIN, and biometrics (currently a fingerprint on Pixel devices) to unlock the device while in AFU. It also allows you at the same time to use a long passphrase in BFU.
> Curve Pay refused to give me an account on my Murena FP6
That's probably because /e/OS uses microG, which is vastly inferior to Sandboxed Google Play on GrapheneOS, and has much worse app compatibility.
You should also know that /e/OS is a highly insecure OS, and both Fairphone and Murena are constantly misleading their customers with false marketing and false promises.
> Are you sure about this? It was my understanding that NFC passes for gyms and stuff worked
This is only true for Google Wallet. It can be used as a normal wallet app for stuff like plane tickets, etc., but Google Pay requires the OS to be specifically whitelisted by Google. This is an incredibly anti-competitive move aimed at supporting Google's monopoly by deliberately disabling functionality on alternative (including much more secure) operating systems like GrapheneOS under the guise of security.