Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking

They couldn't answer the question most on my mind: "We’ve reached out to Google to inquire about why a custom ROM created by volunteers is more resistant to industrial phone hacking than the official Pixel OS. We’ll update this article if Google has anything to say."

Short answer: Google is a business that can be compelled by the federal government in ways that nonprofits are resistant to. Ron Wyden identified one of these weaknesses in 2023: https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...

Let's be very clear: this is still Google's choice. Google could build a phone that they can't be compelled to do anything to after the phone is sold to their customer, but Google alone chooses to not invest in the security of the phones they're selling to their customers. Because: what is good for the government is now equally good for Google.

Do we not remember how Google immediately enabled TLS everywhere, internally, post-Snowden [0]? Remember when Google was "outraged"? Where are those people now? They surely don't work at Google anymore. It's amazing how enshittified Google and Apple have become in a decade.

[0] https://www.bbc.com/news/world-us-canada-24751821

> how enshittified Google and Apple have become

I don’t know about pop-ups or whatever, but as far as mobile security Apple appears to be running the table. 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.

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.

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.

> the Kmart Blue Light Special

Hello fellow old timer. Do kids today even get this reference other than possibly just on context? My other favorite old store was a place called Gibsons where their stores signage had each upper case letter as an individual square. After it went under, more than one location became SBINGOS joints where first/last squares were no longer lit.

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?

No American company has a choice when the Feds want data stored on a company's server.

That doesn't stop Apple or any other company from designing devices that attempt to keep prying eyes out of the data stored on your device.

The government has ways of twisting the arms of uncooperative people/organizations into providing all the backdoors they need. Everything from increased tax and regulatory scrutiny to "discovering" CSAM on executives' computers or phones.

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

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

So we agree: it's puzzling that Google can't manage to do it.

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

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

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

That's not the full story. Using LUKS encryption on your linux laptop might make it "safe BFU", but only if you're using a high entropy password. Most people don't want to enter a 24 character password to unlock their phone, so Apple/Google have to add dedicated security hardware to resist bruteforce attempts, hence the vulnerabilities.

Is grapheheOS actually harder to hack or does cellebrite just not put a lot of effort into supporting it because the very low odds of LEs running into one in the wild?

I read from an old HN post that three letter agencies hate graphen OS. The author heard it from defcon or some similar conference. I couldn’t find the post anyway :/ I think it is buried under one of the posts that discuss Defcon and Blackhat.

Another old-timer here who grew up with Gibsons. It was the only grocery store in town back in the days before WalMart invaded. Ammunition, camping gear, dry goods, garden supplies, farm and ranch supplies, blue jeans, shirts, ties, overalls, etc. They sold everything under one roof in a town of 2500.

I thought they had all been swallowed up and shut down until I moved up here to N Texas and was surprised to find a Gibsons here. It took me a while before curiosity took hold but several years later I visited the store, approx 2003-2004ish, and found they still used old-school cash registers, had no UPC scanning capability and every item had a price tag stuck to it. I think they have since moved into the more modern world locally but the store is still there and is a good source for items that you used to need to go to the town's original hardware stores to find. Some of the items on the shelves may have been in inventory here since the 1970's or 1980's. It's a bit like a time machine where you can get obsolete stuff in a pinch if it is still in stock.

I worked slapping price tags on items in KMart back in the day so I too understand the reference. Glad I'm done with that.

Ah yes, Google could make a unhackable phone secure against state actors, they just do not feel like it.

Not at all a problem that is viewed as so impossible that the very notion of it is beyond belief to the overwhelming majority of software developers. Google can just waltz on down to the corner store and get a jug of unhackable phone software. They just do not want to.

The fact of the matter is that they are incapable of making systems consistently secure against even moderately funded professional cyber demolitions teams. This is true across the entire commercial IT industry with literal decades of evidence and proof time and time again.

Could it also be a conspiracy? Could they also have deliberate backdoors? Sure. But even without them their systems and everyone else are grossly inadequate for the current threat landscape which only continues to pull further and further ahead of their lackluster system security.

It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.

Clearly it's harder but just how much harder is anyone's guess? Surely higher value targets would be more likely to use Graphene, so I would think that would make it just as important to invest resources into.

google even has specially signed fw that let you root the device and unlock anything that doesn't rely on the passcode. secureboot passing and all. i can't imagine that the nsa doesnt have them. after that you just gotta crack the usually very simple passcode. wouldny be surprised if thats what cellrite has lol.

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…

> I moved up here to N Texas and was surprised to find a Gibsons here.

Curiosity kills the cat. What part of NTX? I'm willing to take a trip this weekend just for the lulz. You talking Sherman/Dennison/Paris/Gainesville north, or just Denton/McKinney north? Only thing I'm seeing is one way out west in Weatherford.

You could say that they "hacked the Gibsons".

Two fixes that would be trivial to backport to mainline Android.

I think it's healthy to imagine how authorities might abuse power and under what impetus, in order to head off those abuses. Laws have been subverted in the past, so it's rational to assume that they might be subverted in the future. This is actually a cornerstone of any effort to fix issues.

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.

Google brings to mind the ship of Theseus - many of the core decision makers have changed over the years, to the point where it's arguably a different company.

The biggest change was 2015 (two years after your article): the founders and Eric Schmidt stepped back and a couple of other folks retired, leading to a new CEO, CFO and CBO. Their opinions on how to best run the company were quite different to their predecessors.

I think another major change is the attention Google started to get from government and regulators.

I was pretty much looking for this info. Thank you.

Google being bad doesn't mean Apple is good.

On Lineage this is the default behaviour: charging only until I tap on a notification to change it.

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.

iOS is also compromised according to other cellebrite docs so that makes me think Graphene OS just might not be worth the effort for them.

iOS was hackable in 2024 for certain hardware (in particular the checkm8 era phones) or for iOS versions which had known vulns at that point. Modern hardware with updates was still listed as “in research” which means “we can’t”.

GrapheneOS makes security trade-off that are inconvenient to the user. This results in a far more secure device, but nonetheless a device that the general public would find far more annoying. Google would lose a proportion of its user base by implementing the same protections.

Example: https://old.reddit.com/r/GooglePixel/comments/ytk1ng/graphen...

Also Google Pay is missing.

I'd almost want to avoid GrapheneOS because it gets so much attention from law enforcement that it's probably a big target for various agencies to find vulnerabilities in.

Which particular thing you consider inconvenient or even annoying? You can even install Google Play there.

I see just one minor tradeoff - no face unlock.

It can be fixed, but not through the same protocols and institutions that have been compromised.

That's the closest one to me. I'm in that direction though not in that town. There on Main Street on the left heading south from the courthouse.

This doesn't make sense. If you're worried about the government targeting you, then what is the alternative... less hardened phones? At least Graphene will protect you better than the stock OS. If you're really that concerned then you shouldn't use anything going through cell tower (or take extreme precautions when doing so).

I think that's at the OS level. I think there are things that could be done through the firmware level.

Wouldn't it be a total mindfuck if it turns out that Graphene is less secure[1] than stock Pixel, and this is all part of an ANOM-style honeypot operation that has Feds hyping it up, to trick interesting targets into adopting a less-effective security posture.

1. Such as via slower 0-day responses, for instance. This is a thought experiment, I'm nor alleging that this is what it is.

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

Exactly what someone who sets up a honeypot targeting nerds would want you to think.

This idea is based on empirical evidence.

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.

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

See my footnote in original comment.

Arrows impossibility theorem means someone will always be unhappy, and sometimes those people make the laws too.

That is a major feature. It prevents coerced unlocking.

The last leak was in 2024. Hopefully somone nabs the latest iOS release information

Edit: last released leak showed they had broken the then most recent iOS release (17.5.1) in AFU state on all but the most recent hardware which was marked "available in CAS"

https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...

The good news is neither pixel nor iOS seems to show full file system extract under BFU state in the recent tables I can find.

GrapheneOS updates really fast, like on a weekly basis. The trouble is that you have to trust the developers in general. Even if you did build it yourself, did you read all the code and scripts used to build it? But I think it's still a net benefit for a certain kind of user to have the code, and it raises the minimum complexity of any potential exploit.

You can actually build it. But who has time to audit all that stuff? Then you know, there could be firmware hacks that make all the system-level backdoors a moot point.

Since no phone on the market has open-source firmware, and the firmware likely has all the capabilities of the base system, I think arguing for a firmware lock on that is kind of pointless. Sure, every little bit of security helps, but ultimately you still need to trust a lot of stuff to use a smartphone or most other modern hardware.

Google OS-level integration is absent, and while Google Play Services can be installed, you're still missing things like Chromecast. Also, there's more manual configuration (although I don't remember exactly what, I've never used GrapheneOS). A lot of stuff you do get for free, but not all of it, and stuff that's been removed as a "feature" isn't always stuff that nobody wants.

The auto reboot is configured by default. Its quite a long window, every 18 hours or so from memory. It can be configured to be shorter than this.

I experimented with one hour, but missed an alarm.

Its good security practice to reboot your phone before going to bed, this puts it in the much harder to break in to BFU state.

Neither have had any known BFU on the latest iOS for years. AFU is occasionally possible but most of the leaks had latest software and hardware as still protected. Powering off the phone is always still a good idea though if you can.

Aye but it is good Apple is safe out of the box. BFU is a low bar, and the shame is on Google.

>Lots more devices are safe BFU than just Apple's

Really? Secure against the exploits and methods these tools 3 letter agencies employ? I hate to cry source, but base Android isn't secure. What devices have similar hardware-level security, or have their Android flavor shipping with these Graphene-OS-level patches?

On the other hand, it can be a grave mistake to confuse how things should be with how things are. Activists and whistleblowers should not act with the blind assumption that laws will protect them and that "minor" hurdles to law enforcement (i.e., the 5th amendment in the US) will be sufficient to protect them either.

I'm also unfortunately not convinced that some of these problems are tractible -- one of the core issues is that the legal systems of the world have adopted the third-party doctrine for warrants and so even if there was a legal right to prevent everyone's devices from being backdoored you would also have to depend on Google, Facebook, Twitter, Apple to be willing to go to court at great expense to defend your rights. I don't like to think of myself as being cynical, but I just don't believe that would happen. And if the company is happy to comply, law enforcement doesn't even need a warrant. I honestly don't see how anything other than technological solutions are on the table here.

(I am aware of the high-profile stuff with Apple and Google claiming to fight against backdoors in court. In this respect I must admit that I am a cynic -- Cellebrite/NSO/et al claim they can get into iPhones and Android devices and law enforcement agencies happily buy their products, so someone here is lying.)

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

> Graphene isn't made to cater to what everyone wants.

I know! My entire point is Graphene wouldn't be a good choice for the stock OS on a mass-market phone. The Graphene devices will be great, but if Google were to replace their stock OS with Graphene there would be problems.

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.

That only turns it of on the OS level. GrapheneOS also turns it off on the level of the USB controller.

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

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

They can choose to go out of business instead. See e.g. Lavabit.

GrapheneOS isn't made by volunteers. They have a team of around 10 paid developers. They are a nonprofit foundation that receives donations and uses those to pay developers, infrastructure etc.

Ars Technica has update its article to rectify that mistake. It doesn't mention that anymore.

All of the listed features significantly raise the bar for exploitation ;

https://grapheneos.org/features

Can't manage to do what? Google devices are still full-disk encrypted at BFU... this article is a nothingburger and many previous version charts have been put out over the years.

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.

So much for all the security posturing by Google lol.

Google Wallet works but tap-to-pay NFC payments don't because Google enforces strong Play Integrity for that portion. They only allow Google certified OSes to use it. It's a sad choice on their part, not GrapheneOS' fault or choice.

The face unlock is deliberately left out. Non-EOL Pixel hardware, the only currently support phones, don't have the hardware to support secure face unlock. They lack the sensors. Face unlock on current Pixels is not secure and should be avoided, on stock OS as well.

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

Will Graphene release the patches concurrently with Google? If there's a lag, then then Graphene is a tiny bit less safe in terms of one-day/n-day bugs.

Not having the source of the patch adds some friction to all attackers, but reversing vulnerabilities from binary patches has a long history.

Fingerprint is present in GrapheneOS. Face unlock and pattern unlock are left out because insecure. Patterns unlock is insecure in design. You start at a certain point and the next points you can go to are very limited (not the same point again and you have to be able to reach it). This makes it hard to make a strong lock. Face unlock is insecure because lack of proper hardware for it on the supported phones. Fingerprint is secure. Coercion can be worked around via 2FA feature (fingerprint + pass/PIN).

GrapheneOS provides massive security improvements over Android. You should read https://grapheneos.org/features#exploit-protection for an overview. Cellebrite quite clearly puts substantial effort into targeting GrapheneOS, much more than they do into targeting variants of Google Mobile Services Android across devices. Cellebrite provides much more detailed information and comparisons for GrapheneOS than any other variant of Android. One of the biggest security improvements for exploitation is GrapheneOS using hardware memory tagging (ARM MTE) in the main kernel and userspace allocators for all of the base OS.

GrapheneOS nearly entirely eliminates the attack vector used by Cellebrite Premium by default via software and hardware blocking of new USB connections while locked along with hardware-level disabling of USB data if there are no existing USB connections. Cellebrite's recent documentation shows they can't currently exploit an unlocked GrapheneOS device when the password is obtain from the user which shows that it's not all about the USB protection at all. They were unable to exploit GrapheneOS prior to the replacement of software blocking of new USB peripherals with the much more complete current implementation of USB attack surface reduction blocking USB peripherals, USB gadgets and USB-C alternate modes at both the software and hardware level along with disabling USB data at a hardware level. They were last able to exploit locked GrapheneOS devices in 2022, possibly because of a USB gadget driver vulnerability exposed without needing to enable a non-default mode such as file transfer or a fastboot firmware vulnerability.

Since April 2024, Pixels zero memory in fastboot mode prior to enabling USB in order to prevent a hard reset followed by booting fastboot mode to perform an exploit of the device through the firmware while still partially in the AFU state. GrapheneOS takes care of zeroing memory when booting the OS and zeroes freed memory in both the kernel and userspace. The zeroing of freed pages in the kernel results in properly restoring the BFU state for a clean reboot/shutdown and zeroing at boot deals with unclean resets. Fully encrypted RAM with a per-boot key would be nicer and what we plan to have on future GrapheneOS devices once an SoC such as Snapdragon supports it.

Since July 2021, GrapheneOS implements locked device auto-reboot. It was enabled with a 72 hour timer by default and then reduced to a default 18 hour timer. Users can set it in the range of 10 minutes through 72 hours. This restores devices to BFU from AFU automatically. Both iOS 18.1 (72 hour default) and Android 16 Advanced Protection mode (72 hour opt-in) implemented a similar feature later on. Android implemented it after we proposed it in January 2024 at the same time we proposed several other improvements including the fastboot memory zeroing which we actually wanted to be for all boot modes, but they only did the firmware boot mode and we have to take care of the OS boot modes ourselves in the kernel since they don't do it.

GrapheneOS adds many other relevant features including 2-factor fingerprint unlock (adding a PIN to fingerprint unlock), PIN scrambling, support for much longer passphrases and an optional duress PIN/password.

Duress PIN/password near instantly prevents recovering any data from the device in multiple ways (wipes hardware keystores, secure element and disk encryption headers) in any place the PIN/password for any profile is requested. It also works with the optional 2nd factor PIN for fingerprint unlock, but not currently with a SIM PIN which we're considering implementing.

A basic secure can use a random 6 digit PIN with security based on the Pixel's high quality secure element performing throttling for decryption attempts, which Cellebrite has been unable to bypass for the Pixel 6 and later. A highly secure setup can use a random 6-8 diceware word passphrase not depending on hardware security combined with a fingerprint+PIN with a random 4-6 PIN as a secondary unlock method. GrapheneOS permits 5 attempts for fingerprint unlock rather than 4 batches of 5 attempts with 2nd factor PIN failures counting towards that so a 4 digit PIN works fine for that. Either setup can take advantage of PIN scrambling.

There's a third party article about the userspace memory allocator hardening in GrapheneOS at https://www.synacktiv.com/en/publications/exploring-graphene... with only one minor error (the comparison between out-of-line metadata + random canaries in hardened_malloc vs. 16-bit checksums for inline metadata in Scudo) and one minor omission (write-after-free check for non-MTE hardware). That's just one aspect of how GrapheneOS hardens against memory corruption. It uses MTE in the kernel too. Android 16 only uses MTE for a tiny subset of the OS not including the kernel when Android 16's Advanced Protection mode is enabled. It can't use it for most user installed apps either while GrapheneOS supports enabling it for all user installed apps.

Without Google Pay, Google Wallet is practically a glorified card number vault. Which can still be useful, just not at card terminals.

iOS lacks configurabiluty for both. USB protection is also less thorough technically.

Often faster than weekly around security releases. And that’s on stable.

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.

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.

No, that only changes the USB gadget mode. It doesn't disable USB peripheral support, USB protocol handling, etc. in the OS and doesn't disable USB at a hardware level. It doesn't protect against the vast majority of Linux kernel driver exploits heavily used by Cellebrite. They mainly exploit bugs in USB peripheral drivers but could also exploit lower level kernel code or firmware if they had to.

Modern Android on modern devices does support disabling software USB support for USB peripherals and USB gadgets while locked via Android 16 Advanced Protection feature. It also has a device admin API for disabling USB at a software level through device admin apps, which could implement disable it while locked but cannot provide support for still using a USB device connected while unlocked to make it much more usable. None of that provides comparable protection to the GrapheneOS USB protection feature, which is one small part of the overall GrapheneOS exploit protections.

By default, GrapheneOS blocks new USB connections at a software AND hardware level when the device is locked and then disabling USB data once existing connections end. You can get similar software level functionality via the Android 16 Advanced Protection feature but not the hardware-level protection or the many other exploit protections in GrapheneOS.

https://grapheneos.org/features#exploit-protection explains what's improved compared to standard Android 16. It's not documentation on Android + GrapheneOS features but rather only what GrapheneOS improves.

That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact.

See https://news.ycombinator.com/item?id=45779241 which explains this.

That standard Android toggle doesn't turn off USB support at the OS level but rather controls the default USB gadget mode. USB gadget functionality is one part of the high level USB functionality. That doesn't block USB peripherals, USB-C alternate modes, etc. and leaves nearly all the kernel attack surface being exploited by Cellebrite intact.

See https://news.ycombinator.com/item?id=45779241 which explains this.

That's the standard Android behavior for the USB gadget mode, not something specific to LineageOS, and it does not mean USB is in a charging-only mode but rather than no USB gadget functionality such as file transfer (MTP) is active. It does not mean USB peripherals and USB-C alternate mode are disabled, which certainly work in the default charging-only mode for Android's USB gadget setting. It doesn't even mean that USB gadget mode is fully disabled, only that it's in the MTP mode with MTP disabled. There's a slight difference between the regular and and more advanced setting: MTP mode with MTP disabled vs. no active USB gadget. The USB protection feature on GrapheneOS is for blocking new USB connections as a whole at both a software and hardware level and disabling USB data at a hardware level vs. that setting only controlling USB gadget mode. Most of the attack surface is in the USB protocol implementation and especially the USB peripheral drivers which are not disabled in the default mode Android calls charging-only since it's about USB gadget mode, i.e. using the phone itself as a peripheral.

iOS 18.1 added a variant of the locked device auto-reboot feature used by GrapheneOS, but it has a hard-wired 72 hour timer instead of a default 18 hour timer that's configurable between 10 minutes and 72 hours. iOS doesn't have an equivalent to the USB protection functionality in GrapheneOS and it doesn't enable what it does have by default.

No, that's wrong. You're basing your claims on outdated leaks of Cellebrite documentation showing they didn't support the most recent iOS version yet, which they did end up support weeks later. You can't simply point to outdated documentation where they were working on catching up to claim they don't support those versions and devices today, which is in fact untrue.

Thanks, I was confusing it with the Advanced Protection feature.

That's not true. Cellebrite has working BFU and AFU exploits for recent iOS and usually catches up to the latest iOS versions and hardware in weeks or a couple months. They do not have working brute force support for the Pixel 2 / Pixel 6 or later / iPhone 12 or later due to the secure elements but can still exploit the devices in BFU mode and extract the data available before unlocking. iPhone 17 may work out better due to hardware memory tagging but previous iOS and iPhone models did not hold out in the way you're claiming at all.

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

February 2025 documentation was posted by someone in that thread and a blog post was written by someone about it which was linked there. The initial link posted with the February 2025 documentation died and the blog post only focuses on Android and GrapheneOS rather than iOS too.

GrapheneOS has access to the latest Cellebrite Premium documentation since we have a contact able to share it with us. In April 2024 and then July 2024, we posted screenshots of specific capability tables from the documentation but then stopped doing it because it could result in losing access to it. The contact sharing it with us was still fine with us doing it but later came to the same conclusion we did that it's best not to post anything from it. Cellebrite doesn't like it being posted publicly even though it's essentially marketing their products, probably because it results in pressure on Android and iOS to stop it happening.

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.

Google Pay also works with a Pixel watch connected to a GrapheneOS phone, FWIW.

I did say "almost". But as you mention there aren't many alternative. It would be a better world if there were several options besides just Graphene that prioritize security.

The biggest difference is that the honeypot phones come with their own custom apps all claiming to have completely secure communications. That's their selling point, the set of apps, or even a single one, which they claim is unbreakable. The criminals buying these phones aren't interested in just GrapheneOS on its own. Clearly they don't consider something like Signal secure enough, even if run on GrapheneOS.

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

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.

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.

It’s still a valid question. We have this huge corporation that’s doing so many things, constantly lobbying for policy, obscene revenue all while people are exploiting the apk out of their OS.

In fact, looking at the news this week, the same question applies to Microsoft and Apple as well. Are they too big and distracted to care about security?

Realistic is that some data is impractical to protect and too late to protect if your parents chose a somewhat normal life for you but that is hardly all data.

Even Mr Assange in his embassy could have added fitness trackers to add metrics that were hard and spotty to estimate from video surveillance.

> Really? Secure against the exploits and methods these tools 3 letter agencies employ?

Before First Unlock data on your device is as safe as your password safe. It doesn't really matter if you use Android, iOS or any other devices as long as it have modern crypto on it.

Nah, works without issue. None of the complaints mentioned in this thread is true. There are some issues wrt corp spyware like intune device management, but the kinks are being worked through and figured out (tldr: required apps from corp must be manually installed when activating profile).

Oh is that right? That's cool. That might be enough to give Graphene another go, especially since Android Car is supported now. Thank you.

Reminds me of that one case a few weeks back where Graphene wasn't allowed to release a patch because Google wasn't planning on releasing a patch for it for a few more months.

They generally patch much faster than Google.

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

Citation needed.

Security theater for marketing purposes. End users have no way of verifying that their cloud backups are encrypted, and Apple is the same company that complied with the NSA's illegal, unconstitutional conspiracy to conduct warrantless bulk surveillance on American citizens and lie about it to congress: PRISM.

Fortunately, no intelligence officials faced any consequences whatsoever for perjuring themselves to congress, or for engaging in a unconstitutional criminal conspiracy, so we can trust that the system of laws we've developed is working as intended and that this will never happen again.

I never wrote that the other Graphene OS features and mitigations are trivial. I agree that there is much more to that.

And even if the USB mitigations were hard to write (thanks for all your work, by the way!), they are surely significantly easier to backport from an open source project.

Are you affiliated with the project? I see all your posts are about Graphene OS. On HN it is customary to state it: you often see "author here" in discussions where the author joins. If you are part of the team I would suggest against using the third person ("they have a team...").

I know strcat is the lead Graphene OS developer, and it seems you and Andromxda are very knowledgeable about the project and very active on this thread.

GrapheneOS is basically the Android equivalent of iOS Lockdown mode. Considering how the threat landscape has changed, it would be nice if Google offered this itself. Or became a long-term sponsor of GrapheneOS, seeing how great a job they've been doing.

Virtually every issue I have with GrapheneOS stems directly from the lack of Google Play Integrity causing app incompatibilities. There's some little bits of friction here and there like security mitigations causing app crashes, but when that happens the OS tells you exactly what happened, why, and how to prevent it in the future (there's toggles to disable specific mitigations on a per-app basis). If the OS was deployed widely, those crashes would likely disappear as patches get deployed by developers.

It's very polished and completely usable as a daily driver.

Yeah, technically your phone isn't even involved. The watch manages all the cryptographic keys independently and you can add cards through the Google Wallet app or website.

So Graphene is actually more secure than most stock ROMs, but e.g. banking apps won't run on it "for security"?

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

> GrapheneOS is fully open source

Not really. There is a bunch of proprietary firmware running on those phones, which can be exploited with or without the help of the manufacturer.

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

it might be that guy who uses different accounts for different topics

True but those chips also exist for PCs. Some USB security keys have this feature.

No, it's just that the user will not put up with a system like GrapheneOS.

Is the battery life better with Graphene?

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.

What data _is_ there to extract BFU, really, if you can't break the secure element? I mean, the main storage isn't decrypted yet, right?

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

> In fact, looking at the news this week, the same question applies to Microsoft and Apple as well. Are they too big and distracted to care about security?

Yes, of course they are, but its more rational than just being distracted. If not caring does does not lose you a significant amount of revenue why should you care? The same applies to big players in the industry with regard to security and quality in general.

In this case they have something to gain by keeping phones open to software used by government agencies.

Firmware is not OS.

Your machine is a distributed system. The firmware is what runs a specific node.

Yes they usually have DMA, shared busses, etc. That's an implementation detail.

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

GrapheneOS is literally an OS made specifically with security in mind. They have countless contributions that were later merged into upstream improving the security of all the Android OSs, including hardened malloc and similar.

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

Show me any device on earth that can run a browser that has no proprietary code whatsoever (including hardware) on it?

For many experienced software engineers Microsoft has had a reputation for poor software engineering when it comes to security, reliability, stability, scalability for 30 years.

Google generally has the reputation of doing much better in those areas.

Not sure what would be objective measures to compare.

GrapheneOS has a security preview release channel that is opt-in but includes patches from these embargoed vulns already. Again, it's opt-in but for those with a higher threat model use-case it's nice to have.

One idea is that the stock rom by Google may phone home even when locked. Perhaps with a malicious WiFi network, attackers can exploit the phone through a flaw in DNS or HTTP handling.

If GrapheneOS skips contacting remote servers like that, they would not be vulnerable.

It would be a story of Google prioritizing tracking over security.

For the security preview channel where they have to withhold the code until it's officially released yes that comes out with/days after Google releases them publicly.

With Grapheneos no need for developer options however. It's in the usual menu in the exploit protections submenus.

I would say, similar. In theory it may be slightly worse, because you are not using play services to deliver notifications, but each app does their own fetching (I believe that's how it works), but you will also restrict apps more (due to e.g. being able to restrict network access), so the two sort of cancel out.

Sorry, I had the wrong terminology.

I had the wrong terminology. Your sibling comment explains it better.

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)

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.

Google has many, many government contracts.

I believe that they would face enormous scrutiny in multiple contexts if they adopted Graphene as the next version of Android.

Google also wants Play and GMS to have complete control of the device for their own selfish reasons. I do not see them willingly sandboxing their own control.

So I can think of a few reasons.

Wells Fargo runs on my Grapheme device.

It also runs on Lineage with Mind The Gapps.

> If not caring does does not lose you a significant amount of revenue why should you care?

Sounds like it's time for heavy regulation. These corps are not "normal" businesses anymore, I think special (and stricter) rules should apply to them.

How so? Graphene is perfectly useable for a non-technical user. And once you install Play Store, it's almost indistinguishable UX-wise from any other Android phone.

I see. Thanks for the feedback!

I don't think you can rule out international government pressures to keep these OSes vulnerable.

I agree that not caring happens a lot in the industry. Plenty of places where you'd think security was a high priority shockingly it isn't. Instead, C-levels will dedicate just enough resources to pass security audits clients demand and not a a penny more.

Can concert tickets not be bought in a web browser?

AFAIK older Talos Secure Workstation with Power CPUs was it. Everything open including CPU firmware.

Not sure about smartphones though - they mostly struggle with a fact there are no truly open source baseband.

They removed pattern lock, which makes me uncomfortable.

I don't care for touch/fingerprint (or face) because biometrics aren't protected in the fifth amendment right to be free from self-incrimination.

The only screen lock is PIN.

Do they actually implement anti-bruteforce protections though? Or does it just provide a static secret? Moreover how strong are the anti-bruteforce protections? Do they restrict attempts to a few per second, or actually keep track of how many wrong attempts and wipe themselves if that's exceeded?

Graphene on my Pixel 6 certainly does support fingerprint unlocking.

I prefer pattern unlock, which it does not support.

Not really.

iOS in lockdown mode has multiple features disabled (or crippled, depending on how you look at it), while GrapheneOS is just..... secure by design with secure defaults.

https://support.apple.com/en-us/105120

In iPhone also you cannot just turn on/off/adjust these protections one by one, it's all or nothing.

I mean, hardware is great, it's literally the only safe and secure hardware for AOSP. Samsung are mostly security theater, all the other brands are shockingly bad.

It's literally ONE click away from the GrapheneOS main page, lol, the literacy levels gone through the floor.

https://grapheneos.org/history/

> GrapheneOS now has multiple full-time and part-time developers supported by donations and multiple companies collaborating with the project.

This is beyond being just shockingly, willingly ignorant and this is out there re on the open, so in the spirit of your own response, I would suggest you admit your comment is a hit piece from their infamous competition.

Of your favourite search engine is broken too, here's the link anyone can read: https://grapheneos.org/history/

What they are doing is difficult and expensive.

The talent pool that is willing to work in a nonprofit is not likely large.

In reality you have iPhones (in lockdown mode meaning you mist throw some of the usability away) or GrapheneOS if you prefer android.

No other hardware and software solutions come close. Cellebrite matrix shows it pretty well (and from late 2024 cellebrite cannot even extract entire phone form the unlocked GOS.

Close.

To me it's a biggest missing feature to date (and the team brought that up with European Commission already, as there are no technical or security reasons for that). Worth noting it will work on the old, unpatched, rooted, wildly unsafe phones with the right magisk configuration. But not on the safest os.

Anyway, it keeps the passes okay for me, and for the payments I use Garmin Pay.

Also Garmin watches if you'd prefer wearing something with battery lasting weeks, not hours ;)

No they can’t. It’s very frustrating.

I had to get my friend to buy them for me when I was on Graphene

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

Straight from the horse's mouth: https://discuss.grapheneos.org/d/16393-maybe-re-instate-patt...

> Pattern unlock is a badly designed lock method that's a major downgrade from the security of a PIN for multiple reasons.

> Pattern lock is even more dangerous to people who are as you say more casual users. It is a badly designed and dangerous feature. iPhones not having this is very good for users. We will not add back a major flaw in the OS security design.

If this makes you uncomfortable somehow? OK? Maybe it's not an OS for you :)

Yes unless the app offers Unified Push (like Molly vs Signal).

No, works fine for me from sandboxed (very much unprivileged) YouTube, New Pipe And VLC.

I do have sandboxed Google services installed.

My mental model of this is “Apple releases new iOS with security patches -> time passes before cellebrite develops an AFU exploit -> Eventually Apple patches the exploit -> go to step 1”. By adding auto reboot Apple ensured that since lots of the time is spent in the stage where the latest iOS has no AFU exploit and AFU becomes BFU before that changes, and thus they are stuck with only extracting whatever is unencrypted at boot time at best. The leaked matrices even for September 2024 had no BFU listed for any remotely recent versions.

They are hard to regulate and I really doubt governments have either the willingness or the competence to do so effectively. The businesses are very heavily motivated to find ways around regulations, or manipulate them to to their advantage.

Regulation is a very poor substitute for competition, and for well informed customers.

Some of what I said in this comment is relevant: https://news.ycombinator.com/item?id=45780529

Nope. This is eplus in Japan, and if you try go through the website it tells you you have to use the app. It's cos a lot of shows these days don't use paper tickets, but smart tickets on your phone. It is what it is.

I am not debating what tranq_cassowary and the other two users are writing: it seems all correct (from what I can verify) and useful. I am just suggesting that they disclose their affiliation, if there is any, as a good transparency practice.

I myself am not affiliated in any way with their "infamous competition", not even as a user of their software, so I have nothing to disclose. (Actually, I am a Graphene OS user.)

Don't you remember when Satya Nadella was called in front of a congressional hearing to explain their numerous security breaches? So yeah..

Apple is a different story, but they are not invulnerable to cellebrite either

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

I once thought like you. You do not need to go to extreme lengths to make things difficult and that is what is important. The fact is that the 3 letter agencies are increasingly fucking with normal people in a race to the bottom. Do not be defeatist - that only hurts everyone. The more people protecting themselves the safer everyone is from these people. If people just give up on privacy it puts a spotlight on normal people protecting themselves. The current state of which is so bad I have trouble putting it into words.

Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.

I think their comment is rightly pointing out that if a TLA or other state intelligence actor takes an interest in you specifically, they can do quite a bit of classic spycraft that is considerably more expensive i.e. direct surveillance. No alternative handset OS will protect you from an agent who bugs your house, or someone firing a polonium pellet into your leg from a modified umbrella.

That is hardly the only problem.

The browser is astonishingly bad at dark mode.

The launcher forces almost all icons to greyscale black and white and does not accept icon packs.

I feel like I'm downgrading by my compulsion for Brave and Lawnchair, but some attention is lacking in aesthetics. (e/os has this problem to a lesser degree with the Bliss launcher.)

There is no rooted ADB. Even if a giant OS TAINTED notification appears every five minutes if I ever turn it on, I want it.

There are a few other annoyances that regulate Graphene to one of my experimental spares.

There are many different ones.

More attention than stock android?

Googles goal as a company is to raise their stock price, graphenes goal is to make a secure phone OS. It really shouldn't be surprising to anyone that graphene is doing a better job.

Yes because government regulation when ur comes to technology never makes the situation worse. What are the chances that the government is going to pass laws to increase user privacy and security?

Especially with the current administration that is all about grift and publicly accepting bribes - see Paramount, Disney, Google, Meta, Apple. Twitter

Obligatory https://www.usenix.org/system/files/1401_08-12_mickens.pdf

Put up what exactly? You think privacy and security is readily available to everyone who just desires so? If by "put up", you mean not even putting normal efforts, then sure. That user, along with you, fully deserves to get tracked, profiled and fingerprinted to the maximum extent of mass surveillance

He's a fucking ignorant normie. He has never even tried to install GOS because if he did, he would know how almost identical the experience is with Android and there are no privileged google processes running on your phone which not only hog the resources but sends every single bit of information about your whole life

Why spread FUD? Why prove to the world how fucking dumb you are? Graphene is non-profit. It doesn't allow criminal activities at all. It was never made for it. They do real security research and used to report lots of CVEs to google. It's the most cutting edge android security you're gonna see

You have google to blame. GrapheneOS tried very hard to make sure they have those security patches as google delays publishing the source tree and it's only available to OEMs

That's what I use. The Garmin O/S UX is a bit ass, but usable and I never need to carry money if I am going on a run.

Not sure if any big conspiracy is needed.

Financial pressures cause this to happen well enough on its own.

The marginal gain from making a really secure phone is outweighed by the engineering cost and degraded user experience. (General public would rather the phone support every streaming video and graphics format under the sun than just a few securely implemented ones).

When was the last time you saw a FIPS mode option on a home WiFi router? Or even just the ability to turn off internal services? Oddly, just a single option to disable all management would often by useful and fairly trivial but never exists…

> Regulation is a very poor substitute for competition

I've been following tech for my entire adult life. For more than 30 years now, competition or waiting for customers to become informed has never worked.

The only tools we have against mega corps are the ones the EU is currently applying via DMA and similar. But it will take a global effort in order to permanently shift priorities towards "earning money while doing the right thing" (as opposed to "earning money" state of today).

Corps like Google, Apple and friends are more similar to countries than businesses. The only problem is, international law and political pressure doesn't work on them as they're similar to countries governed by cartels.

"a bit ass" is a charitable way to put it, but same here, it's dependable, dead stable, good enough as a backup map.

You give way too much credit that law enforcement cares about the law and won’t just use rubber hose decryption.

You mean the same Eric Schmidt who admitted that he used a BlackBerry for years after Android was released?

“Install an OS on your phone” is nonsensical to 99.99% of users. You’re in a tech bubble.

That also sounds like a nonstarter for a lot of kiosk and embedded use cases

It's not that bad, my battery lasts around 36 hours. I take it off when I go to shower and by the time I remember to put it back on (~30min) it's usually back to 90%+.

What about people who do not have a smartphone?

This is great information, thank you! Do you happen to know to what extent MTE is used on Android 16 when both Advanced Protection is enabled and when the newly-released "Device Protection" feature is enabled?

Any info on recent ban of SafeDot by Android and GOS? Any plans to implement SafeDot as an official GOS app?

Isn't that now a native android function?

Vanadium is pretty good but I agree there are problems I can circumvent only by using another one (Brave); I presume it's the strict tracking protection that breaks some sites.

Not sure about your launcher problem, but you had to turn it on yourself? I don't experience anything like this on my phones. I miss Nova though; none of the other launchers I tried came near (last tried: uLauncher, Kvaesito, Olauncher, Lawnchar, Niagara. Need to try Square home perhaps).

Lack of rooted adb is a good, conscious choice for the security focused OS. It's not about _you_, it's about the integrity of the OS.

You demand access to adb root. Today Cellebrite cannot extract entire phone with one profile unlocked. I bet they'd be thrilled to hear about the new, beautiful target.

If you really need that, you can build yourself debug image and have access to it. You want it, but that's incompatible with the security model. They give you ways to get it, of course, but without their stamp of OS integrity.

To me safe defaults are a good choice.

I'm not talking about installation. I'm talking about using the OS once it's installed.

Because these apps use google play integrity which only google certified devices pass

It's mostly preventing apps to be botted . As each device has its own certificate and can be banned exclusively, if it's google certified. This certificate( also called keybox/keybox.xml) is stored in the secure enclave in the device.

If you want to dive deeper you can checkout droidguard/play integrity.

Okay, but who cares to be honest? :)

If the general public prefers unsafe phones, they can chose literally any else brand. This is never going to be a mass market phone because of the tradeoffs that are perfectly fine for the intended recipients (eg people who believe a torch/calculator app REALLY doesn't need internet access, or that their Instagram REALLY doesn't need to have access to ALL the photos/videos.

They do it to prevent botting . They use play integrity ( i think ex safety net ).

Okay? Then switch that off? :)

These patches are available to all vendors who chose not to protect their users yet.

Releasing binary patches is allowed, this is why GOS have added the security preview channel.

Well, if you're implying someone is a criminal because they don't want their phone come with the google buttplug and spyware installed....... I think you have a problem :D

I understand that Magisk can be applied to Graphene if the final device lock step is not applied.

I might try that if I elevate it to my daily driver.

I'm not comfortable without root. I have the absolute right to have root on my device.

I don't know why Graphene didn't just take Trebuchet.

A little green dot? No, it's a small fraction of SafeDot functionality. I'm interested in audible notification when camera, mic, or gps is accessed. Currently, I cannot make it work on GOS (maybe, may phone is hacked).

Got it, that makes sense! Thanks for explaining :)

> OS in lockdown mode has multiple features disabled [...] while GrapheneOS is just...

...disabling features. Android Auto, Google Pay, enhanced GPS, SafetyNet, push notifications, support for any apps requiring device integrity, etc.

They aren't redesigning and re-implementing these features securely, they are reducing attack surface just like lockdown mode.

It’s a distinction without a difference when Graphene is installed by zero OEMs.

They don't get to go to concerts in Japan.

An implementation detail where TLAs could theoretically get root remotely? Seems like a bit more than a detail to be glossed over.

It works properly again after post on HN. :-/