9 ms·

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 th

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?

markus_zhang 11mo ago
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.
- overfeed 11mo ago
  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.
  - hollerith 11mo ago
    Anyone can build GrapheneOS from source code, which I doubt is true of any law-enforcement honeypot.
    - embedding-shape 11mo ago
      Exactly what someone who sets up a honeypot targeting nerds would want you to think.
      - wakawaka28 11mo ago
        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.
    - overfeed 11mo ago
      See my footnote in original comment.
      - wakawaka28 11mo ago
        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.
        Semaphor 11mo ago
        Often faster than weekly around security releases. And that’s on stable.
      - wshttp 11mo ago
        [dead]
  - AJ007 11mo ago
    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.
  - brendyn 11mo ago
    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.
    - overfeed 11mo ago
      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.
      - Yokolos 11mo ago
        They generally patch much faster than Google.
      - linux_modder 11mo ago
        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.
  - tranq_cassowary 11mo ago
    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.
    - deaux 11mo ago
      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.
    - subscribed 11mo ago
      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
  - strcat 11mo ago
    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/ 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-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 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.
  - Andromxda 11mo ago
    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 https://grapheneos.org/features#exploit-protection [2] https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc
    - Yokolos 11mo ago
      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.
      - linux_modder 11mo ago
        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.
        largbae 11mo ago
        Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.
        udev4096 11mo ago
        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
  - jmnicolas 11mo ago
    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.
    - horisbrisby 11mo ago
      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.
    - yinznaughty 11mo ago
      >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.
      - 0_____0 11mo ago
        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.
      - cindyllm 11mo ago
        [dead]
    - 11mo ago
  - refurb 11mo ago
    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.
  - udev4096 11mo ago
    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
zb3 11mo ago
It physically disables USB ports when locked which significantly reduces the attack surface + can be configured to automatically reboot.
- fph 11mo ago
  Two fixes that would be trivial to backport to mainline Android.
  - vbezhenar 11mo ago
    You can configure USB port for charging only in the developer options.
    - andrepd 11mo ago
      On Lineage this is the default behaviour: charging only until I tap on a notification to change it.
      - Scrubbed4426 11mo ago
        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.
      - strcat 11mo ago
        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.
dns_snek 11mo ago
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.
strcat 11mo ago
GrapheneOS provides massive security improvements over Android. You should read https://grapheneos.org/features#exploit-protection 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-grapheneos-secure-allocator-hardened-malloc 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.
tranq_cassowary 11mo ago
All of the listed features significantly raise the bar for exploitation ; https://grapheneos.org/features https://grapheneos.org/features
- dotancohen 11mo ago
  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?
  - latentsea 11mo ago
    My banking apps run on it, but my concert ticket app doesn't, so I have a separate phone just for that one app.
    - dotancohen 11mo ago
      Can concert tickets not be bought in a web browser?
      - spencerflem 11mo ago
        No they can’t. It’s very frustrating. I had to get my friend to buy them for me when I was on Graphene
      - latentsea 11mo ago
        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.
        dotancohen 11mo ago
        What about people who do not have a smartphone?

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?

markus_zhang 11mo ago

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.

overfeed 11mo ago
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.
- hollerith 11mo ago
  Anyone can build GrapheneOS from source code, which I doubt is true of any law-enforcement honeypot.
  - embedding-shape 11mo ago
    Exactly what someone who sets up a honeypot targeting nerds would want you to think.
    - wakawaka28 11mo ago
      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.
  - overfeed 11mo ago
    See my footnote in original comment.
    - wakawaka28 11mo ago
      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.
      - Semaphor 11mo ago
        Often faster than weekly around security releases. And that’s on stable.
    - wshttp 11mo ago
      [dead]
- AJ007 11mo ago
  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.
- brendyn 11mo ago
  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.
  - overfeed 11mo ago
    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.
    - Yokolos 11mo ago
      They generally patch much faster than Google.
    - linux_modder 11mo ago
      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.
- tranq_cassowary 11mo ago
  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.
  - deaux 11mo ago
    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.
  - subscribed 11mo ago
    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
- strcat 11mo ago
  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/ 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-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 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.
- Andromxda 11mo ago
  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 https://grapheneos.org/features#exploit-protection [2] https://github.com/GrapheneOS/hardened_malloc https://github.com/GrapheneOS/hardened_malloc
  - Yokolos 11mo ago
    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.
    - linux_modder 11mo ago
      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.
      - largbae 11mo ago
        Would this not defeat the purpose of responsible disclosure? As a bad actor I could learn of secret vulnerabilities from this channel.
        udev4096 11mo ago
        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
- jmnicolas 11mo ago
  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.
  - horisbrisby 11mo ago
    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.
  - yinznaughty 11mo ago
    >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.
    - 0_____0 11mo ago
      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.
    - cindyllm 11mo ago
      [dead]
  - 11mo ago
- refurb 11mo ago
  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.
- udev4096 11mo ago
  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

zb3 11mo ago

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

fph 11mo ago
Two fixes that would be trivial to backport to mainline Android.
- vbezhenar 11mo ago
  You can configure USB port for charging only in the developer options.
  - andrepd 11mo ago
    On Lineage this is the default behaviour: charging only until I tap on a notification to change it.
    - Scrubbed4426 11mo ago
      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.
    - strcat 11mo ago
      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.

dns_snek 11mo ago

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.

strcat 11mo ago

GrapheneOS provides massive security improvements over Android. You should read https://grapheneos.org/features#exploit-protection 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-grapheneos-secure-allocator-hardened-malloc 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.

tranq_cassowary 11mo ago

All of the listed features significantly raise the bar for exploitation ; https://grapheneos.org/features https://grapheneos.org/features

dotancohen 11mo ago
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?
- latentsea 11mo ago
  My banking apps run on it, but my concert ticket app doesn't, so I have a separate phone just for that one app.
  - dotancohen 11mo ago
    Can concert tickets not be bought in a web browser?
    - spencerflem 11mo ago
      No they can’t. It’s very frustrating. I had to get my friend to buy them for me when I was on Graphene
    - latentsea 11mo ago
      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.
      - dotancohen 11mo ago
        What about people who do not have a smartphone?