Gregory's ServerApple and Google have much weaker forms of USB attack surface reduction than our approach. It's also not enabled by default for either. We designed the default balanced security vs. usability mode of "Charging-only while locked" to avoid disrupting almost any real world use case.
|
7 comments
 We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (https://grapheneos.org/faq#future-devices) and we expect it could be implemented for Snapdragon too but it's missing hardware memory tagging and devices using it are missing far more... We've heard that iOS 18.1 is using a 4 day timer for auto-reboot after the device is locked, which is similar to the 72h default we used before moving to an 18h default. Our users can configure it between 10 minutes and 72 hours (or disabled) based on their tolerance for it. When we proposed it to Google in January 2024 as a standard Android feature, we suggested starting with 1 week. Android has a lot more tolerance for adding user-facing configuration so they could expose the same functionality we do just with a less aggressive default for it. @GrapheneOS Lol, the average phone will die on batterylevel long before 1 week. @bartavi Devices can be charged when they're locked and that's the standard operating procedure. They keep them charged the entire time until they're ready to use exploits to break into the device. Do you have any info on how realistic such USB-PD exploits are? To be clear, I mean exploits that would be possible with "charging only" but not with "off". |
We use support in the Pixel USB-C controller for disabling new USB connections but keeping existing ones working. As soon as there are no active connections, data is disabled. People who want more security can make it stricter and even disable charging to block USB-PD exploits.