A few notes from reading through the explainer (which I haven't fully digested yet):

• the rules that the browser not cache the set if there's any mismatch seems a little problematic if a site wants to evolve the set over time (e.g., add a host to it). If something depends on the set being present, they'd need to make sure to roll out the change across multiple hostst at exactly the same time, probably including dropping HTTP cache expiration times for a period leading up to the switchover. Is that avoidable? (There are some thoughts on this later in the "Incremental Verification" section... but I suspect there might be other options for rollout if that isn't viable.)
• Why is a host that is a registerable domain disallowed? ("None of the origins specified is itself a registrable domain") (I'm guessing you have a good reason, but I don't see it, and it seems a little confusing to me.) (Though it seems to contradict the "The design above relies on origins. Shouldn't we evaluate registrable domains instead?" FAQ item.)
• This does appear to pose some risk to users ("How will malicious actors abuse this mechanism?"), but it's not clear to me what the user benefit is over what happens today. It seems like the explainer should be clearer about that.
• The abuse point of hopping between sets seems to be mentioned only in passing, but it seems pretty concerning.

Thanks for the feedback, @dbaron! It might also be useful to get feedback from @englehardt and @ehsan, with whom I briefly discussed this proposal. I'd love to figure out if we can make this more robust together. :)

the rules that the browser not cache the set if there's any mismatch seems a little problematic if a site wants to evolve the set over time (e.g., add a host to it

First, as is probably clear, the rules are somewhat up in the air. This first pass seems like a reasonable balance between deployment difficulty and stability, but we might well want to revisit some of the restrictions. The incremental verification suggestion you mention is one route that occurred to me, but I'm sure there are others. For example, the X-Bikeshed-This-Origin-Asserts-A-First-Party-Set could have a version number rather than a boolean, bypassing the cache expiration.

Second, I don't know how much we need this sort of thing to be trivial to change. The history of Mozilla's disconnect-entitylist.json shows that entities do indeed shift over time, but each individual entity seems relatively stable.

Why is a host that is a registerable domain disallowed?

That's a typo. :) Should have read "is itself a public suffix". Fixing it in https://github.com/mikewest/first-party-sets/commit/34adb31b50d0ae8f9bfa77863b5e4a1792c09ce5.

This does appear to pose some risk to users ("How will malicious actors abuse this mechanism?"), but it's not clear to me what the user benefit is over what happens today. It seems like the explainer should be clearer about that.

I'm hopeful that we can create non-proprietary and publicly auditable alternatives to the lists Apple, Google, and Mozilla are independently maintaining for various features. In the best case, something like this feature would give us the ability to offer entity-related features like credential sharing, and reduce the risk of rolling out tighter controls on cross-entity sharing.

The abuse point of hopping between sets seems to be mentioned only in passing, but it seems pretty concerning.

I think the current design fairly substantially mitigates this risk by making deployment bidirectional and atomic (e.g. the pain point you noted at the top). It seems to me that we can mitigate it more by locking sites into a given set for some period of time if we decide that the inherent difficult is either unacceptable or not enough.

Thanks again!

I'm hopeful that we can create non-proprietary and publicly auditable alternatives to the lists Apple, Google, and Mozilla are independently maintaining for various features. In the best case, something like this feature would give us the ability to offer entity-related features like credential sharing, and reduce the risk of rolling out tighter controls on cross-entity sharing.

I think it would be useful to say something like that in the explainer.

@plinss: Skimming the minutes, I don't think y'all got to this in the 05.03 meeting, and it looks like it fell off the radar for the 12.03 meeting. Perhaps there's an upcoming slot it could fit into?

@dbaron: Yes. I need to restructure the explainer a bit to improve the explanation of the problem I'm aiming to solve, as it grew out of a different document with a distinct purpose. I'll certainly take some time to do that (though I don't think it'll create substantive changes, and hopefully won't block y'all taking a closer look).

Thank you both!

Hi Mike!

Hope you missed me. Lovely explainer. May I ask about a few bits below.

Still, it seems likely that folks will want to stretch the bounds of what first-party sets enables over time

Can you please elaborate why it's likely, and which folks specifically do you mean here? Not asking for all their names and addresses, of course.

Tying those two domains together in the same first-party set could increase the risk of credential leakage, if browsers aren't careful about how they expose the credential sharing behavior discussed above

Any other risks that you can imagine (apart from the stuff listed later in the explainer)? Aside from the Ordinary User not knowing about the existence first/third party stuff, would it make sense to require browser UI changes to indicate that some site is linked with another?

It would be fatal to the design if https://subdomain1.advertiser.example/ could live in one first-party set while https://subdomain2.advertiser.example/ could live in another

That looks unfortunate indeed. Good the explainer is listing plenty of concerns.

Given this reality, we need to add a registrable domain constraint to the design above such that each registrable domain may live in one and only one first-party set.

Would there be a way to deregister from the set, and e.g. change sets in quick time intervals, or something like that? I'm simply wondering if site1 can easily change its membership (rather than: being member of two separate sets on the same time, which is already marked as concern). Apart from the natural expiration of 7 days you speak of, unless it could be the same.

We can mitigate this risk to some extent by limiting the maximum number of registrable domains that can live together in a first-party set, rejecting sets that exceed this number

How would the risk after such mitigation compare with today's risk of making the same? Would you imagine it conceivable that advertisers will start serving their stuff from XXXYYYZZZ.ccTLD, and smartly game the number-limited system? (but: "Forget the entity" looks good).

As the declaration is public by nature, the style of abuse noted here will be trivially obvious to observers, which creates exciting opportunities for out-of-band intervention

Sounds like an opportunity for a new batch of research papers? I'm sure many will be happy ;-)

@mikewest we discussed at today's call having a focused discussion on this one at our next f2f - week of 20th of May. Is that going to be too late to be useful for you? If not, would you like to dial in for that (we will be in ~UTC).

Thanks, @torgo!

we discussed at today's call having a focused discussion on this one at our next f2f - week of 20th of May. Is that going to be too late to be useful for you?

Sure! Chrome will likely have begun implementation by then, but y'all's feedback would be quite welcome as we work through the initial stages.

If not, would you like to dial in for that (we will be in ~UTC).

I can probably make time to chat with y'all; that week looks pretty open. Let me know when you're closer to scheduling something?

Thanks, @lknik! Sorry I missed your feedback when you first provided it.

Still, it seems likely that folks will want to stretch the bounds of what first-party sets enables over time

Can you please elaborate why it's likely, and which folks specifically do you mean here? Not asking for all their names and addresses, of course.

The example I linked in the document (https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0034.html) came to mind as an existence proof of folks with interesting ideas about loosening the same-origin policy based on affiliation.

Any other risks that you can imagine (apart from the stuff listed later in the explainer)? Aside from the Ordinary User not knowing about the existence first/third party stuff, would it make sense to require browser UI changes to indicate that some site is linked with another?

The document lists the risks I've thought about. If I come up with more, I'll add them. :)

I don't personally think there's any value in exposing the relationship between A and B to users directly via browser UI, but I'm not at all a UI guy. I'd expect folks like @estark37 to have strong, well-informed opinions on these topics, and I'd defer to them completely. That said, however Chrome comes down on that question, I don't think it makes sense to specify UI in this kind of document.

Would there be a way to deregister from the set, and e.g. change sets in quick time intervals, or something like that? I'm simply wondering if site1 can easily change its membership (rather than: being member of two separate sets on the same time, which is already marked as concern). Apart from the natural expiration of 7 days you speak of, unless it could be the same.

I don't think it would be helpful to create a way to deregister oneself in an accelerated fashion without also taking some catastrophic action against the data that's been built up given the existing first-party relationships. I could imagine the Clear-Site-Data: * mechanism being draconian enough to enable this, for example.

How would the risk after such mitigation compare with today's risk of making the same? Would you imagine it conceivable that advertisers will start serving their stuff from XXXYYYZZZ.ccTLD, and smartly game the number-limited system? (but: "Forget the entity" looks good).

How would this "game the system"? The risk mitigated by limiting the size of a set is the incentive that would otherwise exist to create a single global set of all an advertisers' otherwise unrelated publishers (e.g. doubleclick.net + cnn.com + sz.de + vox.net + ∞). Allowing an advertiser (or anyone else) to bind their matching ccTLDs together seems different in kind from that scenario.

Sounds like an opportunity for a new batch of research papers? I'm sure many will be happy ;-)

I agree! Mechanisms that encourage transparency are good.

Regarding use cases, I'd like to draw your attention to https://mikewest.github.io/cookie-samesite-firstparty/draft-west-cookie-samesite-firstparty.html (http://tools.ietf.org/html/draft-west-cookie-samesite-firstparty if you prefer "paginated" text), which builds upon the primitive described here in a way that might allow us to avoid some developer pain points while tightening cookie controls over time.

@mikewest Thanks for the answer (We're discussing at f2f Reykjavik).

Given that the repo is now at https://github.com/krgovind/first-party-sets, feels like ccing @krgovind might be useful.

@mikewest just picking this up again, I think we are stalled and this topic has gone into our "abyss." Can you let us know the status and (most usefully) if there are specific questions where the TAG might weigh in. Does it make sense to discuss this at TPAC?

One worry I have after hearing folks talk about this at TPAC is that this becomes as attractive as the PSL and will be used for all the wrong things. In particular there were a number of suggestions this would allow us to ease certain origin restrictions. I know that's not the goal, but once there's architecture in place it'd be annoying to have to have that discussion again and again and again.

(No great ideas other than adding a bright red warning section early on in the document.)

I would like for it to replace the PSL (through a hand-wavey mechnism in which we fix https://github.com/sleevi/psl-problems/ by murdering cookies, locking everything to origins, and relaxing the PSL-related bits via FPS rather than PSL).

(Some TPAC discussion in https://github.com/w3c/webappsec/blob/master/meetings/2019/2019-09-TPAC-minutes.md#origins-and-sites-and-entities).

@mikewest so you'll enable FPS at the same time when phasing out cookies and PSL? Otherwise, what would be the estimated duration of all these mechanisms working at the same time, and potentially a risk that we'll end up with FPS, PPS and cookies forever?

Hi,

@dbaron, @plinss, and I took another look at this at our Cupertino F2F.

I seem to recall @johnwilander chose not to pursue Affiliated Domains, his earlier, First Party Set-like proposal, because after working on it for a while he concluded that it was a bad idea for the web. I'll ask him to distill those thoughts into digestible feedback that is relevant to FPS.

Hi,

@dbaron, @plinss, and I took another look at this at our Cupertino F2F.

I seem to recall @johnwilander chose not to pursue Affiliated Domains, his earlier, First Party Set-like proposal, because after working on it for a while he concluded that it was a bad idea for the web. I'll ask him to distill those thoughts into digestible feedback that is relevant to FPS.

I already have: https://github.com/krgovind/first-party-sets/issues/6

Still waiting for a response to my latest questions and concerns.

I already have: krgovind/first-party-sets#6

Still waiting for a response to my latest questions and concerns.

Sorry for the delay in responding to your comments on the repo, @johnwilander! November was busy with conferences and a vacation. I'll respond within the next few days.

Hi,

@plinss and I took a look at this today in our Wellington F2F. The explainer appears to identify only one use case:

[W]eb platform features can use first-party sets to determine whether embedded content may or may not access its own state[…] It may be reasonable to allow a https://b.example iframe within https://a.example to access the https://b.example databases.

Isn't this solved by the Storage Access API? If it is, we can solve this use case with that API while avoiding the attractive nuisance concern with FPS that @annevk raised. Shouldn't we do that instead?

Thanks for the comments, everyone!

@annevk We certainly need to be careful when introducing a non-origin boundary, but, FPS, eTLD+1, or something else, I think it’s sadly necessary.

The same-origin policy roughly ensures two origin will not interact unless they want to. https://a.example's data is safe from https://evil.example. but, if https://a.example and https://b.example want to share information, there are many opt-in cross-origin channels.

Those channels allow cross-site tracking. Mitigating this means limiting communications between two "sites" (however we define them) even when they want to communicate. This stricter isolation needs a coarser boundary. Consider subdomains like https://accounts.google.com and https://calendar.google.com. Separate origins isolate bugs, but the origins still interact, just as browsers use multiple processes but have IPC. If tracking mitigations worked on the origin boundary, those pages would need to be https://google.com/accounts and https://google.com/calendar to still work. User activity is as linked as before, and we've lost privilege separation.

Thus we need some larger boundary: a collection of origins treated as one “site" for anti-tracking purposes, whether eTLD+1 or first-party sets. Like you say, this comes with needing clear guidance on which to use, probably based on the above distinction.

@hober and @plinss We probably need to do a better job describing the use cases. Let me try clarifying things here and we'll see about updating the explainer. I don't think they'd all be covered by the Storage Access API.

One could imagine recasting the browser's knowledge of related domains into, say, a Storage Access API prompt suppression, but we don't think that would meet the compatibility or privacy needs here. Additionally, if this relatedness is to involve any site opt-in (in addition to the UA policy, of course), we need a standard way to manage that opt-in.

First, the Storage Access API assumes a particular flow (gesture into a 3p iframe), which makes sense for truly 3p scenarios. Multi-domain sites may need to interact more tightly. For instance, seamless single-sign-on across multiple first-party domains kicks in once the page loads.

Second, the platform should be aware of these sets. A pair of sites that always get storage access (prompt suppression or users just granting access on name recognition) are really one site w.r.t. linkability. Privacy-related platform limits must then cover the entire set, or each domain in the set will inflate the limit. Examples where this may make sense: Privacy Budget, Trust Tokens limits, Conversion Measurement limits, or limits on 3p isLoggedIn queries to avoid fingerprinting.

We're also envisioning this feeding into other tracking mitigations that wouldn't fit the Storage Access API. Navigations within a first-party set could be exempt from potential mitigations for navigational tracking (link decoration, referrers, POSTs, etc.), which would reduce unnecessary compatibility impact.

This browser awareness can also translate into UI: clearing site data could offer to clear state across the entire set if the user wants to reset first-party linkability, or the browser could display the owning origin to the user somewhere.

Finally, some of these uses (limits, UI integration) are not just exception grants, so sites won’t want to be associated with unrelated domains. Even if the UA's list approves, it may be incorrect or out-of-date. We can fix this by requiring site opt-in in addition to UA policy, but that needs a standard mechanism. First-party sets provides that mechanism, as well as a story for handling changes (key state on owner domain and clear when it changes).

@davidben well, we already have registrable domains. And at least with those it's somewhat clear to the user they all belong to the same entity.

We do, though we really ought to fix all those to be scheme + registrable domain. That one has the same issues to resolve around when to use it over origins.

There, the problem we're addressing is that the web grew up without these restrictions and sites are often spread across multiple domains. Two browsers have already found they need this: Firefox uses a hardcoded list of related domains to extend first-party-ness. Edge's blog mentions doing something similar. Moreover, these entity lists are paired with a blocklist anti-tracking strategy, rather than platform-wide changes. That means they only need to cover the subset of multi-domain sites also on the blocklist. The true set is likely much larger. (Anecdotally, I've seen bank sites bounce between domains like bank.example and bank2.example, likely because each component is hosted by a different provider.)

You're right that all this is ultimately should tie back to who the user thinks they're interacting with. First-party sets, unlike the lists above or some kind of Storage Access API policy tweak, tries to identify each set with an owning origin, so there's room to explore surfacing that information. But folks like @estark37 have done far more research into this sort of thing than me, so I'll defer to her expertise there.

There's a big difference between curated first-party sets and self-declared first-party sets though, especially for Firefox's use case.

(As for scheme + registrable domain or opaque origin aka site, we're getting there standards-wise. https://github.com/whatwg/html/pull/5354 might be of interest.)

FPS isn't self-declared either. It's an intersection of the self-declared set with UA policy, i.e. curation. (Have you seen the revised explainer? We've recently reworked it to make that combination a bit clearer and give the browser better hooks for this.)

(As for scheme + registrable domain or opaque origin aka site, we're getting there standards-wise. whatwg/html#5354 might be of interest.)

(Yup. I've been pushing on getting corresponding changes elsewhere in the stack like fixing SameSite and finally fixing the scope.)

There have been some issues raised on this on this thread and elsewhere. There are good ideas in this proposal. As the TAG we don't feel we have something to add to the debate at this point. If there is a new major development, we would be happy to review at that time. We find it slightly concerning that this review has been on our plate for over a year and this proposal still isn't in a community group or other standards body.

The discussion in the W3C Improving Web Advertising Business Group this week, specifically in relation to First Party sets, once again raises the issue of governance of the various proposals that have been put forth. Like Turtledove/Sparrow, the proposals around first party sets imply (in fact, they require) a governance structure. Specifically, the group discussed that in some cases independent domains should be allowed to federate browser data, while in other cases this would not be allowed. This means a decisioning structure needs to be put in place to provide basic rules for what federation(s) would be allowed, and to potentially adjudicate requests and violations.

This same requirement is central to the debate over Turtledove and Sparrow, where the main discussion is around what entities have access to end user content consumption data and are responsible for creating the cohorts and populating the reporting structures.

In both cases, it seems implied that the only “governance” is the browsers themselves, and that this governance will be opaque (not necessarily published, without clearly visible procedures).

This proposal needs an explicit understanding of what governance structures are being proposed. There needs to be success criteria for the application of these policies. These criteria should benefit all stakeholders including browser vendors who would avoid any appearance of collusion that could otherwise be viewed as stifling competition. The W3C Improving Web Advertising Business Group have developed a draft of such succes criteria.

Recognizing there are important questions to address in finalizing these success criteria to evaluate first-party sets and other similar proposals aimed at improving web advertised. A non-exhaustive list below highlights some of these issues that deserve greater attention:

• What safeguards are in place to ensure that browser decisions are not unilateral and are consistent with the agreed norms for content owners, marketers who fund them and other stakeholders?

• If for-profit companies govern certain content consumption data collection and processing activities, and if so, what is the minimum number required for a competitive open market as well as should there be limits on the number of these governing authorities?

• How should cross-publisher data sharing permissions be granted, administered and audited?

• Which risks to people will these changes reduce or eliminate?

• Should people be given the right to overrule default settings to further restrict or more broadly allow the collection and processing of their content consumption data?

Also posted on explainer

Also posted on discourse.

Connected to governance, there are also issues of bias that need to be looked into around this proposal, as documented by my issue on the explainer and follow-up on discourse. These biases could be addressed by being more permissive and finding another solution to governance of FPS, or could be more restrictive (proposed by another commenter on discourse) and really have very limited usage so users are not concerned.

Per @jwrosewell comment above, it's important to note that privacy, while important, is not the singular factor that should be used for making all decisions. The draft success criteria layout the other stakeholders and scenarios that need to be taken into account around decisions that affect the viability of a thriving and diverse open web.

This issue came up in the context of our review of the SameParty cookie attribute proposal. (Discussion from our TAG breakout session.)

We are finding that this proposal for first-party sets prompts more discussion in the context of cookies than it did on its own.

So we are reopening this issue to continue that discussion.

Hi! One concern I have is the potential for first party sets to expand the definition of what consists of a “first party” and a “third party” while at the same time web users are becoming ever more aware of their privacy and web browsers are responding by adding privacy features (which in some cases depend on that definition).

In the PrivacyCG call last week (https://github.com/privacycg/meetings/blob/main/2021/telcons/03-11-minutes.md), Kaustubha stated that one mitigation against misuse of FPS would be to “require all the domains in the set are owned by the same organization.” I'd like to drill down on that. First of all, who is requiring that? Would it be up to the browser maker to do so? In which case, does this mean there would be specific allow-lists of first party sets (the “UA policy”)? It's asserted that FPS is better than browsers that ships with “an entity list that defines lists of domains belonging to the same organization” because it allows these organisations to declare their own list of domains. However, isn't a UA policy just another list of allowable domains? Secondly, what counts as a an "organization" in this instance? Amazon.co.uk and Amazon.com, for example, are two distinct organisations in two different privacy-regulatory regions. So in that sense treating them both in the same first party may be counter to relevant data protection laws?

In many cases, two domains may be owned by the same corporate entity, but branded in a sufficiently different way that the web user is not aware that they are part of the same "set." Some high-profile examples are

• Most U.S. Adults Don't Know That Instagram, WhatsApp Owned by Facebook - Variety

• LVMH is a single company that owns "75 distinguished Houses" most of which are long-established famous brands with distinct histories and reputations.

Common domain ownership as a standard is likely to produce surprising results in the handling of individuals' sensitive data. (The same user might shop on one LVMH domain for gifts for their spouse, and from another domain for gifts for a co-worker.) Existing browser entity sets are inconsistent in their treatment of commonly owned domains, and there is no recognized standard for when the user-visible terms and UX are adequate for considering domains as part of the same set.

It would be more appropriate to look at common privacy policy and user-visible site design and branding to determine if domains could be treated as part of a set by the browser: Some possible criteria: https://github.com/privacycg/first-party-sets/issues/14#issuecomment-797191058

Hi! One concern I have is the potential for first party sets to expand the definition of what consists of a “first party” and a “third party” while at the same time web users are becoming ever more aware of their privacy and web browsers are responding by adding privacy features (which in some cases depend on that definition).

@torgo When you say "expand the definition", I think you are referring to the fact that today "first-party" is essentially defined as "same-domain". Unfortunately, domain names are an artifact of the DNS, the primary purpose of which is to map human-readable names to IP address. The premise of First-Party Sets (FPS) is that in today's highly composable web - (a) sites are deployed over multiple domain names (some times for reasons such as security, or localization), and (b) domain names typical serve as brand indicators for the web - therefore, treating "same-domain" as "first-party" is too limiting and antiquated. We are indeed seeking to define a privacy boundary for the web that is more realistic than the domain name; but we want to make sure that we are drawing the boundary correctly, and surfacing the information to users appropriately via UA Policy and UI affordances.

First of all, who is requiring that? Would it be up to the browser maker to do so?

Yes, browser makers should require that any first-party sets accepted by the browser have been previously approved per the "UA policy". Ideally, this verification process is conducted by an independent entity.The WebPKI / TLS certificate issuance serve as precedence here.

In which case, does this mean there would be specific allow-lists of first party sets (the “UA policy”)? It's asserted that FPS is better than browsers that ships with “an entity list that defines lists of domains belonging to the same organization” because it allows these organisations to declare their own list of domains. However, isn't a UA policy just another list of allowable domains?

Yes, the UA policy essentially will result in an allowlist of FPS assertions. The reasons I think this is better than the entities lists that some browsers currently ship:

• First-party sets would be asserted by the site developers themselves and should be less prone to mistakes (assuming we put in appropriate safeguards in place, such as requiring proof of ownership, relatively short expirations, etc.). As an example, Disconnect.me entity list has at least a couple of mistakes (com.com is incorrectly listed as a CBS property, yahoo.co.jp is incorrectly listed as a VerizonMedia property)
• The Disconnect.me list doesn't have a clearly articulated policy and process. Modifying the list appears to be informally managed on GitHub, and it is not clear if browser vendors ship the list without additional modifications. Having a documented UA policy and process will bring more transparency to users, and predictability to site authors.
• My understanding is that the Disconnect.me entities list currently serves as an "exception list" to the "trackers list"; and is not comprehensive.

Secondly, what counts as a an "organization" in this instance? Amazon.co.uk and Amazon.com, for example, are two distinct organisations in two different privacy-regulatory regions. So in that sense treating them both in the same first party may be counter to relevant data protection laws?

Sorry, I'm not sure if there are two questions here. IIUC, the question is primarily about FPS' application to privacy regulations. Note that being part of the same First-Party Set does not preclude organizations from conforming to privacy regulations. FPS only defines "first-party" from the browser's perspective; but organizations still have to do their due diligence and decide whether the domains really should be part of the same FPS, and conform to regulations. (Just as they have to do today on browsers where third-party cookies are available and cross-domain sharing is possible).

Thanks for the reply, @krgovind. We again discussed in today's TAG call and one thing that came up is the transparency of registration of these sets when it comes to these allow-lists... how would an org register these? Is there a scope for a standarised approach to registration / vetting / approval process? Secondly, we discussed permissions promopts - would allowing camera acess for one site in a first party set (like instagram) then allow it for other sites in the set (such as whatsapp)?

how would an org register these? Is there a scope for a standarised approach to registration / vetting / approval process?

The explainer currently only speaks to the technical aspect of the proposal; but yes, we are absolutely interested in working with the ecosystem on a standardized approach to the policy enforcement.

FYI: Chrome is currently running an Origin Trial and has a temporary informal process described here (note: the experiment does not have any privacy implications at this point, because SameParty cookies don't bypass the "Block third-party cookies" user control at this point).

Secondly, we discussed permissions promopts - would allowing camera acess for one site in a first party set (like instagram) then allow it for other sites in the set (such as whatsapp)?

No, we are not proposing to change the scope for permissions. The current scope for FPS is only to be treated as a privacy boundary where browsers impose cross-site tracking limitations (such as third-party cookie blocking).

@torgo said: how would an org register these? Is there a scope for a standarised approach to registration / vetting / approval process?

@krgovind said: The explainer currently only speaks to the technical aspect of the proposal; but yes, we are absolutely interested in working with the ecosystem on a standardized approach to the policy enforcement.

A common approach and governance model for FPS registration is something that we also would want to see, with clear definition of membership rules.

One concern I have is that FPS seems to allow flexibility for browsers to implement their own UA policy. From the explainer:

The browser will consider domains to be members of a set if the domains opt in and the set meets UA policy

Browsers implementing First-Party Sets will specify UA policy for which domains may be in the same set. While not required, it is desirable to have some consistency across UA policies.

Inconsistency is arguably already present on the web today, given each browser’s third-party cookie blocking policy, but the lack of a requirement for consistency across browsers leads to uncertainty around whether a site's declared membership set would be honoured by all browsers. If not, it will be hard to build site functionality that reliably depends on FPS.

@chrisn : At the time that we wrote the explainer, we didn't want to presume that browsers would be willing to converge on UA policy. We can adjust the language in the explainer as we start to take meaningful steps towards a more standard process.

John from Apple WebKit here. I don't think there's any consensus on how FPS should be used by browsers. We have not expressed any interest in relaxing our default cookie blocking based on FPS, regardless of SameParty attributes. I think it's important to decouple FPS as a piece of knowledge browsers can base decisions and policies on and what those decisions and policies are.

John from Apple WebKit here. I don't think there's any consensus on how FPS should be used by browsers. We have not expressed any interest in relaxing our default cookie blocking based on FPS, regardless of SameParty attributes. I think it's important to decouple FPS as a piece of knowledge browsers can base decisions and policies on and what those decisions and policies are.

@johnwilander Thanks for chiming in! I think some aspects of FPS, especially questions around standard UA policy, recommendations around usage by developers for platform predictability, etc. may be well-served if we can lay out specifics/principles on how FPS may be used in WebKit. Would you be willing to share your thinking on what kinds of decisions/policies you would base on FPS?

Linking discussion from the TAG minutes of 29 March

Hi @krgovind - We have just finalized a feedback doc on the proposal which can serve as the basis for our special session tomorrow. Thanks for bearing with us.

I want to explicitly comment that the Microsoft Edge team is generally supportive of this proposal. I'm concerned with some of the framing and conclusions of the feedback doc that was shared. At the same time, some of the concerns in the document are shared by us and highlight that there's more work to be done.

My highest-level concern is that the feedback doc talks about the fundamental importance of origins but either doesn't consider or dimisses the likely alternate outcome that will happen without such a proposal: the consolidation of sites onto shared origins, which will carry both security and privacy implications.

The security implications of entities merging sites currently on different origins to be hosted on a shared one is reduced isolation between the sites, with a broader set of developers deploying code on the shared origin. What may have been a security issue on one site might now impact all of them. This could lead to a dramatic increase in attackable surface area. As the news has shown time and time again, security issues often have privacy impacts.

From a pure privacy angle, when running code in iframes from other entities (e.g. an analytics service), in the "put all of my sites on one origin" approach, the iframe would not have partitioned storage across those sites. With the current First-Party Sets proposal, those unrelated origins being iframed would still have partitioned storage (albeit with the ability for the hosting page to choose to provide a shared identifier) which is still a stronger default protection than today's 3p cookies.

The framing around the "redefines 3rd-party cookies" section potentially hints that 3p cookies are substantially blocked today; I don't know if that was the intent. Safari has blocked 3p cookies for some time, but also offers the Storage Access API to allow access that's shared across all sites. Firefox and Edge have a list-based approach to identify trackers and block 3p cookies for those alone, while also providing the Storage Access API to address instances where user-pereceivable brokenness is present; Firefox is also working on fuller "State Partitioning" but currently has compat affordances for SSO. Chrome doesn't currently block 3p cookies by defualt except in Incognito mode which brings compat issues. This proposal introduces a middle point where 3p cookies can be broadly blocked by defaut while allowing, in a much more limited way, some current scenarios to function as they do today. The proposal also doesn't preclude a browser from continuing to offer controls for users that want a more aggressive blocking configuration, even for First-Party Sets-related cookies.

The question of if this proposal puts users first also reaches a different conclusion that I do (I think it does prioritize users first). While this isn't the forum for feedback on the Storage Access API, it's important to consider the current solution space to evaluate the likely net impact on users. The Storage Access API has challenges in terms of how to adequately inform the user of both the reason for a prompt and the impact of approving it and also will potentially lead to prompt fatigue. If we hope to bring storage partitioning to the broader web, having more scoped primitives like First-Party Sets increases the odds that more browser vendors will be willing to ship with 3p cookies partitioned by default since the general user experience would meet their goals for user acceptance.

An area of the feedback that I do agree with is the concern around governance. This could generate significant interop challenges if entities had to choose to register with different browser vendors separately; many might choose to only focus on the largest market share browsers. At the same time, we already have multiple browsers shipping list-based approaches because it's been the only viable path thus far for an acceptable user experience. The TAG feedback argues that we shouldn't attempt to uplift anything that looks like a hand-approved list into a standard, which is a great goal but which current implementation choices shows is hard to avoid. My understanding is that the approval process for creating a set was added to the proposal in part because of concerns from other implementers that, even if the list size is kept small and sites are allowed to join one-and-only-one set that it would be insufficient due to abuses where sites owned by different entities collude to join the same set.

A non-comprehensive list of areas I'd like to explore to mitigate the potential impact (which are not mutually exclusive) of the governance concern: make the max size of lists small enough to not need any approval (may not be practical due to the past concern about a lack of objective, user-intuitive criteria for when sites can join the same set); an independent entity to approve and/or revoke the ability to use a set, using a common set of criteria that multiple implementers agree to (a bit like CAs and web PKI, which carries its own set of challenges, though perhaps smaller in scope here); or "GREASE"ing of when First-Party Sets are used (e.g. disabling them some small percentage of the time and/or revoking the right to use them at all if the site doesn't function without them) to help sites prove/validate that they will function adequately for browsers and/or users who configure their browsers to limit or disallow the use of First-Party Sets.

Thanks for the healthy discussion!

Thanks @erik-anderson for this really constructive comment! Regarding governance, one of the topics we discussed in a special TAG session on Monday (raw minutes here) is what the governance is for. I think we still need to drill down on this. If the governance is to make sure that FPS members are part of the same organization then what is the definition of organization and how does that fit together with legal and regulatory? For example, we discussed how under some definitions Facebook and WhatsApp might be the same organization - and just yesterday there was some timely press coverage demonstrating how that assumption breaks down when you consider regulatory and legal requirements. So I think the proposal needs to be very clear about the requirements when it comes to governance - what is governance of first party sets trying to achieve? I would like to hear more about the the existing allow lists that have been discussed - e.g. Disconnect, Firefox, Safari. How big are they? How are they managed?

Thanks for the comments and discussion in the thread! I just wanted to share my point of view (not necessarily Brave in general at this point) on first-party sets, and why we don't think they'd be a good addition to the web platform.

1. Having related groups move their properties and applications to a single origin / eTLD+1 is a feature, not a bug. The origin is one of the few security and privacy boundaries we hope (even if imperfectly) users understand, and it''s emphasized in many browsers' UIs accordingly. If nothing else, the platform emphasizes that different origins deserve different levels of trust and caution. First-party sets, and expecting users to understand that different origins now have different amounts of "differentness" will make even these kinds of determinations even more difficult, and likely impossible to all but expert users.

2. If the concern is that clustering multiple "properties" onto a single origin will cause security problems (a problem I totally understand and buy and appreciate), lets try to fix that problem (possibly by allowing a single site declare sub-site/origin security / isolation boundaries), instead of trading privacy for security. For example, I know https://w3c.github.io/webappsec-suborigins/ didn't get broad support last time it was floated, but that seems like a place to build from.

3. A concern I have about first-party sets that I haven't seen discussed much yet (though apologies if i've missed it in minutes) is how, in a first-party-sets-world, to information users about the privacy implications of first-party sets before they visit the site. This seems extremely important (despite the prevalence of dark patterns on the Web, of folks changing URLs out from under users, etc). For example, right now in at least Safari, Brave and Firefox (and more generally browsers that block or partition 3p cookies / storage), I can have an Instagram account, and a Facebook account, and I can log into each as 1p, and know that there is no "web platform supported" (i.e. handwaving away things like fingerprinting, and other known-but-not-solved leaks on the web) way that Facebook and Instagram should be able to link those accounts. That may no longer be the case in a FPS world (if I understand most of the intended use cases for FPS so far).

TL;DR; for point 3, i'd be very interested to know more about how FPS-supporters imagine informing users of FPS, and their implications for tracking before the user commits to visiting a site.

Thanks again all for the discussion!

Appreciate the discussion and feedback, all!

Responding to @erik-anderson

My understanding is that the approval process for creating a set was added to the proposal in part because of concerns from other implementers that, even if the list size is kept small and sites are allowed to join one-and-only-one set that it would be insufficient due to abuses where sites owned by different entities collude to join the same set.

This is accurate. We updated the proposal to require an approval process in response to feedback from Safari and Firefox engineers. The original proposal allowed sites to assert domain relationships with some technically enforced limits and abuse prevention; accompanied by a blocklist when abuse is detected.

A non-comprehensive list of areas I'd like to explore to mitigate the potential impact (which are not mutually exclusive) of the governance concern: make the max size of lists small enough to not need any approval (may not be practical due to the past concern about a lack of objective, user-intuitive criteria for when sites can join the same set); an independent entity to approve and/or revoke the ability to use a set, using a common set of criteria that multiple implementers agree to (a bit like CAs and web PKI, which carries its own set of challenges, though perhaps smaller in scope here); or "GREASE"ing of when First-Party Sets are used (e.g. disabling them some small percentage of the time and/or revoking the right to use them at all if the site doesn't function without them) to help sites prove/validate that they will function adequately for browsers and/or users who configure their browsers to limit or disallow the use of First-Party Sets.

These are some great specific ideas! Since relying on technical mechanisms alone was previously recommended against, our current preference is to have an independent entity approve/revoke sets. GREASE'ing is an interesting idea, although it sounds like we need to come up with (a) strong alternative solutions to help site authors support the clients with the feature disabled; and (b) build robust detection mechanisms to aid revocation.

The other mechanism I had in mind, also inspired from the Web PKI, is transparency logs for any creation/updation/dissolution of sets for increased accountability and auditability.

Responding to @torgo

Thanks to the TAG for meeting with us! We appreciated the opportunity to provide additional context on the problem space, current handling of tracking protection in other major browsers, clarify the confusion around why our proposal will not interfere with SOP and other security mechanisms, and address other points in your feedback document. We will also address these in the explainer, and look forward with reviewing the edits with you.

If the governance is to make sure that FPS members are part of the same organization then what is the definition of organization and how does that fit together with legal and regulatory? For example, we discussed how under some definitions Facebook and WhatsApp might be the same organization - and just yesterday there was some timely press coverage demonstrating how that assumption breaks down when you consider regulatory and legal requirements. So I think the proposal needs to be very clear about the requirements when it comes to governance - what is governance of first party sets trying to achieve?

I am not a policy/legal expert; but I don't think FPS policy verification precludes site authors from conforming to regulatory and legal requirements. Since the assertion needs to be submitted by site authors, they will still have the agency to not form a FPS at all, or form multiple distinct and disjoint sets.

The primary goal of the FPS policy is to prevent abuse that may be possible by formation of sets with unrelated domains. We chose to use "same organization" because that appears to be the common language in tracking prevention policies published by multiple major browsers (see this section for excerpts). The DNT specification, which was developed within the W3C uses the language "share the same data controller as the referring site". If there is more precise or appropriate language to capture the essence of these existing policies, I'd be grateful for any advice.

I would like to hear more about the the existing allow lists that have been discussed - e.g. Disconnect, Firefox, Safari. How big are they? How are they managed?

My understanding is that in their default tracking protection modes, both Firefox and Edge (not Safari) use the Disconnect-dot-me trackers blocklist to selectively block third-party cookies on domains classified as trackers, and then apply an exception to those tracker domains when they appear as subresources on sites owned by the same organization as the tracker domain. The list of these collections of commonly owned domains is called the entities list, which is maintained on Github. I was unable to locate a documented policy for how domains get accepted to the entities list; but it appears to be done on a pretty ad-hoc basis when a compatibility bug is discovered by a browser engineer. I do not believe site authors are involved (unless by happenstance); which I think has the unfortunate consequence of mistakes such as com.com being listed as a CBS property, and yahoo.co.jp being listed as a VerizonMedia property.

First-Party Sets proposes to maintain a single list of related domain sets (similar to the entities list) in place of Disconnect's two lists (currently one blocklist, and one allowlist). Since this proposal would require site authors to submit sets of their domains, and have a published policy in concert with other enforcement mechanisms; we hope that it will be a much more rigorous approach to the issue of supporting multi-domain sites (which are exceedingly common on the modern internet) while also bringing meaningful privacy improvements to the web.

Thanks for sharing your feedback, @pes10k!

First-party sets, and expecting users to understand that different origins now have different amounts of "differentness" will make even these kinds of determinations even more difficult, and likely impossible to all but expert users.

Our intention is not to introduce multiple new levels of "different-ness"; but we hope that the users only have to understand two types of boundaries - a security boundary (origin), and a privacy boundary (First-Party Sets, where a singleton FPS is equivalent to registrable domain).

I don't think it is correct to say that the origin serves as a privacy boundary on the web today, because AFAIK even where third-party cookies are currently blocked, third-party is equivalent to cross-domain, not cross-origin.

Regarding user understanding, I would venture to say that FPS offers the opportunity to highlight the notion of this privacy boundary in the browser UI, in addition to continuing to highlight the origin/domain as the security boundary.

I wonder if forcing multiple distinct sites onto a common registrable domain could also potentially have the opposite effect of what we want, by training users to pay more heed to the subdomain (because it directly indicates the brand/app name) than the domain, and unwittingly teach them to make security decisions solely based on subdomains.

2. If the concern is that clustering multiple "properties" onto a single origin will cause security problems (a problem I totally understand and buy and appreciate), lets try to fix that problem (possibly by allowing a single site declare sub-site/origin security / isolation boundaries), instead of trading privacy for security. For example, I know https://w3c.github.io/webappsec-suborigins/ didn't get broad support last time it was floated, but that seems like a place to build from.

Note that even if we do manage to corral together every platform feature that treats the site/domain as a security boundary, build new features, and resolve the issues over multiple years:

• We still need to develop an interim compat mechanism like the Disconnect list or First-Party Sets.
• Site authors still have to account for older clients/browsers that don't have these solutions in place. It seems like an undue burden to require that site authors maintain substantially different patterns of deployment for different clients.

For example, right now in at least Safari, Brave and Firefox (and more generally browsers that block or partition 3p cookies / storage), I can have an Instagram account, and a Facebook account, and I can log into each as 1p, and know that there is no "web platform supported" (i.e. handwaving away things like fingerprinting, and other known-but-not-solved leaks on the web) way that Facebook and Instagram should be able to link those accounts.

This is certainly not true for Firefox's Default ETP mode, because the Disconnect entities list groups facebook.com and instagram.com as one entity (reference).

TL;DR; for point 3, i'd be very interested to know more about how FPS-supporters imagine informing users of FPS, and their implications for tracking before the user commits to visiting a site.

It seems like this problem would exist even in a world without FPS, no? Since your recommendation was that Facebook should have to redirect instagram.com to instagram.facebook.com; it seems like browsers would then have to inform users of the redirect before committing that navigation?

I don't think it is correct to say that the origin serves as a privacy boundary on the web today, because AFAIK even where third-party cookies are currently blocked, third-party is equivalent to cross-domain, not cross-origin.

and

This is certainly not true for Firefox's Default ETP mode, because the Disconnect entities list groups facebook.com and instagram.com as one entity (reference).

Good point and thank you for the correction. I only mean that the "site" is usually the privacy boundary.

The Moz folks should correct me if I'm wrong, but current Firefox partitions all cookies by default, not just sites labeled by disconnect (with some exceptions for compat / existing SSO flows). But, in general, the site is a privacy boundary in at least Firefox, Safari and Brave (though with differences between them on how to handle cases that expect privacy harming, cross site data flows currently).

But, I don't think we should take those exceptions as signifying that cross eTLD+1 flows are some necessary property of the web. We should take such exceptions (ether centrally curated a la disconnect, or user curated a la Storage Access API) as what they are, an artifact of the Web having serious privacy problems today, and issues we should be sure to solve going forward.

We still need to develop an interim compat mechanism like the Disconnect list or First-Party Sets.

This is interesting! Is the intent for FPS to be a temporary, for-a-year-or-two, bridge to something else? If so, that is very interesting and encouraging, but its surprising given the FPS conversations I've listened in on (which is << all of them, so grain of salt). But, many of the proponents of FPS in the calls I've participated in seem like "we want cross site information flows forever and always" and not "just for a year until X ships". Could you clarify here?

Or, in other words, if FPS is meant to be an interim solution, an interim between the the status quo and what?

It seems like this problem would exist even in a world without FPS, no? Since your recommendation was that Facebook should have to redirect instagram.com to instagram.facebook.com; it seems like browsers would then have to inform users of the redirect before committing that navigation?

Apologies but I'd don't quite follow the concern above. My point is that either 1) there should be a firm privacy boundary between instagram.com and facebook.com which the browser should enforce, or 2) Facebook should make it clear to users that there is no such boundary with www.facebook.com and instagram.facebook.com.

But what would be really really bad if it appeared to users like there was a privacy boundary between IG and FB, but there really wasn't one (or a significantly weakened one) bc of FPS.

But there wouldn't be any need for notification in the example you gave. Users would still know that things they did on instagram.com were different and isolated from facebook.com and instagram.facebook.com, regardless of any bouncing (unless you're describing pushing identifiers across storage areas, a la bounce tracking, in which case, thats another problem to be solved and is being tackled in PrivacyCG).

This is certainly not true for Firefox's Default ETP mode, because the Disconnect entities list groups facebook.com and instagram.com as one entity (reference).

Good point and thank you for the correction. I only mean that the "site" is usually the privacy boundary.

The Moz folks should correct me if I'm wrong, but current Firefox partitions all cookies by default, not just sites labeled by disconnect (with some exceptions for compat / existing SSO flows). But, in general, the site is a privacy boundary in at least Firefox, Safari and Brave (though with differences between them on how to handle cases that expect privacy harming, cross site data flows currently).

That's right, noting that our partitioning feature is not yet on by default. Let me add a bit more context to what we've shared before when this was brought up in a past First Party Sets discussion:

We started using Disconnect's entity list as part of our original "Tracking Protection" feature, which is a content blocking feature. When blocking content, it's absolutely necessary to have an entity list for web compatibility reasons. For example, Facebook's fbcdn.net domain is on Disconnect's blocklist and would thus be blocked when visiting facebook.com. This resource blocking would make that page entirely unusable. When we developed ETP (i.e., cookie blocking based on the same blocklists) we continued to have it respect the entity list, in part for consistency across our blocklist-based features and in part out of an abundance of caution to avoid web compat issues. I'm sure there are some instances where the entity list prevents cookie blocking breakage, but I suspect that many of the rules on that list aren't "required" for a cookie blocking feature.

As Pete said, we believe site is the right privacy boundary for passive cookie access. Our state partitioning feature applies to all third parties and does not use an entity list. We have no plans to add one. It does automatically relax partitioning under a variety of circumstances documented here for webcompat reasons. But we're working to figure out how we can narrow these over time with the goal of removing them entirely at some point.

Our state partitioning feature applies to all third parties and does not use an entity list. We have no plans to add one. It does automatically relax partitioning under a variety of circumstances documented here for webcompat reasons. But we're working to figure out how we can narrow these over time with the goal of removing them entirely at some point.

@englehardt - Is my understanding correct that this mechanism is only in place for opt-in ETP Strict mode? Are you on track to make it the default?

Are you investing in APIs other than Storage Access API to help remove the current heuristics?

Our state partitioning feature applies to all third parties and does not use an entity list. We have no plans to add one. It does automatically relax partitioning under a variety of circumstances documented here for webcompat reasons. But we're working to figure out how we can narrow these over time with the goal of removing them entirely at some point.

@englehardt - Is my understanding correct that this mechanism is only in place for opt-in ETP Strict mode? Are you on track to make it the default?

We intend to continue to ship it to a broader set of Firefox users with the goal of enabling it by default. I don't have a timeline to share, but you can follow along with our next step (private browsing windows) here: https://bugzilla.mozilla.org/show_bug.cgi?id=1698810.

EDIT: One additional note for clarity. By default, Firefox already partitions many APIs by site. It's the storage APIs that have webcompat implications that aren't yet partitioned by default.

Are you investing in APIs other than Storage Access API to help remove the current heuristics?

Nothing else to share at the moment.

The Moz folks should correct me if I'm wrong, but current Firefox partitions all cookies by default, not just sites labeled by disconnect (with some exceptions for compat / existing SSO flows).

Per this announcement the "partitioning by default" mode is only in the opt-in Strict mode, with additional heuristics in place. As @englehardt mentions above, there is additional work to be done to completely remove reliance on lists, heuristics, and consent prompts that are hard to understand.

Or, in other words, if FPS is meant to be an interim solution, an interim between the the status quo and what?

Sorry, perhaps an Oxford comma or two would have helped with my statement. 😅

I meant to refer to the Disconnect-me lists as an interim solution that Firefox/Edge are using. I did not intend to refer to FPS as an interim solution. In my personal opinion, we haven't yet seen viable solutions to remove this mechanism in the future, so it may be premature to say that we can. (I would be thrilled to be proven wrong in the future)

However, if other browsers would prefer to engage with FPS as a medium-term solution, I think that would still be a vast improvement over reliance on lists and heuristics. Blocklists are never exhaustive, they fail open, and are prone to errors such as those evidenced in the Disconnect entities list. Heuristics cause platform predictability issues.

Apologies but I'd don't quite follow the concern above. My point is that either 1) there should be a firm privacy boundary between instagram.com and facebook.com which the browser should enforce, or 2) Facebook should make it clear to users that there is no such boundary with www.facebook.com and instagram.facebook.com.

The point I was anchoring on in your statement was about prompting the user before committing the navigation. If a user navigated to instagram.com, they may not anticipate that it will redirect to instagram.facebook.com. So it seems like if the site author configured such a redirect, it would automatically allow joining of identity across facebook.com and instagram.facebook.com without (or before) the user noticing. This would suggest that the browser should prompt the user before that redirect happens, in order to confirm that it meets the user expectations.

But there wouldn't be any need for notification in the example you gave. Users would still know that things they did on instagram.com were different and isolated from facebook.com and instagram.facebook.com

This goes back to your previous assertion that the domain name in the URL is the only way to communicate the privacy boundary to the user. However, FPS also offer the opportunity to communicate that boundary as a collection of domains. I think this question is orthogonal to the point you were making about prompting the user before committing a navigation.

Per this announcement the "partitioning by default" mode is only in the opt-in Strict mode, with additional heuristics in place. As @englehardt mentions above, there is additional work to be done to completely remove reliance on lists, heuristics, and consent prompts that are hard to understand.

Understood, but also as @englehardt says, their goal is to ship this by default. I only mean that its not the case that FF thinks the Disconnect list (or similar curated exceptions, like FPS) is a good solution to the problem being discussed here; their goal is exception-less partitioning by site.

The point I was anchoring on in your statement was about prompting the user before committing the navigation. …

The browser doesn't need to alert people before a redirect happens as long as there are strong privacy boundaries between sites. Users always know that their behavior on instagram.com is isolated from their behavior on facebook.com or instagram.facebook.com, regardless of what redirection is happening. If there is no way that facebook.com gets privileged access to instagram.com storage (or vise versa) w/o user intention; there is nothing to notify anyone about. Whatever the top level site is decides what storage is accessible.

Where pre-navigation / pre-redirection notification would be needed is if what I did on facebook.com wasn't isolated from instagram.com. Then you would need a "you're about to visit facebook.com. On that page, instagram.com etc will be able to access their 1p storage and share it with facebook.com. Are you sure you want to expose your IG behavior with FB in this way?" notification.

Or, in other words, if FPS is meant to be an interim solution, an interim between the the status quo and what?

Sorry, perhaps an Oxford comma or two would have helped with my statement. sweat_smile

I meant to refer to the Disconnect-me lists as an interim solution that Firefox/Edge are using. I did not intend to refer to FPS as an interim solution. In my personal opinion, we haven't yet seen viable solutions to remove this mechanism in the future, so it may be premature to say that we can. (I would be thrilled to be proven wrong in the future)

However, if other browsers would prefer to engage with FPS as a medium-term solution, I think that would still be a vast improvement over reliance on lists and heuristics. Blocklists are never exhaustive, they fail open, and are prone to errors such as those evidenced in the Disconnect entities list. Heuristics cause platform predictability issues.

I agree that there is more work to do in figuring out solutions for moving away from heuristics. However, FPS by no means obviates the need for heuristics While FPS could certainly fix some instances of breakage (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1620530), there are many more where it can't be used because the breakage is cross-"entity".

Here are some examples that we've seen in Firefox:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1578068 - embedded Disqus widgets. They partially work right now because of the our pop-up heuristic, but image upload is still broken.
• https://bugzilla.mozilla.org/show_bug.cgi?id=1653552 - Scroll's integration doesn't work. The Storage Access API could be used to fix this, though in past PrivacyCG meetings Scroll has expressed concerns about their inability to know which users to prompt.
• https://bugzilla.mozilla.org/show_bug.cgi?id=1656171 - federated login providers (Google, Facebook, Twitter)
• https://bugzilla.mozilla.org/show_bug.cgi?id=1660446 - also federated login providers
• https://bugzilla.mozilla.org/show_bug.cgi?id=1654064 - even more federated login providers
• https://bugzilla.mozilla.org/show_bug.cgi?id=1658257 - Zendesk cross-site auth. Already fixed with the Storage Access API (in FF and Safari at least)!

The Storage Access API could be (or already has been) used to fix these issues. FPS could not. The benefit of the Storage Access API is that it can also be used to fix many of the types of things we might want to fix with FPS. Either way, we are going to have to work through a more generic approach to resolving breakage from reliance on cross-site state and we prefer to focus our efforts on these generic solutions.

By focusing on a generic solution to user-controlled cross-site state, we also lessen the chance that we give large conglomerates a competitive advantage when it comes to UX. I don't think it's great if a multi-site company is granted passive storage access between all of their sites, while single-site companies that rely on embedded content from other sites (owned by other companies) are forced into showing a storage access API prompt. Of course one could argue that these multi-site companies will then combine everything under a single site, but we've heard during our calls that companies want to maintain the separate branding and identity between their sites.

Hi @krgovind - Just thinking about this:

The primary goal of the FPS policy is to prevent abuse that may be possible by formation of sets with unrelated domains.

In the context of the governance discussion. I think it's clear from the discussion we've had on this issue and in our calls that "same organization" is not a technical concept – it's a social / legal / regulatory concept. So I'm wondering whether "preventing abuse" could be expressed in a purely technically way? (For example, the "a site can only be part of one set" requirement.) The transparency mechanism you mentioned above also could serve as a deterrent to abuse.

[Sorry for the delayed responses, last week got away from me. :) ]

The browser doesn't need to alert people before a redirect happens as long as there are strong privacy boundaries between sites. Users always know that their behavior on instagram.com is isolated from their behavior on facebook.com or instagram.facebook.com, regardless of what redirection is happening. If there is no way that facebook.com gets privileged access to instagram.com storage (or vise versa) w/o user intention; there is nothing to notify anyone about. Whatever the top level site is decides what storage is accessible.

@pes10k - Perhaps I'm not completely understanding the scenario here. Is it that the user has an existing session with instagram.com at the time that either (a) a FPS is formed with facebook.com and instagram.com; or (b) instagram.com redirects to instagram.facebook.com? So you're recommending a one-time prompt when the FPS is first formed in case (a), the user should be asked if they're okay with resuming their previous session with instagram.com? And that if there is a browser where (b) leads to a similar situation where a session created on instagram.com is shared with instagram.facebook.com via, say, a URL parameter, a similar prompt should be displayed?

I agree that there is more work to do in figuring out solutions for moving away from heuristics. However, FPS by no means obviates the need for heuristics While FPS could certainly fix some instances of breakage (e.g., https://bugzilla.mozilla.org/show_bug.cgi?id=1620530), there are many more where it can't be used because the breakage is cross-"entity".

@englehardt : Indeed, FPS will not, and should not, be used to solve these scenarios where cross-entity exchange of user identity is currently performed. We are investing in purpose-built APIs to support these cross-entity use-cases. Since third-party cookies are pretty versatile, it is important to think about what these use-cases need - some may need partitioned cookies, some may need WebID (for federated login), some may need to use limited entropy APIs (such as Trust Tokens, or conversion measurement), etc.

The Storage Access API could be (or already has been) used to fix these issues. FPS could not. The benefit of the Storage Access API is that it can also be used to fix many of the types of things we might want to fix with FPS. Either way, we are going to have to work through a more generic approach to resolving breakage from reliance on cross-site state and we prefer to focus our efforts on these generic solutions.

I think FPS can be used to whittle down many of the use-cases where users may feel compelled to grant storage access today. If you have any statistics around commonly granted pairs of storage access, it may be an interesting case study to see if there are alternate solutions for them. My primary concern with the Storage Access API is that the prompt is not something that most users can understand, and that it will suffer the same consent fatigue problems as the widespread "cookie notice" prompts. Since browsers that currently support Storage Access API only require it under specific circumstances (heuristics, blocklists, etc.), I suspect we haven't seen it's full-scale impact.

Also, note that developers that have adopted Storage Access API might need to implement extra user friction/notices to ensure that users grant them storage access so site functionality isn't broken. As an example, see how Zendesk shows a "Safari cookie requirements" notice and instructs users to click "Allow".

By focusing on a generic solution to user-controlled cross-site state, we also lessen the chance that we give large conglomerates a competitive advantage when it comes to UX. I don't think it's great if a multi-site company is granted passive storage access between all of their sites, while single-site companies that rely on embedded content from other sites (owned by other companies) are forced into showing a storage access API prompt. Of course one could argue that these multi-site companies will then combine everything under a single site, but we've heard during our calls that companies want to maintain the separate branding and identity between their sites.

I want to correct two assumptions here:

• First-Party Sets is something that is trying to solve a generic need of multi-domain sites. Multi-domain sites are not unique to large conglomerates.
• I am not suggesting that cross-party usecases should all be forced to using the Storage Access API. I would like to ask that perhaps we need to understand the requirements better and recommend purpose-built APIs as appropriate for those use-cases.

Hi @krgovind - Just thinking about this:

The primary goal of the FPS policy is to prevent abuse that may be possible by formation of sets with unrelated domains.

In the context of the governance discussion. I think it's clear from the discussion we've had on this issue and in our calls that "same organization" is not a technical concept – it's a social / legal / regulatory concept. So I'm wondering whether "preventing abuse" could be expressed in a purely technically way? (For example, the "a site can only be part of one set" requirement.) The transparency mechanism you mentioned above also could serve as a deterrent to abuse.

@torgo - We did initially take the approach of using purely technical mitigations for abuse, and also provided for a revocation-style blocklist in the cases that abuse was later detected. However, the "Incentives to Form Sets" concern raised by @johnwilander on privacycg/first-party-sets/issues/6 and @ehsan on privacycg/first-party-sets/issues/7 led us to pivot to a policy-based allowlist. It might be interesting to have a discussion on whether a transparency mechanism would successfully address this specific concern.

The Storage Access API could be (or already has been) used to fix these issues. FPS could not. The benefit of the Storage Access API is that it can also be used to fix many of the types of things we might want to fix with FPS. Either way, we are going to have to work through a more generic approach to resolving breakage from reliance on cross-site state and we prefer to focus our efforts on these generic solutions.

I think FPS can be used to whittle down many of the use-cases where users may feel compelled to grant storage access today. If you have any statistics around commonly granted pairs of storage access, it may be an interesting case study to see if there are alternate solutions for them.

We don't collect this kind of data from our users, but I agree that in the future "raw" cross-site cookie access should be a last resort. This applies to FPS as well, though.

My primary concern with the Storage Access API is that the prompt is not something that most users can understand, and that it will suffer the same consent fatigue problems as the widespread "cookie notice" prompts.

Sorry for going slightly off-topic but I think we should discuss these claims about prompt fatigue on the Storage Access API because they seem connected to the idea of having a consent step for something like FPS. There are valid concerns to showing permission prompts, but I'd like to show why I'm quite confident that the Storage Access API prompt is in a good position to avoid them:

• Concern: "Users might not understand the Storage Access API prompt." Yes, not all of them will, despite our best efforts to give simple explanations. Will that have bad consequences? Probably not. All available Firefox Telemetry (e.g. on notifications) shows that users do not tend to blindly accept unwanted or surprising prompts. On the contrary, more spammy, invasive and surprising prompts have overwhelming rates of denial in our statistics. This can be further influenced by prompt design. I'm a bit surprised that the Chrome team is making the argument that prompts are generally bad and confusing when we have seen many examples of extremely powerful features such as WebUSB being gated behind permission prompts brought forward by Chrome folks.

• Concern: "Bad actors will start spamming this prompt at every opportunity and/or coerce the user into accepting it." We have already fought many unrelated instances of prompt spam and abuse and I'm not worried about this prompt, because the cost/benefit ratio just doesn't add up for non-essential use cases. To create anything remotely resembling a tracking network a third party would have to beat the strict storage access API requirements and get user consent several times. If this happens, it will be possible for browsers to detect and prevent.

• Concern: "Too many sites need this, users will be annoyed." From several months of running State Partitioning + Storage Access API in pre-release Firefox it's become clear that there are just a few very common valid use cases of cross-site cookies such as federated login, and a long tail of other diverse uses. Storage Access API is able to solve both, but only the former will really account for "prompt fatigue" and as such we should discuss limited or consent-oriented solutions to these common problems. Granting a powerful feature without consent because consent would be annoying is not what we want.

• Concern: "This is another instance of the (in-content) cookie consent prompt." I don't think that this is a fair comparison. As mentioned before, this prompt is entirely controlled by the user agent and can not be designed in a way that tricks the user into giving more consent than they would normally want to. It's also entirely contextual and bound to specific cookie use of a named third party, while at least in Europe the common interpretation of the law seems to be "show this big dialog at the beginning and we're safe". This is literally impossible with the Storage Access API.

Since browsers that currently support Storage Access API only require it under specific circumstances (heuristics, blocklists, etc.), I suspect we haven't seen it's full-scale impact.

Safari does not use any heuristics to relax showing the prompt AFAIK.

Also, note that developers that have adopted Storage Access API might need to implement extra user friction/notices to ensure that users grant them storage access so site functionality isn't broken. As an example, see how Zendesk shows a "Safari cookie requirements" notice and instructs users to click "Allow".

Yes, this pre-prompting pattern has been recommended by both the Chrome and Firefox teams in the past. It can obviously be done badly but it's in the interest of the site to give the user as much context as possible as to why they are seeing a permission prompt and what the functionality is needed for. How this is presented is largely something that the first party can control (in this case the first party chose to leave it to Zendesk). I don't see any malicious use here, though I suspect that this could also have been solved by only state partitioning without any kind of cross-site cookie access, which is something we should encourage in the future.

First-Party Sets is something that is trying to solve a generic need of multi-domain sites. Multi-domain sites are not unique to large conglomerates.

I am not suggesting that cross-party usecases should all be forced to using the Storage Access API. I would like to ask that perhaps we need to understand the requirements better and recommend purpose-built APIs as appropriate for those use-cases.

What are the requirements for FPS that could be built using APIs that either ensure better user consent or reduce the amount of information available to third parties?

We don't collect this kind of data from our users, but I agree that in the future "raw" cross-site cookie access should be a last resort. This applies to FPS as well, though.

To be clear, I was asking for statistics to understand whether the use-cases in question could be solved in a better way, while preserving privacy principles; whether with solutions such as FPS, or something else. :)

And by privacy principles, I mean prevention of tracking across "first parties" (as Mozilla's own anti-tracking policy states: "A first party is a resource or a set of resources on the web operated by the same organization, which is both easily discoverable by the user and with which the user intends to interact.").

I'm a bit surprised that the Chrome team is making the argument that prompts are generally bad and confusing when we have seen many examples of extremely powerful features such as WebUSB being gated behind permission prompts brought forward by Chrome folks.

Sorry, I'm not trying to say that all permission prompts are bad. I'm saying that prompts need to make sense to the user within the context of the task they are trying to achieve. IMO, the existing versions of the SAA prompt that I've observed across browsers are hard to understand for anyone who doesn't know what "cookies and site data" means.

I think the difference between SAA, and say, notifications permissions; is that users will probably soon learn that their site functionality is probably going to break if they didn't say "Allow" to SAA. I guess my hypothesis is: will user activity on "good" sites teach them to accept such prompts everywhere else?

If we expect that users will see the SAA prompt very rarely in their workflow, perhaps there won't be a fatigue problem; but I worry that it's too heavy a hammer - both in terms of placing the onus on users to understand why an embed needs cookies, and in terms of allowing unrestricted access to storage - that is trying to solve for many exceedingly common usecases that exist on the web today. While SAA is a temptingly simple solution to me (as a browser engineer), I can't help wanting to find ways to reduce usage/usecases for SAA. :)

Granting a powerful feature without consent because consent would be annoying is not what we want.

Absolutely. Chrome is following a similar mantra. For powerful features such as federated login, we are also investing in WebID which similarly asks for user consent. Perhaps something like Secure Payment Confirmation will be able to serve a similar purpose for payments.

In my opinion, most 3ps have the scale (since they typically provide services for many 1ps) and resources to adopt an appropriate purpose-built API with strong privacy properties. First-Party Sets allows 1ps to keep legacy behavior without violating anti-tracking principles (we checked across multiple browsers' policy statements).

Safari does not use any heuristics to relax showing the prompt AFAIK.

I was thinking of the "Temporary Compatibility Fix: Automatic Storage Access for Popups" section described here; but maybe this has since been removed?

What are the requirements for FPS that could be built using APIs that either ensure better user consent or reduce the amount of information available to third parties?

We are well aligned that any availability of information to third-parties must be either gated by a meaningful prompt, or by limiting/aggregating the information. The point though is that "third-party" isn't well defined on the web today. IMO, forcing site authors of the same "first-party" to move everything to a common registrable domain, with the only other available alternative being to add new consent prompts, would be unfortunate. It is entirely possible that some use-cases for FPS could make do with a promptless solution such as partitioned state, but many can't.

And that if there is a browser where (b) leads to a similar situation where a session created on instagram.com is shared with instagram.facebook.com via, say, a URL parameter, a similar prompt should be displayed?

@krgovind Im wondering if part of the differing point of view is around what other privacy improvements we hope or expect the platform to have going forward, and so whether the right standard to measure FPS against is the web today, or some possible future web where other privacy harms are addressed.

I understand you to be saying "there is no need to warn a browser user of the weakened privacy boundaries between sites in a FPS before they visit a site in that FPS, because cooperating 1st parties could already circumvent domain-privacy-boundaries. For example, cooperating sites could by linking 1p storage areas though URL parameters on navigation. (i.e. bounce tracking, or tracking through link decoration)"

If I've captured that correctly, then maybe disagreement around whether FPS weakens privacy boundaries scrapes down to whether we think cross-site-tracking through URL decoration / bounce tracking is a solvable problem. If you don't think bounce tracking / link decoration a solvable problem, then I think I understand your point of view, that FPS doesn't really weaken the ability of users to understand privacy boundaries on the Web, bc that ability is pretty weak in the first place.

On the other hand, if you think efforts like https://github.com/w3ctag/design-reviews/issues/342 might be successful (my view) then FPS really does weaken privacy boundaries (and the ability of users to reason about them) just as browsers are trying to strengthen the origin privacy boundary (through bounce tracking protections, among many other efforts).

@krgovind, does that seem like an accurate way of capturing different views on it, and as a plausable explanation for the disagreement here?

@krgovind regarding technical only enforcement. The question is: is there a way that this technology could work without needing a registration system at all? That would eliminate the need for a centralised static list of any kind, would eliminate the need for registration with different UAs, would eliminate the centralization issue, and it would eliminate a lot of compleixity in how it works. It's not clear that the registration criteria that the PR talks about would stop the kind of abuse case that we envision, specifically ad networks using this technology effectively as third party cookies after third party cookies have been deprecated. Given that, would it be possible to design the technology itself to mitigate against those abuse cases? I see the issue referenced above but is this being given serious consideration?

Hi we are tracking some good discussions going on in the Privacy CG. It looks like there is some substantive discussion going on there about enforcement policies. Our view is still that any kind of centralized policy-based enforcement of which parties may claim to be together in a set is problematic and that a technical-only enforcement mechanism may be preferable. However they may not be a technical-only enforcement mechanism that works in the real world because of the complex structure of ownership of legal entities and data sharing legislation globally. We await the outcome of these discussions in the Privacy CG and would be happy to spend time reviewing PRs as appropriate.

I've opened an issue about fragmentation concerns if FPS is implemented differently in different UAs: https://github.com/privacycg/first-party-sets/issues/66

Also related to @martinthomson's comment in https://github.com/privacycg/first-party-sets/issues/62:

there is a switch that we know how to turn on and off, but we don't know what it is hooked up to.

If this switch is not hooked up to the same thing, that a failure of this process.

@torgo - I'd like to address your questions from earlier in the thread, because we've been able to put more thought into the policy enforcement, and published this expanded UA policy proposal a few weeks ago.

It's not clear that the registration criteria that the PR talks about would stop the kind of abuse case that we envision, specifically ad networks using this technology effectively as third party cookies after third party cookies have been deprecated. Given that, would it be possible to design the technology itself to mitigate against those abuse cases? I see the issue referenced above but is this being given serious consideration?

Ad networks would not be able to use this technology as third-party cookies because of two requirements:

• UA Policy requirement: Only domains within the same FPS can access cross-site (third-party) cookies; and only domains that conform to the UA policy can belong to the same FPS. Since the proposed UA policy requires that the "Domains must have a common owner, and common controller.", this would disqualify ad networks that typically operate over groups of domains that have separate owners/data controllers.
• Technical requirement: No domain can appear in more than one set (reference to explainer text); so even if an ad network is able to convince a site author to include the ad domain in the site's FPS; that same ad domain cannot participate in another site's FPS.

Our view is still that any kind of centralized policy-based enforcement of which parties may claim to be together in a set is problematic and that a technical-only enforcement mechanism may be preferable. However they may not be a technical-only enforcement mechanism that works in the real world because of the complex structure of ownership of legal entities and data sharing legislation globally. We await the outcome of these discussions in the Privacy CG and would be happy to spend time reviewing PRs as appropriate.

@rhiaro also touched on similar concerns around centralization, and scalability, which I captured in privacycg/first-party-sets/issues/48, and just responded to. Please take a read, and let me know if you think that our proposal strikes the right balance between interoperability, scalability, centralization, and abuse-resistance.

I've opened an issue about fragmentation concerns if FPS is implemented differently in different UAs: privacycg/first-party-sets#66

Thanks @rhiaro. I just responded on the issue, please take a look.

Also related to @martinthomson's comment in privacycg/first-party-sets#62:

there is a switch that we know how to turn on and off, but we don't know what it is hooked up to. If this switch is not hooked up to the same thing, that a failure of this process.

I responded on the issue, and I believe the comment was aimed at attempting to understand the purpose/goal for FPS. As I responded, the primary purpose of FPS is to define a "privacy boundary", or more explicitly, to provide a technical mechanism that the browser can use to distinguish between what is "first-party" and what is "third-party". It turns out that groups within the W3C have on many occasions defined principles around what "first-party" means (DNT specification, TAG Privacy Principles), but there is no technical manifestation of this principle. Due to the lack of an existing mechanism, browsers have approximated "resource hosted at same registrable domain" to mean "first-party"; but as many browsers are moving towards "on-by-default" privacy protections with rigorous restrictions based on the "first-party" distinction, the approximation is no longer sufficient.

We discussed this again in our meeting last week. Having read the updated UA Policy document, we think this is an improvement. We have a couple more questions now though:

• Can you tell us more about the use cases for a single party with multiple domains placing those domains into different sets?
• We agree it's useful to mandate a particular UI surface to make sure web users are aware of all parties in common in a set as this gives sites less opportunity to potentially mislead people. What are your expectations around normative language regarding the UI? What are your thoughts about how it would be possible to mandate and test for in the specification?
• We are concerned about the international applicability and future-proof-ness of language like "parent company" with respect to the owner/controller of sites/domains. Have you thought about how this would work in the face of different corporate structures?
  • Further, entities frequently use structures like parent companies to obscure their true ownership; this can get very complex very fast and data is not always available to easily verify the connection. How does this impact the job of the independent enforcement entity? "Random spot checks" by the enforcement entity may not be sufficient when there is the potential for huge amounts of data leakage which it would not be possible to claw back if it was shared erroneously (data leaks by other means happen all the time, but it doesn't mean we want to add tools that let the UA facilitate them). Given the low barrier to registering a domain, one company could potentially register many dozens/hundreds of domains in order to participate ('illegally' as it were) in different sets with other organisations, and has a chance to fly under the radar of the enforcement entity for some time, possibly indefinitely.
  • Related is the worry about web users actually recognising the names of the controlling entities, or with sibling entities, when in practice they are only used to interacting with one or two particular subsidiary brands. It may be that presenting this information to a person visiting the site is functionally meaningless - they aren't really giving informed consent to data being shared within the set.

There is some language about pop-ups as a potential solution, which we think would be an unfortunate direction to go in.

In general, we remain concerned about the dependencies on things that don't fit as part of a web standard.

The other abuse angle to this is data sharing between domains that are legitimately owned by the same organisation (in a legal sense of eg. an ultimate parent company controlling the orgs that have registered the domains) but where doing so would subvert end user expectations about how their data might be used.

One example might be state-owned enterprises, where a government could have a controlling interest in organisations across a variety of different sectors, and may put them all into a valid FPS and thus be able to track users between them. Common branding in this case might also be expected by the user but identity tracking or other data sharing remains undesirable. Another might be an individual has a controlling interest in a variety of organisations in different sectors, and because of the way company ownership is defined in the relevant jurisdiction can legitimately (in a legal sense) put them in an FPS, which would pass vetting by the enforcement entity, but still result in a tracking network that is harmful to users.

Other alternate company structures I'm thinking about are things like co-operatives which might be owned equally by members. Domains registered by the co-op can be in the same FPS but be used for a variety of purposes and result in harmful tracking.

I'm sure I saw or heard mention of a maximum set size at some point, but can't find that now. What is your current thinking on a reasonable maximum set size? I would be inclined to suggest it needs be small enough that it isn't burdensome for an end user to grasp the scale of by reading the list if necessary (ie. not like the giant list of a hundred companies you've never heard of that come up when you click "Learn more..." on an EU accept/reject cookie prompt..)

What you touched on during our call yesterday about the "user journey" between participating sites may be key to establishing "legitimate interest" in placing domains in a FPS, but agree that this is going to be very challenging to enforce, or even verify.

Thanks for the feedback @rhiaro !

• Can you tell us more about the use cases for a single party with multiple domains placing those domains into different sets?

We don't have specific use-cases in mind; but this is something we have been recommending to organizations that own a very large portfolio of domains, many of which maybe be unrelated from the user's perspective (e.g. one set of domains that's related to fast food services, and another set related to insurance products). Our recommendation is that entities "strive to create sets consistent with user understanding and expectations."; and in some cases that may lead to an entity splitting up their domains into multiple disjoint sets.

• We agree it's useful to mandate a particular UI surface to make sure web users are aware of all parties in common in a set as this gives sites less opportunity to potentially mislead people. What are your expectations around normative language regarding the UI? What are your thoughts about how it would be possible to mandate and test for in the specification?

Could you clarify whether this is referring to the user agent's UI Treatment; or the recommendation (footnote 2) in the UA Policy document that site authors surface group identity to users via some UI surface in the content area?

If the former; since the UI surface does not affect how developers write code around this feature, it's not clear to me that it needs to be specified. If the TAG's feedback is to include normative language around browser UI, we can consider either (a) using SHOULD to indicate the goals for the UI (e.g. "User agents SHOULD surface First-Party Sets information to users on an appropriate UI surface in order to aid their understanding of how their browsing data may be joined across domains"); or (b) using MAY to recommend possible surfaces (e.g. "User agents MAY surface a website's FPS information on UI surfaces related to site identity or information. Examples of such surfaces are the Origin Info Bubble, and Settings page in the Chrome browser.").

• We are concerned about the international applicability and future-proof-ness of language like "parent company" with respect to the owner/controller of sites/domains. Have you thought about how this would work in the face of different corporate structures?

The phrase "parent company" is referenced in footnote#2 in this section. It is used in a bulleted list of items indicating that "it is the site author's responsibility to ensure that at least one of the following is true". We list many possible scenarios that could achieve the high-level objective of surfacing either common group identity, or indicate same-party affiliation to users. As we encounter additional scenarios, we are able to expand this list, as long as it is consistent with the high-level objective.

"Random spot checks" by the enforcement entity may not be sufficient when there is the potential for huge amounts of data leakage which it would not be possible to claw back if it was shared erroneously (data leaks by other means happen all the time, but it doesn't mean we want to add tools that let the UA facilitate them).

The intention for the random spot checks vs. manual checking of every single submission was to balance preventing abuse and scalability. As footnote #1 in this section calls out "...an organization would need to publicly declare that they own and control the sites listed in their proposed set. ... Organizations could be held responsible for fraud or misrepresentation either in direct legal action from users or by regulators that enforce either privacy or consumer protection laws on behalf of users."

• Related is the worry about web users actually recognising the names of the controlling entities, or with sibling entities, when in practice they are only used to interacting with one or two particular subsidiary brands. It may be that presenting this information to a person visiting the site is functionally meaningless - they aren't really giving informed consent to data being shared within the set.

One way to address this could be to highlight/bubble up the domains/brands that the user has previously interacted with.

There is some language about pop-ups as a potential solution, which we think would be an unfortunate direction to go in.

I believe this is a reference to footnote#2 here which lists possible UX patterns that a site could use to denote group identity/affiliation to the user in its content area; but not a specific recommendation to use pop-ups. For example, if a website would like to list several sibling domains, it may provide provide a UI affordance that opens a pop-up menu listing all the sibling domains.

Perhaps the concern here was around pop-up windows? (Our intention was to say "pop-up menu")

In general, we remain concerned about the dependencies on things that don't fit as part of a web standard.

I think this is referring to the fact that the proposal depends on a UA Policy? I believe there is precedence for this in other parts of the web platform. A couple of examples that come to mind:

• The definition of site / registrable domain (which cookies, and other parts of the web platform use extensively) depends on the Public Suffix List which has an acceptance process, and alludes to the role that user agents play ("Browsers do what browsers do...").
• Browsers perform TLS certificate validation before connecting to https:// URLs, which relies on the the Web PKI infrastructure that is governed by a complex set of rules developed by the CA/Browser Forum.

The other abuse angle to this is data sharing between domains that are legitimately owned by the same organisation (in a legal sense of eg. an ultimate parent company controlling the orgs that have registered the domains) but where doing so would subvert end user expectations about how their data might be used.

Does the privacy policy of the website govern this data usage? I'm wondering if the two requirements to (a) surface group identity/association information; and (b) serve a common privacy policy address this?

One example might be state-owned enterprises, where a government could have a controlling interest in organisations across a variety of different sectors, and may put them all into a valid FPS and thus be able to track users between them. Common branding in this case might also be expected by the user but identity tracking or other data sharing remains undesirable. Another might be an individual has a controlling interest in a variety of organisations in different sectors, and because of the way company ownership is defined in the relevant jurisdiction can legitimately (in a legal sense) put them in an FPS, which would pass vetting by the enforcement entity, but still result in a tracking network that is harmful to users.

Other alternate company structures I'm thinking about are things like co-operatives which might be owned equally by members. Domains registered by the co-op can be in the same FPS but be used for a variety of purposes and result in harmful tracking.

Thank you! I don't have an answer for handling this right now, but I've captured it in privacycg/first-party-sets/issues/75

I'm sure I saw or heard mention of a maximum set size at some point, but can't find that now. What is your current thinking on a reasonable maximum set size?

This is still an open issue: privacycg/first-party-sets/issues/29

I think this is referring to the fact that the proposal depends on a UA Policy? I believe there is precedence for this in other parts of the web platform. A couple of examples that come to mind:

• The definition of site / registrable domain (which cookies, and other parts of the web platform use extensively) depends on the Public Suffix List which has an acceptance process, and alludes to the role that user agents play ("Browsers do what browsers do...").
• Browsers perform TLS certificate validation before connecting to https:// URLs, which relies on the the Web PKI infrastructure that is governed by a complex set of rules developed by the CA/Browser Forum.

The TLS cert validation is a good example. Question: could the first party set enforcement be accomplished using existing data available through certificate validation or existing data in the DNS registration system? This would address the internationalization issues raised as well and would not require spinning up an independent enforcement authority...

Hi @krgovind we discussed today at our virtual f2f... We're concerned we may be going around in circles on this. One idea we had to break the cycle is to refocus our attention on a specific use cases linked to FPS - e.g. Same Party Cookies or possibly CHIPS. This would enable us to go back to the problems we're trying to solve and maybe find better ways to try to solve them. Would that make sense to you? We could then take a look at the specific user needs addressed by those designs and evaluate FPS on the basis of those needs. Yes: we had previously said that we would hold off on reviewing Same Party Cookies until we reviewed FPS - but by talking about Same Party Cookies in isolation we may be able to make some progress here.

Question: could the first party set enforcement be accomplished using existing data available through certificate validation or existing data in the DNS registration system? This would address the internationalization issues raised as well and would not require spinning up an independent enforcement authority...

We did consider whether EV certificates, which perform a kind of organizational validation could be used for First-Party Sets; but were discouraged from going in that direction by TLS/WebPKI experts. The primary reason is that doing so would couple TLS certificates (which are intended for connection encryption), with FPS (which is intended to convey a notion of site identity); and that coupling site identity with encryption would actually result in bad outcomes for users. Please see this comment by Ryan Sleevi for more details.

I do agree that either using the information in the DNS registration system, or plugging in to the domain registration process may be the right long term direction. Regarding use of existing/publicly accessible information from domain lookups; we would likely need to account for failover situations - e.g. when the domain owner has set up privacy protection; so perhaps plugging FPS validation into the domain registration process itself might be the thing to consider?

Hi @krgovind we discussed today at our virtual f2f... We're concerned we may be going around in circles on this. One idea we had to break the cycle is to refocus our attention on a specific use cases linked to FPS - e.g. Same Party Cookies or possibly CHIPS. This would enable us to go back to the problems we're trying to solve and maybe find better ways to try to solve them. Would that make sense to you? We could then take a look at the specific user needs addressed by those designs and evaluate FPS on the basis of those needs. Yes: we had previously said that we would hold off on reviewing Same Party Cookies until we reviewed FPS - but by talking about Same Party Cookies in isolation we may be able to make some progress here.

Is the intention to zoom in on specific applications for FPS? I am happy for us to start with SameParty cookies and CHIPS. However, does it also make sense to also touch upon the intended use of FPS in other platform features that are currently in development, such as sharding FedCM's directed identifiers by FPS, and navigational tracking mitigations exempting navigations across domains within the same FPS from anti-tracking mitigations? I think the purpose of FPS serving as a privacy boundary for the web really manifests itself when we look at the full expanse of applications.

Hi @krgovind we discussed today at our virtual f2f... We're concerned we may be going around in circles on this. One idea we had to break the cycle is to refocus our attention on a specific use cases linked to FPS - e.g. Same Party Cookies or possibly CHIPS. This would enable us to go back to the problems we're trying to solve and maybe find better ways to try to solve them. Would that make sense to you? We could then take a look at the specific user needs addressed by those designs and evaluate FPS on the basis of those needs. Yes: we had previously said that we would hold off on reviewing Same Party Cookies until we reviewed FPS - but by talking about Same Party Cookies in isolation we may be able to make some progress here.

Is the intention to zoom in on specific applications for FPS?

(Speaking only for myself) The intent is to work backwards from intended applications. If all of the intended applications are cases of weakening the existing privacy boundary, it seems to me that we shouldn't add a platform primitive that enables that. If some of the intended applications instead tighten things up, then it would be very valuable to try to figure out how to design a platform primitive that enables that without also accidentally enabling weakening or dissolving the existing privacy boundary.

and navigational tracking mitigations exempting navigations across domains within the same FPS from anti-tracking mitigations?

I think this is the first time I've heard about this particular use case, and I don't see anything about it in the NTM draft. Could you or @jyasskin tell us more? I asked @pes10k but he wasn't familiar with this idea.

I wanted to return to a point @pes10k raised back in April:

2. If the concern is that clustering multiple "properties" onto a single origin will cause security problems (a problem I totally understand and buy and appreciate), lets try to fix that problem (possibly by allowing a single site declare sub-site/origin security / isolation boundaries), instead of trading privacy for security. For example, I know https://w3c.github.io/webappsec-suborigins/ didn't get broad support last time it was floated, but that seems like a place to build from.

I had trouble following the discussion that followed, and it's been almost a year since then, but could we come back to this?

(Speaking only for myself) The intent is to work backwards from intended applications.

We recently wrote up privacycg/first-party-sets/pull/84 which expands on the intended applications, please take a look.

If all of the intended applications are cases of weakening the existing privacy boundary, it seems to me that we shouldn't add a platform primitive that enables that. If some of the intended applications instead tighten things up, then it would be very valuable to try to figure out how to design a platform primitive that enables that without also accidentally enabling weakening or dissolving the existing privacy boundary.

Is this statement assuming "site" as the privacy boundary? I think it's important to keep in mind that we have not seen comprehensive privacy protections enabled by default in major browsers, that haven't run into serious site compatibility and functionality issues due to the usage of "site" as the privacy boundary. For instance, most browsers deploy a combination of heuristics, and blocklists/allowlists to deal with these issues.

and navigational tracking mitigations exempting navigations across domains within the same FPS from anti-tracking mitigations?

I think this is the first time I've heard about this particular use case, and I don't see anything about it in the NTM draft. Could you or @jyasskin tell us more? I asked @pes10k but he wasn't familiar with this idea.

Just to clarify, the discussion about FPS applying to bounce/navigation tracking prevention has happened in the context of FPS between WebKit and Chrome engineers (see PR linked above). I was linking to privacycg/nav-tracking-mitigations primarily to provide a canonical reference to the problem definition.

I wanted to return to a point @pes10k raised back in April:

2. If the concern is that clustering multiple "properties" onto a single origin will cause security problems (a problem I totally understand and buy and appreciate), lets try to fix that problem (possibly by allowing a single site declare sub-site/origin security / isolation boundaries), instead of trading privacy for security. For example, I know https://w3c.github.io/webappsec-suborigins/ didn't get broad support last time it was floated, but that seems like a place to build from.

I had trouble following the discussion that followed, and it's been almost a year since then, but could we come back to this?

@hober - Here was my response to that comment:

Note that even if we do manage to corral together every platform feature that treats the site/domain as a security boundary, build new features, and resolve the issues over multiple years:

• We still need to develop an interim compat mechanism like the Disconnect list or First-Party Sets.
• Site authors still have to account for older clients/browsers that don't have these solutions in place. It seems like an undue burden to require that site authors maintain substantially different patterns of deployment for different clients.

Subsequently, @pes10k asked if we intend for FPS to be an interim compat mechanism; and I responded with:

I meant to refer to the Disconnect-me lists as an interim solution that Firefox/Edge are using. I did not intend to refer to FPS as an interim solution. In my personal opinion, we haven't yet seen viable solutions to remove this mechanism in the future, so it may be premature to say that we can. (I would be thrilled to be proven wrong in the future)

However, if other browsers would prefer to engage with FPS as a medium-term solution, I think that would still be a vast improvement over reliance on lists and heuristics. Blocklists are never exhaustive, they fail open, and are prone to errors such as those evidenced in the Disconnect entities list. Heuristics cause platform predictability issues.

I believe that's where that line of discussion concluded.

Is this statement assuming "site" as the privacy boundary? I think it's important to keep in mind that we have not seen comprehensive privacy protections enabled by default in major browsers, that haven't run into serious site compatibility and functionality issues due to the usage of "site" as the privacy boundary. For instance, most browsers deploy a combination of heuristics, and blocklists/allowlists to deal with these issues.

This is very surprising. Safari, Brave and Tor all use site as the default privacy boundary, and Firefox already does in some modes and intends to in all modes (according to previous comments in FPS threads). Every iOS browser (by choice or not) also uses the site as the privacy boundary by default and w/o heuristics and block/allow lists.

Further, as you mention, some browsers ship lists and heuristic based exceptions to the boundary. But, at least in some cases, these browsers think site-as-boundary is correct, but compat risk is too high. Further entrenching leaks and exceptions to site-as-boundary through FPS would make this problem worse, not better.

More broadly though, I think this conversation is still in exactly the same place it was almost a year ago (wrt privacy), with some vendors and parties interested in FPS as a primitive to build on, but no multi-implementor interest (i.e., other than Blink/Chromium) in FPS as a privacy feature.

I suggest then to both the FPS proposers and the PrivacyCG chairs that PrivacyCG is not the correct place for FPS, and that the work would be better moved to another venue in W3C.

Every iOS browser (by choice or not) also uses the site as the privacy boundary by default and w/o heuristics and block/allow lists.

Safari does use heuristics for their bounce tracking prevention feature. WebKit has expressed interest in using FPS to replace those heuristics so they can enable it more broadly (as well as to improve their implementation of Storage Access API, and Login Status API). This application is also captured in privacycg/first-party-sets#84 and was discussed on the Feb-24-2022 PrivacyCG call. (PrivacyCG requires multi-implementer interest to adopt a proposal as a work item, and it was adopted there due to WebKit's support for incubation)

Further, as you mention, some browsers ship lists and heuristic based exceptions to the boundary. But, at least in some cases, these browsers think site-as-boundary is correct, but compat risk is too high. Further entrenching leaks and exceptions to site-as-boundary through FPS would make this problem worse, not better.

Site-as-boundary’s “compat risk is too high” is exactly the motivation for FPS. The fact that compatibility impact has been too high to ship without exceptions indicates that the web needs something more nuanced, at least in the medium term. We can use the FPS policy controls to ensure that users are still protected. Unifying on a single cross-browser system for these exceptions will also make it easier to understand these use-cases and constraints, and use the policy controls to push the web toward the desired direction in the long run.

Hi all. We have revisited this again in our W3C TAG meetings this week.

The TAG has agreed to close this review. We began our review buy writing this statement, and we have since dedicated extensive time to providing feedback and engaging with the spec authors to improve this design, and do not feel that our suggestions are resulting in evolution of the feature.

We remain concerned about a number of issues, including the privacy implications of this design, and the problems that could be created with any of the proposed governance models for first party sets. Equally, we haven't been able to come up with a governance model that would avoid the same problems.

These concerns extend to any spec or feature with a dependency on first party sets, though we look forward to seeing additional privacy-related specs that are decoupled from FPS.

We understand that this work is moving to WICG, and will be happy to review future documents that address the necessary use cases after further incubation and demonstrated support from other stakeholders in the W3C community.

Hello,

I'd like to request a re-review of the First-Party Sets proposal. This proposal has changed significantly since the previous design review, and we believe we have addressed points in the TAG's feedback. Specifically:

• The new proposal has abandoned the SameParty cookie attribute in favor of integrating with the Storage Access API (which already has multi-browser-vendor support) and the requestStorageAccessForOrigin proposal.
• 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 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 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, 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. 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. The recently-published submission guidelines 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 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!

Thank you for the update and the detailed explanation of the changes. Just to let you know: we discussed this in our virtual f2f last week and we agreed we like the direction this is going in. We're still formulating some questions to ask - and the same regarding requestStorageAccessForOrigin.

There's now an I2S out for this; was the TAG able to discuss?

https://groups.google.com/a/chromium.org/g/blink-dev/c/7_6JDIfE1as/m/wModmpcaAgAJ

@slightlyoff right now the focus is more on requestStorageAccessFor. Do you have any thoughts you can share there?

Hi all. We are looking at this at our TAG f2f. We're noting a pause in the I2S — can you tell us more context about this? How might any consequences might impact the design of FPS, especially any of the aspects we've discussed in this review?

@hadleybeeman Thank you for checking!

We announced a pause in our rollout of the feature in Chrome because we discovered a regression in some of our metrics. Our analysis suggests that the regression may be due to the fact that our implementation currently blocks all network requests on the completion of the set change handling algorithm described here. The algorithm clears out all site data for any site that is leaving an existing set, so we had previously chosen the more conservative route of blocking all network requests until this operation was complete, in order to avoid being in a state where a site that is about to have its data cleared receives requests before the clearing is complete. We are currently waiting for our tentative fix (optimizing this implementation) to propagate, and hope to validate it in the next couple of weeks.

With regards to how that impacts this review; your question made us realize that we had previously neglected to specify this implementation detail in the algorithm, so we've now written up a PR at WICG/first-party-sets/pull/169 that describes this behavior, along with a note recommending that user agents optimize for request latency by being smarter about what requests/fetches to block.

Hi TAG!

We wanted to provide you with some updates:

• We are renaming "First-Party Sets" to "Related Website Sets", which we think better reflects its purpose. We have begun to gradually update relevant artifacts.
• We have increased the "Associated Subset" domain limit slightly from three to five, in response to industry feedback. More on this choice here.
• The feature has now been rolled out to 100% of Chrome stable users. As I mentioned in my last comment, we had previously paused the rollout due to some regressions caused by our implementation to prevent privacy leaks on list changes. We have now resolved that issue, but have a remaining race condition in the Chromium implementation which occurs exceptionally rarely in practice - in those rare scenarios, if a URL is on a the list of sites whose data needs to be cleared due to a set membership change and that URL is loaded during startup, those loads might complete before we've cleared data. We are tracking this issue here.

We recognize that there are some substantial changes to the API since our original review.

We acknowledge that our use of the term origin in this feedback may have lead to confusion, and that we should have used the term site in this context. However, the fundamental points raised in that original review stand.

The primary change here is a reliance on the Storage Access API. However, the decision to automatically grant requests has the same net effect as in the original proposal. We do not think that labeling an auto-grant decision as "implementation-defined" is acceptable, as that defines how the web is experienced by websites and users.

The argument has been made that other browsers ship heuristics that do much the same thing. Our argument has been and continues to be that these heuristics are essentially a workaround and that we should not be building new technologies into the platform that cement this way of working. Furthermore, we observe that many browsers are working to eliminate the need for these heuristics.

We are therefore re-closing this review.