GPP Phase 4

[bretg]

Privacy Year continues with GPP Phase 4: the GPP Infrastructure and the US National Privacy sub-module. See the Prebid and GPP document for details on the updated GPP platform and the USNat protocol specifically.

If the GPP 1.1 module and USNat sub-module are both present, the USNat module should automatically parse the GPP SID 7 string and create activity control configuration.

The team should consider how to handle SIDs 8-12 and the discrepancies the IAB built into those protocols.

Here's how Prebid Server will handle this phase:

1. The activity infrastructure config gets a new command that links an activity to one or more privacy modules.
2. There's a module called iab.usgeneral which can be called from the activity infrastructure
3. This module parses the GPP string. By default it looks for SIDs 7-12, but can be configured to skip configured SIDs. (e.g. in case the publisher wants a different behavior for a certain SID). This module "normalizes" SIDS 8-12 to bring them to the canonical form of SID 7, and the logic is built against that form.
4. A custom module can be built to parse the string however it would like, including which SIDs it's interested in. However, this custom module requires coding in Java/Go and host company support.
5. Eventually PBS will support a 'custom logic' module which will let them define different boolean logic without requiring the Java/Go coding.

[dgirardi]

Proposal for how this could work out (in JS):

1. The main GPP module is updated to augment activity parameters with "global" GPP data (sids & string). That means that a pub could write rules like

   setConfig({
         allowActivities: {
                 transmitUfpd: {
                          rules: [
                                condition(params) {
                                     // rule applies if gpp sid '7' applies and there is no GPP string
                                     return params.gpp.sids.include(7) && !params.gpp.gppString
                                },
                                allow: false
                          ]
                 }
         }
   })

2. GPP submodules augment activity parameters with their section data. If we take USNAT as an example, that would mean rules like this - and the complex conditions at the end of the doc - would become possible (if the usnat submodule is included):

   setConfig({
       allowActivities: {
              transmitUfpd: {
                       rules: [
                             condition(params) {
                                  // rule can use the contents of the USNAT string to make decisions
                                  return params.gpp.sids.include(7) && !params.usnat.MspaServiceProviderMode === ....
                             },
                             allow: false
                       ]
              }
     }
   })

3. GPP submodules also provide default rules (that can be overridden like the above when necessary). This could also be put in separate submodules - if there's a use case for someone overriding all the defaults.

[dgirardi]

it's possible that point 2 above could be done from the main GPP module (depends on the CMP, it's still unclear to me atm). There's also the rather annoying fact that the parsed consent data for GDPR within GPP is formatted differently from the parsed consent data for GDPR within TCF, so naming of the parameters may need to be more defensive.