SameParty cookie attribute

[cfredric]

Hello TAG!

I'm requesting a TAG review of the proposed SameParty cookie attribute.

The SameParty cookie attribute provides web developers a means to annotate cookies that are allowed to be set or sent in same-party (where "party" is defined by the collection of domains within the same First-Party Set), cross-site contexts; and hence should not be subject to the obsoletion/restrictions planned/shipped for third-party cookies in major browsers. In addition, SameParty cookies are blocked in cross-party, cross-site contexts.

• Explainer: https://github.com/cfredric/sameparty
• Security & Privacy self-review: https://github.com/cfredric/sameparty/blob/main/security_and_privacy.md
• Primary contacts (and their relationship to the specification):
  • @chlily1, author, Google Chrome
  • @krgovind, author, Google Chrome
  • @davidben, author, Google Chrome
  • @cfredric, author, Google Chrome
• Organization/project driving the design: Google Chrome

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Plan to be discussed in conjunction with First-Party Sets in PrivacyCG
• The group where standardization of this work is intended to be done ("unknown" if not known): IETF HTTP Working Group
• This work is being funded by: Google

You should also know that…

This is related to First-Party Sets, which was previously reviewed and discussed here: #342.

We'd prefer the TAG provide feedback as:

💬 leave review feedback as a comment in this issue and @-notify [cfredric, krgovind]

[torgo]

Hi folks - this is an interesting proposal. We are just picking it up at our virtual f2f this week and discussing. I note that it builds on First Party Sets, which we previously reviewed and found issues with, which were not resolved. Furthermore there seems to be lack of multi-implementer support for First Party Sets based on e.g. the Mozilla feedback. Therefore it feels to me like it's premature to build things on top of First Party Sets?

[krgovind]

@torgo Thank you for taking a look at this proposal! I'd like to point to support from Edge, and support to adopt in PrivacyCG from Safari. First-Party Sets is currently under discussion in PrivacyCG, and the SameParty cookie attribute was also discussed there. The result of the SameParty discussion is cfredric/sameparty/issues/2

My impression was that we had responded to the issues raised on #342, but perhaps we need to articulate that better back on that thread? Here is my enumeration of our response to the various issues:

• Mozilla's concern around self-declared vs. curated lists (in comparison with Firefox's use of disconnect-entitylist.json) were addressed in the rewrite of the proposal with the UA Policy section.
• Preventing use of First-Party Sets as a cross-site tracking vector is addressed in this section.
• We propose to aid user understanding via UI Treatment.
• We are considering options for enforcement against creation of excessively large sets in Enforcement against formation of large sets  WICG/first-party-sets#29

[torgo]

OK - we have had a more detailed discussion on the proposal today on our TAG call. We have some very strong concerns about the underlying first party sets proposal #342 which I think that discussion has unearthed. Hence we're going to move the discussion back there and re-open that issue. Also pinging @chrishtr.

[hober]

Marking this as blocked on dependency for #342.

[torgo]

@cfredric we are just reviewing again at our virtual f2f. We still feel this is blocked on First Party Sets - a spec which is in active development in the Privacy CG. Is there any additional info on multi-implementer support?

[rhiaro]

We are closing this due to the dependency on First Party Sets.