#919: TAG spec review of Storage Access Heuristics

Visit on Github.

Opened Nov 29, 2023

こんにちは TAG-さん!

I'm requesting a TAG review of Storage Access Heuristics.

The web is moving to deprecate third-party cookies, and not every site developer will have the time and bandwidth to implement workarounds to mitigate user-facing breakage. In particular, flows involving authentication tokens from identity providers are a common web pattern that relies on third-party cookies to operate. This explainer outlines a proposal for granting temporary storage access when a user satisfies certain predefined flows, chosen to balance web compatibility efforts and security/privacy goals.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: We’re planning to enable this in Chrome M120 (by 12/14/2023) for the Third-Party Cookie Deprecation.
  • The group where the work on this specification is currently being done: Web compat and PrivacyCG.
  • The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): WHATWG / Web compat.
  • Major unresolved issues with or opposition to this specification: While other browsers ship these heuristics, there is some lack of clarity regarding to what extent we’d like to specify / standardize them. All involved stakeholders intend for them to be temporary, which is why we opted for specification in the Web Compat spec vs. standardization into HTML.
  • This work is being funded by: Google

You should also know that… N/A

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Discussions

2023-12-18

Minutes

Dan: meta topic of heuristics... we keep hearing that browsers which have deprecated 3p cookies have heuristics so things continue to work, eg. exceptions for youtube. The other area we've heard about heuristics a lot are to do with autofill. These are the hidden functionalities of browsers that are not specified and work differently. It works badly eg. when it tries to autofill a password when what I need is a one-time code. Maybe browsers need to coordinate more on heuristics?

Amy: they might not want to coordinate because some of these heuristics might differentiate browsers... but I don't know

Yves: reminds me of the different heuristics in private mode that are different between different browsers...

Dan: We had a positive review of storage access

Amy: yes but that was because it was multi-stakeholder but are these heuristics multi-stakeholder.

Matthew: There's some info that other broewsers do implement - on MDN. Firefox "includes some heuristics". But Firefox says "feature will be removed at some point in future"

Amy: Wonder if what Firefox has is actually related to this effort to standardize.

Amy: goals - evaluate existing browser heuristics...

Dan: they did evaluate?

Amy: yeah... Might be the right direction...

Dan: all of the spec primary contacts are google...

Amy: yes but fairly early... Want to spend some more time on this... find out how aligned this is with other browsers...

leave until plenary - Amy to do a thorough read

Matthew: "other browsers have implemented some approach to this"...

2024-01-15

Minutes

Dan: this is about mitigation against removal of third party cookies... "unintended impacts" - authentication flows.

Hadley: isn't this trying to solve the same problem as FedCM

Dan: I think so when it comes to authentication.. there's a lot of authentication flows out there already and not all of them are going to immediately embrace fedcm, so it's about making sure things don't break that people are relying on, maybe

Hadley: so we need to be concerned about not settling for the interim solution when people should be moving to the permanent solution. That's a pattern we see often.

Dan: we see the nintendo case pop up as use case 1, which we've already heard about with another proposal.. requestStorageAccessFor?

Amy: is there a path to deprecation, if this is a temporary thing?

Dan: let's ask.. and ask if the design principle for this that they should be implementing the most minimal heuristics possible. I don't see that overriding design goal in this doc. They talk about minimising user facing breakage, and avoiding a solution that is too leniant or cna be manipulated, but they dn't talk about minimal set of heuristics - I feel that should be a design goal. They'd say all browsers have heuristics..

Amy: we talked about one where chrome brought a proposal to standardise on the heuristics, but knowing all implementers do this, didn't we ought to start from a place of all implementers bringing what they are currently doing to standardise, rather than start on what chrome is doing?

Hadley: they're already in a multistakeholder forum in webcompat and privacycg

Dan: slightly concerned about what they list as key pieces of multistakeholder review or discussion - safari docs for this feature, are they pointing to something that is for webkit and is their heuristics? it's documentation of webkit's heuristics, but not a documentation of or indication that webkit is happy to work on standardising these heuristics?

Hadley: looks like it might be that

Matthew: the safari docs say it's a temporary compatibility fix.. interesting sign that they expect to remove it

Hadley: also the intelligent tracking 2.0 document is from 2018.. I'd be shocked if they haven't done any work on it in 5 years

Matthew: there's a link to a recent blog post to talk about improvements..

Amy: in chrome status it mentions users turning heuristics off - does that mean 3p cookies are renabled, or the breaking cases are present? Also, just checking, this exists as an alternative to 3p cookie access right? Not in conjunction with 3p cookies still being on

Hadley: yes

<blockquote> Hi @amaliev, @wanderview - thanks for sending this our way.

It appears that for this effort to work there needs to be cross-implementer consensus. You've highlighted multi-stakeholder review/discussion - however it looks like these are documenting the heuristics of other engines - establishing that these other engines have heuristics, yes, but is there a consensus on agreeing common heuristics in the Privacy CG and WebCompat efforts?

It seems like a design goal for this work should be to implement the most minimal set of heuristics possible in order to achieve the other goals. Would you agree?

Is there a deprecation plan for the heuristics? In the case of authentication, for example, there could be a stated goal to remove heuristics as sites move to FedCM.

In the intent to ship, you state that users can turn off heuristics in settings - does that mean that third party cookies would be re-enabled, or would that mean heuristics off and third party cookies off as well? It would be helpful to have language about that in the explainer.

</blockquote>

posted

2024-02-05

Minutes

Dan: proposes close. polls TAG in chat

Martin: (via chat): +1

Matthew: the changes in the explainer look good. In user signals & preferences section it talks about how Firefox does it. so they have listened to the feedback.

Tess (via chat): +1

Amy (via chat): +1

We held additional discussions in chat and agreed to close this with a positive review, emphasizing the continued need for cross-browser engagement and consensus.