Re: Apple WebKit's feedback on the First Party Sets proposal

John,

Thanks for your summary of issues with FPS in your # General feedback on FPS. It is helpful to have it in consolidated in one place.

I would like to share some of our experience with trust.txt that may help inform this discussion. You may recall we presented our work[1] on the January 13, 2022 call.

I would like to focus on just two elements of the trust.txt file that relate to domain ownership/control (there are other relationships that can be expressed). The specification identifies two attributes to express this relationship, “control=“ and “controlledby=“. The site that is the controlling entity has a “control=“ entry it its trust.txt file that points to the controlled site and the controlled site has a “controlledby=“ entry in its trust.txt file that points to the controlling entity’s site. This can be used to express a symmetric relationship between the controlling site and the controlled site. One claim of control absent the other indicates the relationship is invalid, so false claims of control can be self evident. This also means that at most only two sites need to be queried to validate this relationship.

In our case, the use of trust.txt is entirely voluntary and self-disclosed, which essentially is a simple means by which an entity can publicly disclose their FPS, should they have one.

The intent of trust.txt is to make public and transparent the relationships between websites in a standard machine and human readable format and not to obscure them. This approach avoids the issue of picking winners and losers, since it is entirely under the control of each site individually. It also addresses the issue of scaling a solution, since there are no barriers to publishing a trust.txt file. 

It does not address the question of validating FPS by a third-party (admittedly a tough nut to crack). However, by being a simple means of publicly disclosing an FPS there is nothing that prevents a third-party (or multiple third-parties) from using this to inform any validation they may wish to perform.

With respect to the size of an FPS, in our experience sites that do have an FPS identify somewhere between 1 and 5 controlled sites not sharing a common domain. Admittedly, we don’t yet have a huge sample size (on the order of three thousand referenced sites), but this does seem to be representative.

I would be happy to discuss further on tomorrow’s call.

Ralph

[1] The trust.txt spec can be found at: https://journallist.net/reference-document-for-trust-txt-specifications). Since the last time we talked about trust.txt it has been registered with IANA as a well-known resource: https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml

> On May 24, 2022, at 4:42 PM, John Wilander <wilander@apple.com> wrote:
> 
> 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.
>