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 On 2023-12-06 17:11, Yoav Weiss wrote:
LGTM3 On Tuesday, December 5, 2023 at 6:53:30 PM UTC+1 Rick Byers wrote: 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. On Tue, Dec 5, 2023 at 12:40 PM Mike Taylor <[email protected]> wrote: 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...). On 12/4/23 5:55 PM, 'Anton Maliev' via blink-dev wrote:-- You received this message because you are subscribed to theContact emails [email protected] <mailto:[email protected]> [email protected] <mailto:[email protected]> [email protected] <mailto:[email protected]> [email protected] <mailto:[email protected]> Explainer https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md <https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md> Specification Pull request: https://github.com/whatwg/compat/pull/253 <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 <http://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 <http://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 <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 <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 <https://groups.google.com/a/chromium.org/g/Blink-dev/c/Eeh2pE0DRaE>-- You received this message because you are subscribed to theGoogle Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKGZiuJmtK9N9fQs0EUbYbasG_c04TSoQ%3DmMwK9Zu-ixnKr7LA%40mail.gmail.com?utm_medium=email&utm_source=footer>.Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>. 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 <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/cb88025d-ebe8-43e2-a8e9-0bb51ed0b3a1%40chromium.org?utm_medium=email&utm_source=footer>. --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/5a843f3a-30a9-41a8-b0bb-f0bebfb2a01en%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5a843f3a-30a9-41a8-b0bb-f0bebfb2a01en%40chromium.org?utm_medium=email&utm_source=footer>.
-- 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/3b3b5200-f03c-4a24-b60c-84770581dc5e%40gmail.com.
