tweaselORG / TrackHAR

Library for detecting tracking data transmissions from traffic in HAR format.
Creative Commons Zero v1.0 Universal
5 stars 0 forks source link

ID research #25

Open baltpeter opened 10 months ago

baltpeter commented 10 months ago

We haven't discussed how to handle things that are pretty obviously vendor-specific IDs but that we can't find any documentation on.

For the time being, I won't work on these but document them here so we can come back later.

baltpeter commented 10 months ago

Adapter for singular.net:

baltpeter commented 10 months ago

branch-io/v1 has a whole bunch of third-party IDs in otherIdentifiers. For now, I'll just link to the documentation that e.g. $marketing_cloud_visitor_id is "the Marketing Cloud Visitor ID or Experience Cloud ID" (surprise, surprise), but we probably need some separate documentation for IDs that explains why we consider them personal data.

Probably helpful for documenting the Marketing Cloud ID: https://blog.adobe.com/en/publish/2015/10/20/why-new-adobe-marketing-cloud-id-service-should-be-on-your-radar

baltpeter commented 9 months ago

For the infonline adapters:

client.uuids.installationId, client.uuids.androidId (maybe the ANDROID_ID?), client.uuids.vendorIdentifier (maybe the IDFV?)

baltpeter commented 9 months ago

For onesignal/players:

zner0L commented 9 months ago

How do we argue that ID-like data are IDs?

What we need to argue:

  1. a datum is an ID, i.e. an ID has end-device reference.
  2. the ID is personal, either because it is related to the device, or because the data recipient claims to be able to resolve it.

To argue why installation-specific IDs are also personal: With the first (wlog) ID, a whole series of very unique (fingerprint-like) attributes were linked. The same are then also linked with the new, second ID and thus allow re-identification (can certainly also be well proven with marketing material).