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.
