[blink-dev] Intent to Extend Experiment: Cookie Deprecation Label

[Nan Lin]

Contact emails

lin...@chromium.org, wande...@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

Summary

The cookie deprecation labels are useful for developers to evaluate and optimize deployments of the Privacy Sandbox APIs prior to any changes in the number of browsers which support third-party cookies, so we are asking to extend the current set of labels for three more milestones.

Storage Access Headers will ship in M133, allowing developers to determine if they have access to unpartitioned cookies via the Sec-Fetch-Storage-Access header instead of labels. Extending this experiment gives time for developers to make use of this upcoming API as a signal for cookie access.

Link to “Intent to Experiment” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/0_dR-ffA2LA/m/ZgmMhK-XAQAJ

https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ

https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/v3PiIzm1M-Y

 

Goals for experimentation

Continued deployment and evaluation of Privacy Sandbox Ads APIs.

Experimental timeline

This feature was previously approved to run up until Chrome 132.

We would like to extend this for Chrome 133 through 135, inclusive. 

Any risks when the experiment finishes?

Minimal, the cookie deprecation labels are only available for a subset of users and must be requested. 

Reason this experiment is being extended

We have received feedback that these labels are useful for ad tech companies to evaluate and optimize the APIs in preparation for changes to third party cookie availability.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

No, not supported on webview.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5189079788683264

[Mike Taylor]

Hey Nan,

On 1/24/25 6:29 PM, Nan Lin wrote:

Contact emails

lin...@chromium.org, wande...@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

Summary

The cookie deprecation labels are useful for developers to evaluate and optimize deployments of the Privacy Sandbox APIs prior to any changes in the number of browsers which support third-party cookies, so we are asking to extend the current set of labels for three more milestones.

This is a non-standard experiment, so the areas to demonstrate progress in https://www.chromium.org/blink/launching-features/#origin-trials don't cleanly apply. That said, have you received any useful feedback from developers who are using these labels?

Also, when do you expect this experiment to outlive it's usefulness?

Storage Access Headers will ship in M133, allowing developers to determine if they have access to unpartitioned cookies via the Sec-Fetch-Storage-Access header instead of labels. Extending this experiment gives time for developers to make use of this upcoming API as a signal for cookie access.

My understanding of this experiment was to allow for A/B testing analysis - but it sounds like it can be replaced with a signal of "has 3P cookies" (like navigator.cookieEnabled). Does that fully satisfy the needs of developers trying to understand PS APIs? Or do I misunderstand?

Link to “Intent to Experiment” blink-dev discussion

https://groups.google.com/a/chromium.org/g/blink-dev/c/0_dR-ffA2LA/m/ZgmMhK-XAQAJ

https://groups.google.com/a/chromium.org/g/blink-dev/c/3escBQGtIpM/m/ntcytva5BgAJ

https://groups.google.com/u/1/a/chromium.org/g/blink-dev/c/v3PiIzm1M-Y

 

Goals for experimentation

Continued deployment and evaluation of Privacy Sandbox Ads APIs.

Experimental timeline

This feature was previously approved to run up until Chrome 132.

We would like to extend this for Chrome 133 through 135, inclusive. 

Any risks when the experiment finishes?

Minimal, the cookie deprecation labels are only available for a subset of users and must be requested. 

Reason this experiment is being extended

We have received feedback that these labels are useful for ad tech companies to evaluate and optimize the APIs in preparation for changes to third party cookie availability.

Ongoing technical constraints

None

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

No, not supported on webview.

Link to entry on the feature dashboard

https://chromestatus.com/feature/5189079788683264

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/849254f2-1020-46d2-b42a-b7dd02db5e85n%40chromium.org.

[Nan Lin]

Hi Mike,

Thanks for the response. 

On Fri, Jan 31, 2025 at 11:00 AM Mike Taylor <mike...@chromium.org> wrote:

Hey Nan,

On 1/24/25 6:29 PM, Nan Lin wrote:

Contact emails

lin...@chromium.org, wande...@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

Summary

The cookie deprecation labels are useful for developers to evaluate and optimize deployments of the Privacy Sandbox APIs prior to any changes in the number of browsers which support third-party cookies, so we are asking to extend the current set of labels for three more milestones.

This is a non-standard experiment, so the areas to demonstrate progress in https://www.chromium.org/blink/launching-features/#origin-trials don't cleanly apply. That said, have you received any useful feedback from developers who are using these labels?

Also, when do you expect this experiment to outlive it's usefulness?

We've heard from developers using the APIs that the current implementation of labels remains a useful way to coordinate while there is traffic where Chrome has disabled third-party cookies.

Storage Access Headers will ship in M133, allowing developers to determine if they have access to unpartitioned cookies via the Sec-Fetch-Storage-Access header instead of labels. Extending this experiment gives time for developers to make use of this upcoming API as a signal for cookie access.

My understanding of this experiment was to allow for A/B testing analysis - but it sounds like it can be replaced with a signal of "has 3P cookies" (like navigator.cookieEnabled). Does that fully satisfy the needs of developers trying to understand PS APIs? Or do I misunderstand?

The goal of this experiment is to allow ad-techs to run server side A/B testing from the browser provided treatment and control groups, and evaluate the impact of third party cookie phase out.

It allows ad-techs to continue to test Privacy Sandbox APIs on some traffic without population issues.

[Johann Hofmann]

Just as a side note for anyone who may find this thread looking for answers, navigator.cookieEnabled was changed to align with other browsers and will no longer reliably tell you whether third-party cookies are available in an iframe or not. You can use document.hasStorageAccess() or the Storage Access Headers for this purpose, as mentioned by Nan.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BVrgP%3DyN1TUOaHyF7y_VF-FxALqc274fZp2jixBDNvtfdWcvw%40mail.gmail.com.

[Mike Taylor]

On 1/31/25 3:03 PM, Nan Lin wrote:

Hi Mike,

Thanks for the response. 

On Fri, Jan 31, 2025 at 11:00 AM Mike Taylor <mike...@chromium.org> wrote:

Hey Nan,

On 1/24/25 6:29 PM, Nan Lin wrote:

Contact emails

lin...@chromium.org, wande...@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

Summary

The cookie deprecation labels are useful for developers to evaluate and optimize deployments of the Privacy Sandbox APIs prior to any changes in the number of browsers which support third-party cookies, so we are asking to extend the current set of labels for three more milestones.

This is a non-standard experiment, so the areas to demonstrate progress in https://www.chromium.org/blink/launching-features/#origin-trials don't cleanly apply. That said, have you received any useful feedback from developers who are using these labels?

Also, when do you expect this experiment to outlive it's usefulness?

We've heard from developers using the APIs that the current implementation of labels remains a useful way to coordinate while there is traffic where Chrome has disabled third-party cookies.

Storage Access Headers will ship in M133, allowing developers to determine if they have access to unpartitioned cookies via the Sec-Fetch-Storage-Access header instead of labels. Extending this experiment gives time for developers to make use of this upcoming API as a signal for cookie access.

My understanding of this experiment was to allow for A/B testing analysis - but it sounds like it can be replaced with a signal of "has 3P cookies" (like navigator.cookieEnabled). Does that fully satisfy the needs of developers trying to understand PS APIs? Or do I misunderstand?

The goal of this experiment is to allow ad-techs to run server side A/B testing from the browser provided treatment and control groups, and evaluate the impact of third party cookie phase out.

It allows ad-techs to continue to test Privacy Sandbox APIs on some traffic without population issues.

Thanks - perhaps my question wasn't super clear. Does Sec-Fetch-Storage-Access fully replace this experiment to allow for A/B testing by ad tech companies?

[Nan Lin]

On Fri, Jan 31, 2025 at 4:35 PM Mike Taylor <mike...@chromium.org> wrote:

On 1/31/25 3:03 PM, Nan Lin wrote:

Hi Mike,

Thanks for the response. 

On Fri, Jan 31, 2025 at 11:00 AM Mike Taylor <mike...@chromium.org> wrote:

Hey Nan,

On 1/24/25 6:29 PM, Nan Lin wrote:

Contact emails

lin...@chromium.org, wande...@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

Summary

The cookie deprecation labels are useful for developers to evaluate and optimize deployments of the Privacy Sandbox APIs prior to any changes in the number of browsers which support third-party cookies, so we are asking to extend the current set of labels for three more milestones.

This is a non-standard experiment, so the areas to demonstrate progress in https://www.chromium.org/blink/launching-features/#origin-trials don't cleanly apply. That said, have you received any useful feedback from developers who are using these labels?

Also, when do you expect this experiment to outlive it's usefulness?

We've heard from developers using the APIs that the current implementation of labels remains a useful way to coordinate while there is traffic where Chrome has disabled third-party cookies.

Storage Access Headers will ship in M133, allowing developers to determine if they have access to unpartitioned cookies via the Sec-Fetch-Storage-Access header instead of labels. Extending this experiment gives time for developers to make use of this upcoming API as a signal for cookie access.

My understanding of this experiment was to allow for A/B testing analysis - but it sounds like it can be replaced with a signal of "has 3P cookies" (like navigator.cookieEnabled). Does that fully satisfy the needs of developers trying to understand PS APIs? Or do I misunderstand?

The goal of this experiment is to allow ad-techs to run server side A/B testing from the browser provided treatment and control groups, and evaluate the impact of third party cookie phase out.

It allows ad-techs to continue to test Privacy Sandbox APIs on some traffic without population issues.

Thanks - perhaps my question wasn't super clear. Does Sec-Fetch-Storage-Access fully replace this experiment to allow for A/B testing by ad tech companies?

 

Thanks Mike for clarifying the question. I don't think Sec-Fetch-Storage-Access can fully replace this experiment at this stage, as it doesn't tell whether the third party cookies are disabled by Chrome or not.

We would still need these labels to allow downstream A/B testing on the traffic slice with and without third party cookies.

[Mike Taylor]

I see, thanks. I would still like to understand the plan for/answer to my first question:

> Also, when do you expect this experiment to outlive it's usefulness?

I can imagine some ad techs would be happy to receive the labels forever, if they have some utility today.

In terms of burn-in risk, do we have any use counter or UMA metrics to understand its usage (since it's been in the wild for more than a year at this point)?

[Nan Lin]

Hi Mike,

The labels are only sent on the traffic slice where Chrome enables mode A (label only) and mode B (third party disabled) experiments, and overall this is <8.5% of browsers (these labels are also subject to a number of eligibility requirements).  

The labels will not be sent forever, and will be deprecated when Chrome stops the experiments and there is no traffic where Chrome disables third party cookies. 

Hope that clarifies!

[Mike Taylor]

Nan and I had an offline chat about burn-in risk. Given that, LGTM to extend from 133 to 135 inclusive.

However, I still have some concerns about successfully turning this off and hope the team can present a timeline or approximate plan for expiring the experiment, as an artifact of "progress", should they want to extend past 135. It may be interesting to consider pausing the experiment for a few days/1 week to flush out any code that's assuming navigator.cookieDeprecationLabel et al. will exist forever, or moving to an Origin Trial-based experiment.

[Garrett Johnson]

I wanted to express my appreciation for maintaining the Cookie Deprecation Label into 2025. Speaking as an academic researcher (and only in that capacity), this is an invaluable input into our ongoing research investigating the impact of privacy sandbox on advertiser performance ( https://papers.ssrn.com/abstract=4972368 ) and publisher revenue (work-in-progress). We (and our industry partners) find this helpful for our continued data gathering as the industry adoption of Privacy Sandbox continues to evolve and our industry partner's implementation of these tools adapts. For example, Google Ad Manager was not reporting Protected Audience API revenue from non-Google sources until about August 2024. We are also interested to see how our results change when Chrome eventually offers its user cookie choice option, as industry will then become more reliant on non-cookie alternatives. 

My team and I would appreciate if this label was maintained for the foreseeable future. In any event, I subscribed to this thread as it would be helpful to know when the labels are eventually deprecated. 

Apologies if I have broken any community norms here as a first time poster. 

Best regards,

Garrett Johnson
Associate Professor
Questrom School of Business
Boston University
https://garjoh.com