Re: [w3ctag/design-reviews] First-Party Sets (#342)

Hello,

I'd like to request a re-review of the [First-Party Sets proposal](https://github.com/WICG/first-party-sets). This proposal has [changed significantly](https://github.com/WICG/first-party-sets/issues/92) since the [previous design review](https://github.com/w3ctag/design-reviews/issues/342), and we believe we have addressed points in the [TAG's feedback](https://github.com/w3ctag/design-reviews/blob/main/reviews/first_party_sets_feedback.md). Specifically:

* The new proposal has abandoned the SameParty cookie attribute in favor of integrating with the [Storage Access API](https://privacycg.github.io/storage-access/) (which already has multi-browser-vendor support) and the [requestStorageAccessForOrigin proposal](https://github.com/mreichhoff/requestStorageAccessForOrigin).
* The new proposal, like the previous proposal, makes no changes to the notion of "origin", nor does it change anything w.r.t. the Same Origin Policy. (In fact, it explicitly states that preservation of the Same Origin Policy is a goal of the proposal.)
* The new proposal lists specific use cases that it addresses and which are not addressed by any competing proposal.
* The new proposal does not seek to redefine "third-party cookies". Rather, it seeks to provide a framework for sites to declare why they need third-party cookie access for certain sites. With this information, user agents can make informed decisions, such as reducing user friction by allowing use of third-party cookies in scenarios in which the user agent has sufficient context to believe that doing so will not enable pervasive tracking. This is consistent with [implementation-defined implicit grant behavior](https://privacycg.github.io/storage-access/#ua-policy) of the Storage Access API that is already shipping in other browsers.

We recognize that we have not addressed all aspects of the TAG's previous feedback:
* The First-Party Sets proposal still relies on the existence of a public, transparent, and centrally-governed list of sets that can be consumed by each user agent and browser vendor. We recently published [submission guidelines](https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md) for additions to the list. The process relies on automated checks, and accountability via transparency; which we hope strikes the right balance between scalability and abuse prevention. To address the TAG’s specific points:
  * We do not think that this list will encourage application developers to [target specific browsers or devices](https://github.com/w3ctag/design-reviews/blob/main/reviews/first_party_sets_feedback.md#:~:text=This%20could%20lead%20to%20more%20application%20developers%20targetting%20specific%20browsers%20and%20writing%20web%20apps%20that%20only%20work%20(or%20are%20limited%20to)%20those%20browsers), since the list can be consumed by any browser on any device. This list would be no more browser-specific than the Public Suffix List, for example. Additionally, since the list is currently used to define user agent-specific behavior for Storage Access API, browsers that do not use the list are free to use different logic and still support site functionality.
  * We believe the transparency of such a list would ensure that its definition serves web users first, not sites or cookie issuers. Furthermore, the existence of this list does not prevent user agents from surfacing the list to users, providing transparency and controls as appropriate, and otherwise making these relationships auditable and controllable.
  * We want to avoid introducing custom compatibility "quirks", like those of other browsers. We believe that this would not be beneficial to the web as it may encourage developers to target specific browsers and result in an inaccessible and unpredictable process for users and developers.
* The new proposal does not require user consent, nor did the original proposal. However:
  * We think that this is not [a departure from how the web has worked for years from a user perspective](https://github.com/w3ctag/design-reviews/blob/main/reviews/first_party_sets_feedback.md#:~:text=departure%20from%20how%20the%20web%20has%20worked%20for%20years%20from%20a%20user%20perspective). For many years, third-party cookies have allowed sites to share data with other sites; this experience is not new to web users. The First-Party Sets proposal preserves this data-sharing ability but only in specific non-pervasive-tracking cases, which users may easily audit on the public list or perhaps in browser UI.
    * In the revised proposal, FPS surfaces more metadata for user agents to be more informed in the decisions they make or in the information they choose to surface to users. We continue to maintain that user agents have the autonomy to provide the appropriate UX for their userbase.
  * We do not think that our proposed solution [relies on the user's awareness of the members of a First-Party Set via browser UI alone](https://github.com/w3ctag/design-reviews/blob/main/reviews/first_party_sets_feedback.md#:~:text=proposed%20solution%20to%20making%20the%20user%20aware%20of%20the%20members%20of%20a%20First%20Party%20Set%20via%20the%20browser%20UI). The recently-published [submission guidelines](https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md#set-formation-requirements) require that submitters provide a narrative rationale for why a domain is included in a set, including stating how they've clearly presented the affiliation between sites in the "associated" subset. Again, we rely on the transparency of the list to ensure that these justifications are reasonable.
* The new proposal still adds a configuration layer to the web. However:
  * We think that there are already many configuration layers to the web (e.g.: the Public Suffix List, DNS, public key infrastructure) and one additional layer should not be disqualified as such.
  * We think that the existing use cases listed in the proposal provide sufficient motivation for adding this layer, to elevate browser-specific hardcoded solutions into a more equitable, browser-agnostic solution.

Please note that we have also recently published [a specification](https://github.com/WICG/first-party-sets/pull/120/) for user agents that wish to consume and integrate FPS. We would appreciate a TAG review of this specification and are happy to either “upgrade” this request to a spec review or file a separate issue, as you prefer.

For the above reasons, we would appreciate it if the TAG can take another look at our proposal. Thank you!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/342#issuecomment-1355093008

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/342/1355093008@github.com>