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] <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 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.
