Décodeur de TC string

Ce qu'est une TC string, en pratique

La TC string est le justificatif qu'un CMP écrit quand quelqu'un accepte, refuse ou enregistre un choix sur un bandeau européen. On la trouve presque toujours dans le cookie euconsent-v2. Ouvrez les cookies d'un site qui affiche ce bandeau et cherchez une valeur longue qui commence par C. C'est cette chaîne.

Le format est un champ de bits écrit avec l'alphabet base64url : A à Z, a à z, chiffres, et les signes - et _. Les six premiers bits sont la version. TCF 2 y met un 2, et six bits font exactement un caractère, donc la première lettre sort en C. C'est pour ça qu'une chaîne actuelle commence presque toujours ainsi. Ensuite viennent deux dates, comptées en dixièmes de seconde depuis le 1er janvier 1970 : la création, et la dernière réécriture par le CMP. Puis l'id du CMP, le numéro de build de ce CMP, l'écran où le choix a été enregistré, et la langue du bandeau. Chaque lettre de cette langue est un nombre de 0 (A) à 25 (Z).

Viennent ensuite la version de la Global Vendor List utilisée pour construire le bandeau, et la version de la politique TCF de cette même liste. IsServiceSpecific doit valoir 1. Un 0 veut dire qu'un vendor doit traiter la chaîne comme invalide au regard de la politique, même si le reste des bits se lit. UseNonStandardTexts vaut 1 quand le CMP a modifié les textes standard des finalités ou les illustrations. PurposeOneTreatment vaut 1 quand la finalité 1 n'a pas été présentée de la façon habituelle. PublisherCC est le pays dont le droit sert de référence à l'éditeur : deux lettres, même codage que la langue.

Les finalités occupent vingt-quatre bits de consentement et vingt-quatre bits d'intérêt légitime. La finalité 1 est le premier bit de chaque ligne : stocker ou accéder à des informations sur un appareil. Seules les finalités 1 à 11 ont un nom. Depuis TCF 2.2, les finalités 3, 4, 5 et 6 (profils publicitaires et profils de contenu) ne peuvent plus reposer sur l'intérêt légitime, et ces quatre bits doivent rester à 0. Les special features tiennent sur une autre ligne de 12 bits. Les deux qui existent aujourd'hui sont la géolocalisation précise et l'analyse des caractéristiques de l'appareil pour l'identifier. Un 1 signifie que l'utilisateur a opté pour.

Viennent ensuite le consentement par vendor et l'intérêt légitime par vendor. Chaque liste commence par l'id vendor le plus haut qu'elle couvre, puis un indicateur : un bit par id, ou une série de plages. Les plages prennent moins de place quand la sélection est clairsemée, ce qui est le cas courant sur une longue liste. Un vendor absent d'une liste en plages n'a pas de signal. L'id est le numéro de la Global Vendor List, pas le nom de la société. IAB Europe republie cette liste souvent, et cette page laisse le numéro. Les noms sont dans https://vendor-list.consensu.org/v3/vendor-list.json pour la liste en cours, et dans https://vendor-list.consensu.org/v3/archives/vendor-list-v{version}.json pour la version stockée dans la chaîne. Croiser le fichier du jour avec une vieille chaîne met le mauvais nom sur des vendors déjà retirés.

Les restrictions de l'éditeur ferment le segment principal. Chacune nomme une finalité, un type de restriction et les ids vendor concernés. Le type 0 signifie que l'éditeur n'autorise pas cette finalité pour ces vendors. Le type 1 exige le consentement, y compris quand le vendor a déclaré la finalité en intérêt légitime et l'a marquée flexible. Le type 2 exige l'intérêt légitime. Le compteur de restrictions est toujours là, y compris quand il vaut zéro.

Les points découpent la chaîne en segments. Le premier est le noyau et n'a pas de type : il commence par la version. Chaque segment suivant ouvre sur un type de 3 bits. Le type 1 est Disclosed Vendors, les ids que le CMP a vraiment montrés. Depuis TCF 2.3 ce segment est obligatoire, parce qu'un vendor qui ne déclare que des special purposes n'avait pas d'autre champ où le CMP pouvait le marquer comme divulgué. Le type 3 est le Publisher TC : les finalités que le site demande pour lui-même, plus les finalités propres définies par l'éditeur. Le type 2 est l'ancien segment Allowed Vendors, celui du schéma out-of-band. Les CMP actuels ne l'écrivent plus. Une vieille chaîne qui l'a encore est décodée et étiquetée à part.

Le tilde est en dehors du TCF. Tout ce qui suit ~ est l'Additional Consent de Google : un numéro de version, puis des ids ATP séparés par des points. Les CMP le collent au même cookie pour qu'un tag publicitaire puisse lire des fournisseurs absents de la Global Vendor List. Cette page détache cette fin et liste les ids. Elle n'appelle pas Google et ne résout pas ces ids.

Où la copier

1. Dans Chrome : DevTools, Application, Cookies, puis le site. Copiez la valeur de euconsent-v2. Si le CMP a rangé l'Additional Consent dans le même cookie, gardez la partie après le tilde.
2. Sur une page où le CMP est chargé, dans la console : __tcfapi("getTCData", 2, function (data) { console.log(data.tcString); }). tcString est le noyau plus les segments séparés par des points. Si le CMP remplit aussi addtlConsent, cette valeur est celle qui va après le tilde.
3. Les requêtes d'enchère reprennent souvent la même valeur dans gdpr_consent ou euconsent. Une URL longue est coupée. Une chaîne coupée échoue ici avec un message qui dit qu'elle s'arrête trop tôt. La copie fiable est celle du cookie.

Comment lire le résultat

Les dates s'affichent dans votre langue, puis en UTC. Créée est la première fois que ce choix a été enregistré. Dernière mise à jour bouge quand le CMP réécrit la chaîne, y compris lors d'un rafraîchissement de la liste de vendors.

La ligne CMP nomme quelques sociétés de la liste CMP actuelle d'IAB Europe : Usercentrics (5), Sourcepoint (6), Didomi (7), OneTrust (28), consentmanager (31), Sirdata (92), Cookiebot (134) et Google (300). Tout autre id reste un numéro. Des sociétés arrivent et changent de nom, et un nom deviné vaut moins que l'id.

Le tableau couvre les finalités 1 à 11. Oui veut dire que le bit est posé. L'intérêt légitime des finalités 3 à 6 doit être éteint sur une chaîne écrite sous TCF 2.2 ou plus récent. S'il est allumé, le CMP qui a écrit la chaîne n'a pas suivi cette règle.

Chaque bloc vendor montre un compte, l'id le plus haut, si le stockage est bit à bit ou par plages, puis les ids. Au-delà de 200 ids, le reste est compté et non imprimé, pour qu'un tout-accepter ne bloque pas l'onglet. Si le segment Disclosed Vendors manque, une ligne le dit. Sur une chaîne TCF 2.3, ce segment doit être là.

Questions qui reviennent avec cette chaîne

Où est stockée la TC string ?

Dans le cookie euconsent-v2, sur presque tous les CMP qui implémentent TCF 2. Certaines stacks la mettent aussi dans l'URL d'enchère. Copiez-la depuis le cookie quand vous le pouvez. Une valeur prise dans une URL longue arrive souvent coupée, et une chaîne coupée ne se décode pas.

Pourquoi commence-t-elle par C ?

La version est le nombre 2, stocké sur six bits. Six bits font un caractère base64url, et le caractère de la valeur 2 est C. Une chaîne TCF 1 commence par une autre lettre parce que le numéro de version est différent. Cette page n'ouvre que la version 2.

Quelle différence entre la colonne consentement et la colonne intérêt légitime ?

Le consentement est un bit activé par l'utilisateur. L'intérêt légitime est un bit posé par le CMP quand il a présenté cette finalité sous l'intérêt légitime et que l'utilisateur ne s'y est pas opposé. Le vendor doit encore lire sa fiche dans la Global Vendor List. Une finalité déclarée en consentement n'est pas couverte par le bit d'intérêt légitime.

C'est quoi, la finalité 1 ?

Stocker et/ou accéder à des informations sur un appareil. C'est la finalité des cookies et du stockage comparable, et la politique TCF demande le consentement. PurposeOneTreatment, plus haut dans la même chaîne, dit au vendor si le CMP a présenté la finalité 1 de la façon habituelle. Avec le pays de l'éditeur, c'est comme ça qu'un vendor décide s'il lui faut encore un oui pour la finalité 1 dans ce pays.

Pourquoi y a-t-il des points au milieu ?

Chaque point ouvre un autre segment. Le noyau vient en premier. Derrière, on trouve en général Disclosed Vendors et, sur certains sites, le Publisher TC. L'ordre de ces segments suivants n'a pas d'importance, parce que chacun commence par son type.

C'est quoi, le texte après le tilde ?

L'Additional Consent de Google. Le premier nombre est la version AC, puis une liste d'ids de fournisseurs ATP. Les CMP le rangent à côté de la TC string pour qu'un tag Google puisse lire les deux. Ce n'est pas un segment TCF et ce n'est pas du base64.

Est-ce que vous envoyez ce que je colle ?

Non. Le script de cette page lit le champ et écrit le résultat en dessous. Aucune requête ne contient la chaîne. Vous fermez l'onglet, elle disparaît.

Ça décode une chaîne TCF v1 ?

Non. La version 1 a une autre structure. Si les six premiers bits ne valent pas 2, la page s'arrête et affiche la version qu'elle a lue.

La liste de vendors n'a que des numéros. Où sont les noms ?

La chaîne stocke des ids. Les noms sont dans la Global Vendor List de la version affichée à côté de Liste de vendors. Le fichier en cours est https://vendor-list.consensu.org/v3/vendor-list.json et un ancien est https://vendor-list.consensu.org/v3/archives/vendor-list-v{version}.json, avec la version de la chaîne à la place de {version}. La liste du jour sur une vieille chaîne donne le mauvais nom aux vendors retirés.

C'est quoi, un id de CMP ?

Un numéro qu'IAB Europe attribue à la société qui recueille le consentement. Ce n'est pas l'éditeur, et ce n'est pas un id vendor de la Global Vendor List. La version de CMP à côté est le numéro de build de cette société. C'est le champ utile quand un bug ne sort que sur une release de leur bandeau.