GPP Phase 3.5 - USNP interim proposal

[bretg]

After detailing the Activity Infrastructure in #2591 and the full GPP Privacy Infrastructure in #2686, I've started to become concerned about missing the legal timeline for MSPA/USNat enforcement. I think it will take several months to build, test, and release these features.

Here's a proposal that could utilize the Activity Infrastructure and give publishers a somewhat extreme anonymization option as way to meet the deadline while giving ourselves more time to build out the GPP Infrastructure.

The idea is to build a condition into the existing activity control infrastructure that checks the GPP SID

privacy.allowactivities: {
    syncUser: {
        rules: [{
          condition: {
            gppSid: [7,8,9,10,11,12]
          },
          allow: false
        }]
    },
    transmitUfpd: {
        rules: [{
          condition: {
            gppSid: [7,8,9,10,11,12],
            componentType: ["bidder", "analytics", "module"]
          },
          allow: false
        }]
    },
    transmitGeo: {
        rules: [{
          condition: {
            gppSid: [7,8,9,10,11,12]
          },
          allow: false
        }]
    },
    enrichUfpd: {
        rules: [{
          condition: {
            gppSid: [7,8,9,10,11,12],
            componentType: ["module"]
          },
          allow: false
        }]
    }
}

This new gppSid condition does the following:

1. If regs.gpp_sid doesn't exist, return false
2. If regs.gpp_sid does exist, it's an array of integers, e.g. [2,7]. If there's any intersection between regs.gpp_sid and the value of gppSid, then return true.
3. Else return false

See below for additional conditions: geo and gpc.

[patmmccann]

This appears to be rather alarming at first. If a publisher sends any GPP string, PBS monetization would likely crash 70% overnight. Publishers may quickly be alienated from host companies adopting this configuration.

[SyntaxNode]

Discussed in the Prebid Server Committee. This configuration can apply at the host and account level. The comment above from @patmmccann provides insight into the risk of a host level config, so hosts may wish to consider account level config.

In July, new privacy laws go into effect for California and Virginia. Given this context, there were requests from the Committee to add a geo filter to provide the ability to restrict rules to just those states. This is possible, but PBS-Java resolves geo location after reducing precision making this hard to implement with confidence. PBS-Go relies on accurate user.geo information in the OpenRTB request provided by either the publisher or upstream systems with similar confidence uncertainties. As such, at this time we don't see much value in a geo filter.

[bretg]

Ok, here's a proposed extension to the condition to accommodate the desire to restrain this behavior to particular geographic areas:

        rules: [{
          condition: {
            gppSid: [7,8,9,10,11,12],
            geoCountry: ["USA"]
            geoRegion: ["UT","VA","CT","CA","CO"]
          },
          allow: false
        }]

We would add 2 new conditional attributes:

1. geoCountry - an array of 3-character country codes (ISO-3166-1-alpha-3)
   1. If defined, PBS checks device.geo.country. If device.geo.country does not exist, the result is false.
   2. If device.geo.country exists, and that string is in the geoCountry array, the result is true.
   3. Otherwise the result is false.
2. geoRegion - an array of 2-character region/state codes (ISO-3166-2)
   1. If defined, PBS checks device.geo.region. If device.geo.region does not exist, the result is false.
   2. If device.geo.region exists, and that string is in the geoRegion array, the result is true.
   3. Otherwise the result is false.

Notes:

• In both cases, the comparison is case-sensitive. Since the ISO values are always upper-case, the config should also always be uppercase. If config is lowercase, it won't likely match anything.
• If geo is not available, the rule would not fire.
• IP rounding is not expected to make geo-lookup results inaccurate at the state level, but this has not been tested.

[SyntaxNode]

If we wish to proceed this with feature, I wish to offer a proposal which combines the geoCountry and geoRegion filters, from the perspective that they are hierarchal.

Example:

rules: [{
  condition: {
    gppSid: [7, 8, 9, 10, 11, 12],
    geo: ["USA.VA"],
  },
  allow: false
}]

Where geo is a combination of the 3-character country code (ISO-3166-1-alpha-3) and an optional 2-character region code (ISO-3166-2, 2-letter state code if USA). This aligns with the OpenRTB 2.x geo.country and geo.region fields.

The following patterns are acceptable:
<Country Code> - geo.country of the request must be in this list to match. geo.region is ignored
<Country Code>.<Region Code> - geo.country and geo.region of the request must be in this list as a complete pair

[bretg]

@SyntaxNode 's proposal discussed in committee and approved. The scenario that hierarchical geo simplifies is when multiple countries with multiple regions are involved. e.g. ["USA.WA", "CAN.BC"]

[bretg]

The matching algorithm for when condition.geo is defined:

• If it's not an array or if device.geo is not available, return false.
• loop through the strings in the array
  • if there's not a dot in the string, compare it against device.geo.country. If it matches, return true
  • else if there is a dot in the string, concatenate device.geo.country, ".", and device.geo.region. If it matches, return true
• if we still have found a match, return false

[bretg]

Another aspect of the coming legal milestone is support for taking action based on the Global Privacy Control flag. So I propose adding another straight-forward gpc condition that would need to be implemented with the existing GPC issue

rules: [{
  condition: {
    gpc: "1",
    geo: ["USA.VA"]
  },
  allow: false
}]

Processing:

• if gpc exists in a condition, check regs.ext.gpc. If it exists and matches the value in the condition, return true
• else return false

[bretg]

Discussed in committee. The IAB hasn't yet merged regs.ext.gpc. We will monitor that part of this proposal.

[bretg]

Done in PBS-Java 1.122