Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GPP Phase 3.5 - target activities by geo and sid #2622

Open
bretg opened this issue Mar 3, 2023 · 9 comments
Open

GPP Phase 3.5 - target activities by geo and sid #2622

bretg opened this issue Mar 3, 2023 · 9 comments

Comments

@bretg
Copy link
Contributor

bretg commented Mar 3, 2023

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

bretg commented May 30, 2023

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
Copy link
Contributor

SyntaxNode commented Jun 2, 2023

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
Copy link
Contributor Author

bretg commented Jun 2, 2023

@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
Copy link
Contributor Author

bretg commented Jun 6, 2023

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
Copy link
Contributor Author

bretg commented Jun 6, 2023

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 bretg moved this from Needs Requirements to Ready for Dev in Prebid Server Prioritization Jun 6, 2023
@bretg
Copy link
Contributor Author

bretg commented Jun 7, 2023

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

@bretg bretg added the PBS-Go label Jun 30, 2023
@bretg
Copy link
Contributor Author

bretg commented Jun 30, 2023

Done in PBS-Java 1.122

@bretg bretg changed the title GPP Phase 3.5 - USNP interim proposal GPP Phase 3.5 - target activities by geo and sid Dec 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Ready for Dev
Development

No branches or pull requests

3 participants