Intent to Ship: Third-party cookie deprecation exemption heuristics

Anton Maliev

未読、

2023/12/04 17:55:242023/12/04

To: blin...@chromium.org

Summary

This proposal examines a heuristics-based pattern of allowing temporary third-party cookie access in limited scenarios, which would mitigate site breakages after third-party cookies are blocked by default in Chrome. These scenarios are tightly scoped and build on similar work from other browsers such as Firefox (docs) and Safari (docs).

These heuristics will include:

When a third party is loaded in a popup, after possible redirects, and the third party receives user interaction, the third party receives storage access on the opener site.

Use cases: identity provider login, payments processing, etc.
Example: nintendo.de (bug)

When a first party redirects to a third party, the third party receives a user interaction, and navigates back to the first party, the third party receives short-term storage access on the opener site.

Use cases: identity provider login, etc.
Example: pixnet.net (bug)

See the explainer for details on background, additional considerations and our approach to prototyping. Aligned with what other browsers have indicated, we intend to eventually retire these heuristics as alternative solutions become widely used, subject to further feasibility analysis.

Blink component

Privacy>Heuristics

TAG review

https://github.com/w3ctag/design-reviews/issues/919

TAG review status

Pending

Risks

There is a risk of shipping overly lenient heuristics, which may introduce unintended privacy and security risks. There are also risks of bad actors abusing these heuristics to leak user history data, or to exploit credentialed access requests. The explainer explores these privacy and security considerations; here is a summary of how our implementation is designed to mitigate these risks:

The heuristics are limited to requiring a concurrent interaction in both the popup and redirect case. (As opposed to accepting a prior user interaction on the same site.) This provides a stronger signal of user intent and reduces the privacy risk of leaking user interaction history via cookie behavior.
The storage access grant durations are gated by flags, which can be changed and rolled out within 24-48 hours.

In Chrome, users will also have the ability to turn off heuristics in Settings.

We look forward to working with other browsers in the community to perform additional analysis and possibly narrow the heuristics further.

Interoperability and Compatibility

Our goal is to align closely where possible with Other browsers that have already shipped similar heuristics that give storage access grants in limited scenarios, e.g., Safari has implemented a similar popup heuristic (docs) and Firefox has implemented similar popup and redirect heuristics (docs). In this manner, developers can have consistent expectations around cross-platform compatibility.

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

No

Debuggability

N/A

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

All except WebView. (Third-party cookie deprecation launches don’t include WebView.)

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

Web Platform Tests are in progress, and will be checked in by the week of 12/11.

Flag name on chrome://flags

Third-party Cookie Grants Heuristics Testing

chrome://flags/#tpcd-heuristics-grants

Finch feature name

TpcdHeuristicsGrants

Non-finch justification

N/A

Requires code in //chrome?

True

The code for awarding and reading grants is in //components. Some code is necessary in //chrome due to dependencies on e.g. the DIPS database.

Estimated milestones

Shipping to Stable M120 on 12/14

Anticipated spec changes

There are a few open questions around the details of the scenarios for which grants should be awarded. For instance:

Should grants only be created when there is a concurrent interaction on the popup/redirect domain? Or would a past interaction also allow storage access?
Does the popup heuristic behave differently depending on the source of the iframe that initiates the popup?
Does the redirect heuristic behave differently depending on the user's navigation flow?

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5181771549507584

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/g/Blink-dev/c/Eeh2pE0DRaE

Mike Taylor

未読、

2023/12/05 12:40:352023/12/05

To: Anton Maliev、blin...@chromium.org

I see this as a critical web compatibility intervention, so LGTM1.

It seems like there is some disagreement about spec venue (compat vs fetch/html), but I don't think we need to block on landing given the other browsers shipped their heuristics without specifying in any standards venue. Thanks for doing the work to unify these and push for interop.

And good luck on removing them one day (one can dream...).

--
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/CAKGZiuJmtK9N9fQs0EUbYbasG_c04TSoQ%3DmMwK9Zu-ixnKr7LA%40mail.gmail.com.

Rick Byers

未読、

2023/12/05 12:53:302023/12/05

To: Mike Taylor、Anton Maliev、blin...@chromium.org

LGTM2

Thank you for putting the extra rigor and effort into trying to specify and align on this behavior, rather than just copy the precedent set by the other two engines in relying on non-standards-track heuristics! It's exactly in these messy real-world examples of web behavior that our principles around real interoperability are tested. Also +1 to not worrying too much about venue at this stage of paying back technical debt incurred by other engines. I've always seen the webcompat spec as the place for pragmatically documenting what the web really depends on when the "right" group was too idealistic to want to be accountable for the reality. If we can graduate some or all of this out of web compat into better homes, then great! But if the PR doesn't land in webcompat soon (before the end of the year?) then we should explore other lightweight temporary homes.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb88025d-ebe8-43e2-a8e9-0bb51ed0b3a1%40chromium.org.

Yoav Weiss

未読、

2023/12/06 11:11:502023/12/06

To: blink-dev、Rick Byers、ama...@google.com、blin...@chromium.org、Mike Taylor

LGTM3

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

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

--
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+unsubscribe@chromium.org.

Daniel Bratell

未読、

2023/12/06 11:21:572023/12/06

To: Yoav Weiss、blink-dev、Rick Byers、ama...@google.com、Mike Taylor

While this is approved, I do have a followup question about:

> we intend to eventually retire these heuristics as alternative solutions become widely used, subject to further feasibility analysis.

In many other plans there have been dates or milestones mentioned, and even though they have not always been achievable, they have acted as a clear signal that something will happen.

In comparison this sounds open ended, and almost defeatist. Would it be good to set a target end date on this as well?

/Daniel

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/5a843f3a-30a9-41a8-b0bb-f0bebfb2a01en%40chromium.org.

Ben Kelly

未読、

2023/12/06 13:49:352023/12/06

To: Daniel Bratell、Yoav Weiss、blink-dev、Rick Byers、ama...@google.com、Mike Taylor

This needs to be a discussion with the other browsers. The remedies and timescale will also depend on how things shake out during the third-party cookie deprecation over the next year. These are the reasons we have not set an end date right now. Any date would be somewhat arbitrary pending additional information and discussion with other browsers.