Andromxda

https://grapheneos.social/@GrapheneOS/116016068519170752

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

Starling Bank has been officially supporting GrapheneOS using Android's hardware attestation API (not the Play Integrity API) since 2024.

Starling Bank has been officially supporting GrapheneOS using Android's hardware attestation API (not the Play Integrity API) since 2024.

There are several banks, especially over here in Europe, that have their own implementations of contactless payments, if that's what you mean. Here's a German article outlining this and mentioning a few examples: https://www.kuketz-blog.de/nfc-datenschutzfreundlich-bezahle...

It's totally possible that there will be an option to buy the device with GrapheneOS preinstalled https://grapheneos.social/@GrapheneOS/114749924008111970

It definitely won't be Fairphone. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand...

https://grapheneos.social/@GrapheneOS/115379774100353715 and

https://grapheneos.social/@GrapheneOS/114874684738751793

It isn't Samsung

There is no smartphone fully powered by open firmware. Also keep in mind that the hardware itself is proprietary too.

GrapheneOS releases patches very quickly, often even faster than OEMs do. But patches are only useful for fixing individual known vulnerabilities. GrapheneOS additionally focuses on defending against whole classes of vulnerabilities. [1] For example, in addition to fixing memory corruption bugs in individual system components, GrapheneOS has deployed memory protections for the entire OS in the form of hardened_malloc [2] and by enabling the ARM memory tagging extension for the kernel, most system processes (with very few exceptions) and all user-installed apps.

The honeypot theories don't make sense, since GrapheneOS is fully open source, and very transparent about developers, funding, infrastructure, and other internal stuff.

[1] https://grapheneos.org/features#exploit-protection

[2] https://github.com/GrapheneOS/hardened_malloc

GrapheneOS provides PSDS, SUPL (which are enabled by default IIRC) and an optional Wi-Fi based location provider, so there shouldn't be any positioning issues with E911

The Pixel 5 isn't supported anymore. The Pixel 6a still has a little less than 2 years of support left. These have become pretty cheap.

The Pixel 8 and 8a aren't that expensive either. And keep in mind that they are supported until 2030 and 2031 respectively. [1] They not only receive security updates for 7 years, instead of the 5 years for previous Pixel generations, but also have stronger hardware security, by implementing the ARM memory tagging extension. [2]

[1] https://grapheneos.org/faq#device-lifetime

[2] https://grapheneos.org/faq#recommended-devices