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.
On Wed, Dec 6, 2023 at 11:21 AM Daniel Bratell <[email protected]> wrote: > 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: >>> >>> 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 discussions Intent 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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKGZiuJmtK9N9fQs0EUbYbasG_c04TSoQ%3DmMwK9Zu-ixnKr7LA%40mail.gmail.com?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/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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b3b5200-f03c-4a24-b60c-84770581dc5e%40gmail.com?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/CAK7rkMhdHJtEizvbBO0SAYvriRCAqZmd7SBweAnTr7_gGkRYkQ%40mail.gmail.com.
