Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ID research #25

Open
baltpeter opened this issue Aug 25, 2023 · 5 comments
Open

ID research #25

baltpeter opened this issue Aug 25, 2023 · 5 comments

Comments

@baltpeter
Copy link
Member

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
Copy link
Member Author

baltpeter commented Aug 25, 2023

Adapter for singular.net:

@baltpeter
Copy link
Member Author

baltpeter commented Aug 28, 2023

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
Copy link
Member Author

For the infonline adapters:

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

@baltpeter
Copy link
Member Author

For onesignal/players:

  • ad_id: "Based on the Google Advertising Id for Android, identifierForVendor for iOS. OptedOut means user turned off Advertising tracking on the device." (source). Ugh.

@zner0L
Copy link
Contributor

zner0L commented Sep 26, 2023

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

  • Benni researches how others argue.
  • Possibilities we can think of:
    • It's in the docs
    • It's in the SDK's open code or we decompile the SDK:
      Search for the ID property and code that stores and uniquely generates it or loads it from the server or other SDK
    • Empirical dynamic analysis: the date occurs repeatedly in multiple requests, but differs from device to device or installation to installation

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants