Intent to Deprecate & Remove: Third-Party Cookies

[Johann Hofmann]

Contact emails

joha...@chromium.org, wande...@chromium.org, dylan...@chromium.org, kaust...@chromium.org, jka...@chromium.org, john...@chromium.org

Explainer

For general information on Privacy Sandbox for the Web and Google’s plans to phase out third-party cookies, see https://privacysandbox.com/open-web/.

For additional information on the planned semantics of third-party cookie blocking and its interaction with the SameSite cookie attribute, see https://github.com/DCtheTall/standardizing-cross-site-cookie-semantics 

Specification

The Cookies RFC contains some language that, in theory, allows user agents to block third-party cookies, leaving a lot of details unspecified. We are not happy with this status quo and are collaborating with other browsers on a significant spec refactoring effort called cookie layering to give Fetch/HTML more responsibility over specifying how and when cookies are stored and attached, as well as a WebAppSec Note based on our existing explainer that describes how cookie blocking interacts with SameSite cookies.

Summary

We intend to deprecate and remove default access to third-party (aka cross-site) cookies as part of the Privacy Sandbox Timeline for the Web, starting with an initial 1% testing period in Q1 2024, followed by a gradual phaseout planned to begin in Q3 2024 after consultation with the CMA (The gradual phaseout is subject to addressing any remaining competition concerns of the UK’s Competition and Markets Authority.)

Phasing out third-party cookies (3PCs) is a central effort to the Privacy Sandbox initiative, which aims to responsibly reduce cross-site tracking on the web (and beyond) while supporting key use cases through new technologies. Our phaseout plan was developed with the UK's Competition and Markets Authority, in line with the commitments we offered for Privacy Sandbox for the web.

Blink component

Internals>Network>Cookies

Motivation

Our goal on the Privacy Sandbox is to reduce cross-site tracking while still enabling the functionality that keeps online content and services freely accessible by everyone. Deprecating and removing third-party cookies encapsulates the challenge, as they enable critical functionality across sign-in, fraud protection, advertising, and generally the ability to embed rich, third-party content in websites—but at the same time they're also a key enabler of cross-site tracking.

Initial public proposal

N/A

TAG review

The TAG has explicitly endorsed (n.b. as a draft document) the deprecation of third-party cookies in the past. Additionally, we requested feedback on our proposal to define the 3PC security semantics and received generally positive feedback.

TAG review status

Tentatively Positive, see above

Risks

Compatibility

Impact on the Ads ecosystem:

A suite of APIs for delivering relevant ads, measuring ad performance, and preventing fraud and abuse are now generally available in Chrome to continue to facilitate ad-supported content on the web. We continue to work closely with the UK Competition and Markets Authority (CMA) on evaluating the impact of this change on the ads ecosystem. 

Web Compatibility:

Despite 3PCs already being blocked in Firefox and Safari and developer outreach efforts to raise awareness and encourage developers to prepare for the deprecation, we currently estimate that a non-trivial number of sites are still relying on third-party cookies for some user-facing functionality. To address this breakage, we have developed a two-pronged strategy:

1. Breakage Discovery & Outreach

Through various efforts, such as UKM-based signal analysis, scaled manual testing and dogfooding, we are collecting a list of impacted use cases. These individual breakage cases inform our mitigation strategy (see next step) and future API improvements, as well as our ongoing developer outreach efforts.

We also offer developers the ability to report 3PC breakage to the Chrome team via goo.gle/report-3pc-broken or ask general questions at https://github.com/GoogleChromeLabs/privacy-sandbox-dev-support/issues.

2. Temporary Breakage Mitigation

It will take time for developers to replace their usage of 3PCs with new APIs or different approaches, and some developers may not be aware of this deprecation until they discover breakage. In order to reduce the impact of such breakage on the web, we have implemented a series of temporary mitigations:

• Exemption Heuristics: We are planning to ship heuristics mirroring those that already ship in Firefox and Safari, and are also working with both browsers on a coordinated removal process. Additional details can be found & should be discussed in the I2P & upcoming I2S.

• Deprecation Trial: This will be outlined in more detail in the upcoming Request for Deprecation Trial, but it’s important to note that a review step including evidence of user-facing breakage will be required for participation. Further, we do not intend to approve trials for ads-related use cases, to avoid interference with the quantitative testing.

• As with other launches, we will also have a set of server-side controls to manage the rollout as a whole and minimize issues specific sites are causing for users.

Despite all these efforts, we want to be clear that we are intentionally taking some risk here in the interest of user privacy.

Enterprise Compatibility:

To help with the transition, we intend to allow enterprise organizations to opt their applications out of third-party cookie blocking using the existing BlockThirdPartyCookies or CookiesAllowedForUrls policies. Given that enterprise systems are often gated and are therefore hard to analyze from an external perspective, these policies will provide additional time for the enterprise ecosystem to adapt. We intend to publish additional guidance for enterprises on https://goo.gle/3pcd-enterprise for the period beyond the 1% testing period.

Interoperability

Both Firefox and Safari have removed default access to third-party cookies already, though there are small differences in how browsers treat SameSite=None cookies in so called “ABA” scenarios (site A embeds site B, which embeds site A again). Chrome ships the more secure and more restrictive variant, and from initial conversations we are optimistic that other browsers will adopt it as well. There are also subtle differences in how browsers restore access to third-party cookies through mechanisms such as heuristics or custom quirks. Where Chrome implements similar measures (such as the heuristics), we try to follow the launch and standards processes to achieve as much interop as we can, given other requirements such as privacy and security.

Gecko: Shipping

WebKit: Shipping

Web developers: Mixed Signals

As one of the most impactful changes to the web platform in a long time, the deprecation of 3rd party cookies and the introduction of alternative APIs have received a lot of helpful feedback from web developers to an extent impossible to summarize in a few sentences. As described in the summary, the Privacy Sandbox wants to ensure that a vibrant, freely accessible web can exist even as we roll out strong user protections and we will continue to work with web developers to understand their use cases and ship the right (privacy-preserving) APIs. And we’ve received feedback that gives us confidence that we’re on the right track.

WebView application risks

This deprecation will not affect WebView for now.

Debuggability

Developers may use the command-line testing switch --test-third-party-cookie-phaseout (available starting Chrome 115) or enable chrome://flags#test-third-party-cookie-phaseout (available starting Chrome 117), to simulate browser behavior with default access to third-party cookies removed. We also started reporting DevTools issues for cookies impacted by the deprecation starting in Chrome 117 to help identify potentially impacted workflows. We are continuing to improve our developer documentation on debugging third-party cookies usage, and guidance on migration to new APIs.

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

Yes. We have put together a set of WPTs which cover third-party cookie blocking for subresource requests. It is not yet comprehensive, we are working on adding additional tests to support our standardization efforts.

Flag name on chrome://flags

TestThirdPartyCookiePhaseout

Finch feature name

Due to the nature of the Chrome-facilitated testing period, as well as the general complexity of managing breakage related to removing third-party cookies, there won’t be a single Finch feature that takes us from 0% to 100% deprecated. Instead, a collection of features, supporting different phases and components, will be used.

Non-finch justification

N/A

Requires code in //chrome?

No, the base third-party cookie blocking functionality does not require Chrome code. Some custom Chrome functionality (such as the aforementioned facilitated testing, mitigations and user experience improvements) does require it.

Estimated milestones

Initial phase of Deprecation (1%) is planned as part of the “Chrome facilitated testing period” beginning in Q1 2024, as described on https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline, further phaseout is planned to begin in Q3 2024. (The gradual phaseout of third-party cookies is subject to addressing any remaining competition concerns of the CMA.)

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5133113939722240

This intent message was generated by Chrome Platform Status.

[Yoav Weiss]

LGTM1

I cannot imagine a more thorough and thoughtful approach than the one the Privacy Sandbox team has taken to tackle this significant change to the web's privacy model while minimizing breakage and providing replacement APIs. Thanks for pushing this important work through!!

--
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/CAD_OO4ikogMJZce42o-QcGUMDNiM2Lr_6BGAfP8Gzktakc5_fw%40mail.gmail.com.

[David Dabbs]

This morning's Implementation status change to Deprecated  results in

Deprecate Third-Party Cookies (Deprecated)

Did you intend to also rename the feature to "Third-Party Cookies?"

Thanks

[Johann Hofmann]

Hey David, yeah, that was me trying to fix the entry not showing up on API Owner dashboards. I don't think that was what fixed it though, so I can change it back to "In Developer Trial" (which feels like the most accurate right now?)

Thanks!

Johann 

[David Dabbs]

Thanks for the explanation.

David

[Daniel Bratell]

You say Q1 2024, but do you know a more exact date? I ask because we are entering the holiday freeze period when companies do no changes whatsoever and even if this makes a site want to fix something, they might not be able to until some time into the quarter.

I also think it might be good to split it into the 1% part, and a 100% part since it is hard to judge the web compatibility level already and that is part of what the 1% run will do.

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1d705388-c7ff-46ad-9d4e-db6276b8035an%40chromium.org.

[Johann Hofmann]

Hi Daniel,

On Wed, Nov 15, 2023 at 6:09 PM Daniel Bratell <brat...@gmail.com> wrote:

You say Q1 2024, but do you know a more exact date? I ask because we are entering the holiday freeze period when companies do no changes whatsoever and even if this makes a site want to fix something, they might not be able to until some time into the quarter.

we're currently planning for early Jan, i.e. M120 would be the first release that contains the technical capabilities to ramp to 1% (breakage mitigations, quantitative testing). The holiday freeze is definitely a risk to call out here. However, as mentioned in the intent, we're already operating under the assumption that some sites, despite our outreach efforts, will only find out about this once the deprecation begins. To help with that, we have a number of temporary mitigations available that work quickly and effectively and can be initiated by various stakeholders in this process (site, user, browser). While not directly relevant to the web platform pieces, we plan to have user interface controls to give temporary exceptions per top-level site in Chrome.

 

I also think it might be good to split it into the 1% part, and a 100% part since it is hard to judge the web compatibility level already and that is part of what the 1% run will do.

The 1% is a long-running testing period that we're doing as part of the commitments we entered with the CMA. However, from a readiness / web platform perspective, we'd really like to treat it with the same seriousness and care that we would treat a full rollout, as 1% of users (over a significant amount of time) should not have a greatly degraded user experience. We're trying to ship the full array of breakage mitigations we will have available for potential future rollouts in this phase as well.

So, if possible, I'd prefer to discuss any concerns you might have about web compatibility, mitigations and ecosystem readiness in this thread, rather than pushing it further out. :)

Thanks,

Johann

[Rick Byers]

LGTM2 - It's time.

Given that this is our biggest breaking change ever and I've gotten some feedback saying at least a couple people appreciate it when I expand on my thought process in compat analysis, I figured I should take the time to try to systematically evaluate this against our blink compat principles. Hopefully we'll learn some things from how this deprecation goes in practice to help us further improve our framework for evaluating and mitigating future compat risk.

• Minimizing end-user impact
• Page views impacted: High risk
• The UseCounter has been steady at around 46% for years. Clearly a huge risk from our first line of reasoning. 
• Unique sites impacted: High risk
• I don't have a pointer to data handy, but I assume it's also very large (eg. due to 3p embeds like ads).
• Severity of breakage: Moderate risk
• One argument is that most sites already need to work for all the Safari and Firefox users and the X% of Chrome users with 3P cookies disabled, and so have adapted.
• But on the other hand we have plenty of examples of sites which just tell users they must enable 3PCs to make the site function at all. 
• So I think we have to say that there are a non-trivial number sites where the severity is total site breakage - necessitating all the mitigations, even if most impacted sites have non-visible breakage.
• Chrome's release process: Moderate mitigation
• This change is under very careful finch control with tons of monitoring. 
• We also have a variety of feedback channels including the manual breakage reporting Johann mentioned, as well as monitoring of user behavior to infer breakage, and a pretty big team motivated to react quickly to keep user impact to a minimum. 
• One thing to be mindful of here is that the CMA-mandated 1% experiment will place some limits on the team's options to respond to reports of breakage (eg. the deprecation trial says it can't be used by sites on the disconnect.me advertising list). 
• User opt-out: Very strong mitigation
• I've been playing with the cookie control UI (eg. see screenshot below) on my personal account and I'm quite happy with it. I've seen the user education directing me to this UI including in scenarios like when I reload a page. Some of that may be experiments or things undergoing design change (I don't actually know the specific plans, just commenting on what I've experienced personally), but it gives me confidence that the team is seriously working to educate users on how to opt-out in the case of breakage.
  
• Maximizing user experience
• Security & Privacy: Strong mitigation
• Personally it seems clear to me (and eg. the W3C TAG) that 3PCs being off is the right long-term default for the web in the name of privacy.
• In addition I believe there's some security benefit - eg. making side-channel attacks for sharing data between frames less useful to attackers
• Performance: Weak mitigation
• You could argue that sites will be faster without 3PCs, but I suspect that's temporary.
• Perhaps more importantly, the deprecation of 3PCs creates pressure to raise the level of abstraction of the web and I think history has shown that we can make the web faster the more sites operate at a higher level of abstraction (eg. consider scrolling/animation being JS-driven vs. browser-driven and the rise of threaded compositing with mobile browsers and how web advertising might look 5-10 years from now).
• User annoyance: Weak mitigation
• Maybe a risk of some increase in annoyance - eg. need popups for some things that used to work in-page via iframes. 
• Certainly having to turn 3PCs back on for a site that doesn't work otherwise will be annoying
• I'd also argue that, like for performance, raising the level of abstraction will give us more opportunity to reduce annoyance. Eg. users will have more centralized and consistent control over their advertising preferences.
• Minimizing web-developer impact
• Ease of adaptation: Moderate mitigation
• Key functional scenarios like identity have well known and long-used alternatives like pop-ups and redirects. Chrome adopting the temporary heuristics already used successfully by other browsers seems like a significant mitigation for these flows to me.
• The requestStorageAccess API is a drop-in option in many scenarios (again, already deployed for other browsers)
• Advertising use cases require a lot more work to adapt to, but massive effort has gone into (and will presumably keep going into) building and validating these alternatives.
• Developer opt-in / opt-out: Strong mitigation
• The deprecation trial seems like a big mitigation to me - pretty easily giving non-ads origins an extra year.  
• The prior move to require SameSite=None also seems like a significant mitigation, developers have effectively been opting into 3PCs in chromium for three years! 
• There's also been an effort to variety of mechanisms and tools for developers to opt-in to 3PCD and validate their site works
• Enterprise policy opt-out: Moderate mitigation
• Policy control exists. Given the scope of potential impact in enterprises, this still seems like an area of some risk to me (eg. BYOD scenarios with Chromium-only custom apps). But again the user opt-out is a huge mitigation for this risk.
• Debuggability: Moderate mitigation
• Purpose-built tools A variety of tools have been built to help developers understand and adapt their cookie usage. Still cookies can be complicated, there's no silver bullet.
• Outreach: Moderate mitigation
• Almost certainly more outreach than we've ever done for a deprecation (even Flash!), yet still not so much as to avoid the likelihood of some developers being surprised. This is a place one could always argue for more work, but it's hard to know where the point of diminishing returns is, especially prior to the slow roll-out even starting. I expect this is something we'll learn more about during the 1% experiment period to guide the ramp-up process after that.
• Maximizing web ecosystem benefit
• Interoperability: Strong mitigation
• The other two major engines have disabled 3PCs by default for some time. I'm personally uncomfortable with 3PC-related breakage being a reason why developers might encourage users to use chromium-based browsers. Restoring interoperability across browsers seems like strong motivation for accepting some risk here.
• The team has gone the extra mile to advance specs, write WPTs and generally work to move the web away from UA-specific heuristics to a new likely interoperable and standardized state wrt. cookie behavior
• Standards conformance: Weak mitigation
• No standard requires 3PCD, but it seems likely that future web standards will be built under the assumption of 3PCs being unavailable (lots of such specs in development on a standards track)
• IP rights: Not relevant
• Accepted interop risk: Not relevant

Overall it seems to me like the high risks are appropriately balanced by significant mitigations and justifications for accepting the cost of the risk. More importantly, every technical tool in our web compat toolbox has been brought to bear on mitigating the risks, and significant resources are devoted to monitoring and responding to any issues. I both trust the team to effectively manage the risk during roll-out and expect that there will be some bumps and mistakes that we will want to learn from. 

Best of luck!

   Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAD_OO4ispE4%2Bj-YsxyyxHU%2BGAJ8honiS0feV4zgf_4R_ZJq9MA%40mail.gmail.com.

[Johann Hofmann]

I really appreciate the thorough analysis and the vote of confidence, Rick. You've captured the challenges (and opportunities) of this entire effort incredibly well.

[Mike Taylor]

LGTM3.

I won't try to compete with Rick's blog post, but am sufficiently satisfied that the 3PCD team has made best-of-class efforts on comms, mitigations, and developer tooling, with the goal of landing this deprecation with reduced web compatibility impact. Good luck - exciting-slash-interesting times ahead. :)

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

[Johann Hofmann]

Thanks all! We'll keep this thread posted on our progress in rolling this out.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/82ea3de7-a520-4b64-b1b9-451abd03492a%40chromium.org.

[Adam Gertenbach]

Good morning all,

Our organization is currently re-reviewing the impacts of the third party cookie deprecation now that registration for deprecation trials have been made available. Among our offerings, we provide consulting, hosting, architecture, and development services for customers in the business intelligence and enterprise analytics space, including Microsoft Power BI, Qlik Sense, ThoughtSpot, and Tableau. The ability to provide embedding of analytics capabilities, such as visualizations and dashboards, is common across the industry and is supported by each of the major vendors; as such, we've facilitated these capabilities in architecting and building solutions for our customers, often using these embedding capabilities to create custom solutions or enhance enterprise portals that have seen very large adoption.

https://help.qlik.com/en-US/sense-developer/November2023/Content/Sense_Helpsites/embed-qlik-sense.htm

https://learn.microsoft.com/en-us/power-bi/collaborate-share/service-embed-secure

https://docs.thoughtspot.com/cloud/latest/intro-embed

https://help.tableau.com/current/pro/desktop/en-us/embed.htm

As one might expect, these embedded solutions are often reliant on a combination of iframes and cross domain third-party cookies to supply authentication and authorization and cannot be made to operate under a single domain. While we intend to actively engage with these vendors to notify them of expected breakage due to the pending deprecation and would hope that options for partitioning/CHIPS will make its way into these products in a timely fashion, there is a significant risk that existing solutions will be impacted in the interim period; furthermore, the customer perception around this breakage is likely to impact our reputation based on our role in delivery, despite the fact that we do not and cannot directly resolve the underlying cause without third-party participation and product updates.

Historically, resolution of these types of issues have not always been proactive. Qlik Sense had to update their interfaces as the SameSite None rollout was occurring due to customer breakage ( https://community.qlik.com/t5/Official-Support-Articles/Missing-SameSite-attribute-blocks-requests-in-Chrome-80-and/ta-p/1712551 ). More recently, Microsoft's Power BI login process for embedded reports broke in September when the third-party storage partitioning policies were enabled due to their use of cross-window localStorage usage for signaling during authentication. Not knowing that this was in use by their product, mitigation of this issue involved an all-nighter investigation on our part to understand what was happening and the enrollment of a first-party deprecation trial by us to re-enable services for our customers.

While I recognize the motivations behind the strategies outlined, the lack of a first-party deprecation trial to provide wide-spread temporary mitigation is likely to significantly impair our service offerings and existing customer solutions while these issues are ironed out and implemented by these vendors. We're hoping to prepare our customers through proactive messaging where possible (enterprise policy, anticipated per-user UI overrides, etc.) but I'd like to call out this scenario and see if there's anything I'm missing in terms of short-term solutions available to us, and to ask if a first-party deprecation trial offering is expected for cases like these where influence on the owners of third-party embeds is limited.

[Johann Hofmann]

Hi Adam,

Thank you for the detailed feedback. I'm discussing with the team and will follow up here.

Thanks,

Johann

[Kaustubha Govind]

Hi Adam,

Just FYI, we are in the process of setting up a first-party deprecation trial (applicable to non-advertising usecases only) as you requested. Please see this thread for details.

K

[Adam Gertenbach]

That is great news, thank you for the update!

We appreciate the review and action, it will absolutely help us ensure a smoother and more seamless transition for our clients.

Thanks,

Adam

[Ben Kelly]

As per previously announced plans, Chrome is restricting third-party cookies by default for 1% of Chrome users to facilitate testing, and then ramping up to 100% of users from Q3 2024. The ramp up to 100% of users is subject to addressing any remaining competition concerns of the UK's Competition and Markets Authority (CMA).

As of 4th January 2024, Chrome has started restricting third-party cookies by default for 1% of Chrome browsers. It may take several days to reach the full 1%.

Please see the associated blog post for more information.

[Ben Kelly]

Please note, due to a bug we have temporarily disabled bounce tracking mitigations in mode-B Chrome-facilitated testing experiment traffic.  Once we have a fix deployed we plan to re-enable bounce tracking mitigations for Chrome-facilitated testing traffic.  We will update here when that occurs.

[Ben Kelly]

Following up on our previous message we'd like to provide an update on the bounce tracking mitigation issue and its possible impact on partners participating in Chrome Facilitated Testing:

We've taken proactive steps to ensure Bounce Track Mitigation (BTM) functions correctly. We had identified cases where BTM incorrectly cleared storage related to Privacy Sandbox APIs. This primarily affected adtechs using their own domains for both legacy click tracking and new Privacy Sandbox API calls. BTM's impact is currently limited outside of the Mode-B Chrome-facilitated testing group, as it only activates in situations where third-party cookies are already blocked. Our code changes to protect Privacy Sandbox API storage are undergoing rigorous testing outside of Mode-B traffic.  We will re-enable BTM in the Mode-B environment once we've confirmed the fix resolves the issue.

We took swift action to address an issue impacting a small subset of users. On 1/8/2024, we disabled Bounce Track Mitigation (BTM) in Mode-B and notified the ecosystem via this blink-dev thread on 1/23/2024.  Our analysis shows less than 1% of users in the 3PCD Mode-B experiment were affected.  The current impact is minimal. Affected users have had time to accumulate new Privacy Sandbox API data, and the vast majority of users were unaffected, minimizing the likelihood of continued impact when BTM is re-enabled.

We plan to analyze how BTM could potentially interact with Privacy Sandbox storage better in the future.  We welcome any feedback on the W3C PrivacyCG issue.

[Ayuba Audu]

👋🏾 all,

Expanding on Adam Gertenbach’s excellent feedback, we’re wondering what options we have as a first-party web app, in the likely scenario that a third-party app doesn’t update their iframe/embeds, and we’re  past the deprecation trail (DT) period with third-party cookies phased out?

We’re concerned about the customer experience and reputation impact to our first-party app, hosting the third-party iframe. We’re hoping for some programmatic hooks or options we can leverage as a first-party, so we can provide some affordance to educate our customers.

For example, you could imagine similar to the Google new sign-in page notice or older Google chrome plug-in crash butter bar — see screenshots below, we show a similar notice for third-party iframes/embeds that are out of compliance or some other experience e.g., break glass, so we have an opportunity to customers and set expectations accordingly.

We wanted to call out this scenario and see if we missed options here we can leverage as this feature rolls out to all chrome users.

[Ben Kelly]

Thanks for the feedback Ayuba.  Can you please file this issue/request in the github repo here?

https://github.com/privacysandbox/privacy-sandbox-dev-support/issues

[Ayuba]

Many thanks, Ben — filed here!