Is calling the Topics API on behalf of a Publisher legit?

[sukria]

A single-domain publisher website calling the Topics API will only see Topics related to its own properties, by design. This has very low (to zero) business value for the publisher (eg: The New York Times will get "News" most of the time in the Topics returned).

An adtech provider, whose JS tag is called from many domains, will on the other hand see a wide range of different topics (all corresponding to the domains it reaches).

What about this scenario:

• and AdTech provider offers a JS library (hosted on its domain) to its clients (publishers)
• some of those publishers source the JS lib from the AdTech domain and call a function defined there to get the topics returned, from the Adtech perspective
• Publisher can then store locally (and do whatever they want with) the Topics returned.

Here is an example of the code I have in mind.

// topics-proxy.js (hosted on AdTechFoo's domain)
function addtechfoo_topics_proxy(publisher_callback) {
  publisher_callback(  document.browsingTopics() );
}

Then, on the Publisher site, we would have the following code:

<script src="https://addtechfoo.example/resources/topics-proxy.js"></script>

var topics_seen_from_addtechfoo = null;
addtechfoo_topics_proxy(function(topics) { 
  topics_seen_from_addtechfoo = topics;
} );

Will the topics returned be in the scope of AdTechFoo, or PublisherN ?
If the Topics returned are the ones AdTechFoo sees, is it OK regarding the Privacy Sandbox philosophy?

Thanks for the clarifications.

[dmarti]

This is also relevant to dynamic pricing (#34). A single-domain retailer would see only topics from their own domain, so would need a service provider as Topics API caller, to get a wider range of topics -- for better optimization of pricing for more and less price-sensitive users by topic.

[sukria]

Thanks @dmarti for the comment and the ref to dynamic pricing.
I'd love to hear from @jkarlin about this issue.

According to the Topics API implementation, would the the code provided in my example work as expected? I mean, when we call document.browsingTopics() in a function hosted in a JS file sourced from a 3rd-party provider, which Topic set is returned? The one the third-party domain sees? Or the one the 1st-party domain sees?

If I understood well the Topics paper, that would be the Topic set returned from the 3rd-party perspective, hence, it would be possible with such a JS resource to bypass the current limitation of "I see only the Topic inferred from my network".

Please feel free to tell me if I misunderstood something.

Thanks.

[jkarlin]

Hi folks. Thanks for raising the issue. From my perspective, it is up to publishers to determine which third-party service providers they include, and up to service providers to determine what they're willing to divulge to publishers.

[fbastello]

Hi folks. Thanks for raising the issue. From my perspective, it is up to publishers to determine which third-party service providers they include, and up to service providers to determine what they're willing to divulge to publishers.

Just to clarify @jkarlin - it would be okay for a third-party service provider that has already a large footprint (because already integrated in many websites) to share Topics with a publisher and for these topics to be send downstream to SSPs and DSPs if this publisher chooses to, in addition of Topics they would have themselves collected?

In other words, if I assume that publishers transmit Topics signals downstream as Seller-Defined Audiences (as proposed in #12 and #3 ), anyone downstream could see 2 signal sources for chrome Topics:

 {
   ...,
   "user": {
     "data": [
       {
         "name": "publisher.example",
         "ext": {
           "segtax": 600
         },
         "segment": [
           { "id": "243" },
           { "id": "247" }
         ]
       },
       {
         "name": "large-third-party.example",
         "ext": {
           "segtax": 600
         },
         "segment": [
           { "id": "59" },
           { "id": "129" },
           { "id": "173" }          
         ]
       }
       ]
     }
   }
 }

If that's the case, then what @alextcone suggests in #11 is okay if it happens but might defeat the restrictions you are trying to put in place?

[jkarlin]

Just to clarify @jkarlin - it would be okay for a third-party service provider that has already a large footprint (because already integrated in many websites) to share Topics with a publisher and for these topics to be send downstream to SSPs and DSPs if this publisher chooses to, in addition of Topics they would have themselves collected?

Yes, that is a way in which we expect Topics to be used.

[npdoty]

Sensitive data about the user's advertising or commercial interests should be shared only for specific purposes (selecting more relevant advertising for the current page) and with direct limitations on additional distribution and use.

That being said, I would expect it to become common under the current design for an embedded party to communicate back to the publisher the observed interest topics -- perhaps though an iframe and postMessage rather than a script embedded in the first party context, but still. Communicating the observed topics could be used for the specific purpose of passing that on to get relevant advertising, or for the publisher to use in making its own advertising decisions ('oh, you're interested in content about cars, check out the new motor vehicles section of our site').

Enough so that I'm not sure how much value there is in hiding the user's topics from the site itself while sharing them with an embedded third party. Users seem unlikely to understand that distinction, as a practical matter it seems expected that the data will be shared between the embedded parties and the top-level site, and the relaxation of the privacy principle seems the same (context about behavior on other sites is reflected on this site).

We're coming back to this distinction pretty frequently, see: #11, #38, #67

[jkarlin]

If we assume that everyone shares everything and the third-party provider observes the user on every page. Then sure, they're equivalent. The reality is likely somewhere in between. It is up to each provider and site to determine for itself what data it shares.

[npdoty]

According to the Topics API implementation, would the the code provided in my example work as expected? I mean, when we call document.browsingTopics() in a function hosted in a JS file sourced from a 3rd-party provider, which Topic set is returned? The one the third-party domain sees? Or the one the 1st-party domain sees?

The one the first-party domain (the "site", or the top-level browsing context) sees.

As I understand the proposal and the current state of browser security, a <script> tag loaded in the top-level browsing context of a site would have access to cookies and other local state regarding that origin, and so document.browsingTopics would return the topics that are available to the top-level browsing context (ones that that origin has 'seen' when it called the API for that user in the past), among the ones that have been selected for that site.

But JavaScript running in an iframe loaded from a different origin, which currently would have access to a separate set of cookies (third-party cookies) would receive responses from document.browsingTopics that might be very different, based on what was available to that origin (that that origin has 'seen' when it called the API for that user in the past, including on other sites).

(We could also test this with the Chrome origin trial or a Google implementer could confirm, but I'm just doing my best to quickly summarize my understanding.)

[jkarlin]

@npdoty is correct. If the top frame on a page is for example.com, and foo.com/script.js is on the page and wants to get its topics, then script.js should create an iframe for a document at foo.com and call document.browsingTopics() from there.

[jkarlin]

Closing as I believe all questions here have been answered.