Summary of proposed changes:

Based on feedback received during the incubation of First-Party Sets in the Privacy Community Group, we are proposing changes to the proposal. Following is a high-level summary of the changes, on which we invite community feedback. Please review the linked sections below for additional detail.

All of these changes are part of PR #91 which we will review on an upcoming WICG call (see issue #89)

• Define a set through use-case-specific "subsets". Each subset category will have its own requirements, and browser handling approach.
• Leverage the Storage Access API for sites to request cross-site cookie access, instead of the SameParty attribute.
• Abandon development of the SameParty cookie attribute, which allowed synchronous cookie access on subresource requests, and, for the most part, allowed legacy same-party flows to continue functioning with minimal adoption costs involved for web developers. However, it prevents browsers' ability to mediate these flows and potentially intervene on behalf of users.

Benefits of proposed changes:

• Allows for more granular use-case specific requirements and browser handling policies that are more likely to align with user expectations.
• Achieves alignment and interoperability with other browsers' approach to mediate cross-site cookie access via Storage Access API.

Challenges:

• SAA involves greater adoption costs for web developers, compared to the SameParty cookie attribute. We hope to alleviate this to some extent via our proposed extension to SAA.

Open question(s):

• We recognize that these changes also necessitate re-examining how CHIPS integrates with First-Party Sets. We are working on technical changes to that design as well, and will share updates when we have a proposal.