Alternative to centralized GitHub repository for submission of First-Party Sets (FPS)

[brownwolf1355]

The current FPS proposal (https://github.com/WICG/first-party-sets) requires FPS be submitted to a GitHub repository and authentication of source is accomplished by requiring the FPS files be served from the /.well-known/first-party-set location on every site that makes up the set (https://github.com/GoogleChrome/first-party-sets/blob/main/FPS-Submission_Guidelines.md#set-level-technical-validation).

Since the FPS files are public and authenticated by virtue of being a /.well-known resource, the requirement for submission to a centralized GitHub adds additional overhead and burden to the site operator. Maintenance of the GitHub repository itself adds additional complexity and overhead (e.g. removal of abandoned FPS).

An alternative approach would be to simply scan websites periodically for their /.well-known/first-party-set file and dynamically aggregate the global list of FPS. An example of this kind of scan is the Well-Known Resource Index (https://well-known.dev/). This eliminates the need for a centralized repository and the burden of submission by site-owners. This has been the approach of JournalList (https://journallist.net) in aggregating trust.txt declarations (also a well-known URI resource).

There are two issues that this alternative approach raises:

1. Parsing failures: If the scan has trouble fetching/parsing a file, or validating FPS associations across multiple sites (i.e. the set "primary" disagrees with a "member"); do we silently drop that entry, or do we log the failure and notify the site operator? Since FPS membership is required for access to cross-site cookies, a failure in set inclusion could mean that a site is potentially broken/unusable. With the GitHub process, we run these checks as soon as a pull request is submitted, and the submitter is notified immediately that their entry will be rejected and provide the cause of failure.

The Well-Known Resource Index scan captures these types of errors in his scan and reports them. Some examples:

• https://well-known.dev/sites/fastcompany.com
• https://well-known.dev/sites/okpress.com
• https://well-known.dev/sites/quinlan-tawakoninews.com#trust_txt

The action taken may depend on the cause of the failure. In all cases the site operator should be notified of the failure specifics (e.g., a pointer to the public scan status). If previous scans were successful, rolling back to the last scan is an option, but there would need to be a time limit on how long the failures are tolerated before dropping the FPS. Stating the obvious, it is the responsibility of the site operator to ensure their well-known FPS file is accessible to FPS scanning bots and accurate. With JournalList and trust.txt members are notified of issues with their trust.txt files upon discovery.

2. Transparency log: Having a single public location where users and civil society can examine creation/modification of sets provides transparency for users, and increased accountability on behalf of site operators. Perhaps an automatically aggregated version can also provide this (assuming that it hosts the compiled list in a publicly-accessible location), but there is some amount of indirection involved.

The Well-Known Resource Index is an example of such a public transparency log. It is a single place where one can see and query the status of millions of sites for 10 well-known resources.

[krgovind]

@brownwolf1355 Thanks so much for filing this idea as per our email discussion! I think you proposed good solutions for the two concerns I had raised (handing parsing failures, and providing a transparency log).

At this time, we are preparing to ship First-Party Sets in Chrome, and have set up a centralized GitHub repository to accept set submission. Since we hope that FPS will fill in a gap with existing web platform solutions in preparation for third-party cookie deprecation, we expect to learn from how FPS is leveraged by site authors. As the list of sets grows over time, and the ecosystem adapts to a post-third-party cookie world, perhaps we can also mature the process to the point where we can consider alternative decentralized schemes such as the one you proposed. With the current process, we expect to institute set lifetimes, which will allow us to evolve the intake process over time.

I am adding the "future" label to this issue, so we can revisit once the submission process matures.

[estein-de]

@krgovind your link to https://github.com/GoogleChrome/related-website-sets/blob/main/FPS-Submission_Guidelines.md#set-lifetime is broken.

[mhamann]

Let me add my vote for this issue/feature.

I think the way RWS is implemented currently (requiring a submission to a centralized JSON file that has to be downloaded by browsers) is a huge problem. The web is meant to be distributed and this breaks that contract.

Chrome has oversized market power whereby developers will be forced into using RWS in order to not break existing functionality, so Google needs to be extremely cautious in how these changes are designed and deployed.

RWS, as it stands currently, should never see the light of day. It's a huge step backwards in terms of functionality. I get the goal and am definitely a privacy advocate, but without the changes outlined in this issue, it should not be rolled out widely.

The WICG is a body meant to explore and incubate future web standards. Neither the WICG nor the W3C itself should be involved in user interactions throughout the web itself "at runtime." RWS changes that and puts the WICG/W3C (and really just Google at this moment) in between users and organizations. How is that acceptable to anyone??