Opportunity to reduce complexity: Topic API restrictions

[alextcone]

Not every API caller will receive a topic. Only callers that observed the user visit a site about the topic in question within the past three weeks can receive the topic. If the caller (specifically the site of the calling context) did not call the API in the past for that user on a site about that topic, then the topic will not be included in the array returned by the API.

While I appreciate the spirit of what you're trying to achieve here, I think in practice this restriction won't amount to much other than making the proposal more difficult to read and for browsers, implement. Here's why I think that:

Ad Request Flow

• In a typical ad request you have multiple technology provider types in play. For the sake of simplicity I'm only going to mention the two that matter for this particular issue: SSPs and DSPs
• Most SSPs now integrate with sites via header bidding which is client side code that will be able to read this Topics API (side note: the leading header bidding library, Prebid, will almost assuredly take it upon itself to query the Topics API, and because of the broad deployment of Prebid and limited Topics taxonomy it is likely that all Topics would be covered on day one of this API going live)
• SSPs then take what they know about the site/visit, whether supplied by Prebid library or their own header bidding wrapper, which would now include the Topic(s) shared by the API, and use it to populate an ad request out to one or many DSPs. The SSP is incentivized to get as many bid responses as possible to maximize monetization potential for the publisher and therefore would include the Topic(s) supplied to it by the API knowing that in the future many DSP customers will include targeted Topics in their campaigns
• Those DSPs may or may not have called the Topics API on a site with the Topic now carried in the ad request. The SSP has no current way of knowing that and the browser doesn't have any idea what DSPs will be called.
• The DSPs on the other end of the request now have the Topic(s)

Ad Response Flow

• After a few days of operation at any scale it is likely that a DSP or other buy-side tech that is only delivered to a site via an ad (or pixel on advertiser's site) will have seen all of the several hundred Topics via its ability to call the Topics API once on page
• If the restriction was intended to reduce the amount of parties in the ecosystem that could see all Topics nearly all the time then it only achieves this for likely a few minutes or at most hours at each site/user/Topic refresh

Again, I appreciate the spirit of wanting to limit what could be known about a given site/user/Topic to what is readily observable by an API caller, but the realities of the data flows and systems in the ecosystem mean that the restriction doesn't hold up well. Thus I am suggesting this piece of the proposal be revisited.

Bigger picture, companies landing on sites/apps via the ads themselves are one of the more complicating factors of privacy and data protection. Restrictions here probably are better delivered via things like Fenced Frames.

[jkarlin]

Closing as we're planning on moving forward with filtering for the privacy reasons detailed in the explainer and in other threads here.