Popups de cookie: cinq raisons pour lesquelles ils ne peuvent pas fonctionner

Sur de nombreux sites web, le visiteur est agacé par les popups de cookies. Non seulement ils sont agaçants, mais ils ne sont pas fiables et génèrent ainsi de nombreuses violations de la loi. Cet article prouve que les outils de consentement ne sont pas fiables en soi.

Introduction

Lorsqu'une page Web relie un service comme Google Analytics, ce service ne peut être chargé qu'après l'accord du visiteur de la page Web. La base juridique est la directive ePrivacy, au moins lorsque cela concerne les cookies. D'autres raisons pour une obligation d'accord sont fournies par l'article 5 RGPD (minimisation des données) et l'article 44 ss RGPD (transfert de données dans des pays tiers non sûrs).

Une demande de consentement sur les sites web est souvent appelée cookie popup, cookie blocker, consent tool ou consent popup. On parle aussi souvent de plateformes de gestion du consentement.

Ce billet montre que les promesses de marketing de nombreux fournisseurs d'outils de consentement sont invérifiables. En pratique, les outils de consentement détériorent souvent les sites Web. La conséquence est un grand nombre de défauts juridiques. C'est ce que j'ai montré dans mon grand test pratiqué sur les bloqueurs de cookies.

Dans cet article, vous apprendrez pourquoi les outils de consentement aux cookies ne fonctionnent jamais de manière fiable et objective, tant que l'on se fie à leur automatisme ou utilise des outils courants tels que Google, Facebook, Vimeo etc. Mais il y a également une imprécision inhérente, car les cookies peuvent pénétrer dans un appareil par plusieurs voies (c'est d'ailleurs la raison pour laquelle il existe la directive ePrivacy).

Raisons du manque de fiabilité des bloqueurs de cookies

Je vais citer cinq raisons qui sont objectivement valables et généralement démontrables. Il est important que vous compreniez cela. Les cinq raisons reposent sur des faits durs, inattaquables.

1. Le bloqueur de cookies

Le premier motif, pour lequel Cookie Blocker ne peuvent pas fonctionner de manière fiable, est d'ordre technique. Le fonctionnement d'un script de consentement, tel que suggéré par les déclarations publicitaires de nombreux fabricants, est comme suit:

1. Le script Consent est intégré à chaque page d'une page web, et ce de manière à ce qu'il soit chargé avant tous les autres scripts et fichiers.
2. Le script de consentement reconnaît soi-disant toutes les opérations nécessitant un consentement et les bloque soi-disant jusqu'à ce que l'utilisateur ait donné son consentement

La pratique est différente. Les navigateurs modernes chargent plusieurs fichiers presque simultanément. Cela se produit surtout lorsque les fichiers sont chargés à partir de serveurs différents. Lorsqu'on intègre par exemple Google Maps, Google Polices et un script de consentement sur une page web, cela se passe approximativement comme suit:

1. Le chargement du script de consentement commence
2. Le processus de chargement pour le script Google Maps commence
3. Le chargement des polices Google commence
4. Quelque temps avant ou après le point 2 ou 3, le processus de chargement du script Consent est terminé. Ce n'est qu'à ce moment-là que le script Consent peut tenter d'interrompre les processus de chargement suivants. Cela ne fonctionne que pour les processus de chargement qui n'ont pas encore commencé

Il n'est pas possible de prédire si le script Consent se chargera suffisamment vite pour être chargé et prêt à travailler avant de commencer à charger Google Maps ou les polices Google. Dans la pratique, on constate des milliers de fois que les interruptions souhaitées des processus de chargement ne fonctionnent pas.

J'ai délibérément inclus les polices Google dans l'exemple, car elles n'installent probablement pas de cookies. Il est évident que les outils de consentement n'empêchent pas le chargement des polices Google sur les sites web. La raison en est donnée ci-dessous.

2. Le scanner de cookies

Comme l'indique le nom Cookie Blocker ou Cookie Consent, de nombreux outils de consentement se concentrent sur la volonté de bloquer les cookies. Le fonctionnement de tels bloqueurs est comme suit:

1. Un scanner de cookies parcourt une page web
2. Sur chaque page trouvée sur le site, on vérifie si des cookies sont installés
3. Les processus de chargement auxquels des cookies peuvent être associés sont notés
4. Si la page web est consultée ultérieurement, le script de consentement qui y est intégré tente d'empêcher tous les processus de chargement précédemment identifiés comme étant liés aux cookies, jusqu'à ce qu'un consentement soit donné

Il est évident que cette approche ne fonctionne pas pour Google Fonts et également pas pour le vidéo YouTube intégrée avec les paramètres de confidentialité élargis. Cela signifie en effet qu'aucun cookie YouTube n'est créé. Comme je l'ai montré dans un article à part, les processus de traitement des données de YouTube sont tellement complexes que seul cela donne lieu à une obligation d'informer conformément à l'article 5 du RGPD. De plus, on pourrait encore invoquer le transfert de données vers des pays tiers non sûrs comme argument. ([1])

Une autre raison du manque de fiabilité objectivement constatable des outils de consentement est d'ordre technique.

Imaginez qu'une page web charge Google Maps. Supposons que le script de la carte ne place pas ses propres cookies, mais qu'il charge des fichiers à partir de l'adresse google.com.

Un scanner de cookies parcourt maintenant le site Web sur lequel la carte est intégrée. Ainsi simule-t-il un navigateur. Ce navigateur correspond à un navigateur qui a été appelé pour la première fois. Dans ce navigateur, il n'y a donc pas encore d'informations de cookie stockées. Le navigateur est vierge. Le scanner ne reconnaît alors aucune information de cookie.

Dans la réalité, c'est différent. Supposons que vous appelez le site web google.com. Des cookies sont alors déposés. C'est effectivement ainsi (au 03.02.2021). Essayez-le vous-même ! Maintenant, appelez une page qui intègre Google Maps. Cette dernière charge ensuite des fichiers de google.com. Lors du chargement de ces fichiers, les cookies stockés sur votre appareil sont transmis à l'adresse d'appel (google.com) lorsqu'ils sont appelés. La carte charge donc des cookies. Le Scanner de Cookies n'a pas pu les reconnaître !

Il faut savoir que chaque utilisateur a potentiellement d'autres cookies stockés sur son appareil (ordinateur, smartphone, tablette) partout dans le monde. Il est impossible de les connaître tous. Au sujet du Google Tag Manager, on nous explique souvent qu'il s'agit d'une domaine sans cookies. C'est du bluff. Vous trouverez plus bas un lien vers un article "Bullshit Basics" que j'ai écrit à ce sujet, avec la preuve du contraire. Sur mon appareil, il y a probablement des cookies pour le domaine googletagmanager.com et ils sont transmis sur chaque site web qui utilise le Tag Manager. C'est une opération qui nécessite l'accord de l'utilisateur.

Pour plus d'informations sur les cookies, consultez mon article de base .

3. Manque de connaissance du monde

Supposons que le point précédent soit réglé, c'est-à-dire qu'un scanner de cookies connaisse le nom et le contenu de tous les cookies du monde. Ce n'est évidemment pas le cas, comme vous me l'accorderez sans avoir à y réfléchir longuement.

Maintenant, le scanner de cookies devrait connaître la finalité de chaque cookie. D'où vient cette connaissance ? Supposons que vous offriez un bulletin d'information. À part vous, personne ne sait qui a écrit l'e-mail du dernier bulletin d'information. Maintenant, il faudra au destinataire de l'e-mail du bulletin d'information expliquer qui a écrit cet e-mail. Apparemment, cela n'est pas possible sans vos informations complémentaires.

Il en va de même pour les cookies: si le fournisseur d'un outil qui utilise certains cookies ne révèle rien sur les finalités de ces cookies, il n'est pas possible pour un tiers de se prononcer sur les finalités de ces cookies.

L'article 13 du RGPD oblige cependant à expliquer les finalités des cookies. C'est impossible pour tout le monde, sauf pour le fournisseur de cookies lui-même. Pour les outils Google, il est souvent possible de constater que le fournisseur, à savoir le groupe Google, ne fait aucune ou pas d'assertion précise sur la finalité des cookies Google.

Presque toutes les explications que vous trouvez sur les cookies tiers dans les déclarations de protection des données ou sur les demandes de consentement sont inventées ou supputées. En ce qui concerne le cookie NID, Google déclare par exemple:

Le cookie NID contient un identifiant unique qui nous permet d'enregistrer vos préférences et d'autres informations, telles que votre langue préférée, le nombre de résultats de recherche à afficher par page (10 ou 20, par exemple) et si le filtre Google SafeSearch doit être activé.

https://policies.google.com/technologies/cookies?hl=fr

Le cookie NID est, selon mon enquête, principalement utilisé pour identifier de manière unique les utilisateurs. Par exemple, une identification unique est attribuée après que vous vous êtes connecté à google.de, afin d'éviter de devoir confirmer les conditions de protection des données à chaque fois. Dans la même déclaration, il est fait mention d'autres informations. Cette affirmation est presque impossible à préciser et ne répond en aucune manière aux exigences du Article 12 RGPD concernant l'information transparente et complète.

Pour beaucoup d'autres cookies, Google ne fournit aucune information, et pourtant on peut trouver des informations de la part de tiers. On retrouve souvent cette affirmation dans les articles. Je n'ai pas pu la trouver sur le site du groupe Google. Quoi qu'il en soit, l'affirmation est incompréhensible et donc inopérante.

Tout ce qui a été dit sur les cookies s'applique également aux Services (Outils). Les cookies sont créés et gérés par des services et ne se produisent pas simplement ainsi. Il faut expliquer les buts de ces services. Seul le fournisseur d'un service connaît les traitements exacts des données, les lieux où elles sont collectées et les destinataires des données.

En plus des finalités, il convient de faire d'autres mentions à propos des cookies. Il s'agit notamment de la déclaration du fournisseur. Savez-vous si "Google" désigne par "Google" ce que "Google" entend par "Google", lorsqu'il parle de "Google" dans de nombreux avertissements sur la protection des données et les conditions d'utilisation de "Google"? S'il vous plaît, dites-le-moi. Sous cet article se trouve un champ de commentaires. Évidemment, le responsable du site Web doit être en mesure de fournir cette information pour tous les services utilisés.

4. Les cookies comme motif central

La directive ePrivacy est la base juridique pour obtenir le consentement de l'utilisateur, et ce, en raison d'autres raisons que les cookies seuls. De nombreux outils de consentement sont ainsi appelés "bloqueurs de cookies" ou similaires. Les cookies ne constituent qu'un des motifs parmi plusieurs nécessitant une autorisation du utilisateur. ([1])

Un autre motif pour une autorisation est le principe de Minimisation des données. En pratique, cela signifie: Lier un site Web Google Schriften de telle sorte que les polices soient chargées à partir d'un serveur Google nécessite une autorisation. Finalement, la police ne pourrait pas être utilisée. La solution serait simple: stocker la police localement et la charger depuis son propre serveur. Avec le groupe Google, je n'ai pas pu trouver de DPA valide qui justifierait l'intégration d'externes Google polices sans autorisation.

Il devient encore plus plastique lors du chargement de vidéos YouTube:

• De nombreuses fichiers sont chargés des domaines youtube-nocookie.com, ytimg.com et ggpht.com.
• Les polices Google sont chargées depuis le domaine gstatic.com.
• Le DoubleClick tracker publicitaire est chargé depuis le domaine doubleclick.net.
• Youtube envoie des données à un serveur Google après avoir chargé la page.
• DoubleClick envoie à intervalles irréguliers des données vers un serveur de Google.

Tout le monde devra admettre qu'il s'agit d'un transfert de données évitable. L'intérêt légitime est donc exclu ici.

Après l'arrêt duTribunal de justice de l'Union européenne (TJUE) sur le Privacy Shield, il est probable que la rumeur se soit répandue selon laquelle le transfert de données vers les États-Unis et d'autres pays tiers non sûrs ne peut pas être assuré, même avec l'aide des clauses contractuelles types ou Règles de liaison corporatifs.

Les solutions d'acceptation centrées sur les cookies semblent souvent demander uniquement une acceptation pour les cookies. Mais le utilisateur devrait plutôt donner son consentement pour un service. Google Analytics par exemple, utilise dans de nombreuses configurations trois cookies. Il n'a pas de sens de demander l'acceptation pour ces trois cookies. Ce qui est correct, c'est de demander l'acceptation pour l'utilisation de Google Analytics. On explique alors que ce service utilise trois cookies. Cette information détaillée peut être fournie à un niveau ultérieur.

L'image montre trois cookies qui sont attribués au Google Tag Manager. Cette attribution est fausse. Le gestionnaire de balises est mentionné ici comme fournisseur, et non comme service. La mention du fournisseur réel manque manifestement. L'attribution est fausse car le gestionnaire de balises tunnelise d'autres services et donc également leurs cookies gérés.

En tout cas, il n'est nulle part demandé à l'utilisateur s'il accepte ou non Google Analytics. Pour cet outil, le but n'est pas donné dans la demande de consentement. Ainsi, un consentement éclairé n'est pas possible. L'erreur dans le centrage des cookies est particulièrement visible dans les vidéos YouTube intégrées. Celui qui explique les cookies qui sont placés lors de l'intégration du script YouTube correspondant, n'a pas expliqué l'objectif du script YouTube. On peut très bien le prouver par le fait que le script YouTube peut également être chargé sans cookies.

5. L'absence d'approche de la protection des données

Beaucoup savent que, outre la demande d'autorisation, l'affichage de la politique de confidentialité est également important. Penser à l'attestation SSL fait souvent partie des tarifs de hébergement web. Lorsque certaines personnes ouvrent une page Web sans https sur la version SSL, elles oublient parfois.

Le lien vers la déclaration de confidentialité n'est pas présent sur chaque page de la page d'accueil d'un nombre considérable de sites web, j'estime qu'il s'agit de 75%.

De nombreuses personnes intègrent encore des vidéos YouTube de manière à ce que des cookies entrent en jeu. Ce n'est pas nécessaire, car la solution est simple.

Tous ces points et bien d'autres encore ne sont pas pris en compte par Consent Tools, mais ils sont importants pour des raisons juridiques.

Extra: 5+1: révocation souvent impossible

Les cookies tiers techniques sont des cookies qui existent dans un domaine d'un fournisseur d'outils qui n'est pas le même que celui du site web visité. L'exploitant du site web n'a aucune possibilité d'influence technique sur le domaine tiers. Ainsi, les cookies ne peuvent être supprimés dans ce domaine (révocation du visiteur d'un site web !) que si le fournisseur d'outils propose une interface à cet effet. Souvent, cette interface n'existe pas. La révocation n'est donc objectivement pas possible. Dans la mesure où l'interface de révocation est exceptionnellement proposée par le fournisseur d'outils, elle devrait être explicitement appelée par le responsable (exploitant du site web). Malheureusement, dans les rares cas possibles, cela se produit si rarement qu'il n'est guère nécessaire d'en parler.

Exemple: Plugin vidéo YouTube (prétendument sans cookies avec le domaine youtube-nocookie.com). Le plugin installe un cookie nommé CONSENT, contrairement au nom de domaine. Ce cookie ne peut être supprimé que par l'éditeur lui-même. D'après ce que je sais, YouTube n'offre pas d'interface pour cela. Par conséquent, le plugin vidéo YouTube ne peut pas être utilisé conformément aux lois car la révocation en vertu de Article 7, paragraphe 3 du RGPD est impossible. Que le Joueur YouTube nécessite une autorisation a des raisons supplémentaires que le cookie.

Résumé

Comme je l'ai annoncé au début, j'ai pu montrer et aussi prouver ce qui suit:

• Le processus de chargement d'outils nécessitant un consentement ne peut pas être empêché de manière fiable
• Les outils qui n'utilisent pas de cookies ne peuvent pas être détectés de manière fiable par un système automatique. Aucun des outils de consentement que je connais ne fait de tentative significative dans ce domaine, probablement par peur de bloquer un fichier qui est fonctionnellement important pour le site web
• Chacun d'entre vous a d'autres cookies enregistrés sur son terminal. Aucun des scanners de cookies les plus répandus n'est en mesure de déterminer lesquelsLes cookies ne peuvent pas être reconnus de manière fiable et ne peuvent donc pas être gérés en toute sécurité juridique
• Les finalités des services et des cookies ne sont pas connues avec certitude sur le plan juridique pour la plupart des outils populaires
• Se concentrer sur les cookies dans la demande de consentement est une erreur
• Pour les sites web, il existe de nombreuses autres prescriptions en plus de la thématique du consentement

Ma recommandation: évitez les demandes d'approbation autant que possible. Voici une petite aide (détails dans mes autres contributions):

• Omettre les outils dont on n'a pas vraiment besoin
• Remplacement d'outils comme Google Maps et autres par des alternatives
  • Google Maps: Bouton "Route planen"
  • Google Analytics: Matomo
  • Vidéo YouTube ou Vimeo: vidéo locale ou image d'aperçu avec saut sur la plate-forme vidéo
  • Google reCAPTCHA: autre solution, par exemple plugin WordPress pour Contact Form 7

Aussi intéressant

• Liste de contrôle pour les popups de cookie
• Cookiegeddon: Test pratique des solutions d'acceptation populaire
• Alternative aux outils Google
• Les bases du con: Les cookies ne sont pas des fichiers texte
• Les bases du bullshit: Le Google Tag Manager utilise lui-même des cookies