Add Third-Party Cookie Deprecation Heuristics to Web Compat #253

amaliev · 2023-11-17T03:02:12Z

Proposal to add third-party cookie deprecation heuristics to the web compat spec.

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

Issue #254

At least two implementers are interested (and none opposed):
- Chrome
- Firefox
Tests are written and can be reviewed and commented upon at:
- https://github.com/web-platform-tests/wpt/tree/master/cookies/third-party-cookies
Implementation bugs are filed:
- Chromium: https://issues.chromium.org/u/2/issues/40282235
MDN issue is filed: …
The top of this comment includes a clear commit message to use.

Preview | Diff

karlcow

Hi @amaliev @miketaylr was there an issue opened for this?
Why is it opened in the first place on the webcompat spec?

Could you open an issue
Explain a bit more.

Thanks.

gsnedders · 2023-11-17T11:03:06Z

+1. It's unclear why Google believe this is the right venue for this. The Privacy CG, where most of Google's CHIPS proposal has been discussed, would be an obvious first port of call—other options include the Fetch Workstream (which does deal with integration with the Cookies spec today), or the HTTP WG.

I realise many of these groups are unlikely to take on a pure description of Chromium's current implementation, which seems to be what you want to do here. After all, standards groups deal in normative requirements, not descriptions of varying implementations. But that's true of the Compat workstream too, and we should still be focused on normative requirements.

So, two questions:

Is this the right venue? (And I'd suggest it is not.)
Should this be outlining a normative set of requirements about when third-party cookies are allowed, rather than documentation a single implementation's choices of implementation-defined behaviour? (And that's definitely going to require a lot more consensus building!)

wanderview · 2023-11-17T14:40:32Z

For context, this was discussed in the privacycg session at TPAC. Our original idea was it should go in html spec, but it was suggested somewhere else, like web compat spec, would be better to indicate its not intended to be a permanent feature of the web. We could investigate privacycg as well, but it's not clear where it would go in there either.

Should this be outlining a normative set of requirements about when third-party cookies are allowed, rather than documentation a single implementation's choices of implementation-defined behaviour? (And that's definitely going to require a lot more consensus building!)

As browsers are moving to blocking 3P cookies by default it seems relevant to specify when cookies are permitted due to web site actions. This is definitely web observable in default modes in browsers that have already shipped blocking 3P cookies. Why would default web observable behavior not be specified? Both firefox and safari ship these heuristics or something very similar, so this is definitely not a chrome-only thing.

We're happy to collaborate with other browser vendors on the appropriate place and shape of the spec, but just not specifying default web observable behavior does not seem like a good choice.

cc @miketaylr @johannhof

amaliev · 2023-11-17T15:13:20Z

I realize there was probably some confusion around the line:

The following spec represents the Chromium implementation of this feature.

This wasn't meant to imply this feature is Chrome-specific, but rather that each browser has a slightly different implementation. The explainer I added to the description goes into more detail, but similar heuristics have been shipped by Firefox (docs) and Safari (docs). We'll want to either establish a normative standard (we haven't had concrete discussions yet) or at least reflect the current differences in the spec (similarly to the UA section).

miketaylr · 2023-11-17T15:58:55Z

@amaliev can you go ahead and open an issue in this repo for discussion? Personally I think it's fine to document these heuristics here, even if they get moved to another spec down the road (we've done this multiple times in the past). But I agree that we don't want to just document the Chromium implementation and should aim for a normative interoperable ideal (and if there are UA-specific differences, we should file bugs against them and possible add non-normative notes describing them in the spec).

FWIW, the User-Agent section is unique in describing UA-specific differences. But the User-Agent string is unique (and terrible) in many ways. 🙈

amaliev · 2023-11-17T17:08:08Z

SGTM. Sorry for the trouble, I will open an issue and move these changes into a separate repo for the time being.

karlcow · 2023-11-20T01:52:52Z

SGTM. Sorry for the trouble, I will open an issue and move these changes into a separate repo for the time being.

Thanks. An issue has been opened

annevk · 2023-11-20T12:29:06Z

I don't think this necessarily had to be closed @amaliev. One thing I'd recommend is to always include the pull request template to avoid any misunderstandings. Perhaps you created this through CLI and therefore it got excluded. That's unfortunately a shortcoming of this process.

johannhof

A few early thoughts

compatibility.bs

johannhof · 2023-12-04T21:41:25Z

compatibility.bs

+    </dl>
+
+</div>
+


Can you add a description of how this impacts the (admittedly underspecified) cookie computation in Fetch like in https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations-network-cookie-write-monkey-patch

Added a new section with a TODO for now. Will update soon.

compatibility.bs

johannhof · 2023-12-04T22:00:12Z

compatibility.bs

+1. If |origin| is an [=opaque origin=] then abort these steps.
+1. Let |site| be the result of running [=obtain a site=] given |origin|.
+1. Let |host| be |site|'s [=host=].
+1. [=Grant access for heuristics=] given:


Let's file an issue and add a XXX that links to that issue here about potentially restricting cross-site iframes from triggering this heuristic.

Filed an issue in my personal repo, since it has the explainer: amaliev/3pcd-exemption-heuristics#3. Let me know if I should move it to the web compat repo.

If this is to be merged in the actual Web Compat standard, then yeah this issue should probably move over to that repo. But maybe Mike can make the final call, since he's the editor here.

I'm still not sure this should be in the compat spec.

compatibility.bs

domfarolino · 2023-12-04T23:30:51Z

compatibility.bs

+  1. Let |bounceHost| be |bounceSite|'s [=host=].
+  1. If |bounceHost| [=host/equals=] |firstPartyHost|, [=iteration/continue=].
+  <!-- TODO: check if |bounceUrl| has a transient activation. This will require patching bounce tracking record. -->
+  <!-- TODO: check A-B-A user flow. This will require traversing the navigable's history. -->


So the redirects aren't going to be stored in session history I believe (i.e., visit https://origin-a.glitch.me/redirect?location=https://example.com and note what happens when you click the back button). So you won't want the navigable's session history. You'll instead want to grab the navigation params's request's URL list, which is where redirect URLs are stored: https://fetch.spec.whatwg.org/#ref-for-concept-request-url-list%E2%91%A4

compatibility.bs

domfarolino · 2023-12-06T19:57:54Z

compatibility.bs

+      for: browsing context
+        text: is popup
+        text: opener origin at creation
+urlPrefix: https://privacycg.github.io/nav-tracking-mitigations/


This might be a tough sell for a WHATWG standard to accept. If this doesn't fly then maybe we could move this PR to a more local spec? Curious what @miketaylr would think.

The link targets here are an extra field on HTML's top-level traversable. Part of merging this PR might be to merge that field into HTML. (Merging it into Compat is also possible, but I believe the bounce tracking record is intended to be more permanent than the heuristics in this PR.)

compatibility.bs

bvandersloot-mozilla · 2024-10-17T19:07:22Z

compatibility.bs

+1. Let |firstPartySite| be the result of running [=obtain a site=] given |firstPartyOrigin|.
+1. Let |bounceTrackingRecord| be |navigable|'s [=navigable/top-level traversable=]'s
+    [=top-level traversable/bounce tracking record=].
+1. [=list/For each=] |bounceUrl| in |bounceTrackingRecord|'s [=bounce tracking record/bounce set=]:


Does chrome's implementation follow this? If you use the bounce record, you are relying on the user going through the entire "auth" page in <10 seconds, since the records are purged after 10 seconds on one page.

Ah, maybe I misunderstood. The extended navigation here is just the B->A to end it? and that last TODO is looking for the A->B in the same navigatable's history to complete the A->B->A?

Yes, the second comment is correct. Generally the flow goes:

User navigates from Site A to Site B

User interacts with Site B to authenticate

User is bounced (possibly through other sites) back to Site A

And we are running this algorithm after the final navigation concludes.

I realized that in this case per the nav tracking spec, Site B would be the bounce record's initial host rather than in the bounce set, so I updated the spec to consider the initial host as well.

Okay, that makes more sense.

If that is the case, I don't think that Site B would be in the user activation.

I think when you were patching the bounce tracking proposal, you should have also added initialHost to the user activation set in the If navigable’s [bounce tracking record](https://privacycg.github.io/nav-tracking-mitigations/#top-level-traversable-bounce-tracking-record) is null: step (currently 6 in process navigation start for bounce tracking).

Thanks for the catch. I've updated the nav tracking spec to add the initial host to the user activation set in both cases.

bvandersloot-mozilla · 2024-10-18T12:46:39Z

compatibility.bs

+
+<h3 id="sa-heuristics-redirect">Redirect Heuristic</h3>
+
+Insert the following steps in [[!HTML]]'s <a spec="html">load a document</a> algorithm, before the


This probably isn't what you want. Most documents (all text/html documents among them) don't reach this step.

Thanks for the callout, I've updated this to point to the start of the "load a document" algorithm.

Generally we prefer to call any end-of-extended-navigation algorithms after the navigation "commits" (which is a standard term in Chrome and MDN but not in the HTML spec). This is to avoid spurious calls in case a navigation aborts, e.g. on loading an invalid resource. However, the structure of the "load a document" algorithm makes it difficult to patch a step at the end of all branches, after the load completes. Anyway, in this case the effect of allowing uncommitted navigations is minor (especially due to the A-B-A requirement below).

bvandersloot-mozilla · 2024-10-22T16:19:30Z

@amaliev: do you have any update on those questions? I'm looking at implementing this in Firefox and there are a few issues that keep this from working.

amaliev

@bvandersloot-mozilla Sorry for the delay, we had shelved this PR for a while. Addressed the questions inline.

compatibility.bs

amaliev · 2024-10-22T21:28:43Z

compatibility.bs

+1. Let |firstPartySite| be the result of running [=obtain a site=] given |firstPartyOrigin|.
+1. Let |bounceTrackingRecord| be |navigable|'s [=navigable/top-level traversable=]'s
+    [=top-level traversable/bounce tracking record=].
+1. [=list/For each=] |bounceUrl| in |bounceTrackingRecord|'s [=bounce tracking record/bounce set=]:


Yes, the second comment is correct. Generally the flow goes:

User navigates from Site A to Site B

User interacts with Site B to authenticate

User is bounced (possibly through other sites) back to Site A

And we are running this algorithm after the final navigation concludes.

I realized that in this case per the nav tracking spec, Site B would be the bounce record's initial host rather than in the bounce set, so I updated the spec to consider the initial host as well.

amaliev · 2024-10-22T22:14:14Z

compatibility.bs

+
+<h3 id="sa-heuristics-redirect">Redirect Heuristic</h3>
+
+Insert the following steps in [[!HTML]]'s <a spec="html">load a document</a> algorithm, before the


Thanks for the callout, I've updated this to point to the start of the "load a document" algorithm.

Generally we prefer to call any end-of-extended-navigation algorithms after the navigation "commits" (which is a standard term in Chrome and MDN but not in the HTML spec). This is to avoid spurious calls in case a navigation aborts, e.g. on loading an invalid resource. However, the structure of the "load a document" algorithm makes it difficult to patch a step at the end of all branches, after the load completes. Anyway, in this case the effect of allowing uncommitted navigations is minor (especially due to the A-B-A requirement below).

karlcow reviewed Nov 17, 2023

View reviewed changes

amaliev closed this Nov 17, 2023

amaliev mentioned this pull request Nov 18, 2023

Consider moving Storage Access Heuristics spec into web compat spec #254

Open

annevk reopened this Nov 20, 2023

amaliev mentioned this pull request Nov 29, 2023

TAG spec review of Storage Access Heuristics w3ctag/design-reviews#919

Closed

1 task

johannhof reviewed Dec 4, 2023

View reviewed changes

domfarolino reviewed Dec 4, 2023

View reviewed changes

compatibility.bs Outdated Show resolved Hide resolved

domfarolino reviewed Dec 6, 2023

View reviewed changes

This comment was marked as spam.

Sign in to view

This was referenced Dec 28, 2023

Add WPT for popup heuristic web-platform-tests/wpt#43809

Closed

Add user activation set to bounce tracking record privacycg/nav-tracking-mitigations#70

Merged

bvandersloot-mozilla reviewed Oct 17, 2024

View reviewed changes

compatibility.bs Outdated Show resolved Hide resolved

bvandersloot-mozilla reviewed Oct 17, 2024

View reviewed changes

bvandersloot-mozilla reviewed Oct 18, 2024

View reviewed changes

amaliev commented Oct 22, 2024

View reviewed changes

amaliev force-pushed the main branch from be23a0e to 84af521 Compare October 23, 2024 18:45

amaliev added 5 commits October 23, 2024 18:50

heuristics spec start

a414a12

heuristics spec

f6e492d

heuristics spec

71b7843

finish first draft

c0506bb

intro wording changes

5d58b64

domfarolino and others added 7 commits October 23, 2024 18:50

Reference top-level traversable correctly

c875c3b

User activation reference

3b10ef8

Opener origin at creation time

c56b58e

Bounce tracking traversable

bfbe0a8

Use global map instead of permissions API, plus various fixes

a8c9ecf

address redirect comments

fd75560

Update monkey patch location in Load a Document

6c927ab

amaliev force-pushed the main branch from 84af521 to 6c927ab Compare October 23, 2024 18:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Third-Party Cookie Deprecation Heuristics to Web Compat #253

Add Third-Party Cookie Deprecation Heuristics to Web Compat #253

amaliev commented Nov 17, 2023 •

edited by pr-preview bot

Loading

karlcow left a comment

gsnedders commented Nov 17, 2023

wanderview commented Nov 17, 2023

amaliev commented Nov 17, 2023

miketaylr commented Nov 17, 2023

amaliev commented Nov 17, 2023

karlcow commented Nov 20, 2023

annevk commented Nov 20, 2023

johannhof left a comment

johannhof Dec 4, 2023

amaliev Dec 8, 2023

johannhof Dec 4, 2023

amaliev Dec 8, 2023 •

edited

Loading

domfarolino Dec 27, 2023

karlcow Dec 28, 2023

domfarolino Dec 4, 2023

domfarolino Dec 6, 2023

jyasskin Jan 16, 2024

This comment was marked as spam.

bvandersloot-mozilla Oct 17, 2024

bvandersloot-mozilla Oct 17, 2024

amaliev Oct 22, 2024

bvandersloot-mozilla Oct 23, 2024

amaliev Oct 23, 2024

bvandersloot-mozilla Oct 18, 2024

amaliev Oct 22, 2024

bvandersloot-mozilla commented Oct 22, 2024

amaliev left a comment

amaliev Oct 22, 2024

amaliev Oct 22, 2024


		<h3 id="sa-heuristics-redirect">Redirect Heuristic</h3>

		Insert the following steps in [[!HTML]]'s <a spec="html">load a document</a> algorithm, before the

		</dl>

		</div>

Add Third-Party Cookie Deprecation Heuristics to Web Compat #253

Are you sure you want to change the base?

Add Third-Party Cookie Deprecation Heuristics to Web Compat #253

Conversation

amaliev commented Nov 17, 2023 • edited by pr-preview bot Loading

karlcow left a comment

Choose a reason for hiding this comment

gsnedders commented Nov 17, 2023

wanderview commented Nov 17, 2023

amaliev commented Nov 17, 2023

miketaylr commented Nov 17, 2023

amaliev commented Nov 17, 2023

karlcow commented Nov 20, 2023

annevk commented Nov 20, 2023

johannhof left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amaliev Dec 8, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

This comment was marked as spam.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bvandersloot-mozilla commented Oct 22, 2024

amaliev left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

amaliev commented Nov 17, 2023 •

edited by pr-preview bot

Loading

amaliev Dec 8, 2023 •

edited

Loading