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.
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.
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.
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.
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.
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.
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?
So we agree: it's puzzling that Google can't manage to do it.
>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?
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.
Source? Note that "disables faceid/fingerprint" isn't the same as "BFU".
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.
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.
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.
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 does what it wants because it's the government. Mere laws generally don't stand in its way for long.
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.)
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.
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.
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.
Not having the source of the patch adds some friction to all attackers, but reversing vulnerabilities from binary patches has a long history.
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.
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.
See https://news.ycombinator.com/item?id=45779241 which explains this.
See https://news.ycombinator.com/item?id=45779241 which explains this.
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.
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.
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.
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.
Example: https://old.reddit.com/r/GooglePixel/comments/ytk1ng/graphen...
Also Google Pay is missing.
I see just one minor tradeoff - no face unlock.
Coerced unlocking also holds true for fingerprint in some instances and that's worked around by using 2FA (fingerprint + password/PIN).
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 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.
Ars Technica has update its article to rectify that mistake. It doesn't mention that anymore.
My only issue was less compatibility with my local emergency services, since they can't see me on a map for some reason if I call from a GOS phone.
My solution to that was a second Pixel as an emergency phone - one with the stock OS, that I'll swap sims with and take with me when hiking, stand up paddle bording and doing other activities that carry risk. This phone has no sensitive information in it. I also have a PLB for added protection.
understanding sec,
them observing actual demand for security.
History says don't hold your breath.
We get lucky once in a while, like with Google's hardware (without their software).
Picking a Pixel specifically as an emergency phone is quite the choice, given years of on and off 911 issues.
(it's been available since 2024 -- found by searching for "android os access support matrix" on documentcloud)
The FBI?
To calibrate your sense of time, the iPhone 15 had been released in September 2023 and that doc is dated April 2024, so ~6 months.
And just for completeness, here was the Android doc that leaked at the same time: https://www.documentcloud.org/documents/24833831-cellebrite-...
It passes Play Integrity "MEETS_BASIC_INTEGRITY" but of course doesn't pass higher levels but not because it's insecure - it's because it refuses to grant GMS elevated privileges. Good news is that banking apps can whitelist GrapheneOS using standard Android attestation mechanism (and some already did).
Is it? I hadn't followed news of the new Pixels.
I don't like the idea of modernizing this and going full eSIM. It will introduce a lot of new friction, somehow I don't doubt it. Just now arrived to Mexico for a quick trip and grabbed a prepaid SIM from a 7-11 in the airport. All quick and simple. I doubt things would be so seamless when not having a SIM tray in the phone. Having to go through an official process to register a new card, ID oneself, hope to not have any incompatibility with the eSIM slots in your phone (admittedly I don't know how this works)... vs. just paying MXN100 and leave the store with a ready to use number.
I'm sure eSIMs are a good idea if your aim is to gain even more control over our personal devices.
1. migrating between iPhones also transfers the eSim
2. if I get a tourist sim card at an airport, I don't have to worry about taking out or losing my main sim
3. the ability to have multiple sims is also ideal: I currently have phone plans in AU and SG, in addition to any tourist sim cards I pick up
Getting an (e?)SIM from a local carrier is always better and often cheaper too.
You enter Serbia or Faroe Islands, and to get a SIM you have to find the operator booth, hope it's not in city center where parking is close to impossible, wait in a queue, they don't accept card, go find an ATM, pay extra for foreign withdrawal, pay extra ATM fees...
e-SIM just solves that, you simply buy it online before. And if you forget, I have a bit more expensive "any country" e-SIM that will allow me to do so.
Before e-SIM was a thing mobile roaming outside of EU was on the extreme expensive end. Now, I don't even get to use my e-SIM capabilities, as my network operators have pretty cheap package rates to just roam outside of EU. I wonder if widespread of e-SIM has anything to do with that.
A bunch of their software was also leaked in a hack back in 2023: https://ddosecrets.com/article/cellebrite-and-msab
There’s always the hope they are hit back: Cellebrite can develop solutions to automate the hacking of target phones, but in doing so their physical devices are exposed to being hacked as well.
While some of this comes down to "Apple increased their security posture", a lot of it is that these exploits are $$$ now... and also that nation state actors only really care about data exfiltration. It's https://xkcd.com/1200/ all over again. The thing the nerds actually want is, well, not useless to the glowies, but it is definitely overkill.
These charts have been available for years and don't tell us anything particularly scary IMO.
This "hacking" especially for BFU/turned-off Pixel devices, at best would amount to brute-forcing your password, either on-device or after copying the flash elsewhere.
Short of using top-secret multi-million dollar 0days or something, there is no inherent Pixel flaw that lets them bypass the device's encryption or anything crazy like people are thinking. They still have to get your password somehow, just like anyone else.
gnabgib•1d ago