Benoît Oberlé (Sirdata) : “Google doit mieux respecter les policies du TCF”

Google prend désormais part au Transparency & Consent Framework v2.0 de l’IAB Europe, et annonce respecter ses règles et spécifications. Tant mieux, car le groupe fait partie des partenaires et acteurs majeurs du secteur publicitaire. Mais de nombreuses questions techniques restent à résoudre pour articuler le TCF et les choix effectués par Google, lesquels on le sait s’imposent souvent aux autres acteurs, en raison de sa position centrale entre vendeurs et acheteurs publicitaires.

C’est notre cas à Sirdata. Notre société a intégré le TCF dès l’origine, en tant que vendor (ID 53) et comme CMP (ID 92). Et certains choix de Google nous posent question. Nous ne sommes pas les seuls du reste.

Google diffuse et transmet la chaîne de TC (TC String) pour les demandes d’annonces depuis la mi-août 2020 et a produit des consignes d’interopérabilité qui visent à satisfaire les exigences actuelles de ses règles, et en particulier celles relatives au consentement de l’utilisateur dans l’UE et celles interdisant le fingerprinting.

Afin de laisser aux éditeurs le temps de gérer les erreurs et les mauvaises configurations liées au lancement du TCF v2.0 de l’IAB Europe, Google produit unilatéralement des rapports d’erreurs détectées et autorise un délai de grâce de 90 jours.

C’est dans ce cadre que de nombreux éditeurs utilisant une CMP compatible ont reçu ces dernières semaines des alertes de la part de Google dans leur console Adsense ou Ad Manager.

Malgré la qualité de nos solutions, nos partenaires n’ont pas été épargnés. Dans la plupart des cas, il s’agit des alertes 1.1 et 2.1a. Il nous semble indispensable désormais de (r)établir les rôles et responsabilités de chacun. 

Les tags publicitaires de Google devraient être revus

L’erreur 1.1 survient lorsque les tags publicitaires de Google sont appelés sans (avant) que l’utilisateur ait donné son consentement pour Google.

Cela peut résulter :

• d’une non-présentation de Google comme partenaire de l’éditeur dans la CMP (Vendor ID 755 dans le TCF)

• d’un choix de l’utilisateur de rejeter Google

Lorsqu’un site charge un script publicitaire de Google sans consentement pour ce dernier, il contrevient aux règles de Google relatives au consentement de l’utilisateur dans l’Union européenne, qui imposent le recueil du consentement pour les cookies et pour le traitement de données personnelles par Google et ses partenaires, permettant de servir des publicités personnalisées ou non.

En revanche, il ne s’agit pas d’une erreur d’intégration de la CMP, mais d’un problème de conditionnement des tags publicitaires de Google.,

Google reconnaît que les CMP “peuvent être configurées de différentes façons…. et qu’il est important de noter que de telles configurations ne contrôlent pas automatiquement la collecte de données ou les cookies.” 

Le TCF est architecturé sur un principe de Privacy by Design qui permet un conditionnement à toutes les étapes par chaque acteur concerné : les éditeurs mettent un signal à la disposition des Vendors qui doivent interagir avec la CMP pour déterminer leur statut de consentement et agir en conséquence.

C’est ce que précisent les policies du TCF :

• IV-22)2. A Publisher will, in accordance with the Specifications and Policies, and considering and respecting each Vendor’s declarations on the GVL, signal, or instruct to Vendors which Legal Basis it has established on behalf of each Vendor.
   
• II-13)3. A Vendor must respect Signals communicated by a CMP or received from a Vendor who forwarded the Signal originating from a CMP in accordance, with the Specifications and Policies, and act accordingly.
   
• II-13)5. If a Vendor is unable to act in accordance with the contents of a received Signal, the Vendor must not store and/or access information on a device, or process personal data for any Purpose and/or Special Purpose.

Sirdata n’a pas vocation à conditionner les tags de Google. Toutefois, pour aider les éditeurs désemparés, nous avons intégré à la CMP Sirdata des contrôles non prévus dans le TCF, basés sur les exemples de code d’annonce de la section de l’aide Google dédiée.

Nous lançons par exemple automatiquement les commandes fournies par Google pour mettre en pause Adsense avant de finir de charger la CMP et interagir avec l’utilisateur si nécessaire.

Mais nous constatons que malgré cette mise en pause du service, et sans information de consentement donnée par la CMP, le script de Google, adsbygoogle.js, va charger d’autres scripts en lui permettant d’accéder à ses cookies publicitaires.

L’un d’eux interagit avec la CMP afin de récupérer le statut de choix de l’utilisateur et vérifier si ce dernier a bien donné son consentement au moins à Google et au dépôt des cookies. Les choix de l’utilisateur sont encodés dans la TC String.

“Nous invitons l’IAB Europe à étudier l’implémentation du TCF par Google”

Ce contrôle aurait dû avoir lieu dans le premier script et empêcher le cas échéant le chargement des suivants, et quel que soit son résultat un appel de bannière publicitaire est effectué et comporte différentes variables dont gdpr_consent, qui permet la transmission de la TC String, conformément aux spécifications techniques du TCF.

Si la TC String indique que l’utilisateur a donné son consentement pour Google et les cookies alors l’appel publicitaire obtient une bannière en réponse.

Si la TC String indique que l’utilisateur n’a pas donné son consentement pour Google et les cookies alors l’appel publicitaire n’obtient pas de bannière en réponse.

Dans les deux cas, l’appel de bannière qui est initié donne accès à Google à ses cookies et à de la donnée personnelle. Mais l’Utilisateur n’y a consenti que dans un seul cas.

D’un point de vue contractuel, les erreurs 1.1 sont imputables à l’éditeur qui ne conditionne pas ses tags et appelle Google sans consentement, et ce indépendamment du TCF et de l’implémentation de notre CMP.

Mais dans les rôles et responsabilités définies par le TCF, Google ne traite pas correctement le signal de non-consentement : l’erreur 1.1 ne peut par définition pas exister, car en l’état, pour la comptabiliser, Google appelle un tag sur un domaine qui lui donne accès à ses traceurs, ce que l’utilisateur n’a pas accepté.

Nous demandons donc à Google de cesser ces appels qui peuvent embarquer traceurs et données personnelles sans consentement, et face à ce doute raisonnable et conformément à l’article II-6)5 des Policies TCF, nous invitons l’IAB Europe à étudier l’implémentation du TCF par Google.

Par ailleurs, les erreurs de classe 2 sont liées au délai de grâce 0 : pendant les 30 premiers jours , les éditeurs pourront résoudre les problèmes de mauvaise configuration sans conséquence sur la monétisation selon la documentation Google.

Pendant les 60 jours suivants du délai de grâce, des annonces non personnalisées seront diffusées.

Avec l’erreur 2.1a, Google informe les éditeurs du nombre de fois :

• où la CMP a été en erreur (“error”)

• où la CMP est restée bloquée à l’initialisation (“stub”)

• où la CMP est restée bloquée lors du chargement (“loading”)

Les tags de Google ont été adaptés, comme expliqué plus haut, pour décoder les signaux du TCF prioritaires sur les autres signaux de Google sauf si plus permissifs.

Mais Google a semblé préférer l’efficacité au respect du choix de l’utilisateur en paramétrant un “timeout” pour le chargement de la CMP : au bout d’un délai accordé de 500 ms le script Adsense coupe le processus et renvoie le code erreur tcfe=1 et la valeur “tcunavailable” pour le paramètre gdpr_consent en lieu et place de la TC String.

Ce timeout n’est pas le délai accordé à la CMP seule mais à tous les scripts qui s’exécutent sur la page et la fenêtre de temps accordée est beaucoup trop courte compte tenu de la réalité du temps de chargement des pages.

Chaque chargement de CMP ainsi interrompu est comptabilisé comme une erreur 2.1a par Google. Si Google attendait la fin du chargement, il recevrait le signal adéquat et il n’y aurait pas d’erreur imputable au timeout.

“10 à 15 % des erreurs 2.1a permettent de déclencher à tort une publicité ciblée”

Nous pensons que ce fonctionnement, maîtrisé uniquement par Google, est à l’origine de la grande majorité des erreurs 2.1a attribuées par Google aux éditeurs et leur CMP, et présente un risque pour le respect des choix des Utilisateurs.

Les serveurs de Google ne reçoivent en effet pas les signaux de consentement (TC String) mais l’information “tcunavailable”, et conformément à sa documentation Google accède à ses cookies et traite de la donnée personnelle pour servir des publicités.

Du point de vue de l’éditeur et pour Google l’effort est louable : les revenus de chacun sont maintenus au moins en grande partie. Mais du point de vue de l’internaute, c’est plus problématique : lors de nos tests, toutes ces publicités personnalisées ont été affichées alors que nous avions refusé au préalable les cookies et tous les Vendors dont Google.

Des fournisseurs de technologie publicitaire partenaires de Google sont également susceptibles d’avoir reçu et traité de la donnée personnelle malgré eux.

L’information de notre refus était bien présente lorsque la CMP était chargée, mais le script de Google n’ayant pas attendu cet événement (eventStatus “tcloaded”) à cause du timeout, elle a été ignorée.

Compte tenu des taux moyens de consentement on peut estimer que 10 à 15 % des erreurs 2.1a comptabilisées ont masqué des refus et permis de déclencher à tort une publicité ciblée.

Compte tenu du poids de Google dans la publicité en ligne (2 millions d’éditeurs adhérents), même si tous n’ont pas encore implémenté une CMP compatible TCF V2, cela représente probablement des centaines de millions voire des milliards de publicités personnalisées déclenchées potentiellement sans consentement voire malgré un refus comme dans nos tests.

“Des erreurs dont l’éditeur et la CMP ne sont pas responsables” 

Nous estimons donc qu’en l’état ce timeout peut représenter un danger très important pour le respect de la vie privée, et qu’en interrompant le processus avant le chargement de la CMP et en ne recevant ainsi pas le statut de consentement, Google ne respecte pas les Policies du TCF :

• II-12)1. In addition to implementing the Framework only according to the Specifications, a Vendor must support the full Specifications, including being able to retrieve and/or pass on Signals in the technical formats required by the Specifications and in accordance with Policies, when available.
   
• II-13)4. If a Vendor is unable to read or process the contents of a received Signal, the Vendor must assume that it does not have permission to store and/or access information on a device, or to process personal data for any Purpose and/or Special Purpose.

Enfin, en générant la valeur “tcunavailable” pour le paramètre gdpr_consent Google crée un signal.

• II-13)6. A Vendor must not create Signals where no CMP has communicated a Signal, and shall only transmit Signals communicated by a CMP…

   

Nous demandons donc à Google de désactiver le time out imposé au chargement de la CMP. Et face à ce doute raisonnable et conformément à l’article II-6)5 des Policies TCF nous invitons l’IAB Europe à étudier l’implémentation du TCF par Google.

Par ailleurs, en étudiant l’origine de l’erreur 2.1a, nous avons relevé que des tags tiers (ni l’éditeur, ni la CMP, ni Google) perturbent voire corrompent le fonctionnement du TCF. Dans certains cas, l’API de la CMP est écrasée par une API fictive qui peut engendrer des erreurs dont l’éditeur et la CMP ne sont pas responsables.

Nous faisons confiance à l’IAB Europe pour endiguer les entorses faites aux policies, qui in fine viennent endommager la réputation des éditeurs, des CMP et de tout le marché publicitaire.

Toutes les ressources liées à cet article

Les Personnalités

Benoit Oberlé

Les sociétés

Sirdata

Accès à la fiche entière

Google