GPP integration

[dmarti]

user story: As the administrator of a web site that runs advertising, I want to use all features in a compatible way that is less prone to compliance errors.

Add a check for Global Privacy Protocol - IAB Tech Lab to ensure that any necessary consent, opt-outs, and/or objections are handled properly.

(While some sites may choose not to load any script that performs attribution tracking until after the appropriate GPP check, a GPP check step would make this compatible with existing code already deployed by sites.)

[martinthomson]

To use an analogy, browsers don't ask whether sites have received the necessary justification when storing a cookie.

It is the responsibility of sites that invoke the API to ensure that their use of the API is compliant with whatever regulation they believe to be operative. If site operators believe that GPP will help them achieve compliance, then that is an option available to them.

To add to this, even if we were to entertain this suggestion, we would need a deterministic algorithm to follow. My understanding of GPP is that it is pluggable and dynamic in a way that would make the definition of an algorithm very challenging.

I'm sure that sites would appreciate the W3C taking on that regulatory risk for them, but I can't see a way to make this practical, even if it I could be convinced that it was a useful addition to the API.

I recommend that we close this issue without action.

[dmarti]

This is different from simply setting a cookie -- by invoking the API, the site is requesting actual processing on the part of the browser.

If you look at any of the other attribution tracking systems, they're generally set up to be handled with appropriate configuration of an existing GPP-compliant CMP. Lack of GPP support on this system would impose an extra, likely costly and error-prone, special case on many sites.

This might be "challenging" for the browser-side implementation, but it's preferable to solve the problem once than to impose additional code and checks on each site. Site administrators don't just choose to invoke the API or not -- they have to deal with JS from a variety of sources that might introduce an API call and bury the news in the fine print of the release notes.

And as a practical compliance matter, a browser that regulators consider a "gatekeeper" in the EU would not be able to give its own tracking system a preference over the competitors.

[bmayd]

I believe this use case is out of scope for the Global Privacy Protocol (GPP) which focuses on the packaging and transmission of consent signals that have been gathered by a Consent Management Platform (CMP) for the purposes of communicating to downstream providers what user choices apply to a given ad-related interaction.

My expectation is that website owners will work with their CMP partners and compliance departments to decide whether, under what conditions and through what mechanisms, access to this API should be restricted and implement controls accordingly. I assume that CMPs will generally approach the Attribution API the same way they do other browser-based, ad-related tracking capabilities and that and they and their partners will be able to extend existing capabilities to cover the Attribution API with minimal effort.

Whether, when and how to restrict browser capabilities for regulatory reasons are jurisdiction-specific and are best considered out of scope for technical standards, so long as browsers provide sufficient capabilities to enable websites to comply with regulations generally, which I believe in this case they do.

I agree with @martinthomson in recommending that we close this issue without action.

[dmarti]

@bmayd "My expectation is that website owners will work with their CMP partners and compliance departments to decide whether, under what conditions and through what mechanisms, access to this API should be restricted and implement controls accordingly."

But it's important to consider the priority of constituencies, that puts user agent implementors, spec writers, and theoretical purity last.

I appreciate the desire to preserve the theoretical purity of this proposal as a "technical standard" that doesn't have to refer to non-W3C standards in the same space, but in the real world that's going to create an extra, unnecessary compliance ticket per site instead of a task at the spec and browser level. And it's a ticket that has to be handled on the browser's schedule, not the site's.

• Without GPP support: complex compliance ticket, possibly involving new code, timing is determined by browser releases

• With GPP support: one reconfiguration to add a vendor to an existing GPP CMS, timing is determined by when the site wants to start using the system

Existing GPP participants didn't want to have to support it either, and would rather have made each site do a special integration -- but GPP turned out to be the compromise that enabled multiple parties to cooperate in a workable amount of time.

[bmayd]

@dmarti My concern is not about maintaining technical purity; it is about the functional suitability of GPP for this use case and the architectural risk of forcing user agents to interpret and enforce consent signals originating within a first-party context.

As noted previously in this thread, GPP is a protocol designed for packaging and transmitting inputs gathered by a CMP. The protocol’s purpose is to communicate consumer choices downstream from a first party to third parties operating outside that first-party context in a standard way. Your suggestion would require using GPP as a gating mechanism within the user agent and first-party context to determine whether a native browser API executes. That is fundamentally different from what the protocol is designed for.

Instead, we should continue to use the model GPP relies on: depend on CMPs to manage consent relationships with consumers and communicate choices to websites, which then have the responsibility for acting on them. Even in standard GPP implementations, websites maintain executive authority—they are responsible for retrieving the GPP string from the CMP and including it in third-party communications. The CMP manages the data, but it is ultimately up to the website to apply it.

This ties into my second concern: shifting the responsibility of interpreting first-party consumer relationships and making enforcement decisions away from websites and onto the user agent. CMPs already exist to manage these often complex and nuanced relationships and communicate user preferences to first parties in forms that are actionable. We give first parties responsibility for determining when and how they will abide by those inputs, and they in turn rely on user agents to provide the technical capabilities to do so.

This existing model is entirely sufficient for the Attribution API. Consumers communicate preferences to websites via CMPs. Websites then interpret those preferences to determine how to honor the consumer's choices. If a website determines that the Attribution API should be restricted, administrators already have access to several industry-standard browser mechanisms to control, restrict, or completely disable it, including:

-Permissions-Policy HTTP headers (to disable the API globally at the server level)
-Permissions-Policy attributes on iFrames (to restrict third-party execution)
-Conditional resource loading and feature gating via JavaScript

Providing these robust enforcement tools fulfills the browser's responsibility to site administrators without breaking the architectural boundary of who interprets consent.

[dmarti]

@bmayd The browser's primary responsibility is to the user. I agree that it is possible to do what you describe, and have the site, and every third party present on the site, do the necessary GPP checks, and if everyone involved does everything right, then it should all work.

But the possibility that it could work in a best case scenario does not necessarily mean that the browser should enforce an arbitrary architectural boundary even when a GPP string that disallows this API is present. Protecting the purity of the design does not justify missing an opportunity to protect the user.

[AramZS]

@dmarti The current model for browser features which may or may not be of concern on opt-out is that they are features for whom the responsibility of managing activation lies with the page and developer.

We will not write something into the specification that creates behaviors in reaction to GPP or any other privacy signal because the right surface for deciding on how a privacy signal interacts with triggering an impression or report is the surface that makes a decision on activating those triggers. The sites themselves must decide how any legal regime applies to them and make a choice on what browser features to use, not use, or block as a result. This is how it works across the web in the current day and there's no justification for changing how that control works for this particular specification at this level.

The responsibility for deciding if a website is going to trigger this API cannot reside in the browser, it must reside in the website that is making the decision. Presumably that site will read any and all privacy signals and decide on its own.

Since this feature request is not within bounds for a web specification, we will not consider it further and I am closing the issue.