Inconsistent behavior of initialConsentMetadata in different CMPs

[Tudmotu]

What's the issue?

window.context.initialConsentMetadata behaves inconsistently between different CMPs and different consent types (GDPR / CCPA). This inconsistency makes it difficult for 3p providers to identify which consent type is being used, and basically means we cannot rely on window.context.consentMetadata and have to resort to other ways of identifying the consent type / value.

How do we reproduce the issue?

Example 1 - LeFigaro

LeFigaro are using AppConsent CMP with the amp-consent integration. Issue: The consentHrefResponse doesn't contain consentMetadata field, but somehow it gets into the 3p iframe. Example url: https://amp.lefigaro.fr/flash-actu/trump-appelle-les-republicains-a-se-retourner-contre-leur-chef-au-senat-20210216 Seems like the response from the checkConsentHref doesn't contain the consentMetadata field (this is after "accepting" - also no consent string):

But if you check window.context.initialConsentMetadata (inside a 3p frame), it has a value:

Example 2 - DailyMail

DailyMail are using their own CMP solution (under dmg::media brand). Issue: Seems like their CMP implementation doesn't support consentMetadata. Example url: https://www.dailymail.co.uk/news/article-9264237/amp/Joe-Biden-plans-release-immigration-bill-grant-path-citizenship-11-million.html Use a proxy to route your traffic via California, US, otherwise the consent request is not sent. The consent request contains a consentString but no consentMetadata:

The window.context.initialConsentMetadata object is undefined (as expected I believe).

Example 3 - Bloomberg

Bloomberg are using Sourcepoint as their CMP. They are NOT using the amp-consent integration. They have custom consent URLs. Issue: Their implementation differs between CCPA and GDPR. There is no consentMetadata in either response, but with GDPR window.context.initialConsentMetadata exists with values. Example url: https://www.bloomberg.com/amp/news/articles/2021-02-14/u-k-backs-biden-over-call-for-china-to-release-covid-data

Route your traffic via California, and the CMP response will not contain consentMetadata:

initialConsentMetadata will be undefined (as expected..?):

If you route via Europe, you get a different response, with all kinds of stuff but no consentMetadata:

But you do get a initialConsentMetadata object somehow:

Example 4 - Ouest France

Ouest France are using the Didomi amp-consent integration. Issue: Always uses GDPR even when navigating from California. Does not provide CCPA consent. Example url: https://amp.ouest-france.fr/economie/banques-finance/cryptomonnaies-nouveau-record-pour-le-bitcoin-7106717

When navigating from California, the checkConsentHref response contains consentMetadata but has consent type of GDPR:

What browsers are affected?

Only tested on desktop Chrome with emulation.

Which AMP version is affected?

Not sure, we were unaware of this issue until recently (last week or two).

cc @micajuine-ho

[micajuine-ho]

Hi @Tudmotu , thanks for your bug report. It seems like the problem here is that different CMPs are not passing in consistent metadata dependent on geolocation.

Example 1 - LeFigaro

In the screenshot of checkConsentHref we see that they have expireCache set to false. Therefore, the metadata stored in LocalStorage will be sent to the ads, since it is not cleared by expireCache.

Example 2 - DailyMail

Does a consent metadata need to be sent within CA under CCPA? In my understanding, the CCPA consent string passed in (1YNN) should be able to be interpreted by vendors as under CCPA jurisdiction.

Example 3 - Bloomberg

The issue of having consentMetadata in the initialContext in GDPR but not in CCPA is the same as Example 1.

Example 4 - Ouest France

This is a problem, however AMP provides solutions for Didomi to detect geoLocation and then to change requests based upon that: https://github.com/ampproject/amphtml/blob/master/extensions/amp-consent/amp-consent.md#geooverride

Or they should do the geolocation on their severs and then return a correct gdprApplies values. . . .

Of these problems, I believe we could look into better ways of being more transparent with the consent data passed from CMP; i.e. the fact that the CMP has not updated or expired the consent metadata therefore it might be stale. Would this help?

[Tudmotu]

Thank you @micajuine-ho for looking into this and for the explanations! :) About your question - I'm not sure if this would help. But, it's a complicated topic and I definitely can't speak for other 3p vendors. What we wanted to have is a clear distinction between CCPA and GDPR, but since the implementations are inconsistent, we can't count on initialConsentMetadata. Currently we identify the source (CCPA / GDPR) based on the format of the initialConsentValue string, like you suggest, and it seems to work for us :)

[micajuine-ho]

Does a consent metadata need to be sent within CA under CCPA? In my understanding, the CCPA consent string passed in (1YNN) should be able to be interpreted by vendors as under CCPA jurisdiction.

IMO, I think CMPs should pass in consentMetadata w/ consentStringType field, which would be passed to the ad iframe, this way we can distinguish GDPR vs CCPA without interpreting the string.

Another question is how does GDPR vs CCPA work outside of AMP? Do all CMPs do the same solution?

[Tudmotu]

As long as consentMetadata is not consistently supported, it will be difficult to rely on. I assume we want to keep AMP "agnostic" and not parse the type in AMP? About your question - Outside of AMP there are standard APIs for each consent type created by the IAB organization. GDPR has the __tcfapi and CCPA has __uspapi. BTW, outside of AMP it is possible (and sometimes required) to support BOTH the CCPA and GDPR consent. In AMP this is not possible as far as I can tell.

[micajuine-ho]

__tcfapi

We have recently added a proxy implementation of the TCF PostMessage APIhttps://github.com/ampproject/amphtml/issues/30385. Maybe this will help in the future.

__uspapi

I will look into this.

[Tudmotu]

Thanks! Good to know about the __tcfapi support! :)