If apps refuse to run on graphene it's not because of graphene's content it's just a question of whether the attestation is recognised. It's not signed by Google.

I guess one reason you'd want to avoid that is that makes it harder to e.g spoof your location or falsely tell the app that screenshotting is disabled.

> Why can't the stock ROMs use these features and be more secure also?

Some of the features may hurt user experience in some way and people made different trade-off.

For example, GrapheneOS disables USB before unlock so that there's no chance that some driver codes in Linux kernel run in response to a device being plugged in, for attack surface reduction. Then, say, if you have a cracked screen, the touchscreen no longer works and you don't want to fix it, if not for this mitigation, you can use an USB-C OTG cable to connect a mouse / keyboard to the phone, unlock it and export all your data. With this mitigation the keyboard won't work so you are forced to fix the screen first just to get your data out.

For what its worth, all of my local banking and e-government apps work flawlessly on GrapheneOS. The only unsupported feature or app I've found so far is Google Pay. (I'm from Italy)

A good deal of banking apps will run on it just fine.

Some of these features are backported to mainline android, others may be deemed too advanced or just the incentives don't match (e.g. being able to disable networking by the user could cut into Google's earnings, e.g. limited ads in apps).

My banking apps run on it, but my concert ticket app doesn't, so I have a separate phone just for that one app.

Most American banking apps run on Graphene https://privsec.dev/posts/android/banking-applications-compa...

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

Those honeypot phones clearly use marketing aimed at criminals and make all sort of false promises and clearly aren't technical and transparent projects like GrapheneOS. GrapheneOS community doesn't tolerate discussion of crime or implying you are a criminal on their official community chat rooms and forum. Doesn't make sense for it to be a project aimed at luring in criminals.

Anyway, GrapheneOS ships security patches very quickly, often bumps kernel versions quicker than the stock OS etc. Security isnt only reactive, also proactive. Some features like MTE even outrule entire classes of vulnerabilities.

I use graphene not for security but because it doesn't come with any Google surveillance stuff.

Let's be realistic if some 3 letters agency really want some data about me, there's not much I can do to counter that unless I'm ready to go to extreme lengths.

Now in grapheneosin the updates settings it allows you to apply Google's upstream security patches, but grapheneos is forbidden from releasing the source code for these until a certain time later. You can read more about it on their blog. I have them enabled. At least I can rest easy knowing the Grapheneos Devs are able to inspect the code on users behalf even if they can't yet release it.

GrapheneOS is an open source project which was started in 2014 by people with an existing history working on open source projects. It has existed for over 11 years. It resisted a takeover attempt by a company sponsoring it. It's entirely funded by donations with no strong ties to any company, no government grants, etc. We don't accept strings attached funding, only donations. The core people working on the project have all been involved for years.

GrapheneOS has much faster patching than the stock OS. It's many months ahead on Linux kernel LTS patches. It ships the latest GKI LTS revisions from Greg KH which don't lag far behind the kernel.org LTS releases. It also updates other software such as SQLite to newer LTS versions earlier. GrapheneOS also develops downstream patches for many serious Android vulnerabilities before those get fixed upstream.

There are currently a bunch of downstream fixes for Android vulnerabilities in GrapheneOS including fixes for a severe tapjacking vulnerability (https://taptrap.click/), 5 outbound VPN leaks, a leak of contacts data to Bluetooth devices and more serious issues which may be remotely exploitable.

GrapheneOS already provides the November 2025, December 2025 and January 2026 Android Security Bulletin patches for AOSP in the security preview releases:

https://discuss.grapheneos.org/d/27068-grapheneos-security-p...

Galaxy and Pixel devices ship a small subset of these patches early, but not most of them. Shipping them early is permitted. There's 1 to 3 month gap between Google disclosing patches to OEMs and those patches getting shipped as part of the Android security patch level. Shipping the patches early is allowed, but is a lot of extra ongoing work requiring a much faster release cycle to do it well.

GrapheneOS mainly focuses on systemic protections for vulnerability classes either wiping those out or making them much harder to exploit. The systemic protections are what makes it stand up much better to Cellebrite rather than patching known vulnerabilities earlier. Patching known vulnerabilities earlier does help in the real world, but the systemic protections help much more due to severe vulnerabilities being quite common in the current era of widespread use of memory unsafe code and to a lesser extent (for Android, definitely not the web platform) dynamic code loading, both of which are heavily addressed by GrapheneOS. I posted about several of the systemic protections relevant to this in my reply at https://news.ycombinator.com/item?id=45779157.

GrapheneOS has reproducible builds which will eventually be usable to enforce that updates are signed off by other parties as matching the code where they can define their own system for approving releases. Delayed patches are a serious security issue and this needs to be approached carefully with groups which can be depended on to have the necessary resources and skills to manage approving releases properly.

This occurred to me. If I were the feds and broke some secure app like Signal, I’d keep complaining how the encryption is hurt law enforcement and watch people flock to it.

Anyone can build GrapheneOS from source code, which I doubt is true of any law-enforcement honeypot.

It wouldn't be the first honeypot phone, haha.

What bothers me is that when phones are stolen, they end up in other countries. Maybe you are a nobody, but if it is trivial to extract the information on a phone then there is more than an identity theft issue. Generative AI makes all of this shit way worse than it was even a year ago.

That's definitely not trivial and it's a small fraction of the security features GrapheneOS provides. https://news.ycombinator.com/item?id=45779157 explains several of the relevant features. Using hardware memory tagging for the whole base OS is definitely not trivial, and neither is implementing a much more hardened memory allocator. Our USB protection is not a trivial feature and is much more advanced than the USB protection features available in standard Android via the device admin API and Android 16 Advanced Protection mode.

You can configure USB port for charging only in the developer options.

iOS already does both of this afaik. At least the automatic reboot part, I think the USB data functionality is disabled in some cases while locked too.

Alarms work after reboot in the default system Clock app configuration. However, it does not work in all configurations since not everything is properly handled for the Clock app's Direct Boot mode. Google's Clock app works better since it diverged from AOSP Clock years ago. The main thing you'll miss are push notifications since the vast majority of apps do not have Direct Boot support for detecting there are notifications available. We aren't actually aware of any non-Google app supporting it.

True. This is an issue in America specifically. Where there is a Google Apple duopoly on tap-to-pay tech. Can be worked around though with smart watches like Garmin watch with Garmin Pay. In many other regions there are alternatives like Curve Pay or tap-to-pay functionalities in banking apps

That's not the reasoning. The reasoning is lack of proper hardware support on supported devices for secure face unlock.

Coerced unlocking also holds true for fingerprint in some instances and that's worked around by using 2FA (fingerprint + password/PIN).

> stuff that's been removed as a "feature" isn't always stuff that nobody wants.

Graphene isn't made to cater to what everyone wants. Face ID and fingerprint unlocking so clearly have no place in a hardened OS. "Google OS-level integration is absent" should not be suprising.

This said, you ought to be able to have BFU security with stock Android and it's embarrassing Google ships stock vulnerable.

I have no idea what you're talking about. Graphene is my daily driver. "Manual configuration" does not ring any bells. Google OS-level integration being "absent" is a core feature, not an annoyance.

The problem with Graphene is that some app publishers are absolute asshats, they think their app is "more secure" when they require the Google verification spiel, when it is the other way around.

That's because the OS integration is priviliged and that's problematic. On GrapheneOS Play runs sandboxed, like any other user-installed app.

Is it really missing Chromecast? I read that it works if you have Play services (but haven't tried)

The government certainly objected when Apple designed an implementation of encrypted cloud backups for iDevices.

That didn't stop Apple from eventually rolling out encrypted cloud backups anyway.

Apple also refused to insert a backdoor into iDevices when James Comey ordered them to do so. They took the FBI to court and forced them to back down.

Google is perfectly capable of fighting too, but their business model puts them at a huge disadvantage.

If you make your money spying on users to make ad sales more profitable, then you have no choice but to hand it over to any Federal, State or local agency that can convince a judge to issue a warrant.

I think this is a very negative idea to promote: that laws should can be subverted. Everyone should believe that laws work and when they don't we should work to fix that, not assume that it can never be fixed.

>The government does what it wants because it's the government. Mere laws generally don't stand in its way for long.

Sounds an awful lot like terrorists.

Well then why hasn’t the government “discovered” CSAM on apple executives’ computers? We know that at least last year iOS users who had reasonably modern hardware and kept up with software updates were very difficult to hack on par with Graphene, and last fall Apple introduced automatic reboots in iOS 18.1 which closed a lot of “wait for AFU exploit” paths off.

> the founders and Eric Schmidt

Still have huge influence as demonstrated by them stepping in to lead parts of the AI push. Ezra Klein actually has an interesting perspective that the owner class of Silicon Valley has moved right a lot more and the workers are still the same politically causing companies to behave differently. My experience in Tech largely tracks. I would say the middle management and manager class are largely good people and try to navigate the world as best they can although they will choose to not rock the boat whenever possible. The tolerance for activism has just evaporated so we don't hear as much about it anymore.

I’ll be asking Anwar down at the bodega to start carrying jugs of unhackable from now on! I want to try the new razzle dazzle berry and 4D cool ranch if he can get them…

BFU = Before First Unlock after power on or reboot.

In this state, a significant portion of the data on the device remains encrypted and inaccessible, unlike the "After First Unlock" (AFU) state, where the necessary encryption keys are available.

>Last cellebrite leak showed they couldn’t do anything in BFU, and you can tell Siri to put it back in BFU without hands while being arrested.

Source? Note that "disables faceid/fingerprint" isn't the same as "BFU".

“Siri, whose phone is this” doesn’t work on recent iOS versions. You could ask it to reboot, but that requires confirmation

Lots more devices are safe BFU than just Apple's. It's not that complicated on a technical level - it's basically full-disk encryption.

Apple sells the illusion of security and privacy, but they're not meaningfully more secure or private except from the device's owner. Remember when they made a big deal of blocking Facebook tracking, while simultaneously adding their own intrusive tracking?

Cellebrite is like the Kmart Blue Light Special of Israeli spyware, when you compare it to Greykey and NSO Group offerings. I would not use their capabilities as the be-all end-all.

Also fair! I think "leaker" is just bristly to me in this context, when there's a nearly identical version of it just hanging out for folk to find. But also just a hope that some folk might poke around documentcloud for similar documents lying around. Lots of newsworthy gems in there just waiting to be picked up and this's a good example.

> It sounds like you’re talking about the benefits of having both?

physical sims make no contribution to any of their points.

It can be more secure, but it also feels like the kind of "improvement" that's ripe for exploitation. When you put in a step where you have to ask your service provider for permission to swap the SIM, buckle up for the inevitable development of them asking for a $5, $50 or $100 "service fee" so they consider allowing it.

Thought so.

I do wonder what this guy’s on about, hope he comes back.

if you're relying on such feature, you'll probably serve less time being charged with destruction of evidence...

How would they know? Genuine question, I don't run GOS.

If the Duress PIN is an obvious one, it may be one of the first ones your adversaries try. Like 1111 for example. So you may not even have to tell them the Duress PIN for them to attempt it.

They'll have to prove it.

Honestly seems like if you just stay on the latest-and-greatest you'll stay ahead of Cellebrite long enough.

I'll be amused when Apple finally drops a portless iPhone as the next step ahead.

(Apple already has their Qi2/Magsafe setup, and they already have been using 60GHz wireless USB for quite some time now internally with the Apple Watch for diagnostics and service management since Series 7.)