Proposing changes to First-Party Sets based on community feedback

[krgovind]

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.

[dmarti]

Thank you, it is very encouraging to see sets that can be based on user understanding of contexts.

Putting the set review process into a GitHub repository (or a similar collaboration tool) means that there will community management challenges for interactions between site owners proposing sets and independent reviewers evaluating set validity. Discussions of valid/invalid sets are likely to become contentious and turn into moderation problems if they turn to matters of opinion about whether a set is "clearly presented to users."

In order to make GitHub (or similar) reviews of sets work as well as possible, it would be good to see what could be done to make the work of a public reviewer less open-ended. I added a suggestion that proposed sets should be accompanied by user research, on the real site audiences, that shows that the users do find that a set is "clearly presented." That way the public review process can better be able to start from a shared understanding of what the users really understand about a set.

[krgovind]

Closing this now since #91 has now been merged; and new issues have been opened to capture feedback and discussion.

[trishann7777]

Please let me say thank you Patricia Collier pcollier294@gmail.com