Changes to a domain's first-party-set.json after github submission

[brownwolf1355]

The use of a centralized github repository for aggregation of First Party Sets creates a cache consistency issue. It is possible that a domain's first-party-set.json becomes modified, either as a result of a merger, reorganization, bad actor, the site is taken down, or simply human error, and does not get resubmitted to the github repository. The github repository is effectively the cache, while the first-party-set.json at each domain may reflect the current state of their FPS.

As I understand it, either at each new FPS submission or during the weekly merge, the contents of the github repository is checked against the first-party-set.json files for all domains that have submitted an FPS. If discrepancies are discovered through this process (a cache miss) the respective domain administrator is notified of this discrepancy and is requested to update their submission or correct their first-party-set.json file (resolve the cache discrepancy).

It is possible that a site isn't accessible during this process either temporarily or permanently. Regardless, it will become necessary to think about the policies around doing a little garbage collecting and removing an FPS from the github repository. Setting a time limit (say some number of months) for a response from the site administrator to correct the issue might be a reasonable expectation.

[cfredric]

Thanks for filing this issue, @brownwolf1355! We'll investigate how best to respond/react in cases like that where a mismatch between the .well-known files and the JSON file arises after some period of time.

[brownwolf1355]

@cfredric, no problem, happy to provide any feedback or discuss.

[dopry]

What was the reasoning for a first-party-set.json controlled by a 3rd party, rather than using http headers?

[krgovind]

What was the reasoning for a first-party-set.json controlled by a 3rd party, rather than using http headers?

@dopry FYI, I responded to your question here.