TIL ANDROID_ID and who comes up with this malicious shit? does GrapheneOS do anything reasonable to fix it?
Conversation
Replying to
On Android 8+, it's based on a secret generated for each profile and made into an app-specific value based on app signing key. Apps can implement their own ANDROID_ID via app-specific external storage directory unless scoped storage is being used which clears that on uninstall.
2
We cover these things in grapheneos.org/faq#hardware-i and grapheneos.org/faq#non-hardwa.
We've planned to change how it works for a while so that it's instead a per-app id tied to the app install and will be different on reinstall. Not much benefit with low scoped storage adoption though.
2
1
Replying to
How would storage persist across uninstall? If it's in shared storage at least it's visible and subject to manual deletion, no?
1
Replying to
You could manually delete the app-specific directory from external (shared) storage. Apps can access their own directory in Android/ without a permission. With scoped storage, this gets cleared on uninstall, so they can't persist data without asking you to choose a place for it.
1
Replying to
Couldn't you just always ask on uninstall whether the user wants it wiped, even if it wasn't using the scoped storage api?
1
Replying to
Yes, although there are a LOT of privacy and security improvements tied to API level. Play Store enforces API level 29+ for new apps and app updates. That will become 30+ (enforced scoped storage) around this time next year. It's unfortunate it got delayed a whole year like this.
There's a soft enforced minimum API level in the OS set to API 23 in AOSP/stock. We raise that to match the Play Store (currently 28) requirement. Ideally, this would be a hard minimum, but we can't just break all legacy apps. It could be enforced better than AOSP/stock though.
1