search

eylenburg / eylenburg.github.io

https://eylenburg.github.io/
Creative Commons Attribution Share Alike 4.0 International
119 stars 12 forks source link

Android Advertising ID #76

Closed eylenburg closed 1 month ago

eylenburg commented 1 month ago

Reminder to myself: Potentially add a row in "Privacy" for the Advertising ID.

Footnotes: if Play Services are installed on GrapheneOS or LineageOS, the situation would be the same as stock Android (i.e. it creates an Advertising ID but it can be deleted in settings)

lucasmz-dev commented 1 month ago

IIRC microG when used generates a random ID for each call or app, so instead of returning 0000 and making it clear to the app that is off, it instead just makes it unusable for tracking

I would consider that to be green

eylenburg commented 1 month ago

Thank you, and yes you are right:

In stock Android:

The user may manually reset this Advertising ID.
Since Android 12, when the user turns off ad personalization, then all apps receive zeros for the advertising ID. In all prior Android versions, the app will still have access to the Advertising ID.

In CalyxOS:

Any app that tries to get an Advertising ID simply gets a random number each time.
There is no ability to set this to zero or reset it.

Source: https://calyxos.org/docs/guide/security/identifiers/#android-advertising-id-aaid

I suppose this would still warrant the colour "green" as it makes the AAID useless for tracking, just needs to get a different description for ROMs using microG.

thestinger commented 1 month ago

IIRC microG when used generates a random ID for each call or app, so instead of returning 0000 and making it clear to the app that is off, it instead just makes it unusable for tracking

It's trivial for an app to check for this.

eylenburg commented 1 month ago

But wouldn't the end result be the same? Whether the app gets 0000 or a new random ID every time, it can't use this information to track the user via the Advertising ID?

thestinger commented 1 month ago

Yes, just saying that returning a different random number each time is easy to detect just like it being zeroed.

Apps within a profile can communicate with mutual consent, so this isn't really needed. Apps can just include an ad SDK which generates a random number and shares it between the apps using the SDK in the profile. GrapheneOS App Communication Scopes will allow controlling this within profiles but is still an experimental feature and doesn't fully block comms yet, so we could only ship it as an attack surface reduction feature documented as not fully blocking comms yet.