Support for Global Privacy Platform (regs.gpp)

[robhazan]

Type of issue

Feature Request

Description

The IAB Tech Lab has published a proposal for Global Privacy Platform that seems very likely to be ratified in 2022 and poised for adoption in 2023.

CPRA will take effect in California and VCDPA will take effect in Virginia on January 1, 2023, and IAB Tech Lab is only planning to provide new signals that support these regulations in GPP. This means that usprivacy as it’s currently implemented in Prebid Core will effectively be deprecated. I’m not sure what adoption of GPP will look like from CMPs, but Prebid Core likely needs to be ready so that all upstream ad tech participants can comply with the legislation.

Prebid Core likely needs to implement a new consent module that retrieves the GPP string from CMPs and makes it available to bid adapters.

[robhazan]

@SyntaxNode and @patmmccann - similar question to the one I asked in the Prebid Server FR: does Prebid.JS need to actually decode/interpret the GPP string and decide which bid/data/analytics adapters should or shouldn't receive/make a bid request?

[dgirardi]

Is the expectation that on January 1st all parties will understand the new GPP string, and know how to extract CPRA/VCDPA from it? Or will they expect Prebid to do it?

[pm-harshad-mane]

@dgirardi JS API __gpp(command, callback, parameter, [version])

Page 17, https://iabtechlab.com/wp-content/uploads/2022/06/global_privacy_platform_rfc_june_2022.pdf

[bretg]

I've taken a cut at outlining a Prebid path for GPP support. https://docs.google.com/document/d/1dRxFUFmhh2jGanzGZvfkK_6jtHPpHXWD7Qsi6KEugeE/edit?usp=sharing

Would suggest reviewing in this week's meeting.

[patmmccann]

We've received guidance on upgrade / downgrade of tcf2 <-> gpp by prebid. Prebid should never upgrade. Prebid should downgrade if gpp is present but tcfapi is missing

[jsnellbaker]

I'm not sure if this is too early ask yet, but has it been decided which __gpp commands Prebid.js will use to listen and fetch the data?

I was reading through the spec, and it seems to me (maybe I'm missing something) that there's no one command that will fetch everything. The eventListener approach for GPP seems to rely on events that were existing for the individual spec (eg TCFv2) in order to get an 'event' that should contain the choices the end-user made; I'm referring here to the [API-prefix] or [API-prefix].[Eventname] event on page 24 of https://iabtechlab.com/wp-content/uploads/2022/06/global_privacy_platform_rfc_june_2022.pdf.

If this is the 'event' we need to use, it seems we'd need to be listening for many potential events from the various regional flavors to capture the correct (and complete) set of information. Is that our likely path here, or is there some other gpp command that we're planning to use?

[bretg]

@jsnellbaker - no one has done that level of thinking on this yet. You're way out ahead, so suggestions welcome.

[jsnellbaker]

On extra exploration, I found there was an official github project for GPP. When I reread the CMP API spec on github project, there were some additional functions available that were not present in the RFC PDF that was linked in the previous comments.

There was a specific function named getGPPData that returns the current version of the GPP string: https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md#getgppdata-

Further there was an example (the second one from the link) that shows one way to use the API after listening for an update to a certain spec (Canada spec in this case): https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/CMP%20API%20Specification.md#using-the-cmp-api

We can try to use something like this possibly for our implementation - though it would still rely on listening for several options to update GPP value in Prebid.js. So this is one possible option; there may be other combinations out there that may be better. If anyone has ideas about this approach, please feel free to share.

[jsnellbaker]

As a further follow-up thought to my previous comment and in reviewing the events of the spec further, I tried to put together a possible mark-up by tweaking the example from the spec. It should be more generalized to ensure we get the updated information as it changes or as the CMP loads.

There are some questions that came up while putting this together; noted in the comments in the bottom half. Any thoughts are welcome.

if(__gpp) {
  __gpp('addEventListener', function (evt) {
    // react on changes or when the data is loaded
    if(
      evt.eventName === 'sectionChange'  // new consent data?
      ||
      (
        //cmp is loaded and not/no longer visible, a tc string should be available
        evt.pingData.cmpStatus === 'loaded' && 
        evt.pingData.cmpDisplayStatus !== 'visible'
      )
    ) {
      var GPPData =__gpp('getGPPData');

/*  should return the full gpp string that can be shared with adapters in prebid.js
    GPPData = {
      sectionId : Number,  // Always 3 to indicate the header section
      gppVersion : Number, // The version number parsed from the header
      sectionList : Array of Number, // the sections contained within the encoded GPP string as parsed from the header
      applicableSection: Array of Number, // Section ID considered to be in force for this transaction. In most cases, this field should have a single section ID. In rare occasions where such a single section ID can not be determined, the field may contain up to 2 values.
      gppString: String // the complete encoded GPP string
    }
*/

    // how will we get TCF2 EU purpose information from GPPData (to maintain hasPurpose1Consent() logic in Prebid.js)?  It does not appear to be present in the object above.

    // do we need a possible second call if section is tcfeuv2, to grab the data in the format used by that spec?
    if(evt.pingData.currentAPI === 'tcfeuv2') {
        var tcfeuv2Data =__gpp('getSection', null, 'tcfeuv2');
        // tcfeuv2Data.purpose.consents['1'] === true/false ???
    }

    // do we need to grab special data for other sections (tcfcav2/uspv1) that matter for storage or other vital things for adapters?
  }
 });
}

[jsnellbaker]

As a follow-up to the suggestion above (on ways to obtain the data from the GPP CMP), could we please ensure to include the actual gppData object as part of the payload that's provided to the adapters by the module; like what we did for including the tcfData for the TCF consentManagement module?

Based on internal discussions with @drpaulfarrow, we want to read the applicableSection value and pass that along with the gppString to our endpoint. If we only get the string (which I think was the running assumption for the module), it would not allow us to pass this additional data point. Please let us know if there are any concerns about including the whole gppData object. Thanks.

[jsnellbaker]

On another topic, related to user-sync, there was some brief discussion yesterday in the prebid bi-weekly meeting about updating the call signature to include the gpp consent information. Would it be possible to include the gppData object (instead of just the gppString)?

I mentioned it briefly yesterday, but ideally we would want to have some type of eventual value derived by the GPP module that's similar to the purpose-1 of TCF2; where its value represents a signal to not do cookie related activity. There was some internal thoughts (on our end) around looking at the do-not-sell or do-not-share values that in the USP spec, but with some parts of this overall GPP/USP spec still in motion - it's not a definite thing at this point, but it could happen that way.

Providing a gppData consent object for user-sync would help provide help now (for people who want the gppString, sectionId, etc) and allow flexibility for checking against another signal down-the-road.

[slimkrazy]

Hi folks,

Just wondering when the passthrough feature outlined in phase one is planned to be worked on for both PBJS and PBS?

I understand things are still TBD, but I just want to point out that we (and quite possibly most ad serving platforms) really need access to not only the gpp string but also the applicable section ID taken from applicableSection of the array within the GPPData object. Prebid JS Core and Prebid Server probably should provide access to all of the GPP data so bid adapters can select what they need to.

[patmmccann]

@slimkrazy we'd welcome yahoo's contribution.

GPP work is near the top of our roadmap, but we're not sure this ticket is quite yet ready for dev.

We're also not sure the urgency some other entities are implying is real. TL wouldn't answer our question on what in uspapi is insufficient to comply with California or Virginia law on January first and referred us to legal counsel. We aren't yet aware of legal opinion suggesting uspapi is insufficient for compliance.

We are aware of additional notice requirements that go into effect on that date, yet it feels safe to use the second character of uspapi to indicate all applicable notices have been given, and the third to indicate opt out of everything possible to opt out of.

We're not yet aware of any publisher who plans to stop using uspapi. We don't yet have any implementations of GPP live to see how it behaves.

[drpaulfarrow]

I (Paul at Xandr) would be happy to discuss why we didn't think uspapi satisfied the requirements of the new legislation. Yahoo welcome to join of course. Shall we set up 30 mins next week? I can invite my legal counsel to help give our perspective.

[patmmccann]

Absolutely, please email me pmccann at cafemedia to discuss scheduling. I'll loop in some other people in email

[jsadwith]

@drpaulfarrow did you and Pat get a chance to discuss this change? We (Kargo) received a request from Yahoo DSP about whether or not we can support GPP by January 1. Since Prebid.js doesn't yet support it, and once it does, many publishers will be slow to upgrade, it seems like it'd be better to have a solution sooner rather than later as more DSPs will be pushing for it.

[robhazan]

In case folks haven't seen it OpenRTB v2.6-202211 was released last night.

And gpp was officially added to the mainline of the regs object here.

Updating the title of this issue to reflect that.

[drpaulfarrow]

There are a couple of very small threads to tie off with respect to the spec itself but Patrick, I and others have been discussing it intensely. Hoping we can break ground shortly.

[patmmccann]

assuming https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/pull/25 gets merged, this appears ready for dev

@jsnellbaker I believe that addresses several of your open questions above. If not, can you link or repeat open questions?

Things that appear resolved to me are:

bidders can begin development now, the objects they need will be on bidderRequest.ortb2.regs.gpp & bidderRequest.ortb2.regs.gpp_sid

we no longer need to make two calls, gppdata object contains the ping data return and all necessary scope info

Unresolved {?): how to determine haspurpose1consent? Appears to me to be a secondary call to the tcfeuv2 api within gpp if and only if tcfapi is not defined on the page, a scenario we don't expect in the near term.

[jsnellbaker]

We still need to make two calls, the first to listen for the eventlistener (so we can listen to the right events made by the CMP and know that the GPP data is 'complete' and reliable) and the second would be to grab the encoded GPP string from the CMP itself. Calling the getGPPData too early would risk getting an incomplete version.

There was some discussion about changes in v2 of the spec, where they may look to add the gppData object (or at least the encoded string) to the eventListener's event response object, much like how it's there in the TCF2 spec. This change would reduce us to one call to the CMP, since we'd just call the CMP to register the addEventListener and then listen to all the events for the one we care about and move on from there in the module.

There are some open questions on the google doc I put together that are still in need of feedback; mainly:

• the return value of the getConsentMeta() in consentHandler.js
• the PBS usersync questions in prebidServerBidAdapter/index.js
• attaching the gpp data as query params for bidViewability.js and dfpAdServerVideo.js
• if any changes are needed now in userId/index.js (or if that's future work)

I'll be making some updates to the other areas that had Open Questions with the decisions that were made by the IAB (ie the PR you linked). I'll try to start putting together the Prebid.js draft PR this week with what seems solid at this point.

[duncanfordAZ]

I have been told that Prebid.js doesn't currently support LGPD (Brazil) consent. Once Prebid.js supports GPP, would this be resolved?

[patmmccann]

@duncanfordAZ the gpp does not yet support LGPD afaik, so no. https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Sections/Section%20Information.md

You can attempt to set ortb2.regs.ext.lgpd with some sort of consent string, not sure where the format would come from, and you could form contractual relationships with each of your connections about how to interpret it.

[patmmccann]

closing with #9321