InteractiveAdvertisingBureau / GDPR-Transparency-and-Consent-Framework

Technical specifications for IAB Europe Transparency and Consent Framework that will help the digital advertising industry interpret and comply with EU rules on data protection and privacy - notably the General Data Protection Regulation (GDPR) that comes into effect on May 25, 2018.
860 stars 360 forks source link

Clarify use of wildcard identifiers in "Vendor Device Storage & Operational Disclosures" #316

Closed mattpr closed 2 years ago

mattpr commented 2 years ago

Docs indicate wildcards are allowed for domain...

* = any domain (ex. first party cookie) *.vendor.com means multiple subdomains may exist

However it doesn't say whether using wildcards are allowed elsewhere but we have noticed some vendors that use wildcards in their identifier fields (for instance if they have a cookie naming pattern prefix-customerId... prefix-1234 and prefix-5678 would be covered by prefix-*.

Just wondering whether this is allowed/intended/supported. If so, can we get some clarification in the docs?

dmdabbs commented 2 years ago

We will look into it. cc: @anderagakura

anderagakura commented 2 years ago

Thanks @mattpr for raising this point. As mentioned @dmdabbs, we will have a look on it and keep you updated

anderagakura commented 2 years ago

@mattpr As mentioned in the Doc, the wildcard is only allowed for domain.

Regarding the current status of the doc, if any vendor applies the wildcard outside the domain field then it does not follow the doc. Fyi, we have a compliance program in order to check the devicestorage.json of the vendors and notice them if something is wrong. In the meantime, if you see similar issues any devicestorage.json, your feedback are definitely welcome to framework@iabeurope.eu

dmdabbs commented 2 years ago

We should investigate AdSpirit's use of wildcards in the name field. I believe Jan Winkler used to work at AdSpirit and could speak to it or connect us to them. I'll reach out to him on Slack.

If a vendor's cookie names incorporate, for example, match partner ids or the like, accommodating the asterisk will be the only tenable way for those vendors or publishers to provide the mandatory transparency.

dmdabbs commented 2 years ago

Jan replied in Slack:

Jan Winkler 6:06 PM the * in adspirits cookie names are wildcards as the cookies follow a simple rule (clientname_cookiename). the amount of clients changes, hence there is never a definite list of cookie names (or the list would be super long)

anderagakura commented 2 years ago

@dmdabbs We understand the need behind declaring a super long list of cookies, maintaining cookies with partners etc... but what we want is a granular declaration of the cookies, provide transparency.

This choice is also to prevent some scenario which could question the main utility of devicestorage.json such as :

mattpr commented 2 years ago

IAB is already relying on vendors to self-report accurately (what cookies are used for what purpose). Sure you can try to automatically monitor for enforcement, but many types of cookies may not get set (or seen by your monitoring) if you just load a bunch of top1000 sites.

I know a lot of companies are trying to keep customer data segregated at much as possible (concerns about data leakage, etc) so it can be quite common to have something like profile_XXXX or metrics_XXXX cookies where XXXX is a customer/account ID. The profile_ prefix cookies are for purpose of retargeting (for example) and the metrics_ cookies are for the purpose of conversion tracking/reporting (for instance).

It would not make sense to update devicestorage.json to enumerate a complete list of cookies every time a customer is won or lost...at least that doesn't seem like something many vendors would want to implement.

I can imagine wanting to avoid declaration of * cookie name. However if all the cookies are all named profile_XXXX (and there aren't any other cookies in use by this vendor...ie no metrics_XXXX cookies)... then whats the difference between saying profile_* and just * as the cookie name as long as the purposes declared are accurate? This comes back to the point about having a certain level of trust for vendors to self-report their cookies and the purpose of those cookies.

Some vendors may be using a single cookie (e.g. user_data) for a ton of different stuff (purposes and customers). It could have been broken out into different cookie names to give more granular transparency about what types of data/use is currently active from a vendor on a device...but they didn't make that technical decision. Practically speaking, I think it is more useful to be able to say something like:

profile_*: purpose OBA profiling/ad-selection metrics_*: reporting

than

user_data: * purposes

In any case, if the wildcard won't be allowed to more accurately describe naming patterns of certain categories of cookies, then some technical guidance should be offered to vendors that use this types of cookie naming/partitioning scheme.

anderagakura commented 2 years ago

@mattpr We're going to have a broader chat internally and we will come back to you asap. cc : @dmdabbs

anderagakura commented 2 years ago

Closed following the update in PR #320