AzerionEdge RTD Module: Compatibility with GDPR/USP Privacy Modules

[garciapuig]

Type of change

• Bugfix

• Feature

• New bidder adapter

• Updated bidder adapter

• Code style update (formatting, local variables)

• Refactoring (no functional changes, no api changes)

• Build related changes

• CI related changes

• Does this change affect user-facing APIs or examples documented on http://prebid.org?

• Other

Description of change

AzerionEdge RTD Module: Added Compatibility with GDPR/USP Privacy Modules

Other information

prebid/prebid.github.io#5414

[muuki88]

Isn't this something the tcfConsentManagement module should handle?

[gguridi]

I'm not sure we understood the functionality of the consentManagement module correctly. Please let me know if anything that I'm saying is incorrect.

The consentManagment module is used to fetch, decode and pass the user consent to bid adapter, RTD modules, etc. The publisher uses this module to configure the integration with its CMP. It also allows adding some rules to automatically enforce GDPR based on their GVL_ID through the gdprEnforcement module. Like the one shown here as Sirdata's example:

pbjs.setConfig({
    consentManagement: {
        usp: {
            cmpApi: 'iab',
            timeout: 100 // US Privacy timeout 100ms
        },
        gdpr: {
          cmpApi: 'iab',
          timeout: 8000,
          defaultGdprScope: true,
          rules: [{
            purpose: "storage",
            enforcePurpose: true,
            enforceVendor: true,
            vendorExceptions: ["appnexus"] //Can work without consent for cookies
          },{
            purpose: "basicAds",
            enforcePurpose: true,
            enforceVendor: true,
            vendorExceptions: ["appnexus"]
          }]
        },
    }
});

But if we want to automatically check the consent given for our module from inside our RTD module, without the publisher having to configure that, we can't use the consentManagement module. We've seen other modules doing the checks manually like in our case. For instance sirdata.

We are not sure if there's a better way of doing this through any helpers, or exported functions from consentManagement/gdprEnforcement modules. The closest we could find was the method hasPurpose1Consent but it only checks for one purpose and we need to check five.

Any insight or suggestion about how to better approach this would be greatly appreciated.

[dgirardi]

But if we want to automatically check the consent given for our module from inside our RTD module, without the publisher having to configure that, we can't use the consentManagement module.

Generally we prefer to let the publisher specify how they want their consent to be handled - which for you would mean not worrying about it at all (at least client side). Access to storage, ortb2, etc is gated depending on consent + configuration - as long as you go through the gates (which you appear to do, although I don't know what's going on in the external script).

With what you have here you still need some configuration from the publisher - they need to set up the consentManagement modules at least, otherwise you would interpret it as not applicable / consented. So IMO it's reasonable to expect that they also have reviewed / decided / configured how they want to restrict what modules do depending on it.

If you prefer to also do your own parallel check, you're signing up for a lot of work. USP is in theory being phased out and replaced by GPP, which is already supported in Prebid, but not considered by this PR. Canada is planning to adopt a version of TCF that's just different enough to be annoying. Other jurisdictions are planning other systems.

[patmmccann]

@dgirardi in theory perhaps we should add a loadExternalScript activity? This way, Azerion wouldn't need to worry about their script getting attached if various consent strings suppressed the activity. I agree the consent checks they are doing for attaching data should be covered already by https://docs.prebid.org/dev-docs/activity-controls.html#:~:text=None-,enrichUfpd,-A%20Real%2DTime

[dgirardi]

@patmmccann I'm not saying we shouldn't add a script activity, but it'd just be an additional gate that still requires the publisher to set it up / configure consent modules to restrict it. If the goal is to always check for consent regardless of publisher preference it wouldn't help.

[garciapuig]

@dgirardi thanks for your clarification.

Would that mean that as we already use getStorageManager and getBidRequestData, those actions will not be happening if the consent management enforcement is already configured on the publisher (equivalent to checking to purposes 1, 2 for example)?

We need to validate also other purposes i.e. '5', '7', '9'.... should we keep manually checking for those?

On the other hand, I'm right to assume we will need to add the gvlid in the module export anyway, if that's the case?

[dgirardi]

GDPR purposes are only indirectly linked to those. Storage manager and adding user segments (through the argument passed to getBidRequestData) are gated with activities (accessDevice and enrichUfpd respectively; there's more if you do more than adding segments). If the publisher sets up tcfControl then those are denied based on GDPR purposes 1 and 4 respectively. But they are free to use any other strategy (and again, tcfControl is only a little piece of what can set up rules for those activities).

So if your goal is specifically to check for a particular GDPR purpose, it doesn't help you. I don't know the specifics of your situation but that's something that I think is best done server side.

The GVL id should be added as a parameter in your submodule definition (gvlid: ...); if it's missing, it will fail any check from tcfControl.

[garciapuig]

@dgirardi @muuki88 after the clarification we applied your recommendations to move the consent checks to the backend script (removing any consent check logic from the submodule) and also added the missing GVL ID.

Many thanks