Should there be a way to send topics via Fetch as a request header?

[jkarlin]

This would reduce the need for expensive (and slow) x-origin iframes to be created.

[maorithu]

Yes, I think this is very important to have. When requesting ads, our ad javascript is running on the publisher’s context which is a different origin from the one which observed the user visit various sites. For us to receive the topics, we would need to create an iframe, read the topics, and post-message them back to the publisher’s context. This introduces significant latency that is bad for user experience. Additionally, messaging the topics via the publisher's context could leak the user’s interests to parties on the publisher page, which would be a privacy step backwards relative to third-party cookies.

Ideally, topics should be sent in a way that is comparable to how cookies are sent today. Today, 3p cookies can be attached to requests as a header by:

1. XMLHttpRequest.withCredentials = true
2. Fetch() or WebBundle with credentials: 'include'
3. Sent by default using an iframe

I propose we add a separate withTopics option on each interface (XHR, Fetch, iframe, WebBundle) to activate the API and attach the Topics as request headers to the ad request. It will significantly improve the ease of use of the API, reduce latency, and protect users’ privacy.

There is precedent here: this is also the approach Chrome has taken with Trust Tokens.

[jkarlin]

I don't think we'd want to send Topics by default, it should be explicitly called out. XHR and Fetch options seem reasonable to me.

[maorithu]

I understand we don't want to send Topics by default. For resources that are requested via iframe, what about a new iframe attribute to activate the Topic API? Similar to here and here

[jkarlin]

Yep, an attribute could work.

[igrigorik]

Can we expose this as an opt-in feature policy extension on iframes? The opt-in provides clear signal of intent and FP enables existing tools to introspect the active policy, etc.

[zhengweiwithoutthei]

Disclaimer: I am a Google Ad Manager engineer. The user 'maorithu' above is my personal account. I have a few follow up questions:

1. Does using the Fetch/Xhr options proposed above imply a call to the API?
2. In other words, does the caller still need to call document.browsingTopics() before using those options to send topics?
3. If the answer to question (1) is yes, can these options be used for observing topic on a site? For example, with the option set to true, a fetch call from site A to T will make T an observer of user's visit of A and A's topic.

[jkarlin]

This line of thinking does lead me to a question: What if the destination origin receiving topic headers does not want to receive topic headers for that user on that site? With the existing design, the API must be explicitly called via js in the context of the origin, so the origin has full control over receiving topics.

Can we expose this as an opt-in feature policy extension on iframes? The opt-in provides clear signal of intent and FP enables existing tools to introspect the active policy, etc.

There is already a permissions policy (used to be called feature policy) designed for the Topics API. Are you suggesting that if the policy is enabled, then any site covered by the permission should automatically get the header in their iframe document request headers?

Does using the Fetch/Xhr options proposed above imply a call to the API?

Yes, it would, since the topics are being received.

In other words, does the caller still need to call document.browsingTopics() before using those options to send topics?

No.

If the answer to question (1) is yes, can these options be used for observing topic on a site? For example, with the option set to true, a fetch call from site A to T will make T an observer of user's visit of A and A's topic.

Yes. I think the idea is that we'd semantically make receiving topics headers equivalent to calling the API.

[igrigorik]

There is already a permissions policy (used to be called feature policy) designed for the Topics API. Are you suggesting that if the policy is enabled, then any site covered by the permission should automatically get the header in their iframe document request headers?

Yes, I think that's one of the design options we should consider.

Can you point me to the definition of existing PP? If you are referring to browsing-topics=(), my understanding of that was as an opt-out mechanism for the top-level frame.

[zhengweiwithoutthei]

Can I assume Chrome is committed to the new API options proposed here for Xhr, fetch, iframe? When should I expect a new specs for those options to be published?

What about an "topics: 'include'" option in webbundle too(see WICG/webpackage#624 for proposed webbundle usage in ad serving)?

[jkarlin]

Can I assume Chrome is committed to the new API options proposed here for Xhr, fetch, iframe? When should I expect a new specs for those options to be published?

I think we're going to need some way for third parties to opt-in to this behavior. Otherwise, they may receive data that they hadn't intended to be privy to via a request header.

[zhengweiwithoutthei]

Understood. I think sending topics is less of a concern as one can already send arbitrary data to a server. For setting topics, we can use a response header to indicate opt-in.

[jkarlin]

I think the natural fit here is client-hints. Client hints will eventually be partitioned to be per-top-level site, which we'd need. The server could signal that it wants to receive topics for this user on this site on future requests. It'd be overridden by the permission policy. If a site needs to have the topics on first seeing the user, they can use critical-ch and the request will be resent with the topics in the headers.

This would then replace the notion of using xhr/fetch/iframe options to send the topics, as it places the control of whether topics are received in the server's hands instead of whoever is calling them.

[jkarlin]

I'm not sure it's a perfect fit for client-hints though. We'd want a permission policy of * (the default for Topics) to mean that an accept-ch would be honored and topics sent with requests, while a permission policy of 'self' to mean that accept-ch would be registered but topics would not be sent with requests in that context if not self. I don't believe that's how client-hints usually interpret the permission policies and that could be problematic. Thoughts @yoavweiss @miketaylr ?

[zhengweiwithoutthei]

I am not sure Client Hints is a good fit here. Client Hints has a same origin policy which requires:

• opt-ins will only be granted when the opt-in headers are received with a top-level navigation resource
• after the opt-in, hints will only be sent with same-origin requests

This means the publisher has to change their server to opt-in and delegate hints to ad server with Feature Policy. Sending a request from the publisher's site to ad server and receiving an ACCEPT-CH response header won't register the hints.