Is FPS good for users?

[martinthomson]

First-party sets (FPS) violates some central principles of the modern web. Specifically, the priority of constituencies puts user interests first; and the Vegas Rule says that what happens on one site stays with that site.

The ideal these principles describe is one where the identity that a person presents to a site is under their control. In particular, the identity that a user presents to a site is something that is specific to that site.

FPS substitutes the user-visible notion of a domain with the abstraction of "organization". In doing so, it removes control over how users interact with sites.

FPS would deprive users of a choice about whether information propagates across an organization through their various interactions with that organization. In place of control, users are given the sop of being able to discover the extent to which they have lost control. FPS proposes new, untested mechanisms that aim to improve visibility of shared ownership, which are not an adequate substitute for control.

So, the issue name is not an accident.

If there is any benefit to users, that benefit is at best indirect. Users only benefit to the extent that the sites they value might be better able to function.

The Bargain

This gets to the central concern. People have built sites that rely on cross-site cookies. Taking those cross-site cookies and storage away makes those sites stop working.

Long term, the answer to that is likely something browser-mediated. That might be storage access (I don't think that it is, for reasons similar to the ones I describe here) or it might be something more narrowly focused like a federated identity-specific API (in exemplar only, that proposal is a very long way from being realized).

Obviously, those sorts of long-term things take time. In the interim, it makes sense to provide sites that depend on cross-site state help. Early implementations of in-browser controls for cross-site state have exemption lists. Those lists are a manifestation of browser-specific policies about what sort of information transfer is needed to keep the web functioning for most users.

FPS attempts to codify the practice of building lists by allowing sites to self-declare. It replaces browser-curated allow lists with self-declaration of the same, plus browser-curated deny lists. Recently, there was an attempt to define a singular policy for those deny lists, so that sites would have more certainty about compatibility. To give due credit, if you start from the assumption that lists are necessary, this is a good thing as uncertainty and inconsistency only hurts smaller actors.

The effect of all of this is that the short-term solution becomes a permanent one. A FPS declaration that complies with agreed standards for inclusion carries an expectation that the bargain is respected. There is usually no time limit on these bargains on the web. Pursuing standardization for FPS effectively makes it an indefinite commitment.

The browser-curated lists constitute no such promise. Indeed, there is an understanding that the lists are temporary. This is obviously imperfect - and increasingly so over time - but the intent is clear. And, partly owing to the inconsistency in how lists are implemented, no site can rely on them.

All of this is to say that we're in a transition period. In the previous state, activity on any site could be joined through the use of cross-site cookies. In the liminal state we're currently in (for most browsers, if not most users), a limited number of sites retain that capability through a patchwork of special exclusions. In the state we seek, users can interact with sites and present a different identity to each site without that information being used without their knowledge and direct engagement.

FPS would be better than the old state of the web. But if we are to consider it part of the future of the web, it does not appear to be a good deal for users.

History of this Issue

I apologize for opening an issue that is effectively a duplicate of numerous other issues, but it seems like this central point is not being addressed in any meaningful way. This issue has been raised in a few different ways, but I'm trying to make a cogent, singular issue that addresses what I think is the most important question to address.

This issue has been discussed in a number of places. I reviewed open issues and found clear statements to the same effect in #6, #7, #14, #30, and likely more closed issues. There are also mentions of the notion or issues adjacent to it in #19, #21, #22, #23, #28, #31, #40, #49, #50, and likely more closed issues.

There is a lot of cost and complexity to building and maintaining a system like the one that is proposed here, with lots of interesting implications for how sites, intermediaries, and adjacent services operate. I see most of the other issues being related to that. But answering the big question in the negative makes a lot of that moot.