Support for Global Privacy Platform (regs.gpp)

[robhazan]

Feature Request

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 Server will effectively be deprecated. I’m not sure what adoption of GPP will look like from CMPs, but Prebid Server likely needs to be ready so that all upstream ad tech participants can comply with the legislation.

[SyntaxNode]

Thank you for bringing this to our attention @robhazan.

There's a lot to read through in the Global Privacy Platform (GPP) spec. At a high level, this is a new consent string / privacy signals container which will incorporate all existing IAB standards (TCF v1, TCF v2, CCPA) and will be the exclusive home to future standards, like the upcoming TCF for Canada and new signals related to CPRA.

The current TCF v2 string can be embedded as-is. The CCPA string can also be embedded as-is and they're introducing a new more compact format with the exact same fields. For the most part, we need to write a parser for the GPP container and can interpret the embedded consent strings with our existing code.

The current approach in OpenRTB may become "messy" as many more jurisdictions introduce their own privacy frameworks. With at least three new frameworks in development now, this is a problem that needs to be addressed. GPP expands on the technical approach of TCF v2 to create a new container format uniform across the ecosystem / not specific to just OpenRTB. I expect this to especially help with AMP where PBS can simply place the GPP string in the created OpenRTB request and our main auction logic can run normally.

PBS-Go and PBS-Java should already pass regs.ext.gpp downstream without any additional work, but we should verify this.

PBS will need to implement:

• A parser for the GPP consent string. This looks to exist for JS, but not for Java or Go. We can base the parser on what we have today for TCF v2.
• Use regs.ext.gpp (or regs.gpp in OpenRTB 2.7) instead of regs.us_privacy and user.consent. In this case, regs.ext.gpp_sip takes precedence over regs.gdpr. The next spec update being worked on will include specific directions on how to handle precedence when multiple signals are present in the request.

PBS should not create a a GPP consent string as that is a job reserved for CMPs. If a request is received with the soon-to-be legacy regs.us_privacy and user.consent fields, PBS should preserve the original privacy signals not up convert to a GPP container. Hence, PBS does not need the ability to write GPP consent strings.

[robhazan]

@SyntaxNode My primary question is whether Prebid Server needs to actually enforce based on what's in the GPP string. In other words, determine which bid adapters should or shouldn't make bid requests based on the user's consent preferences.

[bretg]

Discussed in committee today.

We agreed that it makes sense to consider at least two phases:

1. PBS passes through regs.ext.gpp with no parsing or enforcement actions.
2. PBS fully understands regs.ext.gpp and enforces actions appropriately.

Open questions:

• should we consider breaking out regs.ext.gpp into component pieces (e.g. regs.gdpr, regs.us_privacy)? Or would this provide disincentive for bidders to adopt the new rules?
• should we consider a middle phase where PBS breaks out regs.ext.gpp and enforces the TCF2 and USP portions according to the current logic?
• what is the timeline for finalization of the GPP spec?

[SyntaxNode]

I spoke with the IAB Working Groups about our questions and have the following responses/guidance:

should we consider breaking out regs.ext.gpp into component pieces (e.g. regs.gdpr, regs.us_privacy)? Or would this provide disincentive for bidders to adopt the new rules?

No. We should keep the privacy signals exactly the same as we received them. Doing otherwise might introduce liability. Let' discuss at the next meeting if we feel strongly agains this guidance.

should we consider a middle phase where PBS breaks out regs.ext.gpp and enforces the TCF2 and USP portions according to the current logic?

Yes. TCF2 (retroactively renamed TCF-EU2) and USP are a "shift and lift" into GPP so our current logic is fine as a middle phase.

what is the timeline for finalization of the GPP spec?

Soon. The current target is October 2022, although this may slip a little a 2022 release seems highly likely. They are currently working on updates from the public comment feedback.

[SyntaxNode]

Also, the plan for regs.ext.gpp has been scrapped. Instead, OpenRTB 2.6 will move to a monthly release cadence and the next release will define regs.gpp directly. A little less complicated for us. :)

[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 next week's meeting.

[bretg]

Discussed in committee

• the IAB suggests that it would be ok to pull the TCF/USP strings out of a GPP string to send to endpoints that can handle the older formats.
• We agreed the following work is 'ready-for-dev':
  • passthrough of regs.gpp (string) and regs.gpp_sid (integer array) (i.e. update the ortb schema).
  • adding a gpp and gpp_sid param to cookie_sync and setuid urls. /cookie_sync passes these values from the POST body through the {{gpp}} and {{gpp_sid}} params. gpp_sid is either an int or a comma-separated list of integers - don't include any array symbols
  • GPP parsing libraries for Go and Java
  • bidder config for GPP support. Add a "gpp-supported" configuration flag.
    • If true, it lets PBS-core know that this bidder can accept regs.gpp and regs.gpp_sid and it doesn't need to split out the GPP string.
    • if false, split the GPP string into TCF and USP strings for the bidder
  • parse and enforce TCF and USP components of the GPP string using existing logic
    • if GPP string is present, parse out TCF/USP and use those for enforcement purposes. Warn if there are TCF/USP string in the request that don't match.

Go and Java dev teams can design these features and plan the release strategy.

Full GPP support will be tracked by a separate issue.

[SyntaxNode]

Notes from the Prebid Server Committee:

• This is an important priority for Prebid.
• The California and Virginia laws go into effect Jan 1, 2023. Other state laws may have a later start date.
• Some publishers are planning to expand USP signals for California and Virginia and change their disclosures to be more conservative during a transition period.

GPP Phase 1 support as defined in this thread has been given a higher priority on the PBS Road Map.

The IAB offers a JavaScript implementation. The PBS-Go team is building https://github.com/prebid/go-gpp . There may not yet bet a Java library.

[bretg]

There's a Java library being built by the IAB at https://github.com/IABTechLab/iabgpp-java

[bretg]

To reiterate: the scope of this issue's "ready-for-dev" status is the 'Phase 1' work. There will be a separate issue for the refined enforcements and multi-state work.

[bretg]

Added "regs.gpp_sid" support as defined in the latest revision of GPP.

[patmmccann]

Did you see pr 25 that defines 0 and -1 gpp_sid?

[bretg]

No, which repo is PR 25 in?

[bretg]

Was reading through the IAB's doc at
https://github.com/InteractiveAdvertisingBureau/Global-Privacy-Platform/blob/main/Core/Consent%20String%20Specification.md

and ran across this syntax I don't understand: GPP_STRING_XXXXX

${GPP_STRING_XXXXX} where XXXXX is the numeric GPP ID of the vendor receiving the
string. - The applicable GPP Section ID must also be inserted, where the ${GPP_SID}macro
is present.

Does anyone understand why they're making this distinction?

When the /cookie_sync endpoint receives the gpp string in the POST body, it needs to be the full cross-vendor string. Is there some vendor splitting we need to do there in order to pass the string through the sync urls?

[SyntaxNode]

This use case seems to apply specifically to situations where Javascript cannot execute, so AMP. We'll need to learn more about the intent to understand if the cooke sync macros would need to be "addressed" to the PBS Host GPP ID or if we can use the adapter IDs here.

[SyntaxNode]

As an agenda item for next year, GPP SID works a bit differently than the GDPR flag. The flag can be nil, 0, or 1. If it's nil, we replace it with a required default value. For SID, it's an array of all policies in play. In practice, this is one.. maybe 2, values. So far, it appears the industry is treating a nil SID array and an empty SID array the same - as no privacy policy to enforce for the request. Do we allow the host to set default values if none are provided? .. and does this need to have logic since it applies to GDPR/TCF2, CCPA, the new US Privacy laws, and many others on the horizon?

[bretg]

Do we allow the host to set default values if none are provided?

My take: in the short term, no need for host-level defaults.

Once we built out full GPP support, we're going to need PBS to be able to resolve the user's geo. Each regulation should have a 'module' that can take all the known information about the request, including geo, and determine the scope.

[hhhjort]

Looking over the discussion on ${GPP_STRING_XXXXX} in the document, the only use case I can imagine is there is some use case where the GPP string can be vendor specific. That is the GPP string could be different for different vendors for the same user on the same page. I am trying to get some confirmation on this idea. In my idea, the IAB here is asking vendors to supply their URL templates with these vendor specific macros so publishers will not have to edit them all to support this vendor specific GPP usecase.

For us, I don't think it will be too big of an issue. We only have access to a singular GPP string, so either PBS hosts will have to strip off the vendor identifier from supplied cookie sync URLs, or PBS will search and replace ${GPP_STRING_XXXXX} with ${GPP_STRING}. For AMP, I don't imagine Google supporting this vendor specific use case, given the long lag for them to support TCF at all. We will just need to supply AMP endpoint URLs with whatever macro AMP supplies for GPP, and some logic to detect if the consent string is GPP along with the logic to detect between TCF and US privacy.

[bretg]

As we started implementing for PBS-Java, found the spec for wrapper behavior was not well-defined. I've revised Phases 1 and 2 in the Prebid GPP doc. Some pretty major changes to phase 2, so we should discuss in light of PBS-Go already working on this.

In the meantime, continuing on to Phase 3

[patmmccann]

Talking at an IABTL meeting abouit the string_XXXX macros now. Apparently we shouldn't call user syncs that have the macro XXX in them if vendor XXX does not have purpose 1 consent. Related: InteractiveAdvertisingBureau/Global-Privacy-Platform#60

[bretg]

Interesting. There's no "purpose 1 consent" in GPP, but anyhow, Prebid Server will be able to suppress usersyncs for vendors that need to be anonymized without need of XXXX. The usersync macro supplied by bidders in the YAML file will be {{gpp}}, replaced by the full GPP string.

But I think this observation may have implications on bid adapters utilizing iframes that do a 'second-level' DSP sync. That iframe code may need to be responsible for suppressing syncs to other entities.

Worth noting, though, that not all GPP SIDs have the concept of vendor ID. e.g. TCF-CA will, but USNat doesn't. In the case of USNat, it's probably easy -- if PBS is letting the bidder's iframe run, syncs are ok since that regulation doesn't differentiate vendors (thank goodness). But in the case of TCF, I suppose it means the iframe code needs to 'Do The Thing': parse the string for allowed GVL IDs. That's a lot of replicated parsing of a complex string. If that's a problem, Prebid could make that easier by passing a list of P1-approved GVLIDs into the iframe. That would entail a bunch of refactoring by any bidder doing this.

[bretg]

Closing this issue. See related issues for phases 3, 3.5, and 4.