Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TAG spec review of Storage Access Heuristics #919

Closed
1 task done
amaliev opened this issue Nov 29, 2023 · 6 comments
Closed
1 task done

TAG spec review of Storage Access Heuristics #919

amaliev opened this issue Nov 29, 2023 · 6 comments
Assignees
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Progress: review complete Provenance: Privacy Sandbox Resolution: satisfied The TAG is satisfied with this design Topic: privacy

Comments

@amaliev
Copy link

amaliev commented 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

@torgo torgo added Topic: privacy privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Provenance: Privacy Sandbox and removed Progress: untriaged labels Dec 6, 2023
@torgo torgo added this to the 2023-12-18-week milestone Dec 17, 2023
@torgo
Copy link
Member

torgo commented Dec 19, 2023

#807

@wanderview
Copy link

#807

Is there some additional context or meaning to this reply. Sorry if I'm misunderstanding, but more explanation would be helpful to me. Thank you.

@torgo
Copy link
Member

torgo commented Jan 8, 2024

Sorry for the lack of context @wanderview - that was more intended as a note-to-self as part of the discussion we held on 12-18. We'll be re-addressing during this week's calls.

@torgo
Copy link
Member

torgo commented Jan 16, 2024

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.

@amaliev
Copy link
Author

amaliev commented Jan 16, 2024

Hi @torgo , thanks for the feedback! Responding inline below.

is there a consensus on agreeing to common heuristics in the Privacy CG and WebCompat efforts?

We brought this to Privacy CG at TPAC and got a consensus on the general need for these heuristics. The details are being worked out in the WebCompat spec in whatwg/compat#253. We have tried to align with other browsers as much as possible, and the few changes we made were to make the heuristics more restrictive, in response to privacy/security reviews internally. We plan to continue talking with other browsers both on the heuristics and on how to reduce their usage on the web.

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.

Agreed. I have added this as an explicit goal in the explainer.

Is there a deprecation plan for the heuristics?

I have also clarified this as a long-term goal in the explainer. Other browsers have indicated that they want to deprecate their versions of the heuristics, but do not have specific plans we could align with yet. Deciding on a deprecation timeline will require future collaboration with other browsers and site devs.

does that mean that third party cookies would be re-enabled, or would that mean heuristics off and third party cookies off as well?

The explainer covers this in the User signals and preferences section. Turning off heuristics would mean third-party cookies are blocked in these cases. (Although most browsers also have user settings for re-enabling cookies in case of breakage.)

@torgo torgo modified the milestones: 2024-01-15-week, 2024-02-05-week Feb 4, 2024
@torgo torgo added the Progress: propose closing we think it should be closed but are waiting on some feedback or consensus label Feb 7, 2024
@torgo
Copy link
Member

torgo commented Feb 9, 2024

Hi @amaliev - this looks good to us and we're happy to see this move forward. Please continue to coordinate through the privacyCG and ensure there is mutli-browser consensus.

@torgo torgo closed this as completed Feb 9, 2024
@torgo torgo added Progress: review complete Resolution: satisfied The TAG is satisfied with this design and removed Progress: propose closing we think it should be closed but are waiting on some feedback or consensus labels Feb 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Progress: review complete Provenance: Privacy Sandbox Resolution: satisfied The TAG is satisfied with this design Topic: privacy
Projects
None yet
Development

No branches or pull requests

5 participants