Privacy Module: TCF-Canada

[bretg]

The next GPP Module will be TCF-Canada.

The general requirements, legal basis determination, and mapping to Activity Controls is drafted at https://docs.google.com/document/d/1SFTHpgQHhgVjKnyyw87EbR3YpSIxaI6r2sJDcuAoOFM/edit . Note that this is still under review, and IAB Canada may make updates to reflect TCF 2.2.

This issue proposes a Prebid Server-specific configuration, highlighting differences from the processing of TCF-EU.

Differences between TCF-CA and TCF-EU

The differences noted in the doc are: GVL file location, field renaming, and one dropped feature: PurposeOneTreatment.

In addition to these differences, other changes proposed in the doc as compared to existing TCF processing:

1. Linked to the Activity Control infrastructure
2. "Strong" vendor exceptions are no longer supported - only "soft" exceptions.
3. Prebid can control which legal bases are available for which Purposes.
4. The "basic" and "full" legal basis processing algorithms have been merged.
5. The requirement to have channel-level enabled flags has been removed since that can be managed at the activity control level.
6. No geo-lookup is needed to determine the TCF-CA scope - the existence of '5' in the GPP SID array is sufficient.
7. Special Feature 1 (precise geo) no longer supports vendor exceptions.
8. Support prebid-level control of implied-vs-express consent.

Linking to TCF-CA from Activity Config

There are no changes from how we defined the top-level Activity configuration in #2686 . This is just another privacy module named "iab.tcfca".

  privacy: {
    allowactivities: {
      activityN: {
        rules: [{
          privacyreg: ["iab.*"]   // check all IAB privacy modules
        }],
        default: false
      }
    }
  }
}

Proposed TCF-CA Privacy Module Config

The name of the module is iab.tcfca.

In general, the TCF-CA configuration aligns with the existing "GDPR" (TCF-EU) configuration, allowing account-level configuration of important details. The differences from GDPR:

• normalizing the attributes to camelCase
• only purposes relevant to Prebid can be specified: 1,2,4, and 7.

For example:

{
  "privacy": {
      "modules": [{
        "code": "iab.tcfca",
        "enabled": true,                                         // defaults to true
        "config": {
           "purposesAllowingImpliedConsent": [1,2,7],
           "purposes": {
               "pN": {                                                 // where N can only take the values 1,2,4, and 7
                   "enforcePurpose": true/false,       // defaults to true
                   "enforceVendors": true/false,       // defaults to true
                   "vendorExceptions": [ "bidderA", "9999" ]
               }
           },
           "specialFeatures": {
               "f1": {
                   "enforce": true/false                     // defaults to true
               }
           }
        }]
  }
}

Where:

1. enabled is a flag that allows the publisher to completely turn off this module, causing it to effectively "abstain" from any Activity which consults it. The value must be boolean. The default value is true.
2. purposesAllowingImpliedConsent maps to purposeAllowsImpliedConsent[P] in the legal basis algorithm. The value must be an array of integers. The default value is [1,2,7].
3. enforcePurpose maps to enforcePurpose[P] in the legal basis algorithm. The value must be boolean. The default value is true.
4. enforceVendors maps to enforceVendor[P,V] in the legal basis algorithm. The value must be boolean. The default value is true.
5. vendorExceptions maps to softVendorExceptions[P] in the legal basis algorithm. The value must be an array of strings. The values may be a bidder code, a hardcoded bidder alias, a dynamic bidder alias, or a bidder GVLID. The default value is empty.
6. enforce maps to featureEnforced[F] in the legal basis algorithm. The value must be boolean. The default value is true.

If there's a minor validation error with one of these values (e.g. bad datatype), fall back to the default. A failure should cause the system should generate an alert.general metric with N% logging and emit a warning in the ORTB response.

Ignore unknown fields in the JSON.

If there's a major validation error with the account-level JSON, 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.

iab.tcfca Processing

When called by the Activity Control infrastructure, module processing follows this high level outline:

1. If not enabled, return "abstain".
2. If regs.gpp_sid does not contain 5, return "abstain".
3. Determine which purposes or special feature require legal basis for this Activity based on the table in the document. e.g. accessDevice requires basis for Purpose 1.
4. For each Purpose/Feature for which legal basis is required, use the Legal Basis algorithm in the doc to determine whether basis is obtained for each activity/vendor.
   1. Note: the vendorExceptions array of strings can match any of the following: a bidder code, a hardcoded bidder alias, a dynamic bidder alias, or a bidder GVLID.
5. If all required Purposes/Features have obtained legal basis, return "allow"
6. Otherwise, return "disallow".

[SyntaxNode]

Discussed in committee.

Significant changes are expected for the TCF Canada specification based on industry criticism. No urgency from our Canadian members at this time.