Activity control enhancement: transmitEids exceptions

[bretg]

As covered in prebid/prebid-mobile-ios#1057 (comment), not every extended ID (EID) is the same. Some of them are very relevant to privacy like those based on hashed-emails, while others are less of a privacy concern to many publishers like SharedID, which is more like a session identifier because it doesn't work across domains or across apps.

Towards letting PBS host companies have control over which EIDs are sensitive in which privacy scopes, there's a proposal to enhance the activity controls to allow for more flexible exceptions.

Use cases:

1. An app developer wants to let SharedID through to bidders no matter the privacy regime
2. An app developer wants to let SharedID though to bidders, but not when the GPC flag is set

Proposal:

Enhancing the existing activity control conditions was explored, but the problem is that

• enhance the existing rules
• add filterExceptions, which currently only applies to the transmitEids activity
• filterExceptions can be specified at the top level of the activity and be overridden in a specific rule.

Configuration for Use Case 1. An app developer wants to let SharedID through to bidders no matter the privacy regime

{
  "privacy": {
    "allowactivities": {
      "transmitEids": {
        "filterExceptions": [ "pubcid.org", "pubprovided" ],
        "rules": [{
            "privacyreg": ["*"]
        }]
      }
    }
  }
}

Configuration for Use Case 2. An app developer wants to let SharedID though to bidders, but not when the GPC flag is set:

{
  "privacy": {
    "allowactivities": {
      "transmitEids": {
        "filterExceptions": [ "pubcid.org", "pubprovided" ],
        "rules": [{
            "condition": {
                gpc: "1"
            },
            "allow": false,
            "filterExceptions": [ ]
        },{
            "privacyreg": ["*"]
        }]
      }
    }
  }
}

Changes:

1. Tie the LMT flag to transmitEids and transmitPreciseGeo processing activities instead of having separate processing. However, when these activities are initiated as a result of LMT, the "default" allow rule should be false.
2. Support filterExceptions only on the transmitEids activity
3. Update transmitTids processing.
   1. Determine the overall allow status for this component as usual, but also calculate filterExceptions: if it's an empty array, there are no exceptions.
   2. If the EIDs are not allowed but there are filterExceptions defined, instead of simply removing EIDs, loop through the EIDs array:
      1. If eid.source is on the array of filterExceptions, leave this element. If not, remove it
   3. If we reach the end of the array and it's empty, then remove the entire EIDs object before sending it

At this time it's out of scope to support the opposite scenario where specific EIDs are removed from the array. That could be added in the future as needed.