Request for position: First-Party Sets

[cfredric]

Request for position on an emerging web specification

• WebKittens who can provide input: @johnwilander @annevk

Information about the spec

• Spec Title: First-Party Sets
• GitHub repository: https://github.com/WICG/first-party-sets

Design reviews and vendor positions

• Mozilla standards-positions issue: First-Party Sets mozilla/standards-positions#350

Anything else we need to know

First-Party Sets proposes a new web-platform mechanism to declare that a collection of related domains is a First-Party Set.

This proposal has previously been discussed in PrivacyCG and WebKit has indicated a position in May 2022. However, the First-Party Sets proposal has undergone some significant changes since that position was published, in particular:

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

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

Given the extent of the changes (particularly as they relate to some more recent WebKit comments), I'd like to request a "re-"review of the First-party Sets proposal. Thanks!

[annevk]

The feedback below was previously shared and reproduced to preserve the original formatting. We think it's still applicable to this revised proposal. Given that, I plan to label this "position: oppose" on January 6 given the holidays.

---

As far we know, 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 storage by top-level site. 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 also provided at Is FPS good for users? WICG/first-party-sets#53 (comment)). 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 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 also provided at Is FPS good for users? WICG/first-party-sets#53 (comment)). 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 at Enforcement against formation of large sets  WICG/first-party-sets#29 (comment), 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 at Expand Set Eligibility Beyond a Single Organization WICG/first-party-sets#17 (comment).
  • 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.
• Some of our original feedback was posted on a personal repo and copied over. For instance Exploring the potential for abuse WICG/first-party-sets#6 contains our concerns on “Incentives to Form Sets” and “Personalized Sets.”

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 File System Access API (Local Filesystem) #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 also provided at Is FPS good for users? WICG/first-party-sets#53 (comment)).
• Enhanced reporting to users on which parties has data on them and how that landscape changes over time.

[johannhof]

Hi @annevk, thank you for the response.

However, the feedback you pasted was actually already shared verbatim in May 2022 on the PrivacyCG mailing list. It is referring to the previous version of the proposal, and Webkit’s feedback from that thread was an important consideration in developing our updated version which we published in July 2022. As an example, John Wilander said in the PrivacyCG discussion that Webkit would “be fine with browsers allowing prompt-less cross-site cookies and storage within a set as long as it went through the SAA path”, which we try to enable now. There are various other pieces of feedback here that aren't quite fitting anymore.

As we're seriously trying to incorporate feedback from other browser vendors, even if it is just to help us maintain interoperability with non-FPS environments, we'd appreciate if you could take another look at the updated proposal. If it helps, we can share which of the feedback you posted above should be reconsidered now.

[johnwilander]

Hi, Johann! We will look at the updates for sure. We're just making sure that positions and feedback provided in other formats earlier is collected here. Also, some mailing lists don't archive HTML emails so the formatting gets all messed up. The above is the latest we've said publicly.

[annevk]

Apologies for not directly responding to the changes. Though as said above we think our original feedback is still very much applicable. It’s also the more significant and fundamental feedback with regards to FPS as the changes made very much assume FPS works, which we are not convinced of.

As for the three bullet points in OP:

• Subsets further complicate FPS and don’t seem to help with the concerns raised, specifically around governance and interoperability.
• On the surface the removal of SameParty seems good, but with the proposed requestStorageAccessFor()/requestStorageAccessForOrigin() there is still an equivalent amount of cookie sharing possible. As we commented in Consider requestStorageAccessFor Method privacycg/storage-access#107 allowing the top-level site to ask the user on behalf of embedded sites without involvement from those embedded sites is incorrect and can be harmful to users. The proposal essentially only kinda work with FPS, but FPS itself does not seem workable as per our prior feedback.
• It’s our understanding that for requestStorageAccess() you propose that (at least for the first call) the user activation requirement is still in effect, but that no dialog is shown to the user. As indicated in our prior reply we do think the user needs to be informed at this point. If FPS was somehow workable it could perhaps be used to influence the language shown to the user.
  • The user activation requirement is very important for interoperability, so it's good to see that being preserved.

[krgovind]

@annevk - Thanks for reviewing the updated proposal. We have some clarifications:

• Regarding subsets:
  • The goal for introducing subsets was not to address interoperability, but to help with governance (see below for more on this). We think the fact that cross-site cookie access is gated on Storage Access API invocations is what helps with interoperability, independently of how subsets are structured within a set. Browser vendors could choose different handling for different subsets, but that allows user agents to provide a varied user experience (which may be based on user configuration), while achieving interop. As you noted, we place the same user activation requirement across all subsets to ensure interop.
  • Regarding governance, the subsets approach allows us to place numeric limits on "associated domains" to a small number as recommended in your feedback. We proposed a limit of three domains for the "associated" subset. On the other hand, since the number of possible country-code TLDs (ccTLDs) is large - IANA supports 250+ variants as of writing - we don't place numeric limits, but can determine via technical checks that a set of domains are indeed ccTLD variants of each other.
• Regarding your other concerns about governance, we believe the detailed submission guidelines that we published since opening this issue addresses many of them.
  • We achieve scalability, a level-playing field, and equitable access for site authors around the world by making the process completely objective and validated automatically via technical checks. The checks are run on every PR submission, and any failures immediately reported.
  • We removed the need for ownership and privacy policy validation by an enforcement entity (which is open to subjectivity); and instead rely on a combination of technical checks, numeric limits, and browser restrictions appropriate to each subset category.
  • Access to the list will indeed be open to any user agents that intend to use the list to implement FPS. Similar to the Public Suffix List and HSTS Preload List.
• Regarding your concern on requestStorageAccessForOrigin allowing top-level sites to ask for storage access without involvement from the embedded site, we believe our proposed change in Add privacy and security sections privacycg/requestStorageAccessFor#12 will address this by requiring that the embedded site also invoke requestStorageAccess in addition to the top-level site invoking requestStorageAccessForOrigin.
• Regarding whether a user dialog should be shown upon invocation of requestStorageAccess; the spec allows a dialog to be shown, but does not require it. As noted in the Leveraging the Storage Access API section, we propose that user agents incorporate FPS into the implementation-defined decision making around whether the storage access request results in an auto-grant/auto-deny/user-prompt. So user agents may choose to show the user dialog with additional information about set membership instead of auto-granting.

Please let us know if you see any other unresolved issues.

[hober]

Closing as we've identified our position.