Intent to Prototype: Third-party cookie deprecation exemption heuristics
Anton Maliev
Contact emails
Explainer
https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md
Specification
TBD
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 unsupported. These scenarios are tightly scoped and build on similar work from other browsers such as Firefox (docs) and Safari (docs).
Possible heuristics include, but are not limited to:
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.
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.
See the explainer (linked above) for details on how these heuristics were decided and how we intend to approach the prototyping. We will perform additional analysis before committing to the precise behavior in the heuristics above. We also intend to eventually retire these heuristics as alternatives become widely used, subject to further feasibility analysis.
Blink component
Motivation
The web ecosystem currently includes established practices where temporary third-party cookie access is granted. These include login flows that rely on an Identity Provider accessing cookies in a third-party context. Third-party cookie deprecation poses a risk of user-facing breakage, and while there are some existing proposals to mitigate the damage (such as the FedCM and Storage Access APIs), most of them require the support of site developers, and more time and bandwidth than they may have at their disposal. This proposal identifies automated heuristics that catch legitimate use cases with high precision, so that temporary storage access may be granted without the need for immediate developer intervention, allowing developers time to implement solutions that do not rely on third-party cookies.
Initial public proposal
N/A
Search tags
third-party cookie deprecation
TAG review
TBD
TAG review status
Not Started
Risks
There is a risk of shipping overly lenient heuristics, which would either immediately exempt illegitimate use cases, or allow them to easily work around the third-party cookie deprecation. There are also risks of bad actors abusing these heuristics to leak user history data, or to exploit credentialed access requests. We look forward to working with other browsers in the community to perform additional analysis, narrow the heuristics, and align on shared principles before committing these.
Interoperability and Compatibility
Other browsers have already shipped similar heuristics that give storage access grants in limited scenarios. Safari has implemented a similar popup heuristic (docs). Firefox has implemented similar popup and redirect heuristics (docs). Our goal is to align closely where possible with these heuristics, for developers to have consistent expectations around cross-platform compatibility.
Debuggability
N/A
Is this feature fully tested by web-platform-tests?
No
Flag name
(Tentatively)
base::features::ThirdPartyCookiePopupCurrentInteractionHeuristic
base::features::ThirdPartyCookiePopupPastInteractionHeuristic
base::features::ThirdPartyCookieRedirectHeuristic
Requires code in //chrome?
Yes, code is currently needed in //chrome to detect heuristics and create storage access grants. Embedders can still enable/disable 3PCs without this code. We have a goal to move some dependencies to //content for this feature.
Tracking bug
Link to entry on the Chrome Platform Status
TBD