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

Third-party Cookie Access Heuristics explainer #42

Open
amaliev opened this issue Oct 2, 2023 · 7 comments
Open

Third-party Cookie Access Heuristics explainer #42

amaliev opened this issue Oct 2, 2023 · 7 comments
Labels
interest: blink Implementer interest from Blink (e.g. Brave, Google/Chrome, Microsoft/Edge) interest: gecko Implementer interest from Gecko (e.g. Mozilla/Firefox, Cliqz)

Comments

@amaliev
Copy link

amaliev commented Oct 2, 2023

The web is moving to deprecate third-party cookies, and not every site developer will have the time and bandwidth to implement workarounds that mitigate user-facing breakage. In particular, flows involving authentication tokens from identity providers are a common web pattern that relies on third-party cookies.

There are established practices where a browser grants temporary storage access when a user satisfies a predefined flow. We have assessed a few existing heuristics for security and privacy concerns, and have decided to prototype the following two scenarios:

  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 for 30 days.
  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 storage access on the opener site for 15 minutes.

We presented this proposal at TPAC to generally positive feedback:
Explainer: https://github.com/amaliev/3pcd-exemption-heuristics/blob/main/explainer.md
Slides: https://docs.google.com/presentation/d/e/2PACX-1vQAjOEnKv3fyXchlYwO2JbPGrvaT7w3Q24ikac_1YWO8IhFJhPvaWBpXZPTMx0wYud1jgiM_TkVQIvw/pub

We appreciate any additional feedback, comments, or concerns from the broader community. Thank you!

@DavidScales
Copy link

This proposal seems like it would definitely help my use case (3P edTech embeds iframed into a top level 1P site), where I expect authentication to break with 3P cookie deprecation.

My current hangup on the Storage Access API, which seems to be the explicit invocation of this proposed behavior, is the user prompt, which is challenging for my user base (underage students with limited consent ability, admin-limited Chrome settings, and high risk of confusion).

At a minimum, it would give myself and my partners more time to evaluate APIs like CHIPS and FedCM, which are promising but still have limitations or still have features in flux.

I have two questions/concerns for the proposed heuristics:

  1. Do interactions with Identity Providers counts as top level interactions?
  2. If a developer implements SAA in Chrome today, and then this behavior is shipped, would the existing SAA code need modification? In other words, I'm assuming this change would work as a progressive enhancement to SAA implementations. For example document.hasStorageAccess(); would just return true if the browser grants implicit access and so devs are never unnecessarily raising the user prompt.

@martinthomson
Copy link

@johannhof are you still interested in having agenda time? How much time do you need?

@johannhof
Copy link
Member

@martinthomson I presented this at the last call. Apologies if I should have removed the label, I feel like someone else did that in the past.

We're happy to discuss again if there's interest / feedback from the community but we don't have any net new info from the last 2 weeks I think.

@johannhof
Copy link
Member

Also, I think it would be good to know what the chairs think about adoption of this proposal. What we're describing here is (partially) shipped by WebKit and Firefox, with Chrome implementing. I think this warrants adoption in some shared venue for continued discussion (there was some contention on the level of standardization this should receive but that's a different step from CG discussions).

@martinthomson martinthomson removed the agenda+ Request to add this issue to the agenda of our next telcon or F2F label Oct 26, 2023
@martinthomson
Copy link

Just off the cuff, I think that the question in front of us is whether formalizing these heuristics is something that people want to do. Implicit in the shipping of this feature is the idea that this is an area of differentiation between browsers, not standardization. I'm not sure that I personally agree with that conclusion, but we'd need to test it better. For me, I'd like to see explicit indications here from WebKit and Gecko before I was confident that we had agreement.

@bvandersloot-mozilla
Copy link

I said this in the discussion at the last meeting, but it is worth putting in writing here: formalizing these heuristics is a good idea, assuming that we are clear that they are a temporary measure until we have a good solution for the use cases they cover.

@martinthomson martinthomson added interest: gecko Implementer interest from Gecko (e.g. Mozilla/Firefox, Cliqz) interest: blink Implementer interest from Blink (e.g. Brave, Google/Chrome, Microsoft/Edge) labels Oct 26, 2023
@johannhof
Copy link
Member

@martinthomson ping on getting this moved into PCG given that there's two-implementor interest in incubation

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interest: blink Implementer interest from Blink (e.g. Brave, Google/Chrome, Microsoft/Edge) interest: gecko Implementer interest from Gecko (e.g. Mozilla/Firefox, Cliqz)
Projects
None yet
Development

No branches or pull requests

5 participants