[FEATURE PROPOSAL] Hardware/Software Unique Identifiers Protection

Hi /e/ community !

I’m wondering what is the positioning of /e/ on hardware unique identifiers, like those explain in this article. Is there or will be there any protection ? Like faking the MAC adress and others unique things.

And about software unique identifiers like the advertising ID and others identifiers that can be deleted with a factory reset (a little more explanation here) ?

Thank you for your answer :slight_smile:

2 Likes

I’m interested in an answer, does anyone can unlight us ?

since your goodbye post @anon83572368 I went through your questions and I think here I can contribute…

  • IMEI level identifier are hard to evade if you give the App telephony READ_PHONE_STATE permission, this is still the case.
  • wifi MAC is randomized now (https://source.android.com/devices/tech/connect/wifi-mac-randomization)
  • Build serial is device unique - since higher api target (Q) this is behind the READ_PRIVILEGED_PHONE_STATE permission. Apps targeting a lower API (lots still) can read it though
  • Secure Android ID (SSAID) - no longer device global but app signer unique - wrote on it at Android Identifiers - #5 by tcecyk … so that odd weather app gets less valuable from an Ad perspective. Official guidlines discourage using those ids and recommend creating App ids like:
  • app UUID - unavoidable, uuid is just the format - it’s an identifier the App generates for itself for the lifetime of the installation. If the App has any storage, it knows which install id it is talking to

These are or were the easy ids, already present, cheap to read/analyze, cheap to warehouse. I speculate Android APIs have an endless supply of bits to fingerprint though an install if you’re determined, similar to the impression you get from running EFFs browser panopticon.

So what is protecting you as a user? MicroG has several mechanisms to spoof Identifiers when talking to firebase cloud messaging - the backbone of notifications in the play ecosystem. Marvin explains in issues what is still chatting on the network - https://github.com/microg/GmsCore/issues/1508

we strip device identifier (MAC addresses, IMEI, etc) from requests where they normally would be (and if required use random but valid identifiers instead).

Despite tracking / monetization, I’m sympathetic to opt-in telemetrics for services. It’s hard to not be able to defend against resource abuse or know something about your own service - so there’s not only one side to the story.

The SSAID links contains the pdf of current de-google-isation and links to one of Dough Leiths publications. It’s a university group looking at the network behaviour of handhelds.