Fix gdprenforcement module to look for generic purpose 1 consent when enforcing legacy pubcommonid and sharedid modules

[JulieLorin]

Type of issue

I think this is a bug

Description

When using both gdprEnforcement (with enforcement or purpose and vendor for storage) and pubCommonId, pubCommonId is denied access to storage and won't be able to retrieve an ID

Steps to reproduce

Just import both module.
You can use this configuration in setConfig :

consentManagement: {
      gdpr: {
        cmpApi: 'iab',
        timeout: 3 000,
        allowAuctionWithoutConsent: false,
        rules: [ {
          purpose: 'storage',
          enforcePurpose: true,
          enforceVendor: true
        }, {
          purpose: 'basicAds',
          enforcePurpose: false,
          enforceVendor: false
        } ]
      }
    }

Expected results

I expect to have a pubcid when consent is given

Actual results

I have a log live saying pubcid = null

Platform details

Chrome

Other information

I tried some debugging and what is happening is that pubCommonId creates a storageManager with no gvlid and no moduleName.
So when pubCommonId tries to write the ID in the local storage, because of those lines in gdprEnforcement module :

const vendorConsent = deepAccess(consentData, `vendorData.vendor.consents.${gvlId}`); // vendorConsent will be undefined if 
const vendorAllowed = rule.enforceVendor === false || vendorConsent === true;

[patmmccann]

@dgirardi after review this is indeed a bug, and a rather high priority one.

The Pubcommonid does not have a vendor id, which is correct as it is set by the publisher, so I believe we should just be checking consentData for purpose one consent with no specific vendor at all. I had to decode a tcf string to see if this was even a concept, it appears to be so, that there is generalized purpose one consent.

[dgirardi]

@patmmccann right now the logic is "allow if both purpose and vendor are explicitly allowed". The fix seems to be "allow if purpose is allowed, and vendor is either allowed or unknown". Is that right? it seems like a major change in the meaning of the consent string.

Prebid.js/modules/gdprEnforcement.js

Lines 136 to 157 in 02264c8

	// get data from the consent string
	const purposeConsent = deepAccess(consentData, `vendorData.purpose.consents.${purposeId}`);
	const vendorConsent = deepAccess(consentData, `vendorData.vendor.consents.${gvlId}`);
	const liTransparency = deepAccess(consentData, `vendorData.purpose.legitimateInterests.${purposeId}`);
	/*
	Since vendor exceptions have already been handled, the purpose as a whole is allowed if it's not being enforced
	or the user has consented. Similar with vendors.
	*/
	const purposeAllowed = rule.enforcePurpose === false || purposeConsent === true;
	const vendorAllowed = rule.enforceVendor === false || vendorConsent === true;
	/*
	Few if any vendors should be declaring Legitimate Interest for Device Access (Purpose 1), but some are claiming
	LI for Basic Ads (Purpose 2). Prebid.js can't check to see who's declaring what legal basis, so if LI has been
	established for Purpose 2, allow the auction to take place and let the server sort out the legal basis calculation.
	*/
	if (purposeId === 2) {
	return (purposeAllowed && vendorAllowed) || (liTransparency === true);
	}
	return purposeAllowed && vendorAllowed;

[bretg]

@JulieLorin - PubCommon has been deprecated in favor of SharedID since PBJS 5.0. So two comments:

1. I confirmed that the sharedId module contains a reference to Prebid's GVL ID of 887. Users could be asked to consent to this.
2. Or, if the publisher wishes, they can confirm with their lawyers whether it's acceptable to configure the GDPR module with a vendor exception. Unfortunately I just found that the sharedId module still calls itself "pubCommonId" from the perspective of this exception. @jdwieland8282 - we may want to consider fixing this in a future release.

Anyhow, heres an example:

consentManagement: {
      gdpr: {
        cmpApi: 'iab',
        timeout: 3000,
        allowAuctionWithoutConsent: false,
        rules: [ {
          purpose: 'storage',
          enforcePurpose: true,
          enforceVendor: true.
          vendorExceptions: ["pubCommonId"]       // wish it weren't still called pubcommonId here, but it is.
        }, {
          purpose: 'basicAds',
          enforcePurpose: false,
          enforceVendor: false
        } ]
      }
    }

[patmmccann]

I believe Prebid's GVL ID of 887 was there for pre5.x behavior and should be removed. The sharedid and the pubcommonid are generated only in the first party and purpose consent is applicable, but not consent to any particular vendor. The enforcement module should understand how to handle this "vendorless consent" whether a publisher is doing their own analytics, establishing their own id, or suplying their own RTD.

[patmmccann]

@JulieLorin it isn't clear if you are referring to the standalone pubcommon id module or the id submodule, could you also clarify your prebid version?

[patmmccann]

@jdwieland8282 -- let's take up this in next id committee meeting; should there be "vendor-less" modules that gdpr enforcement allows

[dgirardi]

@patmmccann, @bretg does the first party fall outside of GDPR scope? it's not technically difficult to replace the GVLID with a placeholder that means "first party", but it would not be possible to decline consent for it (unless you decline storage in general). It's unclear to me if going this route breaks the rules.

[jeremiegirault]

In my opinion for first party Id, the adapter should support a customization option allowing the publisher/operator to add its own vendorId for tcf check.
@dgirardi I would not assume that fpid falls outside gdpr

[JulieLorin]

@JulieLorin it isn't clear if you are referring to the standalone pubcommon id module or the id submodule, could you also clarify your prebid version?

@patmmccann
I am talking about this module : https://github.com/prebid/Prebid.js/blob/master/modules/pubCommonId.js
So this module is deprecated and we should use sharedId instead (which is named pubCommonId internally) ? (If that is the case, it may be useful to add a note in the module .md file)

The prebid version is 6.11.0

[patmmccann]

@JulieLorin that's true, the old module was kept open at Conversant's request while they work to migrate people. The new module might suffer the same issue however if we remove the gvlid, so we'll keep this open to track.

[dmdabbs]

FWIW, the TCF signals specs support CMPs providing transparency for the publisher's processing. These would be the "authoritative" publisher signal, if present.
https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20Consent%20string%20and%20vendor%20list%20formats%20v2.md#publisher-purposes-transparency-and-consent.

These are reflected in the "publisher" sub-object in the TCData API response: https://github.com/InteractiveAdvertisingBureau/GDPR-Transparency-and-Consent-Framework/blob/master/TCFv2/IAB%20Tech%20Lab%20-%20CMP%20API%20v2.md#tcdata.

Absent these, checking "Purpose 1 consented" is a good baseline.

[bmjoju]

After updating from 7.42 to 7.54.0 this warning now shows up "WARNING: Activity control: TCF2 denied 'accessDevice' for 'userId.pubCommonId'". I guess due to this #9736 ?