Apple WebKit's feedback on the First Party Sets proposal

Hi Privacy CG!

Our meeting on Thursday <https://github.com/privacycg/meetings/blob/main/2022/telcons/05-26-agenda.md> will cover First Party Sets. We wanted to share our collected feedback on the proposal. Please see below. We shared this with the editors about a month ago.

   Regards, John (Apple WebKit)


As far as we know, at least Google explicitly intends to use First Party Sets, or FPS, to allow cross-site cookies and storage within sets. We will include feedback on that even though FPS by itself doesn’t have to mandate what it’s used for.

# Feedback on partitioning and cross-site cookies in the context of FPS
We have already implemented partitioning of state and HTML storage. We think that is where the web platform should be.
We have already implemented blocking of cross-site cookies and the Storage Access API as a general purpose way for cross-site resources to get cookie access. We think either that or partitioned cookies are where the web platform should be.
We are against cross-site cookie access by default in all of its forms, FPS or other (this feedback was provided in for instance issue #53 <https://github.com/privacycg/first-party-sets/issues/53#issuecomment-901234193>). We think cross-site cookie access was an unfortunate mistake early in the development of the web and we have worked since the very first version of our browser to rein in that mistake. We reached that goal in early 2020 <https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/> and do not intend to regress that privacy protection.
We think major browsers allowing cross-site cookies by default, for instance through FPS, would hold the web back, cause fragmentation, and cement legacy functionality (this feedback was provided in issue #53 <https://github.com/privacycg/first-party-sets/issues/53#issuecomment-901234193>). Policy based on FPS that would lead to this risk is explicitly mentioned in the proposal: ‘ensures continued operation of existing functionality which would otherwise be broken by blocking cross-domain cookies (“third-party cookies”)‘.

# General feedback on FPS
We don’t think users in general understand or know which companies or consortia own which domains. This means that FPS has the risk of hiding relationships between websites which would otherwise have to be more explicit and potentially understood by users. Setting browser policy based on joint domain ownership will very likely go against the user’s interest in many cases, violating the responsibility of the user agent. Relaxing data partitioning because of joint domain ownership is one such example.
We think large domain sets are especially troublesome from a user perspective since there will be no reasonable way to show or tell the user about the (vast) set. We think set sizes over five domains become troublesome in this way. This feedback has been provided multiple times throughout the lifetime of the FPS proposal, for instance in issue #29 <https://github.com/privacycg/first-party-sets/issues/29#issuecomment-784756055>, but the proposal doesn’t seem to address this.
We are worried that curation of an FPS list will:
Create winners and losers where some have the means to get on the FPS list and others don’t.
Create barriers to entry when new players have to wait to get onto shipping versions of the FPS list.
Cause inconsistencies across browsers because of different versions of the FPS list.
Put non-western countries and businesses at a disadvantage since all major web browser implementors are western.
Get into serious challenges of what “party,” “business entity,” “domain owner,” etc mean. For example, some brands have different owners in different countries.
Create a barrier to entry for new browsers where they must either create a compatible curated list or get permission from an established player to use theirs. Community governance and maintenance of the list and free access to it would be required to not create such a barrier and community governance is not easy. See for instance the Public Suffix List which is referred to directly in the proposal. The proposal mentions that an “independent entity must verify” and we don’t know what that independent entity will be.
We are worried that per-site declaration of FPS will:
Incentivize the creation of domain consortia to get some kind of preferred treatment. This could potentially undo the privacy work we and others have done for a decade or more. See for instance our comment on issue #17 <https://github.com/privacycg/first-party-sets/issues/17#issuecomment-784760262>.
Lead to false claims of domain ownership and a huge burden to try to police it.
Lead to either page load performance hits as the user agent needs to check a multitude of domains if they belong to the current set, or lead to page load failures due to stale cached FPS data.
Issue #6 <https://github.com/privacycg/first-party-sets/issues/6> contains our original concerns on “Incentives to Form Sets” and “Personalized Sets.” (Thanks, Kaustubha, for finding this link for us since it was filed against a different repo.)

# Feedback on use cases other than relaxed partitioning

We don’t currently believe that a trustworthy and equitable version of FPS can be created. That said, were that to happen, we think such a technology could potentially be useful in the following ways:
Allow single sign-on within a set while being stricter on login-like data transfer such as link decoration across domains which are not in the same set. This requires that sets contain metadata instructing the user agent which domain is the single sign-on domain (this feedback was provided in issue #28 <https://github.com/privacycg/first-party-sets/issues/28>). Note that we mean single sign-on as authentication between domains with a joint owner. We are not referring to federated logins here.
Allow for different wording in cross-site data prompts such as the one for the Storage Access API or for WebAuthn. The different wording would be for domains within a set (this feedback was provided in issue #53 <https://github.com/privacycg/first-party-sets/issues/53#issuecomment-901234193>).
Enhanced reporting to users on which parties has data on them and how that landscape changes over time.