GDPR-Transparency-and-Consent-Framework
GDPR-Transparency-and-Consent-Framework copied to clipboard
Clarify if `__tcfapi` is required to be present in scenarios where gdprApplies is false
Some of the wording in this spec leads me to believe that it is expected for __tcfapi
to always be available synchronously regardless of whether or not GDPR applies or not.
Namely,
The function __tcfapi must always be a function and cannot be any other type, even if only temporarily on initialization – the API must be able to handle calls at all times.
If GDPR does not apply to this user in this context then only gdprApplies, tcfPolicyVersion, cmpId and cmpVersion shall exist in the object.
A CMP-provided synchronous "stub" script must be added by the publisher to their page before any other scripts that rely on __tcfapi (this usually means between the
tags of the HTML document).
It seems like in practice though, the __tcfapi
is left undefined on many sites using CMPs when GDPR is not applicable. The above sections of the spec makes me think it really ought to be available regardless, but I could see room for interpretation and I'm left wondering if it's something that the spec takes a position on or if it's left up to the implementation.
Just to briefly touch on why this distinction could matter: for a site that conditionally defines __tcfapi
based on whether GDPR applies or not, as another third-party script integrating with CMPs, it is impossible to know without doing a GDPR check yourself whether the site is being loaded where GDPR does not apply, or if the site simply isn't running a CMP. If __tcfapi
is mandated to always be defined, you would still be able to setup a listener and end up receiving an event with gdprApplies: false
and can differentiate between these two cases and avoid needing to do the GDPR check as well.