Prebid.js: If both CMP and TCF2.0 APIs exist, if no valid TCF2.0 response is found, it does not fallback to CMP

[jsonUK]

Type of issue

Bug

Description

I am currently testing our CMP from https://www.consentmanager.net. Our CMP stub has both __cmp and __tcfapi present.

If both the __cmp and __tcfapi APIs are present, Prebid defaults to __tcfapi even when no consent string is returned.
We still have v1.1 __cmp running as we plan to switch to TCF2.0 at a later date.

Considering there is a transition period occurring, I would have expected Prebid to check __tcfapi returns a valid response before falling back to __cmp.

Steps to reproduce

Load the test page - agree to the CMP.
Look at the console output. Read the Bid Request object from pbjs_debug, open the first bid entry, the gdprConsent will show apiVersion: 2 and contentString will be undefined.

Above there will be a getConsentData callback result output that will show the consent data from __cmp API with a valid consent string.

Test page

https://prebid.os.network-n.com/demo/?site=steamidfinder&pbjs_debug=true&nndebug=cmp

Expected results

Prebid should be able to determine whether a valid consent is from v1.1 or TCF2.0, and should fall back to v1.1 if no valid TCF2.0 consent is found.

Actual results

Prebid finds TCF2.0, has no valid consent signal and continues the auction without checking for v1.1.

Platform details

Version 3.14.0

Other information

No other information at this time.

[patmmccann]

How do you propose modifying https://github.com/prebid/Prebid.js/blob/master/modules/consentManagement.js#L58 ?

[tahanzania]

@patmmccann would consentManagement.js work with CCPA?

[patmmccann]

that uses consentmanagementusp.js

[bretg]

@jsonUK - this isn't a use case we thought anyone would do. Any chance you can submit a fix? We're rather backed up right now.

[smenzer]

AFAIK, TCF guidelines from the IAB Tech Lab are that a CMP is _either_ v1.x or v2.x, and that a single page should only have one. Therefore, this use case doesn't seem valid to me. That said, @jsonUK if you have example websites that are doing this in production, that would be interesting to review.

[janwinkler]

@smenzer Unfortunately that is not correct. During the transition phase (started in April and ends in September 2020) a CMP can (should?) support both versions, especially as there will be vendors that still support v1 and others that already/only support v2. A vendor/technology could therefore check __tcfapi('ping',...) in order to see if the cmp is actually configured for supporting tcf v1 or v2. As an alternative prebid can simply call both (if both are present) and see which returns with a result.

[janwinkler]

PS: not sure if prebid acutally tests this: __tcfapi('getTCData',2,function (x,y){console.log(x,y);}); --> y should return false in case when tcf v2 is not supported. in this case call __cmp(...)

[patmmccann]

PS: not sure if prebid acutally tests this: __tcfapi('getTCData',2,function (x,y){console.log(x,y);}); --> y should return false in case when tcf v2 is not supported. in this case call __cmp(...)

it just tests to see if tcfapi is a function https://github.com/prebid/Prebid.js/blob/master/modules/consentManagement.js#L58

[smenzer]

@janwinkler I'll have to go back and look for the slack messages about this, but I recall being told that you can't support both versions because the UI/purposes/etc are different. So how/why would a CMP support both api's at the same time?

[janwinkler]

@smenzer Yes the purposes are different and cannot be mixed. hence a single user would always only see a v1 OR v2 message. But as the publisher cannot know if the user comes with an "old" or a "new" cookie on the website, the CMP could support both at the same time and simply display a different message (or respond to a different API call) depending on the user.

[janwinkler]

@patmmccann Not sure i read the code correct but there is a potential second issue: It seems prebid only calls addEventListener and then waits for the response. The issue with this is, that the initial TCF v2 spec does not give a statement what addEventListerner should return as "eventStatus" property. This means a CMP is also valid if addEventListerner calls the callback with eventStatus unknown or null. If addEventListener is called after the actual event, prebid will never receive a positive signal. The issue has been addressed to the TCF working group and will be changed, but for compatibility reasons the v2CmpResponseCallback should also treat eventStatus === null and eventStatus === undefined as valid until the spec has been corrected.

[dmdabbs]

smenzer: AFAIK, TCF guidelines from the IAB Tech Lab are that a CMP is either v1.x or v2.x, and that a single page should only have one.

Correct. It isn't a valid use case for both the v2 and v1 APIs to be present on the same page.
A publisher may choose to "A/B test" for some time while v1 remains 'legal tender.' But on any given page only one API version should be available. Ideally, a pub/CMP testing both would ensure that a user exposed to v2 disclosures never has the v1 CMP used again.

The IAB EU released a spec clarification directing CMPs to delete a v1 consent string (local/service-specific strings only) in this case. From the most recent spec PR:

Before 30 September 2020, after which v1.x strings will be considered invalid, if a CMP encounters a situation where both a v1.x string and a v2.0 string are erroneously present simultaneously, the CMP should remove the v1.x string to ensure that there is only one source of truth for consumers of the string.

After 15 Aug a v1 CMP should no longer surface to gather _new_ v1 consent. Will some CMPs use cached GVL info for publishers that couldn't act by the deadline? Very likely.
After 30 September v1 strings are no longer valid for use, so the publisher should direct their CMP not to make the v1 API available. Prebid releases after that date should remove v1 API cruft.

it just tests to see if tcfapi is a function

That's the proper check before attempting to call either API.

[janwinkler]

it just tests to see if tcfapi is a function

That's the proper check before attempting to call either API.

Yes, to check if the functio exists, but does not automatically mean, that it will reply with the info that we expect ;-)

Correct. It isn't a valid use case for both the v2 and v1 APIs to be present on the same page.

I dont see any policy that says this.

[patmmccann]

@patmmccann Not sure i read the code correct but there is a potential second issue: It seems prebid only calls addEventListener and then waits for the response. The issue with this is, that the initial TCF v2 spec does not give a statement what addEventListerner should return as "eventStatus" property. This means a CMP is also valid if addEventListerner calls the callback with eventStatus unknown or null. If addEventListener is called after the actual event, prebid will never receive a positive signal. The issue has been addressed to the TCF working group and will be changed, but for compatibility reasons the v2CmpResponseCallback should also treat eventStatus === null and eventStatus === undefined as valid until the spec has been corrected.

are you able to open a second issue to track this?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jsonUK]

Afraid changes to the codebase are no longer going to help us achieve a smoother transition in time - as we have picked August 15th as our transition date.

If additional checks are made for validating both v1.1 and v2.0 APIs being present, it may be helpful others who are possibly still waiting to transition at the end of September.

Sorry we did not offer any PR or changes - we opted for a hard-coded solution in the end to remove the v2.0 CMP stub until the 15th August occurs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.