First-Party Sets

[chlily1]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: First-Party Sets
• Specification or proposal URL: Explainer
• Caniuse.com URL (optional): none
• Bugzilla URL (optional): none
• Mozillians who can provide input (optional): @annevk and @ehsan have commented on this proposal in the past

Other information

• Previously provided feedback on an earlier revision of the proposal. (We are requesting an official Mozilla position for the proposal as described in the current version of the explainer.)
• TAG review thread
• Early proposal for integration with cookies (This is outdated now, and we are working on a new proposal that is somewhat different from this one.)

[annevk]

Say rugby.example and football.example decided to create a first-party set together. How would you convey this information to the user?

[annevk]

From @othermaciej: https://lists.webkit.org/pipermail/webkit-dev/2020-May/031222.html.

[dbaron]

Are there parts of the updated explainer that respond to the five concerns brought up in krgovind/first-party-sets#6 and krgovind/first-party-sets#7?

[chlily1]

@annevk:

Say rugby.example and football.example decided to create a first-party set together. How would you convey this information to the user?

The set's owner domain could be displayed in the browser UI.

@dbaron:

Are there parts of the updated explainer that respond to the five concerns brought up in krgovind/first-party-sets#6 and krgovind/first-party-sets#7?

For krgovind/first-party-sets#6, please see replies here and here. Regarding the issues raised there:

• Affiliations Unclear to Users: See UI treatment section (also linked above).
• Incentives to Form Sets and Personalized Sets: These types of sets are considered abusive and should be disallowed by the browser's UA policy. Additionally, personalized sets are mitigated by fetching manifests without credentials and using separate network partitions, as described here.

For krgovind/first-party-sets#7, please see reply here. Regarding the issues raised there:

• Imposing a small size over a First-Party Set may limit the competition opportunities for publishers: This is not a supported use case for First-Party Sets. Sets containing a publisher and unrelated adtech companies, etc., are considered abusive and should be disallowed by the browser's UA policy.
• Compatibility with GDPR and other similar data protection legislation: There is no section of the explainer specifically addressing this, as it is out of scope. Compliance with consumer privacy regulations is currently the responsibility of the website, not the browser. Implementing First-Party Sets should not change this, as it would not result in sites gaining access to third-party state that they cannot already access.

[annevk]

The set's owner domain could be displayed in the browser UI.

What's suggested there is basically not discoverable and seems like a huge step back for users once we have better partitioning between top-level sites.

[chlily1]

The set's owner domain could be displayed in the browser UI.

What's suggested there is basically not discoverable and seems like a huge step back for users once we have better partitioning between top-level sites.

The Origin Info Bubble is only one possibility. Other UI surfaces may be more appropriate, potentially depending on the browser.

[johannhof]

In my opinion this proposal looks reasonable and we should participate in evolving it, but I think the broad definition of "UA Policy" isn't really acceptable to us. Some things I'd like to see formalized across browsers instead:

• Restricting each domain to be in at most one entity.
• A maximum set size

Not having this standardized will have the effect that browsers with a stricter policy will need to spend a lot of time and energy on dealing with the Web Compat fallout.

Also, IIUC in the case of an owner change we would clear all site data from the transferred domain before proceeding? From a purely technical Firefox standpoint, the idea of clearing all site data immediately before proceeding to a site and relying on all caches to be evicted and everything to be gone feels prone to races. I know this is already the case with Clear-Site-Data but there websites don't really have a reason to exploit it.

With regards to the UI, I'm not sure whether it's critical to communicate this to the user in primary UI if the restrictions mentioned above are kept. Showing it in the site identity panel (the Firefox version of Chrome's origin info bubble) might suffice.

[englehardt]

As I summarized here, I see several fundamental issues with the proposal, and think it would be harmful to adopt without first showing that those issues can be resolved.

[cfredric]

First-Party Sets has undergone quite a few changes since this issue was closed. In particular:

• We've introduced the notion of "subsets" to categorize set member domains, and allow the UA to handle them differently and impose different requirements according to their declared type.
• We've abandoned the SameParty cookie attribute.
• We've indicated support for the Storage Access API for sites to request cross-site cookie access, within the bounds of a First-Party Set.

These changes were introduced in https://github.com/WICG/first-party-sets/issues/92. They align the proposal with other browsers' approaches of using the Storage Access API to mediate sites' requests for cross-site cookie access.

Given the extent of the changes, I'd like to request a re-review of the First-party Sets proposal. Thanks!

[martinthomson]

The changes that are proposed don't really address any of the central issues we (and others) originally raised.

1. There are better long-term solutions - like FedCM - for many of the identified problems. These are not always free from operational or transitional costs, but they tend to produce better user accountability properties.
2. The potential for different policy treatment by browsers creates and potentially worsens interoperability problems that disproportionately affect users who choose less popular policies.
3. Governance issues remain as a major barrier to effective implementation, without any plausible solution.

I don't personally see the move to using the storage access as strictly positive. This change really only buries the true changes that are being pursued here. Unpermissioned, cross-site flows of data about site visitors is really what is being sought, but this is the antithesis of many of the privacy actions browsers have taken recently.

Permissioned flows, such as the storage access API enables, isn't really that much better. I have heard strong criticism from a number of people about the effectiveness of that API in terms of ensuring that people understand and truly assent to the things that storage access enables. I tend to agree with that criticism. Storage access is only really tolerable as a pressure-release, a temporary hack that lets sites delay the more significant architectural changes that a better default privacy stance might demand.

That browsers - or perhaps their users - each get to choose what policy to apply is at the core of the problems here. Whatever Google Chrome chooses for its default policy will have a huge influence on what sites will expect. It appears that the policy will involve some amount of unpermissioned cross-site linkage. Otherwise, why insist on having an option to choose? People who reject that default will inevitably need to deal with broken experiences.

As Maciej said, let us instead concentrate on the hard part: agreeing on shared semantics.

(This is just my view of the situation; I will need to confer with others and get you a more concrete answer.)

[martinthomson]

In addition to the above, Apple have helpfully provided updated feedback on FPS. On the whole, we agree with Apple.

As such, we're not seeing any reason to change the position from "negative". Thanks for checking.

[johannhof]

(disclaimer: I previously commented on this proposal while being employed by Mozilla, I now work at Google)

Hi Martin, thank you for taking another look. I understand that this issue is closed and I'm not asking you to re-open, but I wanted to add a response nonetheless.

In addition to the above, Apple have helpfully provided https://github.com/WebKit/standards-positions/issues/93#issuecomment-1357694422. On the whole, we agree with Apple.

I should call out that this is not an updated response from Apple and rather a copy-paste from John Wilander's previous comments on FPS in May '22.

The changes that are proposed don't really address any of the central issues we (and others) originally raised.

1. There are better long-term solutions - like FedCM - for many of the identified problems. These are not always free from operational or transitional costs, but they tend to produce better user accountability properties.

Working closely with the FedCM team, I don't think that FPS and FedCM are currently targeting the same use cases. There are some organizations which happen to be identity providers and also run sites where a social/federated login functionality may be surfaced to users instead of using SAA with FPS. But I wouldn't expect that to be a common case, even for the "associated" set. We're (obviously) very supportive of FedCM and would like to explore ways that we could change it to help deliver better user experiences in other areas, but that doesn't mean it can replace FPS entirely. For things like service domains (JSFiddle/githubusercontent use cases) I'm quite sure that FedCM will never offer an adequate solution.

I don't want to discuss FedCM too much here, but it's important to consider that its main strength comes from being so purpose-bound to federated/social-style login patterns. We have to be careful to not use FedCM prompts outside of where users would naturally understand them. FPS could help with that.

2. The potential for different policy treatment by browsers creates and potentially worsens interoperability problems that disproportionately affect users who choose less popular policies.

An explicit goal of the updated proposal is to put an upper bound on the negative effect on browsers who will choose more restrictive handling (or ignoring) of FPS.

I don't personally see the move to using the storage access as strictly positive. This change really only buries the true changes that are being pursued here. Unpermissioned, cross-site flows of data about site visitors is really what is being sought, but this is the antithesis of many of the privacy actions browsers have taken recently.

Permissioned flows, such as the storage access API enables, isn't really that much better. I have heard strong criticism from a number of people about the effectiveness of that API in terms of ensuring that people understand and truly assent to the things that storage access enables. I tend to agree with that criticism. Storage access is only really tolerable as a pressure-release, a temporary hack that lets sites delay the more significant architectural changes that a better default privacy stance might demand.

Strictly comparing "(un)permissioned cross-site data flows" vs. "better default privacy stance" may be simplifying things a bit too much. Sharing any high-entropy identifier between two sites is equivalent to full cross-site cookie access from a privacy perspective. As such, any API that does this, such as FedCM, will need to be "permissioned" in some way. Given that, we need to think about how we can help the user experience through these flows that necessarily need to share the full user identity.

Our hypothesis is that we can reduce the number of prompts in these necessary flows through the trust in pre-declared use cases established through FPS. Aside from that we also need better prompts, but that's not really a goal for FPS.

That browsers - or perhaps their users - each get to choose what policy to apply is at the core of the problems here. Whatever Google Chrome chooses for its default policy will have a huge influence on what sites will expect. It appears that the policy will involve some amount of unpermissioned cross-site linkage. Otherwise, why insist on having an option to choose? People who reject that default will inevitably need to deal with broken experiences.

As mentioned before, I don't think that even in the long term we can build a version of the web where the user or the user agent doesn't have to make choices about sharing identities in some form, nor do I think that this would be desirable. Things being "broken" (i.e. users being logged out or services not being integrated) when "permission" is not given is a side effect of that.