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

Standardizing Security Semantics of Cross-Site Cookies #904

Closed
1 task done
johannhof opened this issue Sep 28, 2023 · 4 comments
Closed
1 task done

Standardizing Security Semantics of Cross-Site Cookies #904

johannhof opened this issue Sep 28, 2023 · 4 comments
Assignees
Labels
privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. Review type: CG early review An early review of general direction from a Community Group Venue: WebAppSec WG

Comments

@johannhof
Copy link

Guten TAG!

I'm requesting a TAG review of our proposal to align browsers on a secure and consistent model for blocking cross-site cookies.

While there's relative consensus that "third-party" (or cross-site) cookie blocking is desirable for user privacy, the details are entirely unspecified at the moment. As a major pain point, it's unclear how cross-site cookie blocking interacts with the SameSite cookie attribute, which is a definition of "cross-site" that takes into account not simply the plain relationship of an embed with its top-level browsing context, but also various other security-related factors such as the presence of a cross-site ancestor, the request methods and top-level redirects.

We have proposed a resolution to this problem, arguing that cross-site cookie blocking should indeed prevent cookies being loaded in most SameSite=None type scenarios going forward. Specifically, we make the assertion that the SameSite attribute as-is does not sufficiently protect sites from attacks given the lack of granular control for developers.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • The group where the incubation/design work on this is being done (or is intended to be done in the future): WebAppSec
  • The group where standardization of this work is intended to be done ("unknown" if not known): WebAppSec
  • Existing major pieces of multi-stakeholder review or discussion of this design:

Mozilla and Apple deferred to officially comment on this document until it moves under WebAppSec.

  • Major unresolved issues with or opposition to this design: The standardization of SameSite=Lax as the default in the Cookies RFC is more or less stalled by discussion over temporary web compat measures, which is some feedback we've repeatedly heard in relation to our document. We agree that this situation should be resolved, but we also think that this document isn't really dependent on the standardization state of SameSite defaults.
  • This work is being funded by: Google

You should also know that we have already discussed this in the WebAppSec WG and agreed to convert this document into a WG Note, which will also contain additional guidance for user agents on how to securely restore access to cross-site cookies using APIs such as Storage Access or other methods.

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

💬 leave review feedback as a comment in this issue and @-notify @johannhof

@johannhof johannhof added Progress: untriaged Review type: CG early review An early review of general direction from a Community Group labels Sep 28, 2023
@torgo torgo added privacy-tracker Group bringing to attention of Privacy, or tracked by the Privacy Group but not needing response. and removed Progress: untriaged labels Oct 11, 2023
@torgo torgo added this to the 2023-10-16-week milestone Oct 11, 2023
@torgo
Copy link
Member

torgo commented Oct 17, 2023

Hi @johannhof - We're supportive of the effort to develop concrete definitions around cross-site cookies. We think it's vital that this work reflect multi-stakeholder consensus.

You mention that Apple and Mozilla have declined to comment until this moves to WebAppSec - and you've noted that it will be a working group Note. However, a Note doesn't connote consensus of the working group and won't include normative content (testable). So we're a little concerned that the intention is to deliver it as a note - as this might not represent multi-stakeholder consensus.

Has this work been shared with the Privacy Community Group? If so, can you share the feedback?

@johannhof
Copy link
Author

@torgo thanks for taking a look. This will be a note because the normative content will have to land in HTML / Fetch and the Cookies RFC. We're trying to resolve a chicken and egg problem here where we want to build consensus early for informing the cookie layering architecture, but in order to do this we have to produce a consensus-driven document. A Note seems like a good compromise (and some of the content also fits better in a non-normative format, such as general API design advice).

We did some early discussions in Privacy CG but moved to discussing in WebAppSec given that this is mostly about security. We've gotten positive verbal sentiment from browser reps in the meetings (except for the SameSite=Lax standardization feedback I've explained above).

@mikewest
Copy link

Small, partially tangential point in response to @torgo: my understanding is that notes do express the consensus of a working group (insofar as consensus is required for their publication). They're not "standards" and aren't endorsed by the W3C, but neither seems required for them to reflect consensus around best practice or shared guidance for specifications written elsewhere.

@torgo
Copy link
Member

torgo commented Oct 19, 2023

Hi @mikewest I take your point. I have definitely seen examples where working groups have published Notes that contain content that some working group members would have objected to had it been in a Rec. But I think it depends on how the wg operates.

@johannhof thanks for the explanation and the pointer.

We're generally OK with the approach (and the effort to agree this fundamental definition across browser engines) and we'd like to see this work move forward. Please come back to us for a re-review when this is further along and the consensus-blocking issues have been resolved.

@torgo torgo closed this as completed Oct 19, 2023
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. Review type: CG early review An early review of general direction from a Community Group Venue: WebAppSec WG
Projects
None yet
Development

No branches or pull requests

5 participants