Andromxda

I recommend reading https://grapheneos.org/usage and https://grapheneos.org/faq, at least in parts. You can take a look at the table of contents and see what's relevant for you.

> LineageOS really should be based directly on GrapheneOS

I get the point you're trying to make, but in reality, it wouldn't be very useful. Many security features of GrapheneOS could easily be bypassed, due to flaws in LineageOS, such as the fact that they ship userdebug instead of production builds, don't really allow for bootloader relocking, etc. High-level improvements like the GrapheneOS hardened memory allocator, Auditor app (hardware-based remote attestation/device integrity monitoring), etc. are pretty useless, when the entire system has an unlocked bootloader and thus no verified boot, weakend SELinux policies due to the use of userdebug builds, etc. GrapheneOS also purposely narrows the list of supported devices for security reasons. They mandate a high-quality secure element, hardware memory tagging, etc. whereas LineageOS tries to support as many devices as possible. Those two very different philosophies simply aren't compatible.

It's quite the other way around. GrapheneOS is definitely more secure and private, see https://eylenburg.github.io/android_comparison.htm, and also more usable, because Sandboxed Google Play has better app compatibility than microG.

I think they're referring to past contributions to AOSP from GrapheneOS developers.

Klarna also offers tap to pay in their app, at least in Germany. Not sure whether that's the case in the rest of Europe or elsewhere.

Klarna has NFC tap to pay in their app too. Not sure if it works outside Europe though.

That's not true. Look at their FAQ [1]:

> GrapheneOS is permissively licensed and is usable for building devices with an immutable root of trust. GPLv3 is deliberately incompatible with these kinds of locked down devices, unlike GPLv2 code such as the Linux kernel. This means GrapheneOS can't include GPLv3 code without forbidding use cases we want to support. GPLv3 is no problem for our own usage, but we don't want to forbid using GrapheneOS as a replacement for the Android Open Source Project in locked down devices.

They're not against GPLv3 and, but they explain why it's not suited for a project like GrapheneOS.

[1] https://grapheneos.org/faq#:~:text=In%20some%20cases,locked%...

You can also use a privacy screen protector. Or use the two factor fingerprint unlock, which requires both a fingerprint and a PIN to unlock. And that's only after first unlock, so you can still use a separate, strong passphrase for BFU state.

And fully disable the USB port (GrapheneOS-exclusive feature). This will make it impossible to extract data with mobile forensics software/devices (such as the Cellebrite UFED).

GrapheneOS already has an auto-reboot feature that can be set to time intervals ranging from 10 minutes to 72 hours. Rebooting puts the device back in before first unlock (BFU) state. This wipes all memory contents, including the encryption keys. Any unlock attempt will have to go through the secure element, which is basically impossible to tamper with (no successful attacks on the Titan M2 so far, or the Apple SEP for that matter), and includes substantial security mechanisms, such as throttling key derivations (through the Weaver API), or insider attack resistance (requiring user authentication before new firmware can be flashed to the secure element).

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

This makes no sense. GrapheneOS is open source, while SailfishOS isn't. On top of that, GrapheneOS is much more secure.

> It's still more open than AOSP

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

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.

> Micay is somewhat Russian-sounding too

Sorry what?

1) No one is saying that. As another commenter mentioned, Android is open source.

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/

They're partnering with Motorola to build devices with official GrapheneOS support. https://grapheneos.social/@GrapheneOS/116159602850585685

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.

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

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

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

If you want an outdated, insecure, and extremely overpriced phone, sure, go ahead.

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

That's perhaps because typical consumers don't build their own operating systems?

They're insecure [1] and far from usable.

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

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).

[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

No, this is incorrect. The GrapheneOS NetworkLocation client (https://github.com/GrapheneOS/platform_packages_apps_Network...) is using Apple's request format and performing the calculations locally, similar to how it's done on iPhones. The proxy is just an entry in the nginx config: https://github.com/GrapheneOS/grapheneos.org/blob/main/nginx...

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.

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.

> 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

and CAN'T link the location information to any other data

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...

> you can inspect the code it's running

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

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.

> Graphene IIRC keeps a compatibility list somewhere.

This is the community-maintained banking app compatibility list: https://privsec.dev/posts/android/banking-applications-compa...

> 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.

Curve Pay works fine on GrapheneOS, there's even an article by a community member talking about it: https://shkspr.mobi/blog/2025/06/contactless-payments-with-g...