Contact emails

amal...@chromium.org

rtarp...@chromium.org

wanderv...@chromium.org

Explainer

https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md

Specification

TBD

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 unsupported. 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>
).

Possible heuristics include, but are not limited to:

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


See the explainer (linked above) for details on how these heuristics were
decided and how we intend to approach the prototyping. We will perform
additional analysis before committing to the precise behavior in the
heuristics above. We also intend to eventually retire these heuristics as
alternatives become widely used, subject to further feasibility analysis.

Blink component

Privacy>Heuristics
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Privacy%3EHeuristics>

Motivation

The web ecosystem currently includes established practices where temporary
third-party cookie access is granted. These include login flows that rely
on an Identity Provider accessing cookies in a third-party context.
Third-party cookie deprecation poses a risk of user-facing breakage, and
while there are some existing proposals to mitigate the damage (such as the
FedCM and Storage Access APIs), most of them require the support of site
developers, and more time and bandwidth than they may have at their
disposal. This proposal identifies automated heuristics that catch
legitimate use cases with high precision, so that temporary storage access
may be granted without the need for immediate developer intervention,
allowing developers time to implement solutions that do not rely on
third-party cookies.

Initial public proposal

N/A

Search tags

third-party cookie deprecation
<https://chromestatus.com/feature/5133113939722240>

TAG review

TBD

TAG review status

Not Started

Risks

There is a risk of shipping overly lenient heuristics, which would either
immediately exempt illegitimate use cases, or allow them to easily work
around the third-party cookie deprecation. There are also risks of bad
actors abusing these heuristics to leak user history data, or to exploit
credentialed access requests. We look forward to working with other
browsers in the community to perform additional analysis, narrow the
heuristics, and align on shared principles before committing these.

Interoperability and Compatibility

Other browsers have already shipped similar heuristics that give storage
access grants in limited scenarios. 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>).
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>).
Our goal is to align closely where possible with these heuristics, for
developers to have consistent expectations around cross-platform
compatibility.

Debuggability

N/A

Is this feature fully tested by web-platform-tests
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
?

No

Flag name

(Tentatively)

base::features::ThirdPartyCookiePopupCurrentInteractionHeuristic

base::features::ThirdPartyCookiePopupPastInteractionHeuristic

base::features::ThirdPartyCookieRedirectHeuristic

Requires code in //chrome?

Yes, code is currently needed in //chrome to detect heuristics and create
storage access grants. Embedders can still enable/disable 3PCs without this
code. We have a goal to move some dependencies to //content for this
feature.

Tracking bug

https://crbug.com/1484324

Link to entry on the Chrome Platform Status

TBD

-- 
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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKGZiuKON_tVysrEgcaPtLa8D%2BdhNqLQkv-EVwQwZj5aiuWwmg%40mail.gmail.com.

Reply via email to