Will we be able to limit callers?

[ehoch]

Right now it appears anyone who can drop an iframe on a page is able to become a caller on my domain. This would include anyone who currently drops user syncs or potentially even advertisers.

As a publisher, will we be able to limit domains that are allowed to be callers and get access to browsingTopics on our site?

[jkarlin]

There is a way to prevent any callers on your page by setting the following response header: Permissions-Policy: browsing-topics=(), but there isn't a CSP-like way of limiting who is allowed to call the API in the current design.

What kind of use cases might you have for such restrictions?

[michaelkleber]

The Permissions-Policy approach can also be used to create an iframe inside which Topics are unavailable — see https://www.w3.org/TR/permissions-policy-1/#iframe-allow-attribute.

But that wouldn't help if you're concerned about a third party that has a script in the top-level site and which can create its own iframes.

[johannhof]

But that wouldn't help if you're concerned about a third party that has a script in the top-level site and which can create its own iframes.

The way that the proposal is currently worded it looks like only iframes will have the capability to call/"observe" topics (emphasis mine):

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.

This would change quite a bit if issue #7 introduced a mechanism for scripts running in the top-level context to introduce "observe" behavior for fetch origins (arguably this is what 3rd party cookies already enable today).

But otherwise I think this issue can be closed.

[ehoch]

Context. We are Mediavine, a Google Certified Publishing Partner and exclusive ad management company for over 8500 publishers (individual domains).

Our publishers aren't looking to opt out of Topics, but rather, the opposite.

In this case, we (Mediavine) would want to be the sole caller allowed on page and then choose who we would send Topics to in the bid stream.

If the proposal goes as forward (forgetting about #7 for now), anyone who has access to drop iframes on page (nearly every adapter in Prebid), or any winning ad that runs inside of a friendly iframe (again, most of Prebid), would be able to get access to our sites' Topics.

The reason this is a concern is because we have unique value here as small publishers under Topics. Each site gets topics at the domain level, so suddenly our diverse network becomes very valuable to a large publisher that may only have a handful of Topics.

By limiting the ability for Mediavine to protect the value of our independent publishers, you're effectively handing those ad tech dollars to the large publishers.

The rich will get richer under this model.

While I admit third party cookies already enable these issues today, I think that's the point. Shouldn't we solve for these issues and do better this round, especially for small businesses?

There's a lot of potential solutions to this, including using industry standards. Perhaps only callers with domains in the ads.txt could get access. Or a similar mechanism where you specify allowed domains.

[ehoch]

@michaelkleber That could be an interesting solution if Google Ad Manager were to add support to disabling Topics on individual iframes that are dropped, as they're the creator of most of these iframes in question. We could similarly add something to Prebid.

[johannhof]

I think that when the top level document sets a policy via the permissions policy header, it can not be overridden by iframes on the page unless specifically allowed in that policy (see Example 3 on https://w3c.github.io/webappsec-permissions-policy/#examples). So using that mechanism the publisher can decide which third-party origins may access topics, even if they are loaded as scripts in a first party context.

[ehoch]

Important to note, and this was raised during FLoC, it's tough to get small content creators, especially ones on hosted platforms, to be able to set a response header.

I really think an alternative and way to limit callers on page without a response header is going to be needed for this to be equitable.

[jkarlin]

We had further discussion on this (opting out via html instead of headers) in #60. I'm going to close this as we're relying on permissions policy. Support for html could happen if the permissions policy folks adopt it.