GPP Phase 4

[bretg]

The next steps in GPP are covered by Phase 4 in the requirements document:

1. build out a 'Privacy Module Infrastructure' that can be called from the Activity Infrastructure initially defined in Phase 3.
2. build the first privacy module: US National Privacy

Privacy Infrastructure

Prebid Server-Specific Requirements

Any privacy regulation that needs to integrate with the Activity Infrastructure will need to confirm to a new interface. The details of the interface will be left to the Go and Java development teams, but the requirements are:

1. Each privacy module has a 'module code'. e.g. "iab-usnat", "iab-tcf-ca".
2. The privacy infra must have access to request consent strings and scoping information.
3. The privacy infra must be configurable per account with the ability to define separate configuration for each regulation module.
4. The privacy infra must be aware of which activity is currently being processed.
5. Ideally, the privacy infra could be aware of the country and region of the request.
6. It should be possible to refer to multiple privacy implementations by referring to the names with wildcards.
7. The privacy infra must keep state for which 'module codes' have already been considered for this activity in this request. e.g. in the activity4 example below, since gpp-tcf-eu was already called, the reference to * means all regulations other than gpp-tcf-eu.
8. The privacy infra will call one or more regulation modules as directed by the Activity Infrastructure.
9. Each privacy module should return one of these states: "allowed", "disallowed", and "abstain".
10. The privacy infra returns one answer, the least permissive answer, to the Activity Infrastructure:disallow takes precedence and 'abstain' is ignored as an answer.
11. Each privacy implementation may have its own configuration requirements. e.g. GPP has the concept of "section ID" that other regulations may not.
12. Errors in the account-level JSON should cause the system to either fail every request, or, preferably, fall back to the host-level default. We don't want to skip broken sections because that could wind up creating a legal problem. A failure should cause the system should generate an alert.general metric with N% logging and emit a warning in the ORTB response.
13. Errors in host-level JSON should ideally cause a server startup error with a clear log entry.
14. When ext.prebid.trace is set to either "basic" or "verbose", the system must emit a trace of processing steps so that users can determine what activities and privacy modules are doing. The details of what is emitted is left for the tech spec phase.

Non-Requirements

1. It is not necessary for existing GDPR, COPPA, and CCPA functionality to immediately work within the Activity Infrastructure framework. These may be migrated as part of future efforts, or they may stay separate.
2. Request-level configuration is not required.
3. Activity Controls don't affect privacy modules

Linking the Activity and Privacy Infrastructures

See the use cases for how publishers might want to set up the existence of multiple in-scope regulations.

In addition to those use cases, the Prebid Server committee would like to be able to support future non-GPP privacy regulations.

This is the proposed allowactivities syntax extension for referring to privacy regulations from within the Activity controls:

  privacy: {
    allowactivities: {
      activity1: {
        rules: [{
          condition: {
            componentType: ["bidder", "analytics"]
          },
          allow: false
        },{
          privacyreg: ["iab.*"]   // only check IAB privacy modules
        }],
        default: false
      },
      activity2: {
        rules: [{
          privacyreg: ["iab.usgeneral"]  // if this module makes a decision, yay or nay, we're done
        },{
          privacyreg: ["iab.*"]   // check all other GPP modules
        }]
      },
      activity3: {
        rules: [{
          privacyreg: ["*"]	// check all privacy modules, not just GPP
        }]
      },
      activity4: {
        rules: [{
          privacyreg: ["iab.tcfeu"]   // if tcf-eu makes a decision, yay or nay, we're done
        },{
          privacyreg: ["*"]    // check remaining privacy modules
        }]
      },
      activity5: {
        rules: [{
          privacyreg: ["custom.usutah"]
        },{
          privacyreg: ["*"]    // check remaining privacy modules
        }]
      }
    }
  }

Notes:

• the new privacyreg attribute in the activity infrastructure is an interface to a generic layer that can deal with various privacy regulations as they are added to the system.
• This functionality could be phased in -- the ability to supply multiple privacyreg attributes could be done as a later phase.

Configuring Privacy Modules

See General GPP Infrastructure requirements for background.

Prebid Server needs to allow accounts to configure privacy regulations. Here's the proposed syntax, which places the config in a new "privacy.modules" block. The proposal is that we define a new type of module interface for privacy modules. All the ones active for the given account would be registered here.

Assumptions:

• Host level account config should allow the host company to define which privacy modules they've activated.
• If an account config defines privacy.modules, it overrides the host-level default.
• When a detailed technical specification is done, modules should be able to receive at least the following contextual data: regulation-related parameters, geographic information, activity related details such as which bidder(s)/module(s) are requesting the activity.

Example config:

{
  "privacy": {
      "modules": [{
        "code": "iab.usgeneral",
        "enabled": true,                     // default
        "config": {
          … module-specific confg …
        }
      },{
        "code": "custom.sid12",   // custom module
        "config": {
          ... module-specific confg …
        }
      }]
    }
}

Notes:

• privacy.modules is a new account-level block
• modules.code: refers an identifier unique within the privacy regulation namespace that points to a function that knows how to handle this request when it's in-scope.
• modules.config: this is the configuration sent to the module.
• modules.enabled: defaults to true, provides a way for an account to disable particular privacy module

Intended Processing:

1. Each privacy module will determine from request parameters whether it's in scope. e.g. a GPP-based module will inspect the gpp_sid parameter and module configuration to determine whether it's in scope for the current request. A future TCF modules may use the gdpr scope flag and/or geographic information to determine whether it's in-scope.
2. Each module is expected to do all relevant interpretation and return a status: "abstain", "allow", or "disallow".

US National Privacy

See US National Infrastructure requirements for background.

Assumptions:

• Initially, there will be just one module that codes Prebid's default behavior for each activity. It always 'normalizes' state-level requests as defined in the PRD.
• Overrides to the Prebid default behavior will initially be supported by building a custom privacy module (either open source or host-company specific).
• Eventually we may build a 'custom logic' module that will allow publishers to define overrides to Prebid's default logic to specific states.

Here's the proposed syntax:

{
  "privacy": {
      "modules": [{
        "code": "iab.usgeneral",     // privacy module coding the prebid default interpretation
        "config": {
          "skipSids": [11,12]
        }
      },{
        "code": "custom.sid11",      // custom hand-coded module
        "enabled": false
      },{
        "code": "iab.uscustomlogic",    // future module to support override logic
        "config": {
          "sids": [12],
          "normalizeFlags": false,
          "activityConfig": [{
            "activities": ["activity1", "activity2"],
            "restrictIfTrue": {
                { "or": [
                  { "==": [{"var": "MspaServiceProviderMode"},1] },
                  { "==": [{"var": "Gpc"},1] },
                  { "and": [
                     { "==": [{"var": "MspaServiceProviderMode"},2] },
                     { "or": [
                        { "==": [{"var": "SaleOptOut"},1] },
                        { "==": [{"var": "SaleOptOutNotice"},2] },
                        { "==": [{"var": "SharingNotice"},2] },
                        { "==": [{"var": "SharingOptOut"},1] },
                        { "==": [{"var": "TargetedAdvertisingOptOutNotice"},2] },
                        { "==": [{"var": "TargetedAdvertisingOptOut"},1] },
                        { "!=": [{"var": "KnownChildSensitiveDataConsents1"},0] },
                        { "!=": [{"var": "KnownChildSensitiveDataConsents2"},0] },
                        { "==": [{"var": "PersonalDataConsents"},1] }
                     ]}
                 ]}
              ]}
            }
          },{
            ... other activities ...
          }]
      }]
    }
  }
}

The 'iab.usgeneral' module config field:

• skipSids: defines any sids that are processed by other modules. Be default, this module processes all activities for SIDs 7-12 by the Prebid default algorithm after normalizing.

The 'iab.uscustomlogic' module is an envisioned (later phase) module that can be used by publishers to override the default interpretation algorithm.

• normalizeFlags: whether to operate on the active state's native or normalized flags. Defaults to true. It's expected that if this value is false that either config logic or a function will be provided, but this does not need to be enforced.
• activityConfig: this is an optional array of objects where a host company can help publishers define account-specific override logic.
• activities: this is an array of activities that share the same flag logic. It's common that sets of activities resolve to the same logic and since the logic is potentially complex, it is not desirable to duplicate that config.
• restrictIfTrue: arbitrary boolean logic involving the USNat flags specified in JSON Logic format. If the result of the flags is true, the activity is suppressed (i.e. a "disallow" status is returned). The specific syntax of this has been debated and not finalized. The proposal is to settle on utilizing JSON Logic for Prebid Server for this and future general configuration logic needs.

Intended processing:

1. If defined by the allowactivities config, the activity infrastructure calls the relevant privacy module(s) with the supplied module configuration. If a privacy module name is defined more than once in the config, only the first is processed. Others result in emitting a warning and an alert.general metric.
2. the iab.usgeneral module always normalizes as defined in the PRD and process against the defined Prebid default interpretation. Note that the interpretation does differ by activity.
3. The iab.usgeneral module can be configured to 'abstain' for certain configured SIDs, allowing the publisher to define special processing for certain states.
4. When the IAB adds a new SID that falls under US National, we will work with Prebid lawyers to determine the desired behavior. It may be as simple as adding the new SID to the internal list and upgrading the GPP library, or it may involve additional 'normalization' steps, or it may involve an entirely new privacy module.

[bretg]

Discussed in committee. The naming convention of the privacyreg syntax was debated along with what will happen for TCF-EU.

• this draft suggests a gpp prefix with the idea that there is some common GPP functionality such as parsing the string and a "normalization" step.
• there could someday be a need to support non-GPP, non-IAB regulation such as the VPPA.
• Namespacing the module names makes sense to prevent collisions and to allow for wildcards.
• but the handling of TCF-EU is potentially a problem because depending on how we implement it, prefixing the name with "gpp" could be confusing.

So what are some ways we can handle tcf-eu with respect to this new functionality?

1. Leave the existing functionality as completely standalone. Publisher activity controls don't work for GDPR/TCF -- exceptions can only be made through existing vendorExceptions in GDPR config. This system already supports pulling the TCF-EU string out of the GPP string.

2. Integrate the existing GDPR/TCF functionality into this privacy regulation system. Possible approaches:
   2a) Integrate as part of the "privacyreg" system, but outside of the GPP infrastructure and just name it "tcf2" or perhaps "iab-tcf2". This gives publishers consistent control over exceptions. GDPR configuration can be exactly the same as currently documented.
   2b) Migrate to live within the new GPP infrastructure as "gpp-tcf-eu". It can still look within the ORTB body and prioritize the user.consent over regs.gpp. Look for GDPR configuration in both the current location and in the new GPP location.
   2c) Effectively support two TCF-EU modules: a migrated "gpp-tcf-eu" as well as the original "tcf2". The publisher can name these separately in the activityConfig. (This approach seems to have no advantages and could invite confusion)

Discussed additional requirements:

• the system must define a preferred source of consent if there are multiple sources.
• the default privacyreg behavior should be to run all known privacy modules

[bretg]

Discussed GDPR positioning:

• agreed that 2b seems best, but also agreed that 2a and 2b are basically the same thing at a high level. The tech spec phase can implement this.
• We agreed to name All The Things with an iab prefix rather than a gpp prefix and prefixes are separated with a dot rather than dash.

Other items discussed

• • being the MVP, being able to prioritize regs is nice-to-have
• renamed 'consent' account config to 'privacy' for Phase 3
• Open item for the next meeting: should SID filtering be in the config or coded into each sub-module?

[bretg]

Updated after today's meeting:

• revised 'alternate function' approach to just require creating a custom privacy module
• split the 'override logic' out into a separate (future) module
• updated assumptions, intended processing and notes

[bretg]

PBS-Java 1.126 implements the iab.usgeneral module. Working on the iab.uscustomlogic module still

[bretg]

If activityConfig is not specified, the iab.uscustomlogic should return abstain.

[bretg]

Done with PBS-Java 1.130