jkarlin
commented
2 years ago The purpose of limiting the information to each caller is to ensure that the Topics API doesn't provide information to more entities than cookies would. This ensures that we're moving in a positive direction for user privacy. It is up to each provider and site to determine for itself what data it shares.
In regards to performance, the plan is to support Topics via headers in addition to javascript, which should alleviate the cost of creating a third-party-iframe just to call a single API and postMessage it back.
related to #38 #11 and #30
If a publisher is not allowed to see all the topics returned, it seems a new entity will arise, which has the responsibility of reflecting topics back to the publisher, or that ssps will do so as a condition of integration.
There are not a lot of obvious ways to restrict the topics from being shared amongst callers. One way seems to be to isolate the topics call inside an iframe. However, that would appear to break the bid request, as how would the ssp correlate the topics to it? Another is to append the topics to a header in the bid request. In either case, the ssp has the opportunity to reflect the information back to the publisher and the publisher can accumulate them and deliver all the topics into OpenRTB.
This seems to defeat the purpose of limiting the information available to each caller, as the publisher is able to easily determine a lot more information about the user than they have now in the world of 3PC.
Finally, the publisher is now exposed to an enormous incremental security and performance risk profile, if all topics callers must run from third party js on their page. Publishers typically limit the number of parties that are allowed to do this prior to an auction. SSPs through advertisers are not able to run code unless they win. Typically only a video player, a header bidding wrapper, and an ad server have the privilege. It seems in the world of topics, publishers will be incentivized to run as many third parties as possible to try to get every conceivable topic, or to ensure they sent out a bid request that included all possible topics.
Apart from security, it seems this will also contribute to or engrain the existing bid jamming problem in adtech. If a user is a travel or finance enthusiast, the publisher is encouraged to basically spam the topics api with different third party callers and resultingly the bid stream until they can be reasonably assured they would have gotten that topic and its high value bid back.