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