WICG / first-party-sets

This issue seems to apply to both the GoogleChrome/first-party-sets repo as well as the WICG/first-party-sets repo, since it seems to hit both on the implementation of the FPS check under the first and the discussion of FPS under the second.

While the FPS check that is performed during a PR to submit an FPS does check for intersections among FPS (e.g. multiple primary domains including one or more of the same associatedSites domains), there does not appear to be a mechanism to resolve these conflicting FPS. The current behavior would indicate that the first FPS submission takes precedence even if it was a false FPS declaration (e.g., a malicious actor attempting to claim ownership of domains that it does not in fact own) and the true owner would have to somehow prove (to whom, Google Chrome?) that it is in fact the true owner of the associatedSites and not the malicious actor.

This could be resolved with the requirement that the same first_party_sets.json file is present under /.well-known on the primary domain, as well as all of the associatedSites domains. The FPS check could then validate that the all of the first_party_sets.json files match and thus prevent a malicious actor from claiming them, since they would not have the ability to place a fraudulent first_party_sets.json on the associatedSites domains.

Thanks for opening this issue. If I understand correctly, the concern is that the list of First-Party Sets may become non-mutually-disjoint, and this specification does not define how to resolve that mismatch?

If so, then such a problem would actually be a bug in the FPS implementation (in particular, in the submission requirements of https://github.com/GoogleChrome/first-party-sets), since the definitions presented here do require that all of the sets are mutually-disjoint:

first-party-sets/README.md

Line 232 in 74d8480

    
           -   Mutual exclusivity to ensure a domain isn't part of multiple First-Party Sets

Given that such a bug would be in the submission guidelines (or their implementation), we'll track this issue here instead: GoogleChrome/related-website-sets#20

Resolving intersecting FPS and the need for a reverse reference from the associatedSites to the primary