AMP support for IAB Global Privacy Platform (GPP)

[bretg]

Description

The IAB has defined the Global Privacy Platform as the future of ad tech privacy regulation support. Not seeing an existing issue for AMP support.

One approach would be to extend the existing AMP privacy fields. Here's how RTC callout vendors currently obtain privacy regulation consent data:

&consent_string=CONSENT_STRING
&gdpr_applies=CONSENT_METADATA(gdprApplies)
&addtl_consent=CONSENT_METADATA(additionalConsent)
&consent_type=CONSENT_METADATA(consentStringType)

Extending this model seems feasible:

• CONSENT_METADATA(consentStringType) - extend to add GPP as the 4th value of the enum
• CONSENT_STRING: currently contains GDPR and USP strings. Extend to read GPP consent string from the CMP
• add a new CONSENT_METADATA(gppSectionId) to support the "section ID" field of GPP, which is similar to gdprApplies. Note that there can be more than one active section ID so this value should be able to hold multiple values - e.g. a comma separated string.

Alternatives Considered

n/a

Additional Context

No response

[bretg]

Thanks for considering this request @erwinmombay. I know there's a big backlog of issues. We have a number of prebid.org publishers interested in knowing if/when AMP might support this new privacy standard.

[bretg]

@erwinmombay - have there been any discussions about supporting GPP in AMP?

[erwinmombay]

@bretg we have not yet, but i'd like to start a conversation here.

adding @powerivq here who might know more than me

[powerivq]

Your approach should work. However, that would require all consent platforms on AMP to make changes to their API to accommodate, and the timeline will be long. Alternatively, if it is possible to translate the current string to GPP string (I do not know if that is possible, needs research), is this feature useful?

[bretg]

Appreciate the thoughts here @powerivq

consent platforms on AMP to make changes to their API

CMPs are already having to add support for GPP in web. They'll be expecting it for AMP.

if it is possible to translate the current string to GPP string

Not possible.

[marco-prontera]

if it is possible to translate the current string to GPP string Not possible.

I think it's technically possible (not possible see comment below) but it require both "frameworks". A spike could help, and could work like the follow:

1. decode the tcString with iabtcf, so with this you get the tc model and know what is enabled and what not.
2. use the data to set any field of the relative section with gpp and get the GPP string with the relative section for tcf encoded.

Maybe I'm missing something, it's just an idea. If I can ask, by checking if that is possibile, how can be used this solution? And also where this should be done? Because I think amp project wouldn't permit to include both library in the amp-consent since it can break and struggle with performance rules of the amp project (and also increase the complexity of the js and weight that can impact in unexpected way in terms of performance and robustness)

[bretg]

The GPP string is quite different from the original TCF string.

1. GPP is a container that can hold many incompatible consent strings. e.g. it can hold the TCF string, the USP string, the US National string, US Virginia, etc.
2. The 'gpp_sid" field of GPP has no equivalent in TCF, and it's critical -- it defines the scope of the request -- i.e. which sections contained in the GPP string are relevant to the current request.
3. If all goes as planned, GPP is the last format AMP would need to support because the IAB plans to add all new consent formats as a new section in GPP.

decode the tcString with iabtcf

Not exactly sure what's being proposed @marco-prontera , but a couple of cautions:

• The IAB has stated that the tech pipeline is not allowed to fabricate or alter the contents of a GPP string. (or a TCF string for that matter)
• The GPP container holds far more than just TCF-EU. Downstream entities need all the sections, not just section 2.

For anyone interested in Prebid's interpretation of privacy, some references:

• General Activity Control infrastructure
• How Prebid handles Sections 7-12 of the GPP string. https://docs.prebid.org/features/mspa-usnat.html
• Note that section 2 (TCF-EU) is still handled in the legacy way.
• Next up is section 5 (TCF-Canada)

[marco-prontera]

Not exactly sure what's being proposed @marco-prontera , but a couple of cautions:

The IAB has stated that the tech pipeline is not allowed to fabricate or alter the contents of a GPP string. (or a TCF string for that matter) The GPP container holds far more than just TCF-EU. Downstream entities need all the sections, not just section 2.

Very right, sorry I had focused on the technical solution. I completely agree. I think the best solution is the one you proposed since seems also it doesn't introduce any bc.

[powerivq]

Given that this approach requires platform support, cc'ing all the existing platforms here for inputs:

@dav-m85 @janwinkler @carsten1980 @MaximePlancke @yotam-g @Vasile-Peste @nielsbaarsma @oliverfernandez @PierigOgury @gramesan @heikostaab @marco-prontera @nicobatalla @RemiSirdata @molz @andresilveirah @doubaokun @Usercentrics-AMP

[powerivq]

If any one of you have more contacts within these CMPs, feel free to escalate the issue through them as well (since github users might not be the responsible person any more)

[effing938]

Hi @powerivq - checking in here to see if any progress has been made regarding AMP supporting the IAB's Global Privacy Platform. The IAB has indicated that they are deprecating the U.S. Privacy String on January 31, 2024 (more on that here) and replacing it with the Multi-State Privacy String, which sits under the GPP framework.

Without GPP support (and MSPS support) on AMP, I'm not sure how publishers who support AMP would be able to support the Multi-State Privacy String on AMP.

Do you know if any progress has been made since August?

[erwinmombay]

@effing938 we're actively working on this. Do you happen to represent a CMP? As we'd like to have a discussion about the implementation and integration with CMP endpoints

[effing938]

Hi @erwinmombay - yes, I'm in client services for Sourcepoint Technologies so might not be the best representative from a technical perspective but would be happy to put you in touch with the right person on our team.

[erwinmombay]

@effing938 got it. we will try and go through the sourcepoint documentation first, to have a more informed discussion. Appreciate the quick response

[janwinkler]

@powerivq We have already implemented support for GPP and all the sections (canada, us national, california, colorado, ...). For AMP support, all we need is to know the new names of the properties that we shall send back via postMessage on consent update.

in regards to what AMP shall do with the GPP string: I dont think that it is necessary for AMP to actually decode the GPP string. Most vendors will be able to receive the string and decode it on their own. In order to AMP to understand the choices (e.g. for blocking), it seems much easier to rely on Google Additional Consent signals (and include all vendors in there, not only the ones that are not in the TCF) or the purpose signals that are already part of AMP.

in regards to "translate the string to gpp": for both, us privacy and tcf, the CMP can (and should) "translate" the existing strings to GPP

and lastly please note that the IAB is preparing for the TCF to fully switch to GPP (deprecate the __tcfapi and the string format). hence it makes sense to add gpp support for AMP as soon as possible so that CMPs, vendors and publishers have enough time to adopt.

[gabemorazan]

@effing938 got it. we will try and go through the sourcepoint documentation first, to have a more informed discussion. Appreciate the quick response

Appreciate the response Erwin! Here are the docs for web implementation with Sourcepoint.

https://docs.sourcepoint.com/hc/en-us/articles/23845605843347-U-S-Multi-State-Privacy-implementation-guide-web

[powerivq]

@bretg Can you substantiate your use case of gppSid meta? My undetstanding is that one GPP string could have multiple sections and each would have its own SID.

[bretg]

The GPP string itself can carry any number of section IDs. The external gppSid meta is critical because it tells everyone downstream which sections are actually in scope.

e.g. Say you live in California so you have a GPP string that contains section 8 (usca), but you also visited Europe, Colorado, Utah, and Connecticut, so your string also contains sub-strings for sections 2, 10, 11, and 12 . Downstream entities need to know which sections to enforce - it's not correct for them to assume that all 5 sub-strings within the overall GPP string are equally active if present.

It's the job of the CMP to determine which SID(s) are legally active for the current request, that's the purpose of the external gppSid meta.

[powerivq]

@bretg https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md Okay, you meant the GPP_SID at the bottom of the page. It makes sense but I did not see that macro.

[erwinmombay]

hey all. we are going to do a public design review this upcoming Wednesday. Details can be found in https://github.com/ampproject/amphtml/issues/39769

[bretg]

@erwinmombay - what was the result of the design review?

[powerivq]

@bretg We are going to proceed with this proposal. There are several downstreams (receivers of consent strings in AMP) that we are prioritizing to add support for GPP, and then we will merge https://github.com/ampproject/amphtml/pull/39789 to add the CMP support that basically was proposed by you. Thanks for the proposal!

[powerivq]

Hi all,

We have merged both PRs to support the GPP strings on AMP. They are expected to be available on stable in two weeks, and up to 1 month for reaching LTS. Feel free to start implementing GPP now, but please wait until then (1mo from now) before actually starting to send GPP strings to the clients, as some pages might be using LTS and the support is lagging behind.

[janwinkler]

@powerivq can you point me at the documetnation on how AMP expects to receive the gpp string?

[bretg]

@powerivq - question: is the value of the GPP CONSENT_STRING macro URL-encoded? I'm not sure whether it can contain ampersands or other URL-sensitive chars.

Same question for CONSENT_METADATA(gppSectionId) -- is this value URL encoded?

[erwinmombay]

@powerivq could we add some additional documentation and examples surrounding usage

[janwinkler]

@bretg the consent string is URL-safe and therefore does not need encoding (the string doesnt change if you encode it)

[powerivq]

Closing this issue as the follow-up are intended for the CMPs.