Une décision récente émanant de l'autorité autrichienne de protection des données (la Datenschutzbehörde) laisse les ingénieurs réseau et les entreprises européennes qui se servent de Google Analytics (GA) perplexes. La Datenschutzbehörde a considéré que l'utilisation de GA par un site web autrichien enfreignait le règlement général sur la protection des données (RGPD), tel qu'interprété par l'affaire « Schrems II ». En effet, l'utilisation de GA peut impliquer l'envoi d'adresses IP complètes ou tronquées aux États-Unis.
Si la désactivation de ce type de trackers peut constituer une solution (plutôt extrême), procéder de la sorte laisserait les exploitants de sites web aveugles quant à la manière dont les utilisateurs interagissent avec leur site. Une meilleure approche consisterait à trouver un moyen de continuer à utiliser les outils du type GA, tout en respectant une démarche visant à protéger les données personnelles et à les conserver au sein de l'UE. C'est-à-dire, exactement la raison d'être de Cloudflare Zaraz.
Toutefois, avant d'entrer plus en détail dans la manière dont Cloudflare Zaraz peut vous aider, nous devons expliquer un peu plus le contexte de la décision de la Datenschutzbehörde, de même que les raisons pour lesquelles cette dernière revêt une importance toute particulière.
Quels sont les problèmes liés à la confidentialité et à la régionalisation des données ?
Le RGPD est une loi exhaustive sur la confidentialité des données qui s'applique aux données personnelles des résidents de l'UE, peu importe l'endroit où elles sont traitées. Le RGPD en lui-même n'insiste pas sur la nécessité de traiter ces données personnelles uniquement en Europe. Il propose à la place un certain nombre de mécanismes juridiques permettant de s'assurer que des protections comparables au RGPD soient disponibles pour protéger les données personnelles européennes en cas de transmission vers un pays tiers, comme les États-Unis (en dehors de l'UE donc). Jusqu'à la décision « Schrems II », les transferts de données depuis l'UE vers les États-Unis étaient autorisés en vertu d'un accord appelé le bouclier de protection des données UE-États-Unis (EU-U.S. Privacy Shield Framework).
La décision Schrems II se rapporte à la décision, prise en juillet 2020 par la cour de justice de l'Union européenne, qui a invalidé le bouclier de protection des données UE-États-Unis. Cette dernière a considéré que le bouclier de protection n'était pas un moyen efficace de protéger les données européennes contre les agences gouvernementales américaines chargées de la surveillance une fois les données transférées aux États-Unis. Elle a ainsi estimé que, sous le régime du bouclier de protection, les données personnelles européennes ne bénéficieraient pas du niveau de protection garanti par le RGPD. La cour a toutefois maintenu la validité d'autres mécanismes de transfert, conçus pour permettre la transmission de données personnelles européennes aux États-Unis selon un protocole permettant de s'assurer que les autorités gouvernementales américaines ne puissent pas accéder aux données personnelles européennes d'une manière qui enfreigne le RGPD. L'un de ces mécanismes reposait sur l'utilisation des clauses contractuelles types, c'est-à-dire des accords juridiques approuvés par la Commission européenne et autorisant les transferts de données. Ces clauses ne peuvent néanmoins être utilisées que si des mesures supplémentaires de protection sont également en place.
Suivant l'affaire Schrems II, le groupe de défense « NOYB » fondé par Max Schrems (l'avocat et activiste à l'origine de l'action en justice contre Facebook qui a finalement débouché sur la décision Schrems II) a déposé 101 plaintes contre des sites web européens utilisant les trackers Google Analytics et Facebook Connect. Ces plaintes s'appuient sur le motif que l'utilisation de ces trackers enfreint la décision Schrems II, car ils envoient des données personnelles européennes vers les États-Unis sans que des mesures supplémentaires suffisantes aient été mises en place.
Ce problème des mesures supplémentaires a joué un rôle prépondérant dans la décision prise par l'autorité autrichienne chargée de la régulation des données. Dans sa décision, la Datenschutzbehörde déclarait qu'un pays européen ne pouvait pas utiliser GA sur son site web autrichien, car GA envoyait les adresses IP des visiteurs du site vers les serveurs de Google, situés aux États-Unis. La Datenschutzbehörde s'est appuyée sur une jurisprudence déjà prononcée dans l'UE, qui stipulait qu'en raison de la possibilité d'établir un lien suffisant entre les adresses IP et les individus, ces adresses constituaient des données personnelles, auxquelles le RGPD s'appliquait par conséquent. L'organisme de régulation a également constaté que les adresses IP ne tenaient pas lieu de pseudonymes et que Google ne disposait pas de mesures supplémentaires suffisantes en place pour empêcher les autorités gouvernementales américaines d'accéder à ces données. L'autorité régulatrice considéra donc que l'utilisation de GA et la transmission des adresses IP vers les États-Unis enfreignaient le RGPD tel qu'interprété par l'affaire « Schrems II ».
La décision Google Analytics crée un précédent inquiétant
Il convient de se souvenir que la décision prise par les autorités autrichiennes se rapporte à l'utilisation et à la mise en œuvre de GA sur un site web donné. Il ne s'agit pas d'une interdiction de GA partout en Europe. Cette jurisprudence pourrait-elle toutefois constituer un signe avant-coureur d'actions plus larges de la part des autorités chargées de la régulation des données ? Un site web peut utiliser des dizaines d'outils tiers. Si l'un de ces outils tiers transmet des données personnelles vers les États-Unis, il pourrait attirer l'attention de n'importe quelle agence de réglementation des données au sein de l'UE. Même si ces outils ne collectent pas intentionnellement de données personnelles ou d'informations sensibles, une certaine inquiétude subsiste quant à l'utilisation des outils tiers, issus de la structure et du fonctionnement mêmes d'Internet.
Chaque fois qu'un utilisateur charge un site web, ces outils se chargent et établissent une connexion entre le navigateur de l'utilisateur final et le serveur tiers. Cette connexion est utilisée à diverses fins, comme la requête d'un script, l'établissement d'un rapport à partir de données d'analyse ou le téléchargement d'un pixel d'image. L'adresse IP du visiteur est exposée lors de chacune de ces transmissions. La communication entre un navigateur et un serveur fonctionne ainsi depuis les balbutiements d'Internet.
Les implications de cette décision se révèlent, par conséquent, particulièrement profondes. D'autres autorités de régulation européennes pourraient, par exemple, adopter la décision autrichienne et sa conclusion stipulant que tout transfert d'adresses IP vers les États-Unis, même tronquées, est susceptible de constituer un transfert de données personnelles en infraction avec le RGPD. Dans cette éventualité, le secteur devrait probablement repenser intégralement l'architecture Internet actuelle et la manière dont les adresses IP sont utilisées. Cloudflare estime de plus en plus que nous pourrons répondre à ces problématiques en dissociant totalement les adresses IP de l'identité. Nous nous sommes associés à d'autres acteurs du secteur pour lancer de nouveaux protocoles, comme l'Oblivious DNS over HTTPS, qui sépare les adresses IP du contenu visé par les requêtes en ligne, afin d'ouvrir la voie aux technologies qui permettront la concrétisation de cet avenir.
Si nous pouvons envisager ce dernier, nos clients ont besoin de moyens immédiats de répondre aux préoccupations des autorités réglementaires. Le site moyen de 2021 utilisait 21 solutions tierces sur mobile et 23 pour les sites traditionnels. Au 90e centile, ces chiffres s'élevaient à 89 solutions tierces sur mobile et 91 pour les sites traditionnels. Compte tenu de la décision de la DPA autrichienne, qui précise que c'est l'entreprise européenne elle-même qui est responsable de s'assurer qu'aucune donnée personnelle ne soit transmise vers les États-Unis sans traitement adéquat, nous pouvons conclure que les entreprises pourraient bientôt devenir responsables de chacune des solutions tierces mises en œuvre sur leurs sites web. Face à la quantité impressionnante d'outils qui entrent en jeu, la situation exige une solution évolutive. Fort heureusement, il s'agit très exactement de ce que nous avons développé.
La solution de Zaraz tire parti du réseau mondial et de la plateforme Workers de Cloudflare
Zaraz est un gestionnaire tiers, conçu pour la vitesse, la confidentialité et la sécurité. Grâce à Zaraz, les clients peuvent charger des outils d'analyse, des pixels publicitaires, des widgets interactifs et bien d'autres types d'outils tiers, sans modifier leur code en aucune façon.
Zaraz charge les outils tiers sur le cloud par l'intermédiaire de Cloudflare Workers. Nous avons choisi de développer cette solution sur Workers pour diverses raisons, détaillées plus avant dans la suite de cet article de blog. En s'appuyant sur Workers pour décentraliser les outils tiers vers le cloud, loin du navigateur, Zaraz crée une couche supplémentaire de sécurité et de contrôle autour des données à caractère personnel (PII), des informations sanitaires protégées (PHI) ou des autres types d'informations sensibles souvent transmises involontairement aux fournisseurs tiers.
Dans le schéma traditionnel de chargement des outils tiers, que ce soit par l'intermédiaire d'un logiciel de gestion de balises (TMS, Tag Management Software), d'une plateforme de données client (CDP, Customer Data Platform) ou par l'inclusion de snippets JavaScript directement au sein du HTML, le navigateur envoie toujours des requêtes vers le domaine tiers. Cette situation se montre problématique pour toutes sortes de raisons, mais principalement parce que vous n'avez pas la possibilité de masquer l'adresse IP d'un utilisateur, même si vous le souhaitiez. L'adresse est ainsi révélée dans chaque requête HTTP. Ce mode de fonctionnement pose également problème, car les outils exécutent des ressources JavaScript distantes, sur lesquelles vous n'avez aucune visibilité, tant au niveau des actions qu'elles effectuent au sein du navigateur que des données qu'elles transmettent.
Nous pouvons utiliser l'exemple de GA pour illustrer cette différence. Lorsqu'un site web charge GA, via Google Tag Manager ou directement depuis le code HTML, le navigateur télécharge le fichier « analytics.js », qui charge GA. Il envoie alors une requête HTTP POST du navigateur vers le point de terminaison Google « https://www.google-analytics.com/collect ». Ces deux requêtes révèlent l'adresse IP de l'utilisateur final et peuvent ajouter des données personnelles à l'URL, comme l'identifiant client Google, sous forme de paramètres de requête par exemple.
En comparaison, lorsque vous utilisez Zaraz pour charger GA, aucune communication n'a lieu entre le navigateur et le point de terminaison Google. À la place, Zaraz agit en tant qu'intermédiaire. L'intégralité de la communication s'effectue alors entre le service Zaraz (qui s'exécute sur des serveurs Workers, isolé du navigateur) et le tiers concerné. Vous pouvez considérer Zaraz comme une couche de protection supplémentaire entre le navigateur et le point de terminaison tiers. Cette couche supplémentaire nous permet d'ajouter de puissantes fonctionnalités de protection de la confidentialité.
Zaraz permet, par exemple, aux clients de décider s'ils souhaitent transmettre l'adresse IP d'un utilisateur final à GA ou non. C'est aussi simple que ça. Lors de la configuration d'un nouvel outil tiers, comme GA, vous pouvez choisir de masquer l'adresse IP dans les paramètres de l'outil.
Pour le moment, cette fonctionnalité est disponible avec GA et le pixel FB/l'API Conversions de Facebook. Toutefois, face au nombre croissant de plateformes qui ouvrent leur API à notre service et autorisent l'intégration de serveur à serveur, nous nous attendons à ce que le nombre d'outils compatibles augmente rapidement.
Actuellement utilisée par plusieurs de nos clients parmi les entreprises, la fonctionnalité de prévention des pertes de données (Data Loss Prevention, DLP) constitue un autre exemple similaire d'outil proposé par Zaraz. La fonctionnalité DLP analyse chaque requête adressée à un point de terminaison tiers afin de s'assurer qu'elle ne contient aucune information sensible, comme un nom, une adresse e-mail, un numéro de sécurité sociale, un numéro de carte bancaire, une adresse IP, etc. Grâce à cette fonctionnalité, les clients peuvent choisir soit de masquer les données, soit d'être alertés lorsqu'un outil collecte ce type de données personnelles. Elle accorde une visibilité totale et un contrôle intégral sur les informations partagées avec les tiers.
L'aide que Zaraz peut vous apporter dans le cadre de la régionalisation des données
À cet instant, il est probable que vous vous demandiez : « Attendez, en quoi le cas de Cloudflare diffère-t-il de celui de Google ? Et d'ailleurs, les journaux des utilisateurs finaux ne sont-ils pas eux aussi envoyés vers les serveurs de Cloudflare situés aux États-Unis ? ». Ce sont de bonnes questions, dans le contexte desquelles l'alliance entre Zaraz et le réseau mondial de Cloudflare nous permet de briller. La solution Zaraz que nous proposons à nos clients Enterprise s'accompagne de deux puissantes fonctionnalités de la Data Localisation Suite de Cloudflare : les services régionaux et l'isolement géographique des métadonnées du client.
Les services régionaux vous permettent de choisir l'endroit dans lequel vous souhaitez que les solutions Cloudflare s'exécutent, notamment le service Zaraz. La possibilité de contrôler le lieu d'inspection de vos données pourrait vous aider à respecter vos obligations en matière de conformité. Les services régionaux vous aident également à décider de l'endroit dans lequel vos données doivent être traitées, sans perdre les avantages de notre réseau en termes de performances.
Imaginons que vous gériez un site web pour le compte d'une banque européenne. Partons également du principe que vous avez activé la Data Localisation Suite pour l'Europe. Lorsqu'un utilisateur situé dans l'UE se rend sur votre site web, une requête HTTP est envoyée afin d'activer Zaraz. Comme Zaraz s'exécute dans un contexte direct, c'est-à-dire sous votre propre domaine, tous les paramètres de régionalisation des données s'y appliquent également. Le réseau dirigera donc le trafic vers l'UE, sans inspecter son contenu, et y exécutera Zaraz.
L'isolement géographique des métadonnées du client dans l'UE étend les prérogatives de la Data Localisation Suite afin de s'assurer que les métadonnées du trafic de l'utilisateur final restent au sein de l'UE. Le mot « métadonnées » peut paraître un peu effrayant, mais son concept s'avère plutôt simple : il signifie tout simplement « données sur les données ». En d'autres termes, il s'agit de la description d'une activité survenue sur notre réseau. L'utilisation de l'isolement géographique des métadonnées du client pour l'UE implique que ce type de métadonnées ne serait enregistré que dans l'UE.
Enfin, qu'arrive-t-il aux données personnelles de l'utilisateur final traitées par Zaraz ? Par défaut, Zaraz ne journalise ni n'enregistre aucune information sur l'utilisateur final, à la seule exception de la journalisation des erreurs. Dans une optique d'amélioration de notre service, nous enregistrons des journaux d'erreurs, afin de nous permettre de corriger les problèmes. Les clients qui utilisent la Data Localisation Suite peuvent désactiver cette option. Aucune donnée de journal ne sera alors enregistrée par Zaraz.
Que réserve l'avenir pour les fonctionnalités d'amélioration de la confidentialité ?
Depuis l'acquisition de Zaraz, nous avons parlé à des centaines de clients Enterprise de Cloudflare et à des milliers d'utilisateurs de la bêta de la version gratuite de Zaraz. Nous avons ensuite extrait de ces discussions une sélection de fonctionnalités que nous prévoyons de développer en 2022.
- Gestionnaire de consentements Zaraz : le service Zaraz transforme fondamentalement la manière dont les outils tiers sont mis en œuvre sur Internet. Aussi, afin d'offrir à nos clients le contrôle total sur la gestion des consentements des utilisateurs, nous avons compris que nous devions développer notre propre outil conçu pour accomplir cette tâche facilement. Le gestionnaire de consentements Zaraz s'intégrera totalement au service Zaraz et permettra aux clients de prendre des mesures conformes aux choix des utilisateurs en quelques clics.
- Règles de déclenchement géolocalisées : nous prévoyons d'ajouter une option de création de règles de déclenchement basées sur la situation géographique actuelle d'un utilisateur final. Ces règles vous permettraient ainsi de configurer vos outils afin qu'ils ne se chargent que lorsque l'utilisateur se rend sur votre site depuis une région spécifique. Vous seriez même en mesure d'envoyer des événements ou des propriétés spécifiques en fonction de l'emplacement géographique de l'utilisateur final. Cette fonctionnalité devrait aider les entreprises mondiales à définir des configurations précises correspondant aux exigences de leurs opérations internationales.
- Modèles de schémas DLP : à l'heure actuelle, notre fonctionnalité DLP peut analyser les requêtes adressées à des outils tiers en fonction de schémas définis par nos clients eux-mêmes. Dans un avenir proche, nous leur proposerons des modèles qui leur permettront de rechercher les PII les plus courantes encore plus facilement.
Tout ceci n'est qu'un avant-goût des services à venir. Si vous avez des idées de fonctionnalités d'amélioration de la confidentialité que vous souhaiteriez voir développées, contactez-nous sur [email protected]. Nous adorons avoir de vos nouvelles !
N'hésitez pas à cliquer ici si vous souhaitez explorer la version bêta gratuite. Si vous êtes un client Enterprise et que vous désirez en savoir plus sur les fonctionnalités d'amélioration de la confidentialité de Zaraz, merci de cliquer ici pour rejoindre la liste d'attente. Enfin, cliquez ici pour rejoindre notre canal Discord.