Leaker reveals which Pixels are vulnerable to Cellebrite phone hacking
arstechnica.com
arstechnica.com
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?
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.
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.
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.
Their justification is that they were federally prohibited from admitting that the surveillance existed. So no, you couldn't sue them because the fed won't admit that the software exists until their pants are around their ankles.
Sounds an awful lot like terrorists.
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.
The honeypot theories don't make sense, since GrapheneOS is fully open source, and very transparent about developers, funding, infrastructure, and other internal stuff.
Releasing binary patches is allowed, this is why GOS have added the security preview channel.
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.
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.
A working IOMMU will stop both free- and non-feee firmware from rooting your device.
These concepts are orthogonal.
Not sure about smartphones though - they mostly struggle with a fact there are no truly open source baseband.
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.
Even Mr Assange in his embassy could have added fitness trackers to add metrics that were hard and spotty to estimate from video surveillance.
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.
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.
Apps are installed so that their packages are available before first unlock and can explicitly opt-in to supporting a specific subset of their components and data before available before first unlock. An app can implement push notifications before first unlock if the developers want to do it, and they could do that in a way where no message data, etc. is available before first unlock. The OS leaves it up to apps to decide what to do, and nearly all apps stick with the default of all their functionality and data available After First Unlock instead of either making it available Before First Unlock or having it go back at rest while locked again.
Apple and Google do not appear to have a regular source for finding out which vulnerabilities are currently being exploited. Both appear to be refraining from actively seeking our these devices to patch all the exploits they use. It's often external researchers including at Citizen Lab and Amnesty International determining which vulnerabilities are being exploited by these tools and reporting it to both Apple and Google. Long periods of time often pass with no loss of capabilities for new Android and iOS versions. The main reason Cellebrite loses access is likely tied to the deployment of new exploit protections requiring working around those and using new vulnerabilities. Code churn also likely impacts them.
You seem to be mixing up what they're referring to as a BFU exploit with a BF exploit. Pixel 2, Pixel 6+ and iPhone 12+ have withstood Cellebrite's efforts to do brute force attacks against a BFU device. BFU exploit means they can extract data such as saved Wi-Fi networks and installed apps, but without a BF exploit they cannot bypass the secure element throttling. It may become impractical for them to have BF exploits anymore, but it doesn't make their BFU exploits worthless.
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.
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.
Google shipped the Pixel 8 with production quality MTE support at a hardware level in October 2023 but still isn't using it by default and their Advanced Protection mode only uses it for a tiny subset of the OS and nearly no user installed apps. Enabling it would involve a whole lot of work fixing the bugs it finds, but we're already doing that work in GrapheneOS. They'd also need to fix several issues with their MTE integration in Chromium and elsewhere. It wouldn't be as good as our better implementation in hardened_malloc, etc. but they could be using it. They could start using it in full async mode for near zero performance and cost and then enable sync or asym mode for more components over time where the performance cost is irrelevant, which applies to most of the base OS. They might not want to use sync mode in the kernel for performance reasons, but other than that it mostly has no noticeable performance cost outside of apps.
Performance is likely a major factor Apple is not enabling it by default for apps and is instead discouraging app developers from opting into it by scaring them away with compatibility and performance concerns along with implying apps need to be written with it in mind which is really not the case. It finds memory corruption bugs and doesn't have false positives. Apps should not have memory corruption bugs in regular use and it's more than just an MTE compatibility issue if they do. Android made the smart decision to start tagging points with Top Byte Ignore in the system allocators many years ago which paved the way for HWASan support used by Android to nearly fully replace ASan and then later MTE support. HWASan is similar to MTE but with 8 bit instead of 4 bit tags using Top Byte Ignore but all accesses need to be instrumented to be checked since it's not a hardware feature. HWASan is much slower than MTE but Google has heavily used it for many years which means most of the OS was prepared for MTE other than hardware specific parts not well tested by automated testing.
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.
Why can't the stock ROMs use these features and be more secure also?
I had to get my friend to buy them for me when I was on Graphene
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.
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).
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.
If you want to dive deeper you can checkout droidguard/play integrity.
It also runs on Lineage with Mind The Gapps.
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.
It's very polished and completely usable as a daily driver.
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.
I prefer pattern unlock, which it does not support.
I do have sandboxed Google services installed.
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 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.
> 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 :)
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.
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 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.
Unless you relock the bootloader you are forfeiting major avenue into your phone (and it's not really, fully GOS - because you keep most important protections off).
But it's your choice of course. You'd be probably better off just creating your own OS image with preinstalled root libraries, etc.
> I'm not comfortable without root. I have the absolute right to have root on my device.
I agree with you fully. This is your phone.
An unlocked bootloader is standard operating procedure for me by force of habit.
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.
The talent pool that is willing to work in a nonprofit is not likely large.
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.
Ars Technica has update its article to rectify that mistake. It doesn't mention that anymore.
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?
No, I but I would like to make it so. I find your view that people “deserve” privacy to be incredibly depressing and antithetical to the spirit of user empowerment.
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.
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.
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
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.
Especially with the current administration that is all about grift and publicly accepting bribes - see Paramount, Disney, Google, Meta, Apple. Twitter
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.
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…
Google generally has the reputation of doing much better in those areas.
Not sure what would be objective measures to compare.
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.
Apple is a different story, but they are not invulnerable to cellebrite either
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.
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.
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.)
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.
...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.
This is broadly false, not just misleading but false. - Android Auto: working wired or wireless without problems - Google Pay: app vendor choice to put it behind DEVICE_INTEGRITY check, not OS vendor. NFC payments work just fine with other vendors. - enhanced GPS: whatever that means, is most likely false. Users don't experience any issues with GPS
> SafetyNet
SafetyNet Attestation API is deprecated and no longer available so also not true. But from the context I think you meant Play Integrity API.
This is Google Services feature, not AOSP feature. GrapheneOS is an AOSP-based system.
GOS passes MEETS_BASIC_INTEGRITY. It doesn't pass DEVICE_INTEGRITY because it doesn't run privileged, unbound Google Surveillance Services (according to Google 10 year old phone not updated for 8 years is more secure as long as it allows Google Services sniff everywhere). It cannot pass MEETS_STRONG_INTEGRITY they way Google requires it because AFAIR that thing is signed by the TPM. It does provide an alternative STRONG_INTEGRITY assurance based on the AOSP Hardware Attestation API (which many developers in fact use).
> push notifications,
This is so false it should be called out as a lie, not just a falsehood. Reliable push notifications are supported both in the standard way (if user decides to do so), via GCM, or in one in the alternative ways, for example UP, exactly like on the standard Android phone.
> support for any apps requiring device integrity, etc.
This is also a lie or ignorance. See above. For example Starling Bank has explicitly implemented GOS Hardware Attestation API.
> They aren't redesigning and re-implementing these features securely,
What do you mean?
hardened_malloc? Memory tagging for entire kernel? automatic switch to BFU after timeout? USB data blocked by default with the screen locked? Network permission toggle? Storage/contact scopes? Critical patches released seemingly _months_ before the major vendors?
LOL. Half of your claims are either lies or misrepresentation.
The other half (Google Pay and Play Integrity) are vendor functionality. They would have to spoof (fake) it - exactly like rooted phones do (and which can often be detected). Or allow Google in the privileged mode, which is not going to happen.
That has been explained by the development team _so_ many times already.
They cannot "re-implement" a feature that *GOOGLE* offers to the developers using *Google store*. That would for example require using leaked private key. They are challenging Google's stance on Play Integrity with EU commission, because there is no technical reason to bar the safe hardware+OS passing a standard AOSP hw attestation.
This is an AOSP OS, not a hacked Google Pixel ROM.
> they are reducing attack surface just like lockdown mode.
They are reducing attack surfaces without locking down functionality. Google deciding to not support the competition is not GOS locking somehow down.
Entirely different from Apple's lockdown mode. QED.
I wouldn't mind listing _downsides_ of using GOS as a first/main device (because there are many), but I prefer facts over confabulations :)
So why are we even discussing?
Most of the alleged issues you raised are either untrue or broken *by Google*, by design, and yet you attribute them to GOS.
Somehow you also decided to bundle the functionality broken by Google with the security improvements available without turning on any specific, special mode.
What disabled features are you talking about? Face unlock? :)
If GrapheneOS skips contacting remote servers like that, they would not be vulnerable.
It would be a story of Google prioritizing tracking over security.
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.
Hahahha. Also is this a common expression “fallen of the back of a truck”?
> The completely unrelated
> In completely unrelated news, upcoming versions of Signal will be periodically fetching files to place in app storage. These files are never used for anything inside Signal and never interact with Signal software or data, but they look nice, and aesthetics are important in software. Files will only be returned for accounts that have been active installs for some time already, and only probabilistically in low percentages based on phone number sharding. We have a few different versions of files that we think are aesthetically pleasing, and will iterate through those slowly over time. There is no other significance to these files.
(it's been available since 2024 -- found by searching for "android os access support matrix" on documentcloud)
The reasoning is that the company, being concerned with online advertising and reach,^1 has the incentive to ensure that the software becomes popular with the largest possible number of users, perhaps even achieving monopoly power. According to traditional HN commentary, this makes the company and its software a preferred target for exploits by virtue of its popularity
1. Online surveillance practices to potentially support targeted advertising services, where the companies wantonly collect enormous quantities of data about millions of people, also makes them a target for exploits, e.g., "data breaches"
Consider an alternative status quo where computer owners, i.e., software users, have many options to choose from, including many operating systems, browsers, "app stores", "platforms", and so on
None of the options may be necessarily better choices for "security" for technical reasons^2 but the fact that those who target software from a small number of advertising services juggernauts with millions of users ("lucrative targets") are denied access to such lucrative targets, because the lucrative targets do not exist, is an improvement to "security" overall
2. But some may compete and attempt to distinguish themselves on this basis
In this alternative status quo there would likely be requirements that software be compliant with open standards and interoperable, allowing computer users to write, edit, compile, install and choose whatever software they desire, from any source, including their own brain, i.e., they might choose to write, compile and install their own software on their own computers
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).
I do wonder what this guy’s on about, hope he comes back.
Picking a Pixel specifically as an emergency phone is quite the choice, given years of on and off 911 issues.
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).
Called them up, explained the issue and a couple days later a new build without the issue appeared for install.
A bunch of their software was also leaked in a hack back in 2023: https://ddosecrets.com/article/cellebrite-and-msab
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.
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
physical sims make no contribution to any of their points.
That sounds like it would be a physical sim, or am I incorrect?
bold of you to assume we'll still have a sim card slots
As a consumer I was much happier with esims: I swapped provider, got the esim in the mail essentially instantly, put it in my phone, and forgot about it util I swapped phone... at which point esim transfer was part of the migration so I essentially didn't have to think about it either.
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.
An offline device can take a SIM card just fine. But if you're setting up a new device, or setting up an existing device on a new country on eSim, doesn't matter, you can never connect, because you have to already have internet, to get internet.
Esim was a good idea, implemented so horribly it's worse than the 30 year old predecessor.
eSIMs are designed around "the user is the attacker". So you can't do things like transfer profiles from one eSIM to another offline, by design. What the "transfer" really does is kill the old profile and issue a new one for a new eSIM.
It still could be designed for less user friction. But the whole ordeal could be avoided if eSIM wasn't designed to be user hostile in the first place.
"BFU extraction can only pull the small amount of "Device Encrypted" (DE) data that is accessible. This is mostly system logs, some app settings, and other non-personal data. It does not get messages, photos, or detailed app data." It basically gets them the list of apps, when the phone has been powered on and off and perhaps some cell geo location history.
FFS means Full Filesystem Search.
What this implies in practice:
All locked stock Android Pixels (including 10 I am almost sure) are vulnerable to FFS after the first unlock, even in the locked state. If you want to protect your data (crossing a border, or when you are about to be interrogated by Russian FSB), turn off your stock Android Pixel.
I only wished they'd add Automatic call recording.
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-...
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.)
I don't know, even the latest and greatest is eventually cracked, or they can just hold your device in evidence until the capability is there a few weeks (or months) later.
Furthermore by using an official OS from a vendor like Apple (or Google, Samsung) there's always the possibility that they could target your device with a specially crafted update, especially if you're in really big trouble.
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.
The FBI?