Privacy Sandbox: support testing label header

[bretg]

As described in https://developer.chrome.com/docs/privacy-sandbox/chrome-testing, Prebid Server should support reading the special 'cookie deprecation header' that can be sent by Chrome browsers during the Privacy Sandbox testing period.

In order to receive the Sec-Cookie-Deprecation header however, Prebid Server needs to set the following cookie in every publisher's domain:

Set-Cookie: receive-cookie-deprecation=1; Secure; HttpOnly; Path=/; SameSite=None; Partitioned; Expires=TIMESTAMP.

Cookie Deprecation Config

Support a new account-level config to change the setting of the cookie and reading the test header

Proposed config value is

auction.privacysandbox.cookiedeprecation.enabled: false
auction.privacysandbox.cookiedeprecation.ttlsec: secondsForExpiration // default to 604,800 which is 1 week

Defaults to false since some publishers and bidder lawyers are sensitive about keeping lists of which cookies are set as a result of a page visit.

/cookie_sync endpoint

In order to get the Sec-Cookie-Deprecation header as early as possible, it's proposed that the /cookie_sync endpoint set the receive-cookie-deprecation in the sync response. This has the desirable side effect of limiting the reading of Sec-Cookie-Deprecation to Prebid.js requests. It's not relevant for mobile app, CTV, DOOH, etc.

1. If the receive-cookie-deprecation cookie is seen in the incoming request (alongside the uids cookie), then don't do anything since it's already been set.
2. If we were given the account ID, look up account config. If auction.privacysandbox.cookiedeprecation: false or not specified, then we're done. Continue /cookie_sync processing as normal.
3. else if the call to /cookie_sync doesn't contain an account ID, use the default account. We need to know if the account (or default account) wants this behavior. If default auction.privacysandbox.cookiedeprecation: false or not specified, then we're done. Continue /cookie_sync processing as normal.
4. If cookiedeprecation config is true from either the account or default config, then on the response, declare the HTTP header Set-Cookie: receive-cookie-deprecation as defined above. Read the cookiedeprecationexpirationsec config to set the Max-Age.

/auction endpoint

The job of the /auction endpoint is to read the Sec-Cookie-Deprecation header and add the results to the ORTB request.

1. Just before the processed auction phase
2. If $.device.ext.cdep is already present in the request, we're done. Use what's there.
3. If the account-specific or default account config auction.privacysandbox.cookiedeprecation is false or not specified, we're done - nothing else to do here.
4. Otherwise, if the Sec-Cookie-Deprecation header is present in the auction request, validate the value.
5. If the value is a string that's less than 100 characters, copy it to $.device.ext.cdep. If it's greater than 100 chars, don't copy and instead add a debug warning.

[pm-nilesh-chate]

POC implementation: #3381

[bsardo]

Thoughts on changing the config a bit so that cookiedeprecation is an object and also shortening expirationsec to ttlsec to be more in line with other configuration?

auction.privacysandbox.cookiedeprecation.enabled: false
auction.privacysandbox.cookiedeprecation.ttlsec: secondsForExpiration

[bretg]

@bsardo - fine - done and updated above.

[bsardo]

5. If the value is a string that's less than 100 characters, copy it to $.device.ext.cdep. If it's greater than 100 chars, add a debug warning.

As written, if it is greater than 100 chars we don't want to copy it to $.device.ext.cdep but rather just emit a debug warning. I just want to confirm that is the intended behavior as this subject came up on the PR.

[bretg]

Ok, updated the text to "If it's greater than 100 chars, don't copy and instead add a debug warning."

I cannot see this value being larger than 100 chars without a major change in the way these testing labels work.

[SyntaxNode]

Implemented in PBS-Go v2.10.0.

[SyntaxNode]

Looks like it was implemented in PBS-Java v2.11.0. Waiting for confirmation before closing.

[Net-burst]

Yeah, confirming that this was released in https://github.com/prebid/prebid-server-java/releases/tag/2.11.0
Closing this issue.