#904: Standardizing Security Semantics of Cross-Site Cookies
Discussions
2023-10-16
Dan: sounds like they're trying to put some definition around what it means..
Yves: a way to standardise the behaviour between the different browsers. Sounds good to me.
Dan: apple and mozilla don't want to comment until it goes to webappsec
Amy: is this related to First Party Related Web Sets?
Amy: should they be starting the most restrictive definition instead?
Amy: we can say we support the fact that you want to do this - come back to us when there is multi-stakeholder support.
<blockquote> 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?
</blockquote>
OpenedSep 28, 2023
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 theSameSite
attribute as-is does not sufficiently protect sites from attacks given the lack of granular control for developers.Further details:
Mozilla and Apple deferred to officially comment on this document until it moves under WebAppSec.
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 ofSameSite
defaults.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