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."
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.
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?
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.
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.
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.
> 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.
> 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.
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.
> 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.
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
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.
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…
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.
If you look around this thread you will find plenty of people explaining what doesn’t work for them. Of course the GrapheneOS people will explain that this is actually the fault of the banks or the apps or whatever and I would probably agree, but that still makes it hard to recommend to casual users.
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
I mean, I'm not sure what you expect the GrapheneOS project to do about that. I'm sure they'd love to provide hardware if they could, but they are a small nonprofit. They are currently working with an undisclosed OEM to to provide official support on an upcoming phone, which may lead to factory-installed options in the future if all goes well.
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
> You think privacy and security is readily available to everyone who just desires so?
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.
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 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 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.)
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?
> 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.
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.
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.
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).
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)
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 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.
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.
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.
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.
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.
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
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.
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.
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 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.
>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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
Convincing people that the exploit protections are valuable and worth providing as even an opt-in feature let alone an enabled by default one is difficult.
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.
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.
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.
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.
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 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.
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.
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”.
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"
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.
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).
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.
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.
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.
Cellebrite and other companies can develop exploits using independent sets of bugs. Cellebrite is also not the only company developing exploits. These companies (or governments) don't have to wait until the bugs they use get patched or mitigated before they develop more exploits. They can also develop exploits against Beta releases of Android and iOS rather than waiting for it to be used by a large audience. That makes it possible for them to develop exploits against newer exploit protections prior to launch unless they're specific to newer hardware that's not released yet. Android has a more open development model and much longer longer beta testing for new major releases which gives them a lot of time to prepare for next generation exploit protections in standard Android. iOS doesn't give them as much time to prepare, but they still have time to prepare before new major releases come out. That's also not taking into account that they can have more than public sources to test with new versions.
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.
I think the biggest deal with phone security is extracting E2E messages & data or local files on the phone, since most other things the government can subpoena from the service providers if they can't hack the phone. Does doing that require FFS, BF, or AFU capability?
Android and iOS both use filesystem-based disk encryption with fine-grained keys, not only a global encryption key. There's a subset of the OS data available before first unlock to have basic functionality available there. Three examples are installed apps, saved Wi-Fi networks including passwords and alarms with the system clock apps being available before first unlock via explicitly storing it in the before first unlock encrypted data. All of the data and metadata blocks are encrypted, but not all of it is encrypted with keys tied to the user's credentials. Android uses per-profile encryption so it gets security benefits from it too, but both operating systems mainly use it for usability benefits needed to make always on disk encryption suitable for their broad audience. They were able to deploy disk encryption to everyone without complaints partly because they did it this way, so in that sense the before first unlock data has a security benefit.
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.
It's a statement directly based on the regularly updated Cellebrite Premium documentation from the past 2 years. At a bare minimum, the April 2024, July 2024 and February 2025 documentation was posted publicly and even that subset shows what's said above. Do you think Cellebrite's documentation isn't accurate or that the leaked documentation was tampered? We aren't posting it publicly ourselves, but we do have a source providing it to us and can compare it over time. Only Pixels and iPhones are successfully stopping brute force but neither is successfully stopping exploiting the OS whether they're BFU or AFU.
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.
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.
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.
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?
The stock OS doesn't use it for any of the kernel or most of userspace. It only uses it for specific processes where they're explicitly enabling it in that mode and apps explicitly opting into it. Nearly no apps are explicitly opting into MTE. On GrapheneOS, we dealt with third party apps by always using MTE with apps opting in, apps with no native code of their own and apps in our compatibility database. For the remaining apps with native code and no MTE opt-in, we have a per-app toggle and a global toggle to change it to opt-out instead of opt-in. We have user-facing MTE crash notifications providing a traceback to report to developers. We plan to significantly expand our compatibility database to always enable it for more apps like Signal but we're being cautious about that due to the potential for apps to ship a memory corruption bug occurring in regular use which not prioritizing fixing it. WhatsApp is an example of a widely used app which mostly works with our MTE integration but sometimes crashes in regular use and Facebook hasn't taken the issue seriously despite MTE not having any false positives.
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.
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.
>> [...] while GrapheneOS is just...
> ...disabling features. Android Auto, Google Pay, enhanced GPS,
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 you fail to see the difference between AOSP functionality and proprietary Google services?
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? :)
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.
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.
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
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.
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%+.
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.
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.
> 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.
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.
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.
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).
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).
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 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.
> 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 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.
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.
> I understand that Magisk can be applied to Graphene if the final device lock step is not applied
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.
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.
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.
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.
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.
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.
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.
There isn't such a justification. They can refuse to answer questions but they can't proactively lie. And if they were ordered to lie I'm not aware of anything that indemnifies them for securities fraud either.
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.
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.
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.
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.)
It’s the truth, however. Blinding yourself to it won’t make governments any less inclined to bend (or outright break) any laws they deem necessary to achieve their goals. We should work to fix that, no question about it, but ignorance will not by itself improve the situation in imaginable any way.
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.
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.
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.
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.
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 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.
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.
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?
>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.
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?
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?
> 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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
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 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.
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.
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.
The point here is that the doc you linked is a year and a half old, this (if real) is much newer. Security is a constant arms race between attackers and defenders, nothing is static so updates of this nature are always welcome.
Also fair! I think "leaker" is just bristly to me in this context, when there's a nearly identical version of it just hanging out for folk to find. But also just a hope that some folk might poke around documentcloud for similar documents lying around. Lots of newsworthy gems in there just waiting to be picked up and this's a good example.
A ~dozen programmers are shipping a demonstrably more secure version of a multi-billion-dollar corporation's own operating system on that company's own hardware. That's incredible.
It's a possibility. Graphene has some traction though and if a potential high-importance target is running the OS, Cellebrite wouldn't want to be doing emergency vulnerability research to respond.
Perhaps there is an argument to be made that this is a reason "computer security" should not be delegated to a third party, such as an advertising services company like the ones in Silicon Valley, Redmond or Seattle
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
One super simple usability v. security tradeoff that Graphene made is that if you plug a new device into the USB while the screen is locked, it just won't work until you unlock the screen. This is kinda annoying the three times a year I want to use wired earbuds, but it's a major impediment for any kind of AFU hacking.
Maybe with a standardised size suitable for the thin phones we use nowadays, and to make the wires usable in any orientation they can also have one axis of symmetry, maybe along it's primary axis?
I've set up GrapheneOS on my Pixel with 2FA fingerprint + PIN unlock. No way will anyone be getting into it without my cooperation.
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.
Don't know if/how this works in the US, but the EU emergency number can always be called without a simcard/subscription, so no need to swap simcards. (And sometimes even from a locked phone)
GrapheneOS provides PSDS, SUPL (which are enabled by default IIRC) and an optional Wi-Fi based location provider, so there shouldn't be any positioning issues with E911
They are not making a "GrapheneOS smartphone", they are just helping providers make their new devices compatible with the security requirements, so GrapheneOS can be installed on it. But GrapheneOS will not come by default AFAIK.
Probably their legal obligation to comply with secret government orders (FISA, NSL etc - the government probably already said don't make unhackable phones or else) and their informal wish to remain on the regime's good side.
If the Duress PIN is an obvious one, it may be one of the first ones your adversaries try. Like 1111 for example. So you may not even have to tell them the Duress PIN for them to attempt it.
Another great thing about GrapheneOS (besides security) is that Google Play Services can be installed without elevated privileges and even in a separate profile which can't run in the background. This makes the phone suitable for both normal usage and for those cases where you need to use some "official" app.
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).
>Thanks to GrapheneOS, I keep my banking app, my gmail, my social media, my candy crush, and my nudes together with google play services monitoring it all safely sandboxed away from the private profile with my F-droid notes app and an SSH terminal.
So I'm running Pixel 6a with GrapheneOS beta updates, I'm okay? Tho if law enforcement needs in my phone they just need to hold me until after lunch, I get pretty hungry. And those Doritos and coke they offered me sure looks tasty...
Technically, the upgrade to the Pixel 8 (or higher) would be security-wise a lot better, because they offer more memory safety (MTE), but yeah you are probably good.
Since nobody else has mentioned it... "vulnerable to hacking" is doing a lot of heavy lifting here. It's "vulnerable" about as much as my LUKS desktop system is vulnerable.
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.
> Notably, the Pixel 10 series is moving away from physical SIM cards.
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.
eSIMs feel like a solution waiting for a problem. Consumers are happy with physical SIMs, you obtain one, you put it in your phone then you forget about it until you swap your phone.
I'm sure eSIMs are a good idea if your aim is to gain even more control over our personal devices.
It sounds like you’re talking about the benefits of having both? The new iPhones have only eSIM which is currently a hurdle, especially for the ”tourist SIMs”. OTOH, I’m sure Telcos will shape up their support and iron out the major bugs rather quickly precisely because of this.
Fwiw, I can't remember the last time I bought a physical sim at an airport. Airalo lets me buy an eSim at the departing airport, which means I've got cell data from the instant I arrive. They're not the only company offering this, and I'm sure I could min max and find a more cost optimized service, but it's done me well enough. Depending on the amount of international travel you do, and to where, however, US travellers may have a better time with a carrier like T-Mobile which include international data to a number of countries.
eSIMs are nice in that you can install an app and it can activity service immediately. You don't have to go to a store or wait for a physical SIM to be mailed to you.
Also nice for people who frequent different countries, easier to switch by tapping a button in the phone than having to replace the physical SIM card each time. And no more forgetting the right SIM or not having a tiny thing to get the SIM card out in the first place (or having to borrow someone's earring).
For me, eSIM was the only solution to a very real problem: being able to use virtual carriers without mailing a physical SIM. I can pay anonymously for a regional SIM from my MVNO at an affordable price, without giving a local carrier a copy of my passport to retain indefinitely. Unfortunately, they still only resell incumbent bandwidth--but that's the reality of spectrum licensing.
> Consumers are happy with physical SIMs, you obtain one, you put it in your phone then you forget about it until you swap your phone.
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.
And you can buy an eSIM from a local carrier, which will then email you a code. It's unheard of for local carriers to mail physical SIMs to the other side of the world.
The typically tier 2 carriers are the main ideal perfect market for eSIMs. If you want to do everything online, you really can't if it relies on a physical something. I would estimate 90% of the market is for mint mobile and consumer cellular. eSIMs are a genius move progression from the old burner phone days, from the perspective of overhead costs and flexibility.
And on the other hand, you enter Montenegro by car outside of touristy season and no petrol stations carry sim card then, and you have to find some kiosk in city center that does, wasting so much time in the process, relying on offline maps or spotty wi-fi.
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.
The process for migrating eSIMs for me has never been easy and has always taken 1-2 days and repeated contacts with customer service agents to actually work. Compared to the 10 seconds of swapping a physical SIM. I'm sure there isn't an inherent technical reason why eSIM couldn't be just as easy if not more, but I assume it's another case of enshittification.
The "inherent reason" is that user freedom isn't allowed in SIM land, basically.
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.
Agreed, the rest of the comments are delusional. First, you have to contact customer service, which takes a few days to get a response. Then you have to have another device to display the QR code on, which you won't have if you're travelling. They'll send you a QR code you have to scan with the device you're currently on, AND you'll have to do it without an internet connection. Meaning it just doesn't work, at all.
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.
It can be more secure, but it also feels like the kind of "improvement" that's ripe for exploitation. When you put in a step where you have to ask your service provider for permission to swap the SIM, buckle up for the inevitable development of them asking for a $5, $50 or $100 "service fee" so they consider allowing it.
Couldn't they do that with physical SIM cards? On their end, record the IMEI of the first device they see connecting with a specific SIM card and then disallow connections if that SIM is used with a different IMEI.
I'm not sure if that's legal, but even if they did it, it's a lot more opaque. If they started doing it, many people would assume it to be a technical fault by the provider or the phone manufacturer, and the ensuing support calls and drama would probably cost way too much for this to be worth it in the first place. However, with eSIM, they get to redefine all the rules, since the customer has to learn how to use them from scratch anyway. And they also get access to nice, digital, software-driven workflows that can make the need to pay up apparent, as opposed to just randomly cutting service to the user.
I am sure that will cause a lot of trouble in many countries. How hard is it to click Record button for the important calls? I don't think a small project like GrapheneOS should spend time on every small request users want.
Oh, that's what you get by being unaware of the cellphone brands. I was all excited thinking "hey, they found a way to hack phones through, I guess, screen firmware by setting a special sequence of pixels? How frakking cool!". How disappointed I was...
Honestly seems like if you just stay on the latest-and-greatest you'll stay ahead of Cellebrite long enough.
I'll be amused when Apple finally drops a portless iPhone as the next step ahead.
(Apple already has their Qi2/Magsafe setup, and they already have been using 60GHz wireless USB for quite some time now internally with the Apple Watch for diagnostics and service management since Series 7.)
> Honestly seems like if you just stay on the latest-and-greatest you'll stay ahead of Cellebrite long enough.
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.
It seems that a bunch of them are vulnerable in different states. My concern is mostly with BFU and SOS mode (which seems pretty close to BFU). I can't seem to find much that is worrying in these states.
If there's one thing I find the most galling about Cellebrite and the larger realm of state-sponsored hacking, it's that it's practically destroyed the ability to jailbreak devices. Pretty much everything on PPL/SPTM has no public jailbreaks to speak of anymore, at least not until way after the feds have thoroughly 0wned you first.
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.
"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.
Congratulations to the GrapheneOS team. Holding your ground against fucking government backed intelligence corporations is no easy feat. May fortune always smile upon them.
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."
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.
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?
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.
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.
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.
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
> 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.
> 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.
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
> 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.
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
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.
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…
No, it's just that the user will not put up with a system like GrapheneOS.
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.
If you look around this thread you will find plenty of people explaining what doesn’t work for them. Of course the GrapheneOS people will explain that this is actually the fault of the banks or the apps or whatever and I would probably agree, but that still makes it hard to recommend to casual users.
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
I have tried installing it, for your information
“Install an OS on your phone” is nonsensical to 99.99% of users. You’re in a tech bubble.
I'm not talking about installation. I'm talking about using the OS once it's installed.
It’s a distinction without a difference when Graphene is installed by zero OEMs.
I mean, I'm not sure what you expect the GrapheneOS project to do about that. I'm sure they'd love to provide hardware if they could, but they are a small nonprofit. They are currently working with an undisclosed OEM to to provide official support on an upcoming phone, which may lead to factory-installed options in the future if all goes well.
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
> You think privacy and security is readily available to everyone who just desires so?
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.
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.
it might be that guy who uses different accounts for different topics
Of your favourite search engine is broken too, here's the link anyone can read: https://grapheneos.org/history/
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.
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.)
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?
All of the listed features significantly raise the bar for exploitation ;
https://grapheneos.org/features
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?
> 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.
That also sounds like a nonstarter for a lot of kiosk and embedded use cases
Okay? Then switch that off? :)
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.
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.
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).
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)
Most American banking apps run on Graphene https://privsec.dev/posts/android/banking-applications-compa...
My banking apps run on it, but my concert ticket app doesn't, so I have a separate phone just for that one app.
They do it to prevent botting . They use play integrity ( i think ex safety net ).
Can concert tickets not be bought in a web browser?
No they can’t. It’s very frustrating.
I had to get my friend to buy them for me when I was on Graphene
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.
What about people who do not have a smartphone?
They don't get to go to concerts in Japan.
Because these apps use google play integrity which only google certified devices pass
Wells Fargo runs on my Grapheme device.
It also runs on Lineage with Mind The Gapps.
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.
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.
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
> 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.
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.
An implementation detail where TLAs could theoretically get root remotely? Seems like a bit more than a detail to be glossed over.
Free firmware can have a security issue and root your device.
A working IOMMU will stop both free- and non-feee firmware from rooting your device.
These concepts are orthogonal.
Show me any device on earth that can run a browser that has no proprietary code whatsoever (including hardware) on it?
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.
There is no smartphone fully powered by open firmware. Also keep in mind that the hardware itself is proprietary too.
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.
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.
Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.
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
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.
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.
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.
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 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.
>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.
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.
[dead]
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.
Obligatory https://www.usenix.org/system/files/1401_08-12_mickens.pdf
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.
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.
Anyone can build GrapheneOS from source code, which I doubt is true of any law-enforcement honeypot.
See my footnote in original comment.
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.
Often faster than weekly around security releases. And that’s on stable.
[dead]
Exactly what someone who sets up a honeypot targeting nerds would want you to think.
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.
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.
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.
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.
They generally patch much faster than Google.
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
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.
It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.
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.
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.
Two fixes that would be trivial to backport to mainline Android.
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.
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.
Convincing people that the exploit protections are valuable and worth providing as even an opt-in feature let alone an enabled by default one is difficult.
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.
You can configure USB port for charging only in the developer options.
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.
With Grapheneos no need for developer options however. It's in the usual menu in the exploit protections submenus.
I think that's at the OS level. I think there are things that could be done through the firmware level.
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.
Sorry, I had the wrong terminology.
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.
I had the wrong terminology. Your sibling comment explains it better.
That only turns it of on the OS level. GrapheneOS also turns it off on the level of the USB controller.
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.
Thanks, I was confusing it with the Advanced Protection feature.
On Lineage this is the default behaviour: charging only until I tap on a notification to change it.
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.
Got it, that makes sense! Thanks for explaining :)
It is not the same feature as present on GrapheneOS. That is done through the OS while GrapheneOS makes kernel changes to physically shut it down.
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.
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.
iOS lacks configurabiluty for both. USB protection is also less thorough technically.
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”.
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.
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.
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?
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).
It works properly again after post on HN. :-/
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.
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.
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.
Cellebrite and other companies can develop exploits using independent sets of bugs. Cellebrite is also not the only company developing exploits. These companies (or governments) don't have to wait until the bugs they use get patched or mitigated before they develop more exploits. They can also develop exploits against Beta releases of Android and iOS rather than waiting for it to be used by a large audience. That makes it possible for them to develop exploits against newer exploit protections prior to launch unless they're specific to newer hardware that's not released yet. Android has a more open development model and much longer longer beta testing for new major releases which gives them a lot of time to prepare for next generation exploit protections in standard Android. iOS doesn't give them as much time to prepare, but they still have time to prepare before new major releases come out. That's also not taking into account that they can have more than public sources to test with new versions.
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.
I think the biggest deal with phone security is extracting E2E messages & data or local files on the phone, since most other things the government can subpoena from the service providers if they can't hack the phone. Does doing that require FFS, BF, or AFU capability?
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?
Android and iOS both use filesystem-based disk encryption with fine-grained keys, not only a global encryption key. There's a subset of the OS data available before first unlock to have basic functionality available there. Three examples are installed apps, saved Wi-Fi networks including passwords and alarms with the system clock apps being available before first unlock via explicitly storing it in the before first unlock encrypted data. All of the data and metadata blocks are encrypted, but not all of it is encrypted with keys tied to the user's credentials. Android uses per-profile encryption so it gets security benefits from it too, but both operating systems mainly use it for usability benefits needed to make always on disk encryption suitable for their broad audience. They were able to deploy disk encryption to everyone without complaints partly because they did it this way, so in that sense the before first unlock data has a security benefit.
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.
Thanks! So you will indeed get a small amount of data, but nearly nothing tied to a specific user profile.
Citation needed.
It's a statement directly based on the regularly updated Cellebrite Premium documentation from the past 2 years. At a bare minimum, the April 2024, July 2024 and February 2025 documentation was posted publicly and even that subset shows what's said above. Do you think Cellebrite's documentation isn't accurate or that the leaked documentation was tampered? We aren't posting it publicly ourselves, but we do have a source providing it to us and can compare it over time. Only Pixels and iPhones are successfully stopping brute force but neither is successfully stopping exploiting the OS whether they're BFU or AFU.
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.
[dead]
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.
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.
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?
The stock OS doesn't use it for any of the kernel or most of userspace. It only uses it for specific processes where they're explicitly enabling it in that mode and apps explicitly opting into it. Nearly no apps are explicitly opting into MTE. On GrapheneOS, we dealt with third party apps by always using MTE with apps opting in, apps with no native code of their own and apps in our compatibility database. For the remaining apps with native code and no MTE opt-in, we have a per-app toggle and a global toggle to change it to opt-out instead of opt-in. We have user-facing MTE crash notifications providing a traceback to report to developers. We plan to significantly expand our compatibility database to always enable it for more apps like Signal but we're being cautious about that due to the potential for apps to ship a memory corruption bug occurring in regular use which not prioritizing fixing it. WhatsApp is an example of a widely used app which mostly works with our MTE integration but sometimes crashes in regular use and Facebook hasn't taken the issue seriously despite MTE not having any false positives.
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.
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.
> 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.
>> [...] while GrapheneOS is just... > ...disabling features. Android Auto, Google Pay, enhanced GPS,
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 :)
I fail to see any meaningful difference between breaking and disabling a feature.
So you fail to see the difference between AOSP functionality and proprietary Google services?
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? :)
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.
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.
"enforces strong Play Integrity" is just a nicer way to say that they use their market position to stop other ecosystems developing.
Without Google Pay, Google Wallet is practically a glorified card number vault. Which can still be useful, just not at card terminals.
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
Google Pay also works with a Pixel watch connected to a GrapheneOS phone, FWIW.
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.
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.
Also Garmin watches if you'd prefer wearing something with battery lasting weeks, not hours ;)
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%+.
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.
"a bit ass" is a charitable way to put it, but same here, it's dependable, dead stable, good enough as a backup map.
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.
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.
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.
> 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.
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.
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.
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).
Graphene on my Pixel 6 certainly does support fingerprint unlocking.
I prefer pattern unlock, which it does not support.
That's because the OS integration is priviliged and that's problematic. On GrapheneOS Play runs sandboxed, like any other user-installed app.
Is it really missing Chromecast? I read that it works if you have Play services (but haven't tried)
No, works fine for me from sandboxed (very much unprivileged) YouTube, New Pipe And VLC.
I do have sandboxed Google services installed.
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).
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.
Is the battery life better with Graphene?
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.
Yes unless the app offers Unified Push (like Molly vs Signal).
I see. Thanks for the feedback!
That is a major feature. It prevents coerced unlocking.
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).
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.
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 :)
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.
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 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.
> I understand that Magisk can be applied to Graphene if the final device lock step is not applied
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.
I have been running Lineage since my first Cyanogen install on my HTC Incredible.
An unlocked bootloader is standard operating procedure for me by force of habit.
You give way too much credit that law enforcement cares about the law and won’t just use rubber hose decryption.
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.
[dead]
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.
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-...
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.
They can choose to go out of business instead. See e.g. Lavabit.
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.
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.
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.
If you think Apple lied about this you can sue them for securities fraud, as it's illegal to lie to shareholders.
I know Apple lied to me about it: https://arstechnica.com/tech-policy/2023/12/apple-admits-to-...
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.
There isn't such a justification. They can refuse to answer questions but they can't proactively lie. And if they were ordered to lie I'm not aware of anything that indemnifies them for securities fraud either.
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.
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.
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.
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.)
This idea is based on empirical evidence.
It’s the truth, however. Blinding yourself to it won’t make governments any less inclined to bend (or outright break) any laws they deem necessary to achieve their goals. We should work to fix that, no question about it, but ignorance will not by itself improve the situation in imaginable any way.
Arrows impossibility theorem means someone will always be unhappy, and sometimes those people make the laws too.
It can be fixed, but not through the same protocols and institutions that have been compromised.
Who is "the government" here? There isn't a single "the government" in the US.
>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.
[dead]
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
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.
You mean the same Eric Schmidt who admitted that he used a BlackBerry for years after Android was released?
> 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.
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.
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…
> 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.
BFU = Before First Unlock after power on or reboot.
In this state, a significant portion of the data on the device remains encrypted and inaccessible, unlike the "After First Unlock" (AFU) state, where the necessary encryption keys are available.
>Last cellebrite leak showed they couldn’t do anything in BFU, and you can tell Siri to put it back in BFU without hands while being arrested.
Source? Note that "disables faceid/fingerprint" isn't the same as "BFU".
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?
>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.
True but those chips also exist for PCs. Some USB security keys have this feature.
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?
There are many different ones.
> 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.
Google being bad doesn't mean Apple is good.
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?
> 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.
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.
“Siri, whose phone is this” doesn’t work on recent iOS versions. You could ask it to reboot, but that requires confirmation
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.
> 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.
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.
> 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.
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.
You could say that they "hacked the Gibsons".
I was pretty much looking for this info. Thank you.
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.
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.
So much for all the security posturing by Google lol.
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.
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.
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 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.
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.
What they are doing is difficult and expensive.
The talent pool that is willing to work in a nonprofit is not likely large.
More attention than stock android?
> https://signal.org/blog/cellebrite-vulnerabilities/
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.
“By a truly unbelievable coincidence, I was recently out for a walk when I saw a small package fall off a truck ahead of me”
Hahahha. Also is this a common expression “fallen of the back of a truck”?
In France it is indeed a popular expression that means 'stolen' or 'acquired by non-disclosable means'
Also the same in US English
Yep: https://en.wiktionary.org/wiki/fall_off_the_back_of_a_truck
Here's the full document without the blurriness: https://www.documentcloud.org/documents/24833831-cellebrite-...
(it's been available since 2024 -- found by searching for "android os access support matrix" on documentcloud)
The point here is that the doc you linked is a year and a half old, this (if real) is much newer. Security is a constant arms race between attackers and defenders, nothing is static so updates of this nature are always welcome.
I'm not disputing that. :)
Fair, I suppose I've misunderstood. I took "it's been available since 2024" as a dismissal of this new information.
Also fair! I think "leaker" is just bristly to me in this context, when there's a nearly identical version of it just hanging out for folk to find. But also just a hope that some folk might poke around documentcloud for similar documents lying around. Lots of newsworthy gems in there just waiting to be picked up and this's a good example.
This one doesn't have Pixel 9's so the image in the article has been updated a bit.
[flagged]
A ~dozen programmers are shipping a demonstrably more secure version of a multi-billion-dollar corporation's own operating system on that company's own hardware. That's incredible.
Or, it was lower priority for discovering exploits due to the number of users.
It's a possibility. Graphene has some traction though and if a potential high-importance target is running the OS, Cellebrite wouldn't want to be doing emergency vulnerability research to respond.
Perhaps there is an argument to be made that this is a reason "computer security" should not be delegated to a third party, such as an advertising services company like the ones in Silicon Valley, Redmond or Seattle
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
Testament to GrapheneOS' competence and commitment to it's purpose that it's called out by name by Cellebrite.
One super simple usability v. security tradeoff that Graphene made is that if you plug a new device into the USB while the screen is locked, it just won't work until you unlock the screen. This is kinda annoying the three times a year I want to use wired earbuds, but it's a major impediment for any kind of AFU hacking.
Someone should invent a purely analog port for wired earbuds that's immune to that kind of attack.
Maybe with a standardised size suitable for the thin phones we use nowadays, and to make the wires usable in any orientation they can also have one axis of symmetry, maybe along it's primary axis?
I've set up GrapheneOS on my Pixel with 2FA fingerprint + PIN unlock. No way will anyone be getting into it without my cooperation.
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.
> My solution to that was a second Pixel as an emergency phone
Picking a Pixel specifically as an emergency phone is quite the choice, given years of on and off 911 issues.
...with the Google software.
Don't know if/how this works in the US, but the EU emergency number can always be called without a simcard/subscription, so no need to swap simcards. (And sometimes even from a locked phone)
US is the same. I dialed 911 once as a child from an American phone in Indonesia without a SIM card in it. Freaked out and hung up.
First I’m hearing Graphene causes issues with E911 - is this a setting?
Is it E911 or an A-GPS issue?
GrapheneOS provides PSDS, SUPL (which are enabled by default IIRC) and an optional Wi-Fi based location provider, so there shouldn't be any positioning issues with E911
Thought so.
I do wonder what this guy’s on about, hope he comes back.
Is there anything actually preventing Samsung or another vendor from adopting GrapheneOS's security innovations?
GrapheneOS is seemingly working with an OEM to make a GrapheneOS smartphone. Its probably not samsung, but would still be an established vendor
They are not making a "GrapheneOS smartphone", they are just helping providers make their new devices compatible with the security requirements, so GrapheneOS can be installed on it. But GrapheneOS will not come by default AFAIK.
It's totally possible that there will be an option to buy the device with GrapheneOS preinstalled https://grapheneos.social/@GrapheneOS/114749924008111970
It better not be Samsung...
It isn't Samsung
I'd love this for a Fairphone.
It definitely won't be Fairphone. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
https://grapheneos.social/@GrapheneOS/115379774100353715 and
https://grapheneos.social/@GrapheneOS/114874684738751793
Willingness to pay great developers and engineers to build secure hardware,
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).
The hardware Samsung provides is not up to spec.
Probably their legal obligation to comply with secret government orders (FISA, NSL etc - the government probably already said don't make unhackable phones or else) and their informal wish to remain on the regime's good side.
Samsung is not an American company and what you're claiming would conflict with other countries' laws, namely EU Cyber Resilience Act.
Obligatory https://xkcd.com/538
https://grapheneos.org/features#duress :D
Use that and you'll get charged with destruction of evidence
if you're relying on such feature, you'll probably serve less time being charged with destruction of evidence...
If the Duress PIN is an obvious one, it may be one of the first ones your adversaries try. Like 1111 for example. So you may not even have to tell them the Duress PIN for them to attempt it.
Surely that's better than being charged with whatever crime they're trying to pin on you?
It depends, often the cover up is worse than the crime. See: Enron, Watergate, Trevor Jacob
They'll have to prove it.
How would they know? Genuine question, I don't run GOS.
Cooperation under duress is still cooperation.
Source: https://news.ycombinator.com/item?id=45765858
Another great thing about GrapheneOS (besides security) is that Google Play Services can be installed without elevated privileges and even in a separate profile which can't run in the background. This makes the phone suitable for both normal usage and for those cases where you need to use some "official" app.
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).
My bank (largest local in my country) shipped a beta version of their app where my pixel8p with grapheneos was flagged as insecure this summer.
Called them up, explained the issue and a couple days later a new build without the issue appeared for install.
https://xkcd.com/1200/
this is actually not the case on modern android lol
>Thanks to GrapheneOS, I keep my banking app, my gmail, my social media, my candy crush, and my nudes together with google play services monitoring it all safely sandboxed away from the private profile with my F-droid notes app and an SSH terminal.
How?
How come not a single Cellebrite device got "lost" and thoroughly analyzed? Surely quite a few police depts are rather lax.
One did "fall off a truck" and into Moxie Marlinspike's hands back in 2021: https://signal.org/blog/cellebrite-vulnerabilities/
A bunch of their software was also leaked in a hack back in 2023: https://ddosecrets.com/article/cellebrite-and-msab
[dead]
I wonder why they haven't switched to a more lucrative model of remote unlock/forensic acquisition using something like WebUSB.
So I'm running Pixel 6a with GrapheneOS beta updates, I'm okay? Tho if law enforcement needs in my phone they just need to hold me until after lunch, I get pretty hungry. And those Doritos and coke they offered me sure looks tasty...
Technically, the upgrade to the Pixel 8 (or higher) would be security-wise a lot better, because they offer more memory safety (MTE), but yeah you are probably good.
Hell, for another sandwich and a potato salad, I'll go a couple more.
Since nobody else has mentioned it... "vulnerable to hacking" is doing a lot of heavy lifting here. It's "vulnerable" about as much as my LUKS desktop system is vulnerable.
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.
> Notably, the Pixel 10 series is moving away from physical SIM cards.
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.
eSIMs feel like a solution waiting for a problem. Consumers are happy with physical SIMs, you obtain one, you put it in your phone then you forget about it until you swap your phone.
I'm sure eSIMs are a good idea if your aim is to gain even more control over our personal devices.
I've been using an eSim on my iPhone and it's been wonderful because:
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
It sounds like you’re talking about the benefits of having both? The new iPhones have only eSIM which is currently a hurdle, especially for the ”tourist SIMs”. OTOH, I’m sure Telcos will shape up their support and iron out the major bugs rather quickly precisely because of this.
> It sounds like you’re talking about the benefits of having both?
physical sims make no contribution to any of their points.
> 2. if I get a tourist sim card at an airport
That sounds like it would be a physical sim, or am I incorrect?
They probably do mean getting a tourist eSIM at the airport.
iPhones are eSim only for a few years now.
Fwiw, I can't remember the last time I bought a physical sim at an airport. Airalo lets me buy an eSim at the departing airport, which means I've got cell data from the instant I arrive. They're not the only company offering this, and I'm sure I could min max and find a more cost optimized service, but it's done me well enough. Depending on the amount of international travel you do, and to where, however, US travellers may have a better time with a carrier like T-Mobile which include international data to a number of countries.
It's important to point out that few MVNO operators on T-Moble extend this international access.
>if I get a tourist sim card at an airport, I don't have to worry about taking out or losing my main sim
bold of you to assume we'll still have a sim card slots
eSIMs are nice in that you can install an app and it can activity service immediately. You don't have to go to a store or wait for a physical SIM to be mailed to you.
Also nice for people who frequent different countries, easier to switch by tapping a button in the phone than having to replace the physical SIM card each time. And no more forgetting the right SIM or not having a tiny thing to get the SIM card out in the first place (or having to borrow someone's earring).
For me, eSIM was the only solution to a very real problem: being able to use virtual carriers without mailing a physical SIM. I can pay anonymously for a regional SIM from my MVNO at an affordable price, without giving a local carrier a copy of my passport to retain indefinitely. Unfortunately, they still only resell incumbent bandwidth--but that's the reality of spectrum licensing.
> Consumers are happy with physical SIMs, you obtain one, you put it in your phone then you forget about it until you swap your phone.
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.
No, they're a huge improvement
eSIMs are fantastic for anyone who travels internationally.
You can actually get a prepaid travel eSIM before you leave on holiday.
Which are absolutely shit because your data exits out on the other side of the world with 150ms extra latency.
Getting an (e?)SIM from a local carrier is always better and often cheaper too.
And you can buy an eSIM from a local carrier, which will then email you a code. It's unheard of for local carriers to mail physical SIMs to the other side of the world.
The typically tier 2 carriers are the main ideal perfect market for eSIMs. If you want to do everything online, you really can't if it relies on a physical something. I would estimate 90% of the market is for mint mobile and consumer cellular. eSIMs are a genius move progression from the old burner phone days, from the perspective of overhead costs and flexibility.
And on the other hand, you enter Montenegro by car outside of touristy season and no petrol stations carry sim card then, and you have to find some kiosk in city center that does, wasting so much time in the process, relying on offline maps or spotty wi-fi.
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.
The process for migrating eSIMs for me has never been easy and has always taken 1-2 days and repeated contacts with customer service agents to actually work. Compared to the 10 seconds of swapping a physical SIM. I'm sure there isn't an inherent technical reason why eSIM couldn't be just as easy if not more, but I assume it's another case of enshittification.
The "inherent reason" is that user freedom isn't allowed in SIM land, basically.
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.
Agreed, the rest of the comments are delusional. First, you have to contact customer service, which takes a few days to get a response. Then you have to have another device to display the QR code on, which you won't have if you're travelling. They'll send you a QR code you have to scan with the device you're currently on, AND you'll have to do it without an internet connection. Meaning it just doesn't work, at all.
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.
eSIM can be QR code so if they wanted, Mexican vendor just pay and show QR code for you to scan.
The unfortunate problem with eSIM is that you can't swap it between phones.
You absolutely can. But it does need an internet connection for that. Which actually makes eSIM more secure than regular SIM.
It can be more secure, but it also feels like the kind of "improvement" that's ripe for exploitation. When you put in a step where you have to ask your service provider for permission to swap the SIM, buckle up for the inevitable development of them asking for a $5, $50 or $100 "service fee" so they consider allowing it.
Couldn't they do that with physical SIM cards? On their end, record the IMEI of the first device they see connecting with a specific SIM card and then disallow connections if that SIM is used with a different IMEI.
I'm not sure if that's legal, but even if they did it, it's a lot more opaque. If they started doing it, many people would assume it to be a technical fault by the provider or the phone manufacturer, and the ensuing support calls and drama would probably cost way too much for this to be worth it in the first place. However, with eSIM, they get to redefine all the rules, since the customer has to learn how to use them from scratch anyway. And they also get access to nice, digital, software-driven workflows that can make the need to pay up apparent, as opposed to just randomly cutting service to the user.
Only in the US.
<3 GrapheneOS, it does what I need without me spending the time.
I only wished they'd add Automatic call recording.
I am sure that will cause a lot of trouble in many countries. How hard is it to click Record button for the important calls? I don't think a small project like GrapheneOS should spend time on every small request users want.
Those slides have been in the GrapheneOS Forums for ages.
Oh, that's what you get by being unaware of the cellphone brands. I was all excited thinking "hey, they found a way to hack phones through, I guess, screen firmware by setting a special sequence of pixels? How frakking cool!". How disappointed I was...
Wow. I was just thinking about jumping ship from iPhone to Pixel.
All iPhones were vulnerable according to the last available iOS support matrix.
That's not quite correct, but you're not a million miles off: https://www.documentcloud.org/documents/24833832-cellebrite-...
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-...
For iOS there's a slightly newer one released in July 2024 which indicated iPhone 15 support too: https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
Honestly seems like if you just stay on the latest-and-greatest you'll stay ahead of Cellebrite long enough.
I'll be amused when Apple finally drops a portless iPhone as the next step ahead.
(Apple already has their Qi2/Magsafe setup, and they already have been using 60GHz wireless USB for quite some time now internally with the Apple Watch for diagnostics and service management since Series 7.)
> Honestly seems like if you just stay on the latest-and-greatest you'll stay ahead of Cellebrite long enough.
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.
It seems that a bunch of them are vulnerable in different states. My concern is mostly with BFU and SOS mode (which seems pretty close to BFU). I can't seem to find much that is worrying in these states.
If there's one thing I find the most galling about Cellebrite and the larger realm of state-sponsored hacking, it's that it's practically destroyed the ability to jailbreak devices. Pretty much everything on PPL/SPTM has no public jailbreaks to speak of anymore, at least not until way after the feds have thoroughly 0wned you first.
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.
One wonders if that was the goal all along.
BFU inside the table cells means:
"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.
Congratulations to the GrapheneOS team. Holding your ground against fucking government backed intelligence corporations is no easy feat. May fortune always smile upon them.
>However, rogueFed also called out the meeting organizer by name (the second screenshot, which we are not reposting).
The FBI?
No, the Cellebrite rep Alex Rankmore. The screenshot is still in the thread farther down.
[dead]
[dead]