Opt out in HTML or JavaScript

[dmarti]

Some sites are able to modify HTML markup but cannot set an HTTP response header (Typically because of the limitations of their hosting plan.) Those sites will need an opt-out in a meta tag or other HTML element.

See WICG/floc#13

Another possibility is to support a JS function for turning off (but not turning on) subsequent calls to Topics API from the page. This could be run by a script on the page before other scripts are allowed to load.

For example, a script on the top-level page could pass a list

document.limitBrowsingTopicsAccess(['adtech.example', 'shopperprofiler.example']);

If the set of allowed callers from the Permission-Policy was * then the call to limitBrowsingTopicsAccess would directly set the new list of allowed callers.

If the set of allowed callers from the Permission-Policy was already limited to a list of origins, then the call to limitBrowsingTopicsAccess would set the list of allowed callers to the intersection of the sets of existing allowable callers and the list passed in.

[npdoty]

Although I do think the long-term goal is to get more hosting providers to give access to header configuration, I could see this functionality being important so that any site author has the capability to decide whether their site is included in topics analysis. Ideally we could just make that a standard functionality of Permissions-Policy rather than a one-off for this spec.

Although Topics (contra Floc) is site-opt-in (in that sites aren't analyzed unless they use the API), currently that would happen if any embedded frame on the page uses the API, and only that caller would later get access to the data about the user. Because the site owner wouldn't be the only calling the API, then I think usable opt-out / control of the policy for any embedded pages is pretty significant.

[jkarlin]

Agree that it would be nice to adjust permissions policies via meta tags, but I understand there are concerns with that (changing permissions after document load is hard to reason about from a security perspectivem, but one can disallow that by requiring it be in the original document and ignore changes made by javascript). Anyway, https://github.com/w3c/webappsec-permissions-policy/issues is a good place to continue this discussion.

[dmarti]

In the meantime: will Topics API depend on an opt out being available for sites that can't set HTTP response headers, or will those sites need to get their host to set the opt out?

[jkarlin]

The plan is to rely on permissions policy behavior rather than add something new. So, that means http headers for now. If one does not not have response header access, then there are still options. For instance, one could embed their page as a full-page iframe with the appropriate allow attribute.

[dmarti]

Updated to include an alternate approach in JS, which might make it easier to do A/B testing across multiple sites.

[dmarti]

Added a suggestion for how a limitBrowsingTopicsAccess function could work. @jkarlin would this be more straightforward to implement than relying on meta tags?

[patmmccann]

The plan is to rely on permissions policy behavior rather than add something new. So, that means http headers for now

This is rather concerning for at least five reasons:

Consent frameworks from the IAB (eg https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20CMP%20API%20v2.md) rely on signals that may change, either in opt out or opt in scenarios. Our legal counsel considers, and it appears state attorney generals in various states, as well as European DPAs, will likely consider the calls to the topics API, a data sale or share that consent signals will apply to. Publishers will need to obtain legal consent to call the api in some jurisdictions and may receive notice they no longer have it in others. This is not possible to express in an http header.

If we discover someone is a child, we have to consider them opted out of targeted advertising immediately.

If someone navigates to a section of a recipe site for people with a particular health condition (eg low fodmop recipes for people with IBS), we may need to do things like prevent calls to joinAdInterestGroup or the topics API for legal compliance reasons. They may get this content interactively in a SPA rather than in on a new page with a different http header.

Publisher AB testing on opting in or out is largely impossible

Permissions policies are rather technically burdensome as an opt out method. GAM has chosen this as the only way a publisher can avoid its massive million site + topics contributor network (https://support.google.com/admanager/answer/12270543?hl=en#optout). This choice of permissions-policies-only opt-outs appears to be a violation of a CMA commitment that Privacy Sandbox architecture does not favor Google-owned ad platforms. AdX is the only SSP with code on publisher pages capable of opting all its publishers into its network. Your choice to make opt-out incredibly technically challenging for the typical publisher, and GAMs choice not to allow js opt-out in gpt.js API calls, appears to be favoring your own ad product in privacy sandbox APIs.

[jkarlin]

@patmmccann Whether or not you should (or another ad-tech should) use a particular API, or advertise to a particular user, is a long-standing ad-tech issue that has been dealt with for years without top-level opt-outs. Topics is not introducing a new problem here. In fact, thanks to the existing Topics permission policy, you can ensure that the third parties that you embed on a page don't have access to the API when creating their iframes.

Again, I'm supportive of the notion of some form of meta-tag permission policy in theory, but permission policy is the right forum for that discussion.

[jkarlin]

Closing this as permission policy is the right venue to continue this discussion.

[dmarti]

See #208