Caller signatures for abuse mitigation

[dmarti]

Some goals for Topics API include:

• enable usage of the API on first visit to a legit site
• prevent usage of the API to add value on sites that a user is tricked into visiting, to avoid creating incentives to build deceptive sites and drive traffic to them in deceptive ways
• prevent usage of the API for non-advertising purposes such as housing and employment discrimination

It is difficult to achieve all three. Although sites can technically prevent their Topics API data from being collected by removing a caller iframe or setting a permissions policy, in the real world an individual site typically does not have enough market power to, on its own, cut off a problematic Topics data leakage—even to a third party that is providing audience data to known deceptive sites.

One option would be to borrow an abuse mitigation mechanism from First-Party Sets (FPS). Allow for public review of parties that are legitimate users of Topics data, through the same kind of public posting and review that a first-party set would be subjected to. The FPS proposal states, We expect public accountability to be a significant deterrent for intentionally miscategorized subsets, and something similar could be useful for Topics.

1. A Topics user validation organization (which could be a service provider, NGO, or other types of organization) produces a policy document and a public/private keypair. It submits the public key and policy to a GitHub repository or similar forum as a pull request.
2. Browser maintainer(s) choose organizations with policies that meet the goals of Topics API.
3. A site that plans to call Topics API gets its domain name signed by a Topics user validation organization.
4. When the site calls Topics API, it passes the signature from step 3. The browser checks the signature and returns a valid result if the signature is valid.

If a Topics user validation organization is found to be signing the domain names of illegal or out-of-policy sites, their public key would be removed from the repository and browser. Legit sites that had been signed by that organization would then be unable to use Topics API until they had obtained a signature from another organization. This would appear to allow for the intended uses of Topics API (a legit site could use Topics on first visit by obtaining a signature) while making the unintended uses more difficult.

[dmarti]

It looks like this issue is fixed in practice by Enroll for the Privacy Sandbox. Maybe it could be simplified to "Topics API must require enrollment by the user agent."