Contact emails [email protected]
[email protected] [email protected] [email protected] Explainer https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md Specification Pull request: https://github.com/whatwg/compat/pull/253 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 <https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_Access_Policy#automatic_storage_access_upon_interaction>) and Safari (docs <https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/#:~:text=Temporary%20Compatibility%20Fix%3A%20Automatic%20Storage%20Access%20for%20Popups> ). These heuristics will include: 1. 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. 1. Use cases: identity provider login, payments processing, etc. 2. Example: nintendo.de (bug <https://issuetracker.google.com/268390722>) 2. 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. 1. Use cases: identity provider login, etc. 2. Example: pixnet.net (bug <https://issuetracker.google.com/281701307>) See the explainer <https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md> 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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EHeuristics> 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 <https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md#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 <https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/#:~:text=Temporary%20Compatibility%20Fix%3A%20Automatic%20Storage%20Access%20for%20Popups>) and Firefox has implemented similar popup and redirect heuristics (docs <https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_Access_Policy#automatic_storage_access_upon_interaction>). 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 discussionsIntent to prototype: https://groups.google.com/a/chromium.org/g/Blink-dev/c/Eeh2pE0DRaE -- 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 [email protected]. 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.
