Gregory's ServerIt wouldn't make sense for Apple to deploy such as strange and insecure take on it. They've deployed essentially the same feature we use in iOS 18.1, although we aren't sure when they enable it. We enable our auto-reboot feature by default with an 18h timer, which used to be 72h.
|
28 comments
 Our USB-C port control feature and hardware memory tagging are examples of features built on hardware-specific features. Hardware memory tagging is near exclusive to Pixels, but the stock OS only has it as a developer option for finding bugs with a weaker implementation and bugs. We proposed auto-reboot, USB-C port disabling, reset attack mitigation and wipe-without-reboot as features to Google in January 2024. They implemented part of our reset attack mitigation proposal for Pixels in April 2024 and wipe-without-reboot in June 2024, but not the others. We've made a lot of proposals and vulnerability reports to help improve Pixel and Android security but they don't always listen to us. Perhaps they'll add auto-reboot now that Apple shipped something, although as we said above we don't know if it's lockdown mode exclusive, etc.  @GrapheneOS Apple are the rich individuals security and privacy product. Sign on the dotted line and your an Apple fan boy or girl for life. No person under constant surveillance uses Apple lol  @josh @GrapheneOS Sadly many people believe that Apple is secure. That is what they keep saying. Even EFF repeat their ads. @josh @GrapheneOS They do a lot of good things, but they also recommend Apple phones. @thomzane @GrapheneOS So many people I see on here still think Apple is great. I dont even engage with them in conversation. @thomzane @josh iPhones are genuinely the next best option overall for a private and especially secure tablet or smartphone after GrapheneOS. Apple does have some advantages over GrapheneOS but they're mostly related to privacy from apps where we have our own significant advantages. iOS 18 added a similar feature to our Contact Scopes but they don't have our Sensors toggle or other things we do. They're not great at privacy from Apple but do offer more end-to-end encryption, etc. than Google. @GrapheneOS @thomzane Go visit Dread and see how often Apple gets recommended lol is all I need to say. @GrapheneOS @thomzane My point was amongst people with lots to lose they won't choose a device that will sell them out over one that provides what they need to stay out of jail/prison etc @thomzane @josh They do have substance behind their privacy and security marketing. Pixels have substance behind their security marketing too and are largely competitive with iPhones with the stock OS in that regard, but not on privacy overall. We start from a solid base with the Android Open Source Project on Pixels. We see Apple implementing some of the features we've provided for longer as a form of compliment for our work even if they weren't aware of it. In many cases, they probably were. We never said they had best in class end-to-end encryption support, only better support for it than Google does. Google does have E2EE for certain Android services but it's a lot more limited and has a very limited security model. > Then there is the whole notifications issue where Apple and Google were leaking that which should be local. No, you're entirely misunderstanding this. It was about push messaging registration metadata and nothing was being leaked. @thomzane That story is not about apps sending notifications locally. That story is about apps which chose to use their push messaging services to send messages to the device through APNS or FCM. On Android, FCM is optional and alternative push mechanisms can be used. Apps are choosing to use it. For both APNS and FCM, apps can end-to-end encrypt the messages. For FCM, they can also send empty messages to wake the app and then fetch the data themselves. It's not about local notifications. Apple 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. 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. 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". @GrapheneOS@grapheneos.social wait, what's reset attack mitigation?  @GrapheneOS Actually this reminds me of a question about OS updates. Is it my imagination, but does GrapheneOS prevent charging until a reboot has occurred? Clever if so. @adventure_tense No, we don't do any of this based on OS updates and we always allow charging by default. An attacker could physically provide power without that much effort. By default, we disable any new USB-C connections as soon as the device is locked and fully disable USB-C data when existing connections end. If there are no connections, data is disabled right away. There's an opt-in to a stronger mode where USB data is always disabled and an even stronger mode where charging is disabled. @adventure_tense The even stronger mode for disabling charging exists to eliminate the firmware and kernel attack surface from charging including USB-PD rather than to serve the purpose of actually stopping the device being charged. It does still allow USB including charging when the device is powered off, booted into fastboot mode or one of the special OS boot modes (charging, fastbootd, recovery) so you can't brick a device by setting the USB-C mode to Off. Off is intended for temporary use. |
Our auto-reboot implementation builds upon our other hardening which protects the device. We use default enabled hardware-level + software-level disabling of USB-C data while locked, default enabled aggressive use of hardware memory tagging in a hardened allocator and a lot more.