Intent to Experiment: Cookie Deprecation Labeling

[John Delaney]

Contact emails
john...@chromium.org, wande...@chromium.org, lin...@chromium.org

Explainer
https://github.com/privacysandbox/tpcd-labeling/blob/main/cookie_deprecation_labeling_explainer.md
https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing

Specification
None

Summary
To prepare for the third-party cookie deprecation, it is important to understand the full impact of Chrome’s planned transition from third-party cookies to the Privacy Sandbox Ads APIs.

This experiment exposes a temporary set of APIs which provide access to browser-determined treatment and control groups to support opt-in server side testing of the third-party cookie deprecation.

Blink component
A-N/A

TAG review
Not requesting TAG review as this API is a temporary Chrome-specific experiment.

Risks

Interoperability and Compatibility
This feature is only shipping in Chrome to support the third-party cookie deprecation, and will not be interoperable with other vendors.

WebView application risks
Not available on WebView


Goals for experimentation
The goal of this experiment is to allow adtechs to evaluate the impact of third party cookie phase out through opt-in server side testing. We expect partners to run experiments downstream from the browser provided treatment and control groups.

Experiment Behavior and Risks
This experiment will expose temporary APIs which allow access to browser provided experiment labels.

To ensure all parties can easily get access to labels, we intend to expose the APIs without a traditional origin trial. 

To limit burn-in risk, the new APIs will only be available to at most ~10% of users. These APIs should have very little utility to developers outside of this specific temporary experiment, it seems unlikely that user-visible breakage would occur as a result of the eventual removal.

Timeline
We intend to remove the labeling APIs when Mode B of the experiment ends, which we expect to be by the end of Q2 2024 at the earliest.

This experiment temporarily adds a new surface to the web that could be used for active fingerprinting. This is mitigated by the fact that:

• only a subset are assigned labels, reducing the usefulness of the label for fingerprinting
• labels are not sent for users who block third-party cookies, to ensure consistency with those users’ current settings
• the labeling APIs will be removed by the time third-party cookies are phased out
• label assignment is independent of users' browsing activity

Ongoing technical constraints
None

Debuggability
None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
No, not supported on WebView.

Is this feature fully tested by web-platform-tests?
No

Flag name on chrome://flags
#tpc-phase-out-facilitated-testing

Requires code in //chrome?
False

Estimated milestones
  Experiment desktop first     119
  Experiment Android first     119

Intent to Prototype
https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA/m/NZJSW0weAQAJ

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5189079788683264

[Rick Byers]

Exposing a new header and JS API temporarily for the purposes of an experiment (outside the context of an OT) is not something we've ever done before. But given the scope and requirements of this experiment and our desire to help enable the ecosystem to reason about it, it seems absolutely like the right pragmatic approach to me. Burn in risk seems like it would be low even at 100%, and effectively zero due to the 10% exposure. I don't see any interop concerns given that this API is useful only for understanding Chrome-specific behavior variation. 

LGTM1 to "experiment" with this, but I'd like to get two other LGTMs given that it's a very unusual I2E.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/232aa6ed-bb1e-4954-b290-f178b7edd7c1n%40chromium.org.

[Ben Kelly]

FYI, the specific labels to be sent are listed here:

https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/#mode-a

Specifically, the "label_only_1", "label_only_2", "label_only_3", "label_only_4", and "label_only_5" labels.  Note, the "control_1.*" labels are not being enabled yet.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8UhQ%2BVm2NJDZRwF0wvmO-WkVdexPMgT%3DKh07NWauUmKg%40mail.gmail.com.

[David Dabbs]

Per that document, Mode B Chrome instances will also be labeled.

[Chris Harrelson]

Hi,

This plan makes sense to me. It's an unusual situation but IMO justified given the difficulty of the goal. One last piece though: per the Blink launch process you need to specify an end milestone that is <= 6 release after the start milestone, so no later than M125 in this case. And extensions of up to 3 milestones each are always possible to ask for later, also per the Blink launch process.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/84331ce6-c0e4-49a9-9cfb-a37a035c7737n%40chromium.org.

[Ben Kelly]

On Fri, Oct 27, 2023 at 4:45 PM Chris Harrelson <chri...@chromium.org> wrote:

Hi,

This plan makes sense to me. It's an unusual situation but IMO justified given the difficulty of the goal. One last piece though: per the Blink launch process you need to specify an end milestone that is <= 6 release after the start milestone, so no later than M125 in this case. And extensions of up to 3 milestones each are always possible to ask for later, also per the Blink launch process.

Thank you.  We will set the end data at M125 for now, but we expect to come back to request an extension based on current timeline commitments.  We will provide an assessment of the situation at that time.

 

On Fri, Oct 27, 2023 at 1:28 PM David Dabbs <david...@epsilon.com> wrote:

Per that document, Mode B Chrome instances will also be labeled.

This is true, but I was trying to highlight the labels that would be starting in M119.  Sorry for the confusion.

[Chris Harrelson]

LGTM2!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMgsjf4AHkQvgOc%2BQcNpi41o%3DnZiN4JFKMwyY6zMAFCKFA%40mail.gmail.com.

[Mike Taylor]

LGTM3.

(I verified off-list that the temporary navigator.cookieDeprecationLabel API will indeed not be exposed to all users, so I feel pretty confident and the low burn-in risks.)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw85v6qDQFsBqjZMvbprhW%3D3dRipW0bXtdoXYueuf_viuQ%40mail.gmail.com.

[Russ Hamilton]

FYI, based on feedback from testers (https://github.com/WICG/turtledove/issues/946) we are going to send the Cookie-Deprecation label headers during the trusted bidding and trusted scoring signals fetches for Protected Audience auctions beginning in M122. Note that if the user is not part of the Facilitated testing groups or has disabled third party cookies then this feature will not be added to the header.