Aligning TCF and Activity Controls

[bretg]

Prebid Server side of the PBJS issue https://github.com/prebid/Prebid.js/issues/10184

1. Split the transmitUfpd Activity Control. We thought we could get away with combining, but that's not the case.
   1. transmitUfpd covers user.ext.data, user.data, user.id, user.buyeruid, user.yob, user.gender, user.keywords, user.kwarray ,and device.{ifa, macsha1, macmd5, dpidsha1, dpidmd5, didsha1, didmd5}
   2. transmitEids covers user.eids and user.ext.eids
   3. It's likely that not many have used this activity yet, but the release notes should highlight the change
   4. Add a configuration (privacy.gdpr.purposes.p4.eid.activity_transition) which defaults to true.
   5. If the config is true and transmitEids is not specified, but transmitUfpd is specified, then use the logic of transmitUfpd. This is to avoid breaking changes to existing configurations. In a future release, we'll change the default of the flag.
2. Align the outcome of the TCF consent checks to the Activities as described in the updated Prebid+GDPR doc.
3. Add an account-level flag to let the publisher define the transmitEids behavior of TCF

transmitEids config

It's proposed that there's a new account-level config

privacy.gdpr.purposes.p4.eid.require_consent: true/false  // if true, eids require P4 legal basis unless excepted below
privacy.gdpr.purposes.p4.eid.exceptions: ["pubcid.org"]   // doesn't do anything when eids-require-consent: false.

1. If eid.require_consent is true, P4 must have consent (or not being enforced) or else user.eids and user.ext.eids will be removed. Except any source in eid-exceptions can be present if any Purpose 2-10 is consented.
2. If eid.require_consent is false, any Purpose 2-10 must have consent or user.eids and user.ext.eids will be removed. (existing logic)
3. The default for eid.require_consent is false.

[VeronikaSolovei9]

Point 1 Split the transmitUfpd Activity Control will be addressed in PR https://github.com/prebid/prebid-server/pull/2906

[bretg]

Confirmed points 1 and 2 in committee. Ran out of time, will cover the privacy.gdpr.purposes.p4.eids-require-consent config in the next meeting.

[bretg]

Discussed in committee. There's skepticism that the P4 flag will be used without some kind of EID exception ability. Will add that to the proposal and we'll discuss again.

[bretg]

My understanding of the desire for exceptions is to have some of the EIDs suppressed without explicit P4 consent and others to have the broader filter where they can be passed on any P2-P10.

privacy.gdpr.purposes.p4.eid.require_consent: true/false  // if true, eids require P4 legal basis unless excepted below
privacy.gdpr.purposes.p4.eid.exceptions: ["pubcid.org"]   // doesn't do anything when eids-require-consent: false.

When eids-require-consent: true, any eid.source in eid-exceptions falls back to being passed when any consent P2-P10 is found.

[bretg]

Approved by committee pending final legal review.

[bretg]

Received legal counsel approval

[bretg]

In order to avoid the potential for breaking changes, the system should utilize the activity control config for transmitUfpd for transmitEids if the latter is not specified, at least until 3.0.

[bretg]

To clarify the statement "Align the outcome of the TCF consent checks to the Activities as described in the updated Prebid+GDPR doc.":

1. This issue is not intended to fully integrate Prebid Server's TCF enforcement into the Activities Infrastructure. That may happen in the future, but is a larger project.
2. The goal is to make the following changes to the existing TCF/GDPR feature (highlighted in blue in the doc)
   1. At the same location as the transmitUfpd activity, do a consent check for Purpose 4. Same consent logic as used for other Purposes: full consent logic when GVL is available, configured exceptions, etc. If the P4 consent check results in "no consent", then the results are the same as if the transmitUfpd activity were disallowed. (i.e. suppress fields from the bidder)
   2. If privacy.gdpr.purposes.p4.eid.require_consent is true, then at the same location as the new transmitEids activity, also do a consent check for Purpose 4. If the P4 consent check results in "no consent", then the results are the same as if the transmitEids activity were disallowed. (i.e. suppress fields from the bidder, but allow any configured exceptions.)
   3. If privacy.gdpr.purposes.p4.eid.require_consent is false, run the consent checks for Purposes 2-10. If even one of them is consented, leave the EIDs in the request. If none of the 9 Purposes has consent, then remove the EIDs array.

[bretg]

Released with PBS-Java 2.12. Working on docs...