Open Tudmotu opened 3 years ago
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?
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 :)
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?
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.
__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.
Thanks! Good to know about the __tcfapi
support! :)
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 onwindow.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 containconsentMetadata
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 thecheckConsentHref
doesn't contain theconsentMetadata
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 aconsentString
but noconsentMetadata
: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 GDPRwindow.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-dataRoute 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 containsconsentMetadata
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