Email or username:

Password:

Forgot your password?
Top-level
GrapheneOS

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.

20 comments
Josh

@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

thomzane

@josh @GrapheneOS Sadly many people believe that Apple is secure. That is what they keep saying. Even EFF repeat their ads.

Josh

@thomzane @GrapheneOS Valid point not sure what EFF does besides take money though?

thomzane replied to Josh

@josh @GrapheneOS They do a lot of good things, but they also recommend Apple phones.

Josh

@thomzane @GrapheneOS So many people I see on here still think Apple is great. I dont even engage with them in conversation.

GrapheneOS

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

Josh replied to GrapheneOS

@GrapheneOS @thomzane Go visit Dread and see how often Apple gets recommended lol is all I need to say.
GOS gets recommended 24x7 there.

Josh replied to Josh

@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

GrapheneOS replied to GrapheneOS

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

thomzane replied to GrapheneOS

@GrapheneOS @josh Not you too! E2EE without the ability to manage your own keys and verify the mechanisms of encryption means that Apple can introduce more ghost keys behind the scenes allowing themselves and others to be included in who can decrypt the information.

Then there is the whole notifications issue where Apple and Google were leaking that which should be local. reuters.com/technology/cyberse

I don't trust Apple.

@GrapheneOS @josh Not you too! E2EE without the ability to manage your own keys and verify the mechanisms of encryption means that Apple can introduce more ghost keys behind the scenes allowing themselves and others to be included in who can decrypt the information.

Then there is the whole notifications issue where Apple and Google were leaking that which should be local. reuters.com/technology/cyberse

GrapheneOS replied to thomzane

@thomzane @josh

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.

GrapheneOS replied to GrapheneOS

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

GrapheneOS

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.

GrapheneOS

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.

GrapheneOS

We also extended it to the pogo pins on the Pixel Tablet. It's one of our official hardware requirements (grapheneos.org/faq#future-devi) 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...

GrapheneOS replied to GrapheneOS

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.

GrapheneOS replied to GrapheneOS

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.

Bart Groeneveld replied to GrapheneOS

@GrapheneOS Lol, the average phone will die on batterylevel long before 1 week.

GrapheneOS replied to Bart

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

fxnn

@GrapheneOS

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

Go Up