▲ 132 points
back
45 comments
I can't imagine Google doesn't know about the techniques Graphene employs or how to enable them themselves. What are the downsides to offering these mitigations? Is the performance impact of zeroing freed memory that high? Does offering a setting to block USB devices by default impact the user experience that badly?
I kind of want to try GrapheneOS but because unlike other ROMs they care about security and not so much compatibility, most root-avoiding/ROM-block-avoiding features just aren't available on it.
Google is afraid of small performance penalty. GrapheneOS offers knobs to control compatibility. You can always turn off individual protections, in case an app could not function under default settings.
>most root-avoiding/ROM-block-avoiding features just aren't available on it
this isn't really an issue, I've been an happy GrapheneOS user for quite a while and I've found 0 apps that refuse to run on it, even several banking apps, paypal and other "sensitive" applications that usually block "tampered" devices.
Do note that I've relocked my bootloader and haven't installed magisk (but I'm confident in saying that hiding magisk is easy since before GrapheneOS I used LineageOS + microg + magisk without having trouble running banking apps)
Hmm, we must have very different sets of apps. I had a number of issues with common apps working properly on GrapheneOS, even with Google Apps installed. Also, Location Services never really worked, because there seemed to be no inserted alternative to the WiFi and Mobile Tower mapping database necessary for precise location (i.e. Mozilla Location, beacondb.net, position.xyz).
I still used it until recently, but it was a noticably degredation.
A friend of mine who ran customer support said: if you break some app with av upgrade, you get a shitstorm.
I know, but I'd be happy to accept a "lockdown mode" for Android that enables these features with a setting. Lockdown mode on iOS breaks apps (and clearly warns users about it) and that's been accepted pretty well.
Besides, Android breaks tons of apps every major version upgrade.
I always wonder if not doing this is a carryover from spinning disks where the performance penalty was a big deal.
The other reason for not doing it by default is probably to enable digital forensics for people who don’t know any better.
For one, Google would have access to less telemetry for ad purposes.
Google already gets all the telemetry it needs through play services and all the other SDKs they offer (eg. firebase). It doesn't need to search through freed memory.
Since grapheneos sandboxes everything, including google play, is this still true?
I think it is not true. It would help if the GrapheneOS project included some examples of how Google Play is privileged in the standard Android. Google Play Services can access all of the following, for example: clipboard data, network information and connection details, sensor data, the list of installed applications, app usage statistics.
You can install the sandbox without granting these permissions (and they are not granted by default).
As a happy GrapheneOS user, I just want to say thank you to the people behind the project.
[flagged]
Meanwhile, apps are starting to block GrapheneOS (and others), because GrapheneOS doesn't pass the Play Integrity "security" test. At the same time, stock devices that haven't received security updates for 5 years (and are vulnerable to known exploits) do pass Play Integrity.
Google is basically using Play Integrity to limit the functionality of Android variants like GrapheneOS (while pretending it's about security), and app developers are, for some reason, happily going along with it.
Play Integrity is DRM masquerading as a security feature. Unfortunately, many app developers care more about the former.
I kinda understand it if a developer actually wants DRM. But why does my bank care to use it? I'm not likely to pirate my banking app.
Your bank loses money when keyloggers/etc are used. Play integrity claims to avoid this problem, and a rooted device with an alternative ROM is a big red flag.
There are nuances here and there are probably ways app developers could support legit Graphene but not a malicious fork, but that’s a lot of work and expertise to reach an extra 0.01% of the population.
> Your bank loses money when keyloggers/etc are used. Play integrity claims to avoid this problem, and a rooted device with an alternative ROM is a big red flag.
Well... no? Maybe a device with things running as root is a yellow flag, but malware isn't going to replace the ROM or install a normal user-controlled root solution. Or put differently, if your "security" system flags the latest version of Lineage OS but doesn't flag a year-old stock ROM with known CVEs, then your system is actively fighting against security.
I understand the idea, but GrapheneOS doesn't even provide any kind of official support for rooting. It's not that they're checking to see if the device is rooted, they're just checking to see if it has Google's checkmark.
Meanwhile, rooted devices can pass Play Integrity (since they can spoof all the necessary bits via root).
Isn’t play integrity based on PKI and hardware root of trust? How does a rooted device fake the signed ROM / bootloader / etc?
You're not likely to pirate your own banking app, but thieves would love to patch the APK (or OS itself) so that it works "normally" except for skimming off credentials etc. in the background. This is functionally equivalent to what happens in app piracy (or game cheating, etc.), and all the same mechanisms are used to try to prevent it.
I don't blame the banking apps, it makes sense given their incentives and constraints. But if Play Integrity existed to serve the user, it would answer only to the user, and not "snitch" the device integrity status to apps and their backends.
Because it says “security” and looks good on paper. For some inexplicable reason, many banks don’t seem to care about actual security, even the modern ones. (Shame on you, Revolut)
App developers are going along with it because many of the third-party ROMs so insolently take the view that a user's device should serve the user.
And some of those users are malicious. It’s easier to cut off small populations than to sort out the good ROMs from the evil ones.
If your app can be manipulated to your disadvantage by the user, then you are putting undue trust in client-side software, and you need to rearchitect your service.
Or, sure, you can stick with your lazy, slipshod design and try to paper it over with (unreliable and stupid) attempts to disempower the user.
Security isn’t binary, it’s about layers and probabilities.
A client that attests play integrity is less likely to be an attacker than one that isn’t. That doesn’t mean it’s impossible to use an attested device in an attack, or that all non-attested devices are malicious.
A good heuristic is that if you find yourself using absolutes and dramatic, insulting language… you do not have a valuable insight about security.
> Security isn’t binary, it’s about layers and probabilities.
A truth frequently abused to excuse obviously bad practices.
> A client that attests play integrity is less likely to be an attacker than one that isn’t.
A comfortable, yet completely unjustified, assumption.
Security, from an app developer perspective, isn't necessarily about the user getting exploited. It's also about protecting the app's interests.
Phones rooted by malware will fail Play Integrity, if checked well (hardware verification). For apps that are on the hook for paying for users' mistakes (banking apps, for instance), that makes a lot of sense.
Games care more about preventing cheaters than about users getting their Bluetooth stack getting exploited.
Remote attestation like Play Integrity can be used for legitimate security purposes, like in managed MDM settings, but it's not just about security.
This is very well said. Every time the subject of smartphones comes up, people will claim there are workarounds to the privacy, security, repair-ability, or usability issues. These arguments have some merit, but these workarounds are almost always very fragile, tenuous, and completely out of reach for most normal users. If you come to rely on these workarounds, you'll be playing a game of cat and mouse for years as Google and Apple find different ways to indirectly ruin your workflow.
Is everyone forgetting that GrapheneOS only runs on one specific brand, namely Google's Pixel line exclusively?
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-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-sec5...
[3]: https://support.apple.com/guide/security/operating-system-in...
[4]: https://security.apple.com/blog/towards-the-next-generation-...
Do you have a source that iOS Lockdown Mode protects against Cellebrite? Because Cellebrite boasts they can extract data from latest iOS versions and does not even mention Lockdown Mode as an obstacle in their documentation: https://stacker.news/items/617666
Meanwhile, Cellebrite is unabe to extract data from newer Pixel phones with GrapheneOS: https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
That is simply wishful thinking. iPhones have had plenty of embarrassing, severe exploits used in the field, such as zero-click RCEs https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zer...
I've just recently switched to GrapheneOS and I must say it has been very convenient. That is, coming from the hassle of flashing LineageOS to Samsung devices.
Obviously, buying a device and using it as it is will always be the easiest path and I would have recommended Apple to anyone looking for this until this week, when Apple pulled the E2E feature from British phones.
So GrapheneOS is the only reasonable option left that I know of.
Installing sandboxed Google Play (no sideloading needed) from the Graphene App Store is a breeze by the way. It's right there after installing the OS.
And Pixel devices don't try to keep you from replacing the stock rom, you don't lose your warranty doing it. And there is a browser-based installer that gets rid of the need of using command lines.
Klickibunti, as German GUI-defiers would say.
GrapheneOS team has done an amazing job building a rock solid OS for mobile. But because it does not have the feature you need, doesn't mean it's useless for rest of us. I use it everyday for it's privacy and security features. Your argument is really weak. What does cloud backup has to do with it protecting from zero days?
AIUI Lockdown Mode doesn't stop e.g. Cellebite. (Lockdown Mode was introduced as an answer to e.g. Pegasus)
Cloud backup I imagine is seen as an anti-feature.
Nobody _needs_ to side load Google apps. That's the whole point - you don't have to use anything Google.
And I imagine many journalists do indeed take couple of hours to install GrapheneOS as it's a valuable tool of the trade.
Believing iOS is the most secure is just buying into their marketing. Sorry
This is such a shallow take. There is little learning involved in setting up GrapheneOS, especially if someone a little more techy lends a hand. I'd argue I need less of my tech background and run into far less hiccups than my typical linux desktop install experience. What's especially frustrating about this, is there's no need to sideload apps, or anything you're implying. I can use any cloud backup app I want, there's a built-in installer for a sandboxed Google Play Store, and generally you have almost no discernible usability differences vs stock.
> iOS is far more secure OOB than popular Android forks and iOS with Lockdown mode beats GrapheneOS
Do you have a source for this?
I'm curious about this too. AFAIK the most recent leaked Cellebrite docs indicated that GOS can't be broken into, and I dunno how iOS could be more secure than that.
It depends what you mean by secure. Vulnerabilities is a market and if GOS happens to secure the vulnerabilities that are convenient and work on all standard Android releases, most of the market doesn't support putting the research into setting up additional vulnerabilities against it as they will until another iOS vulnerability is found and weaponized.
Probably GrapheneOS is too small a target for Cellebrite to bother focusing on. In the mean time, I would expect Google to fix the 0 days and we move on.
That's just to say that in my ranking of Cellebrite-using threat actors we're all ultimately just meat popsicles anyway.
> basic features like cloud backup/restore
Cloud backup/restore work fine (well, kind of fine; they should stop with the stupid restrictive list of supported backends).
They just don't happen to support Google's cloud, because Google is untrustworthy.
> caveat: MTE is coming soon on iOS
Do you have a source on that? I'm interested.