‒ … au sein de notre équipe des irresponsible intergalactic metavers gold diggers !
Yeeaah !
Via https://www.nextinpact.com/article/69980/flock-aspire-tout-ce-qui-bouge-et-samuse-dun-rien.
Même topo que d'habitude : le site web de Météo France (meteofrance.com), établissement public à caractère administratif sous la tutelle du sinistère de la transition écolo, intègre des scripts et des images hébergés sur des serveurs informatiques de sociétés commerciales états-uniennes (essentiellement des CDN), ce qui est incompatible avec le RGPD. Il faut deux sociétés commerciales ricaines pour afficher la carte de France des prévisions météorologiques ! Pourtant, dans sa politique de confidentialité, Météo France « s’engage à ne pas transférer des données personnelles vers des Etats tiers ne disposant pas d’un niveau de protection adéquat des données personnelles ». C'est beau.
Évidemment, je n'ai pas analysé les trouzemilles scripts chargés depuis trouzemilles acteurs par la place de marché publicitaire à laquelle a recours Météo France, Hubvisor, pas suicidaire la guêpe.
Du coup, hop, plainte à la CNIL.
Le raisonnement juridique reste identique aux précédentes fois.
Nouveautés :
Ma plainte CNIL :
ÉDIT DU 25/11/2022 : Elle contient au moins une erreur : c'est dans sa décision du 22/04/2022 que l'APD autrichienne rappelle que le RGPD ne prévoit pas d'approche basée sur le risque en matière de transferts de données personnelles hors de l'UE, pas dans sa décision 2021-0.586.257 (qui en est tout de même la première partie du film). FIN DE L'ÉDIT.
Bonjour,
Pour afficher la carte des prévisions météorologiques sur son site web (https://meteofrance.com/), Météo France a recours à des ressources web externes, trois scripts, qui sont téléchargées depuis les serveurs informatiques de deux sociétés commerciales états-unienne, Cloudflare (pour cdnjs.cloudflare.com, pour le projet jsDelivr.net, et pour le projet unpkg.com) et Fastly (pour le projet jsDelivr.net).
Ces scripts sont automatiquement téléchargés par le navigateur web de l’internaute qui consulte le site web de Météo France (MF).
Comme l’ont jugé la Cour de Justice de l’Union européenne (arrêt C-311/18 dit « Schrems II ») et la Cour régionale de Munich (décision 3_O_17493/20 portant sur Google Fonts), et comme vous l’avez analysé (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics), ces téléchargements de ressources web en eux-mêmes génèrent de facto un transfert hors de l’Union européenne (UE) de plusieurs données personnelles de l’internaute : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de ses consultations du site web MF (les entêtes HTTP Referer et CORS Origin consignent pour le compte de quel site une ressource web externalisée est téléchargée), la marque et le modèle de son navigateur web (entête HTTP User-Agent), etc.
Ces données personnelles renforcent entre elles leur caractère discriminant / individualisant (voir l’étude Panopticlick de l’Electronic Frontier Foundation qui, depuis plus d’une décennie, identifie de manière unique un navigateur web à partir, entre autres, des entêtes sus-mentionnés) et rendent identifiable une personne, surtout par un acteur hégémonique qui, par sa présence sur de nombreux sites web, peut suivre une personne entre les sites web et parvenir à l’identifier. On retrouve cette analyse dans votre mise en demeure du 10 février 2022 concernant l’utilisation de Google Analytics.
D’après l’article 44 du RGPD, seules une décision d’adéquation (article 45 du RGPD), des garanties appropriées (articles 46 et 47 du RGPD) ou des exceptions (consentement ou exécution du contrat, les autres dispositions de l’article 49 du RGPD ne sont pas applicables dans le présent contexte) peuvent autoriser ces transferts de données personnelles en dehors de l’UE.
À ce jour, il n’existe plus de décision d’adéquation entre l’UE et les États-Unis, l’arrêt Schrems II de la Cour de Justice de l’Union européenne (CJUE) ayant invalidé la dernière décision, le Privacy Shield.
Comme l’EDPS (décision numéro 2020-1013) et vous-même (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’analysez, les clauses contractuelles types, et toutes les garanties appropriées ont été indirectement invalidées par l’arrêt Schrems II de la CJUE au motif de la surveillance de l’État fédéral états-unien, de l’absence de recours effectif et de l’absence de démonstration de l’efficacité à garantir un niveau de protection adéquat au droit de l’UE de toute mesure contractuelle, organisationnelle ou technique.
Dans sa politique de confidentialité (https://meteofrance.com/politique-de-confidentialite), MF ne mentionne pas ces transferts de données personnelles à destination des États-Unis et, au contraire, déclare : « Météo-France s’engage à ne pas transférer des données personnelles vers des Etats tiers ne disposant pas d’un niveau de protection adéquat des données personnelles ». De ce fait, nous pouvons avoir la certitude que MF ne recourt pas à des instruments juridiques et/ou à des mesures supplémentaires prévus aux articles 46 et 47 du RGPD.
On peut avoir la certitude que MF met en œuvre aucune mesure technique complémentaire, car son site web inclut des instructions techniques ordonnant au navigateur web de l’internaute le téléchargement des scripts directement auprès des infrastructures techniques des hébergeurs états-uniens choisis par les éditeurs des ressources web que MF intègre sur son site web (projet unpkg, projet jsdelivr.net, etc.). Dès lors, les requêtes de téléchargement émises par le navigateur web de l’internaute ne cheminent pas par l’infrastructure technique de MF ni par celle des éditeurs desdits scripts (dit autrement, il y a un contact direct entre le terminal de l’internaute et les serveurs informatiques des hébergeurs états-uniens de ces scripts), donc elles échappent totalement à MF et aux éditeurs des ressources web, qui peuvent, de ce seul fait, prendre aucune mesure technique.
Enfin, comme l’analyse l’autorité de protection des données personnelles autrichienne (décision numéro 2021-0.586.257), le RGPD ne prévoit pas d’approche fondée sur les risques en matière de transfert de données personnelles à un pays tiers non adéquat.
MF ne recueille pas explicitement le consentement de son visiteur pour le transfert de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ce transfert peut comporter pour lui, comme l’impose l’article 49.1a du RGPD. Le refus de tous les cookies dans le bandeau dédié a aucune incidence sur le chargement des scripts sus-énumérés. Donc, en l’état, ce transfert ne peut pas reposer sur le consentement.
Quand bien même MF le recueillerait, il serait vicié car, en l’absence des ressources web sus-énumérées, la carte des prévisions n’est pas affichée, ce qui contraint l’internaute à accepter de force les traitements de données personnelles réalisés par les trois sociétés commerciales états-uniennes sus-référencées afin d’accéder aux prévisions météorologiques officielles réalisées par un établissement public administratif.
La nécessité des transferts des données personnelles sus-énumérées aux États-Unis au motif de l’exécution d’un contrat (article 49.1b du RGPD) est irrecevable. Les scripts pourraient être téléchargés depuis un seul acteur au lieu de trois (principe d’optimisation technique et de minimisation au sens du RGPD) et/ou ils pourraient être hébergés sur les serveurs informatiques de MF à un coût nul (c’est techniquement et juridiquement possible sans aucune difficulté) et/ou ils pourraient être diffusés par des entités de droit européen hébergées (informatiquement) dans l’UE. Le recours à plusieurs hébergeurs informatiques états-uniens pour afficher une carte constitue un déséquilibre fort entre le faible intérêt pour MF et l’atteinte disproportionnée aux droits des personnes physiques que cela constitue.
Les téléchargements automatiques de ressources web externes (trois scripts) pour afficher la carte des prévisions météorologiques sur le site web de Météo France, et les transferts de données personnelles vers les États-Unis qui en découlent sont donc illégaux.
En sus, d’autres ressources web externes (images et scripts) sont automatiquement téléchargées lors de la consultation du site web de Météo France. Ces ressources sont hébergées sur des infrastructures techniques situées aux États-Unis et/ou détenues par des organisations de droit états-unien.Inventaire :
- Script Google Tag Manager ;
- Régie publicitaire Google DoubleClick ;
- Place de marché publicitaire Hubvisor hébergée par Fastly ;
- Vidéos Google YouTube ;
- CMP Didomi (privacy-center.org) hébergée par Amazon.
Évidemment, en tant que place de marché publicitaire, Hubvisor fait à son tour télécharger automatiquement des ressources web (des scripts) depuis tout un tas d’acteurs états-uniens. Il sert à rien de les énumérer puisqu’ils changent à chaque consultation du site web MF ou en fonction des campagnes publicitaires en cours. Néanmoins, je peux lister : 3lift (hébergement Amazon), AppNexus (société commerciale états-unienne auto-hébergée), ayads.co (hébergement Cloudflare), casalemedia (idem), PubMatic Inc. (société commerciale états-unienne auto-hébergée), sskzlabs.com (hébergement Amazon).
Je constate que Google Tag Manager fait à son tour télécharger automatiquement l’outil de mesure d’audience Xiti de la société AT Internet dont les scripts « d’initialisation » sont hébergés par Amazon (cf. https://www.atinternet.com/rgpd-et-vie-privee/collecte-de-donnees-sur-les-sites-de-nos-clients/#traitees-et-stockees).
Depuis mars 2021, l’unique actionnaire d’AT Internet est la société commerciale états-unienne Piano Software Inc. (cf. https://www.atinternet.com/presses/at-internet-sassocie-a-piano-pour-creer-la-premiere-plateforme-dexperience-client-basee-sur-lanalyse-contextuelle/). Celle-ci est toujours immatriculée dans le Delaware (cf. https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx) et elle dispose toujours de plusieurs bureaux aux États-Unis (cf. https://resources.piano.io/about/).
Le mémorandum concernant l’application de Cloud Act à des entités européennes commandé par le ministère de la Justice des Pays-Bas (https://www.ncsc.nl/documenten/publicaties/2022/augustus/16/cloud-act-memo) tend à montrer que, de ces faits, AT Internet est soumise au Cloud Act. De là, votre analyse appuyant votre mise en demeure du 10 février 2022 portant sur Google Analytics est de pleine application ici.
Le raisonnement est similaire à celui déroulé au premier point de cette plainte : ces téléchargements de ressources web, déclenchés automatiquement lors de la consultation du site web de Météo France, génèrent de facto plusieurs transferts de données personnelles (cf. liste au premier point) à destination des États-Unis ; il n’existe plus de décision d’adéquation entre l’UE et les États-Unis ; toutes les garanties appropriées, et les mesures complémentaires sont irrecevables ; MF dément tout transfert aux États-Unis (cf. premier point) et ne prévoit donc pas de mesures complémentaires ; le consentement de l’internaute (au sens de l’article 49.1a du RGPD) n’est pas recueilli (et le refus de tous les cookies dans le bandeau dédié a aucune incidence sur le chargement des ressources web sus-énumérées) ; et la nécessité des transferts des données personnelles vers les États-Unis n’est pas établie :
- Un outil de mesure d’audience (c’est ainsi qu’il est présenté par son éditeur, AT Internet) ne peut pas être regardé comme étant nécessaire à l’exécution d’un contrat, car le service peut être fourni sans : si l’on bloque les requêtes web de téléchargement de cet outil avec l’extension pour navigateur web uMatrix, par exemple, le site web de MF reste intégralement fonctionnel ;
- Pour la même raison, des régies publicitaires ne peuvent être appréciées comme étant nécessaires à l’exécution d’un contrat, mais, en sus, la nécessité financière d’un recours à la publicité par un établissement public à caractère administratif interroge ;
- MF peut déclencher le chargement des vidéos (Google YouTube et Vivendi Dailymotion, même combat), après un clic sur un bouton / encart qui informe l’internaute du transfert de ses données personnelles vers les États-Unis et des risques encourus ;
- MF peut réduire le nombre d’acteurs du même type (deux régies publicitaires, deux plateformes de vidéos) qu’elle intègre sur son site web. Principe d’optimisation technique et de minimisation des traitements (et, en l’occurrence, des transferts) au sens du RGPD ;
- En tout état de cause, MF peut soit utiliser des outils hébergés en interne à coût quasi-nul (cas de la mesure d’audience ou de la CMP) ou externaliser auprès d’entités européennes hébergées (informatiquement) dans l’UE (régie pub, CMP, plateforme vidéos, etc.). La nécessité de recourir à des entités états-uniennes et de leur transférer des données personnelles n’est donc pas démontrée.
Les téléchargements automatiques de ressources web externes lors de la consultation du site web de Météo France, et les transferts de données personnelles vers les États-Unis qui en découlent sont donc illégaux.
Je vais signaler, au DPO de Météo France, ces manquements au RGPD afin qu’il s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’il entreprendrait, les faits relatés ci-dessus constituent en soi des violations du Règlement qui justifient à elles seules le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes.Je vous rappelle l'arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a jugé qu'une APD peut agir même si la personne physique concernée par un traitement de données personnelles n'a pas fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.
ÉDIT DU 20/07/2023 :
Le 26/05/2023, j'ai envoyé à la CNIL ce complément de réclamation :
Bonjour,
Depuis quelques semaines (cf. https://twitter.com/nb4ld/status/1659682417039273990), Météo France n'a plus recours à des ressources web téléchargées depuis des entités états-uniennes pour afficher sa carte des prévisions météo. Donc, la première partie de ma réclamation, jusqu'à la fin de la 2e page, est caduque.
En revanche, Météo France a toujours recours à la régie pub Google, à une place de marché hébergée derrière Fastly, à une CMP hébergée chez Amazon, à Google Tag Manager et Piano Xiti (hébergé par Amazon), et à des vidéos incrustées depuis Google YouTube et Dailymotion (dont le lecteur de vidéos est partiellement diffusé par des entités états-uniennes).
En conséquence, je maintiens ma réclamation.
Bonne fin de semaine.
FIN DE L'ÉDIT du 20/07/2023.
ÉDIT DU 22/07/2023 :
Au final, ça n'aura pas duré longtemps dès le 05/06/2023, les scripts externes étaient de retour et à nouveau nécessaires pour afficher la carte des prévisions…
J'en ai donc informé la CNIL le 22/07/2023 :
Bonjour,
Je retire mon complément du 26/05/2023. En effet, dès le 5 juin 2023, les ressources web téléchargées depuis des entités états-uniennes référencées dans ma réclamation étaient à nouveau indispensables pour afficher la carte des prévisions sur le site web de Météo France.
Le manquement au RGPD constaté dans la première partie de ma réclamation (jusqu'à la fin de sa deuxième page) a donc cessé uniquement entre le 16 mai 2023 après-midi et le 5 juin 2023 matin. Sources : https://web.archive.org/web/20230516215928/https://meteofrance.com/ et https://web.archive.org/web/20230605093322/https://meteofrance.com/.
En conséquence, je maintiens ma réclamation initiale dans son intégralité.
Bonne semaine.
FIN DE L'ÉDIT du 22/07/2023.
J'ai amendé ma plainte CNIL portant sur Vitaline. Les emails de leur newsletter non sollicitée contiennent des liens avec un identifiant unique qui pointent sur un site web intermédiaire, 40pyk.r.a.d.sendibm1.com, délégué au prestataire d'e-mailing Sendinblue, et des images rédactionnelles (utiles, quoi) avec un identifiant unique dans leur nom et qui sont hébergées par le prestataire d'e-mailing, c'est-à-dire des liens et des images traçantes. Les images détectent l'ouverture de la version HTML de l'email (qui déclenchent leur téléchargement automatique), et les liens détectent un clic volontaire. Sans nécessité ni consentement.
Les images traçantes sont diffusées via Cloudflare (j'en informe la CNIL dans un complément à mon complément de plainte ci-dessous). Les liens traçants redirigent vers le site de Vitaline via une page web qui contient une iframe (une page web imbriquée) servie via Cloudflare. Ici, le même raisonnement juridique que d'habitude s'applique.
L'identifiant unique est inséré dans l'URL finale (celle qui résulte de la redirection) qui, comme l'adresse IP et des caractéristiques techniques du navigateur web du client Vitaline, est consigné dans le journal des serveurs web de Vitaline (et dans ceux de Cloudflare, utilisé ici aussi…), et transmis à l'outil de mesure d'audience utilisé par Vitaline sur son site web, Google Analytics (une autre non-conformité au RGPD).
Du coup, hop, plainte à la CNIL.
Le raisonnement juridique reste identique aux précédentes fois.
Ma plainte CNIL :
ÉDIT DU 25/11/2022 : Elle contient au moins une erreur : c'est dans sa décision du 22/04/2022 que l'APD autrichienne rappelle que le RGPD ne prévoit pas d'approche basée sur le risque en matière de transferts de données personnelles hors de l'UE, pas dans sa décision 2021-0.586.257 (qui en est tout de même la première partie du film). FIN DE L'ÉDIT.
Bonjour,
J'ajoute deux griefs à ma plainte.
Tous les liens hypertextes des emails de Vitaline du 26/08/2022 et du 31/08/2022 sont des « liens de traçage » (d'après votre terminologie, cf. https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger), voir PJ 2 déjà transmise. Exemple : « https ://40pyk.r.a.d.sendibm1.com/mk/cl/f/zLwgwirvlQtnsnFXm9b-YFQZKud_rURDzKtayU8f-TWq8QWGyN_YAewOicOzYxR-c0Ahmi48Fz6NIfLIMC4zu_ecQ7GaRstf-8O-YaU-nfvV1Dz1sEZL7jrG-2Lpj4Lh17FAXhH8aGoANiG6OthksjV2rn1rK8KlDudtt5StVJbB-ab6BhEmUhWYmGbcAdOqLthQ0l5yKoFFIIkQ-60CsgoCmgiXTq9TRjUN8a0ohHRxyUEXI5qHtRqv9Vvln8IJWhD764nYzgOPDiNs_TW4ZkSLFIF29_gCaPnzEBjeB4eBKOIvLILQjLNkFLp3oBJqJIh0DtIg-Ni80DmyW3Gzrf6L ».
Si l'on clique sur l'un de ces liens, l'URL finale est « https ://vitaline.fr/collections/bars?utm_source=sendinblue&utm_campaign=Toujours prt pour la rentre 22&utm_medium=email », voir PJ 3. On retrouve le traceur : je suis arrivé ici par la campagne emails sus-nommée émise par le prestataire Sendinblue.
Mon adresse IP, cette URL, les informations qu'elle véhicule, et plusieurs caractéristiques techniques de mon navigateur web seront donc consignées dans le journal des serveurs web de Vitaline qui diffusent cette page web, et transmises à l'outil de mesure d'audience intégré par Vitaline sur son site web, Google Analytics (autre non-conformité RGPD, cf. votre mise en demeure du 10/02/2022).
De même, toutes les images de la version HTML de l'email, qui sont des images rédactionnelles (elles participent au contenu), sont également des images traçantes téléchargées depuis le prestataire Sendinblue, voir PJ 4.
La nécessité d'un tel double traçage n'est pas établie : il est parfaitement possible d'utiliser des liens directs (qui pointent sur le contenu web, sans intermédiaire) et des images sans traceur hébergées en interne, chez le même hébergeur que le site web de Vitaline.Le client destinataire de l'email de Vitaline n'est pas informé de ces liens et images traqueurs et son consentement n'est pas récolté.
Il découle des deux derniers paragraphes qu’il s’agit d'un manquement au RGPD selon le CEPD (document WP 118, section V) et selon vous (https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger).
Notons que la destination des liens traceurs est une page web hébergée par Sendinblue (prestataire d'e-mailing de Vitaline) qui redirige vers le site web de Vitaline. Avant la redirection, une iframe (une page web intégrée dans une autre) est automatiquement téléchargée par le navigateur web du client Vitaline, voir PJ 3. Son URL est « https ://sibautomation.com/cm.html?id=2317578#trans=0&user_id=2665379 ». Elle apporte aucune plus-value technique ou rédactionnelle.Le nom de domaine Internet « sibautomation.com » est loué par la société Sendinblue. On retrouve, en paramètre, l'identifiant unique de la campagne d'e-mailing et du client.
Or, pour diffuser ce site web, Sendinblue, prestataire de Vitaline, a recours au CDN de la société commerciale états-unienne Cloudflare :
$ dig +short sibautomation.com
104.18.34.145
172.64.153.111$ whois 104.18.34.145 | grep Organization
Organization: Cloudflare, Inc. (CLOUD14)$ whois 172.64.153.111 | grep Organization
Organization: Cloudflare, Inc. (CLOUD14)Comme l’ont jugé la Cour de Justice de l’Union européenne (arrêt C-311/18 dit « Schrems II ») et la Cour régionale de Munich (décision 3_O_17493/20 portant sur Google Fonts), et comme vous l’avez analysé (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics), ce téléchargement de page web en lui-même génère de facto un transfert hors de l’Union européenne (UE) de plusieurs données personnelles du client Vitaline : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de sa consultation de l’email de Vitaline (s'il clique sur l’un des liens qu’il contient), la marque et le modèle de son navigateur web (entête HTTP User-Agent), etc.
Ces données personnelles renforcent entre elles leur caractère discriminant / individualisant (voir l’étude Panopticlick de l’Electronic Frontier Foundation qui, depuis plus d’une décennie, identifie de manière unique un navigateur web à partir, entre autres, des entêtes sus-mentionnés) et rendent identifiable une personne, surtout par un acteur hégémonique qui, par sa présence sur de nombreux sites web, peut suivre une personne entre les sites web et parvenir à l’identifier. On retrouve cette analyse dans votre mise en demeure du 10 février 2022 concernant l’utilisation de Google Analytics.
D’après l’article 44 du RGPD, seules une décision d’adéquation (article 45 du RGPD), des garanties appropriées (articles 46 et 47 du RGPD) ou des exceptions (consentement ou exécution du contrat, les autres dispositions de l’article 49 du RGPD ne sont pas applicables dans le présent contexte) peuvent autoriser ces transferts de données personnelles en dehors de l’UE.
À ce jour, il n’existe plus de décision d’adéquation entre l’UE et les États-Unis, l’arrêt Schrems II de la Cour de Justice de l’Union européenne (CJUE) ayant invalidé la dernière décision, le Privacy Shield.
Comme l’EDPS (décision numéro 2020-1013) et vous-même (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’analysez, les clauses contractuelles types, et toutes les garanties appropriées ont été indirectement invalidées par l’arrêt Schrems II de la CJUE au motif de la surveillance de l’État fédéral états-unien, de l’absence de recours effectif et de l’absence de démonstration de l’efficacité à garantir un niveau de protection adéquat au droit de l’UE de toute mesure contractuelle, organisationnelle ou technique.
De plus, on peut avoir la certitude que Vitaline met en œuvre aucune mesure technique complémentaire car le navigateur web du client Vitaline qui clique sur un lien contenu dans l'email émis par Vitaline télécharge implicitement et directement une page web auprès de l’infrastructure technique de l’hébergeur informatique états-unien choisi par Sendinblue, le prestataire d’e-mailing de Vitaline. Dès lors, la requête web émise par le navigateur web du client Vitaline ne chemine pas par l’infrastructure technique de Vitaline ni par celle de son prestataire (dit autrement, il y a un contact direct entre le terminal du client Vitaline et les serveurs informatiques du prestataire états-unien de Sendinblue), donc elle échappe totalement à Vitaline et à son prestataire direct, Sendinblue, qui peuvent, de ce seul fait, prendre aucune mesure technique.
Enfin, comme l’analyse l’autorité de protection des données personnelles autrichienne (décision numéro 2021-0.586.257), le RGPD ne prévoit pas d’approche fondée sur les risques en matière de transfert de données personnelles à un pays tiers non adéquat.
Vitaline ne recueille pas explicitement le consentement de son client pour le transfert de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ce transfert peut comporter pour lui, comme l’impose l’article 49.1a du RGPD.
La nécessité du transfert des données personnelles sus-énumérées aux États-Unis au motif de l’exécution du contrat (article 49.1b du RGPD) est irrecevable, car un outil de traque et de suivi ne peut pas être regardé comme étant nécessaire à l’exécution d’un contrat. En tout état de cause, il est techniquement possible de proposer, dans un email, des liens dénués de traceur.
Lors d'un clic sur un des liens proposés dans l'email envoyé par Vitaline, le téléchargement automatique d'une page web de traçage hébergée sur des infrastructures techniques situées aux États-Unis et/ou détenues par des organisations de droit états-unien, et le transfert de données personnelles vers les États-Unis qui en découle, est donc illégal.
Nouveau manquement au RGPD, donc.
Bonne journée.P.-S. : le site web de Vitaline (vitaline.fr) fait automatiquement télécharger des ressources web (images, feuille de style, police de caractères, scripts) depuis des hébergeurs et/ou des CDN de droit états-unien (Cloudflare, Amazon Cloudfront / AWS, Facebook, Google, etc.). Tout cela constitue plusieurs transferts illégaux de données personnelles aux États-Unis, cf. le raisonnement déroulé ci-dessus. C'est un véritable florilège, je n'ai pas la force d'en dresser un inventaire précis dans une plainte CNIL. À vous de jouer.
Certains emails envoyés par la Caisse Nationale d'Assurance Maladie (CNAM) aux citoyens contiennent des liens avec un identifiant unique qui pointent sur un domaine intermédiaire (stat.info.ameli.fr, qui est délégué au prestataire d'e-mailing Worldline), et une image vide (0 octet) dont l'identifiant HTML unique est « openTracking » et qui contient un identifiant unique dans son nom, c'est-à-dire des liens et des images traçantes. L'image détecte l'ouverture de la version HTML de l'email (qui déclenche son téléchargement automatique), et les liens détectent un clic volontaire. Sans nécessité ni consentement.
Certains emails appellent à effectuer des démarches, ce qui oblige à cliquer sur les liens… et à se faire fliquer. Exemples : les emails concernant « Mon Espace Santé ». (Non, tous les messages ne sont pas disponibles dans la messagerie de l'espace personnel web. Ouiiii, on peut chercher à l'aveugle dans le foutoir d'ameli.fr, tout le monde fait ça, c'est bien connu.)
Ça dure depuis au moins deux ans et demi (je n'ai pas conservé les emails antérieurs).
Depuis au moins cette période, la CNAM ne propose pas de version texte (sans image traçante, et avec une possible dissociation du texte du lien et de sa cible, donc) de ses emails. Ce qui oblige le citoyen à se faire fliquer, soit avec la version HTML, soit avec le lien traçant vers la « version en ligne » de l'email. (Non, tous les messages ne sont pas disponibles dans la messagerie de l'espace personnel web.)
Du coup, hop, plainte à la CNIL.
Le raisonnement juridique reste identique à la précédente plainte.
Ma plainte CNIL :
Bonjour,
Le 12/09/2022, j'ai reçu un email de l'Assurance Maladie.
Tous les liens hypertextes qu'il contient sont des « liens de traçage » (d'après votre terminologie, cf. https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger), voir PJ 1. Exemple : « https ://stat.info.ameli.fr/r/ICYvllm6gSuRYwKcMJP8XyiSi35h6z4pCBbIiRVE1Z5ZENiqqIeCFRUagw+McEsw8juMciCs+3wBmP6qz5JPKWEEdK4gxGZXRGRHXp9Q1m6To6/s/TUdyjqQcf7PvciP3PPII7OUyf4D7buAZQWlMGWOYvGlyDUoI7ODtycHaqmGiw==+MTs1O2h0dHA6Ly9hbm51YWlyZXNhbnRlLmFtZWxpLmZyLztUcm91dmV6IHVuIG3DqWRlY2luIHByw6hzIGRlIGNoZXogdm91cwF-9xkUMeezgC0lvt_sEKqEMg7D8 »
En effet, « stat.info.ameli.fr » est un sous-domaine Internet qui porte bien son nom et qui est délégué, par la CNAM, à son prestataire d'e-mailing, la société commerciale française Worldline :
$ dig +short stat.info.ameli.fr
front-cnam-platform-email.worldline-solutions.com.
160.92.30.26
La version HTML de l'email contient au moins une image traçante c'est-à-dire un fichier image vide (taille = 0 octet) dont l'identifiant HTML unique est « openTracking », voir la page 4 de la PJ 1.
La nécessité d'un tel traçage n'est pas établie : il est parfaitement possible d'utiliser des liens directs (qui pointent sur le contenu web sans intermédiaire). D'ailleurs, les emails émis par la même Assurance Maladie, via le même prestataire d'e-mailing, les 23/03/2022 et 07/07/2022, concernant « Mon espace santé », ne contiennent pas de traceurs, voir PJ 2.Le citoyen destinataire de l'email de l'Assurance Maladie n'est pas informé de ces liens et images traqueurs et son consentement n'est pas récolté.
Il découle des deux derniers paragraphes qu’il s’agit d'un manquement au RGPD selon le CEPD (document WP 118, section V) et selon vous (https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger).
Je constate que les emails de l'Assurance Maladie du 23/01/2020 concernant <CENSURE> contenaient déjà des liens de traçage, voir PJ 3.Il s'agit des plus anciens emails de l'Assurance Maladie que je détiens.
Les manquements au RGPD sus-référencés sont donc répétés par l'Assurance Maladie depuis au moins plus de deux ans et demi.
Je constate que, au moins depuis janvier 2020 inclus, les emails envoyés par l'Assurance Maladie n'incluent pas de version texte, mais uniquement une version HTML. La version texte contient uniquement un lien, avec un traceur, permettant d'aller consulter le « nouveau message » de l'Assurance Maladie, voir PJ 4.J'interprète cela comme une volonté de l'Assurance Maladie de tracer les citoyens sans leur laisser le choix.
Cela constitue donc une circonstance aggravante au manquement au RGPD sus-énuméré.
Je vais signaler, au DPO de ma CPAM d'affectation, ce manquement récurrent au RGPD afin qu’il s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’il entreprendrait, les faits relatés ci-dessus constituent en soi une violation répétée du Règlement qui justifie à elle seule le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes.Je vous rappelle l'arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a jugé qu'une APD peut agir même si la personne physique concernée par un traitement de données personnelles n'a pas fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.
P.-S. : votre formulaire de saisie d'une plainte devrait autoriser les formats de fichiers eml et/ou html. Cela permettrait de vous montrer le contenu "caché" d'un email sans perte d'information (ce que ne permet pas le changement d'extension « eml » pour « txt ») et sans devoir recourir à trouzemilles captures d'écran chronophages à effectuer. De même, dans ma plainte 44-965, j'ai dû copier les entêtes d'un email dans un traitement de texte… alors qu'il m'aurait suffi de vous transmettre le fichier eml lui correspondant.
Les emails commerciaux (nouveaux tarifs, fermeture des commandes, nouveau service, etc.) émis par OVH à destination de ses clients contiennent des liens avec un identifiant unique et des images transparentes de dimension 1 x 1 pixel avec un identifiant dans leur chemin, c'est-à-dire des liens et des images traçantes. Les images détectent l'ouverture de l'email (qui déclenche leur téléchargement automatique), et les liens détectent un clic volontaire. Sans nécessité ni consentement.
Certains emails ne contiennent pas l'info qu'ils sont censés véhiculer, ce qui oblige le client à cliquer sur les liens… et à se faire fliquer. Exemple : l'email du 14/09 ne contient pas les nouveaux tarifs dont il est question.
Les images traçantes sont hébergées, par le prestataire d'OVH, Selligent, chez Microsoft et via Cloudflare. Les liens redirigent vers le contenu final via un hébergement Amazon. Ici, le même raisonnement juridique que d'habitude s'applique. Après ça, OVH t'explique qu'elle fait du cloud souverain, qu'elle est certifiée SecNumCloud, pouet pouet… (Oui, je suis au courant que ladite certification couvre un périmètre technique, méthodologique et organisationnel précis, mais on a le droit de se faire plaisir, aussi.)
L'identifiant unique est inséré dans l'URL finale (celle qui résulte de la redirection) qui, comme l'adresse IP et des caractéristiques techniques du navigateur web du client OVH, est consigné dans le journal des serveurs web d'OVH et transmis aux outils de mesure d'audience utilisés par OVH sur son site web, Xiti et Commanders Act.
Ça dure depuis au moins six mois (je n'ai pas conservé les emails antérieurs).
Depuis le 13/04, OVH ne propose plus de version texte (sans images traçantes, et avec une possible dissociation du texte du lien et de sa cible, donc) de ses emails. Ce qui oblige le client à se faire fliquer, soit avec la version HTML, soit avec le lien traçant vers la « version en ligne » de l'email.
Du coup, hop, plainte à la CNIL.
Nouveauté : d'après le CEPD, dans la section V de son avis WP 118 (VO), toutes les techniques permettant implicitement de savoir si quelqu'un a lu un email (liens, images, etc.) doivent reposer sur un consentement explicite. On retrouve cela dans la doctrine de la CNIL.
Pour les tatillons :
Ma plainte CNIL :
ÉDIT DU 25/11/2022 : Elle contient au moins une deuxième erreur : c'est dans sa décision du 22/04/2022 que l'APD autrichienne rappelle que le RGPD ne prévoit pas d'approche basée sur le risque en matière de transferts de données personnelles hors de l'UE, pas dans sa décision 2021-0.586.257 (qui en est tout de même la première partie du film). FIN DE L'ÉDIT.
Bonjour,
Je suis client de la société commerciale française OVH.
Le 14/09/2022, j'ai reçu un email m'informant de l'« évolution des tarifs en 2022 et 2023 » (voir PJ 1). Le lien permettant de prendre connaissance des prix des nouveaux services, « https ://services.ovhcloud.com/optiext/optiextension.dll?ID=iQRiODTlThZWCeOFbF0Bef9PScIG1U%2BZxqmtKrqAaH8m8Vw4a0ZxZzGZruAiFifOw_UxkTMKCNiH7IV3I0UmQc70RoS47 », et celui permettant de prendre connaissance des prix des services existants, « https ://services.ovhcloud.com/optiext/optiextension.dll?ID=iQRiOGfy0NV7BqeNnGO6ofY86HgiLHD283iqarFENPHaKQKyahUg_D_QHTZhiD2MyTWDHDuasZo9pMto0j2S70IMAC94f », sont des « liens de traçage » (d'après votre terminologie, cf. https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger). Il en va de même pour tous les liens contenus dans cet email.
Si l'on clique sur l'un de ces liens, l'URL finale est (voir PJ 2) : « https ://www.ovhcloud.com/fr/new-services-repricing/?at_medium=email&at_campaign=servicial&at_emailtype=promotion&at_creation=fr_int_2022_ovh_multi_multi_FY23_Q1_Mailing_Repricing_awareness_visibility_slgnt-27-4982&at_send_date=20220914&at_link=newservicesrepricing&at_recipient_id=27-4982 ». On retrouve le traceur : je, identifié par un « recipient_id » suis arrivé ici par la campagne emails sus-nommée qui a été envoyée à telle date.Mon adresse IP, cette URL, les informations qu'elle véhicule, et les caractéristiques de mon navigateur web seront donc consignées dans le journal des serveurs web d'OVH qui diffusent cette page web, et transmises aux outils de mesure d'audience et de parcours client Xiti et Commanders Act intégrés par OVH sur cette même page web.
La nécessité d'un tel double traçage n'est pas établie : il est parfaitement possible d'utiliser des liens directs (qui pointent sur le contenu web). D'ailleurs, les emails émis par le service d’assistance aux clients d'OVH contiennent de tels liens directs.Le client destinataire de cet email n'est pas informé de ces liens traqueurs et son consentement n'est pas récolté.
Il découle des deux derniers paragraphes qu’il s’agit d'un manquement au RGPD selon le CEPD (document WP 118, section V) et selon vous (https://www.cnil.fr/fr/nouvelles-methodes-de-tracage-en-ligne-quelles-solutions-pour-se-proteger).
De plus, je constate que ces liens pointent, en premier lieu (avant redirection vers le site web d'OVH), sur le site web « ovh.commander1.com » (voir PJ 3), propriété de la société commerciale française Commanders Act, mais hébergé par la société commerciale états-unienne Amazon.Comme l’ont jugé la Cour de Justice de l’Union européenne (arrêt C-311/18 dit « Schrems II ») et la Cour régionale de Munich (décision 3_O_17493/20 portant sur Google Fonts) et comme vous l’avez analysé (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics), cette redirection web en elle-même génère de facto un transfert hors de l’Union européenne (UE) de plusieurs données personnelles du client OVH : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de sa consultation de l’email d’OVH, la marque et le modèle de son navigateur web (entête HTTP User-Agent), etc.
Ces données personnelles renforcent entre elles leur caractère discriminant / individualisant (voir l’étude Panopticlick de l’Electronic Frontier Foundation qui, depuis plus d’une décennie, identifie de manière unique un navigateur web à partir, entre autres, des entêtes sus-mentionnés) et rendent identifiable une personne, surtout par un acteur hégémonique qui, par sa présence sur de nombreux sites web, peut suivre une personne entre les sites web et parvenir à l’identifier. On retrouve cette analyse dans votre mise en demeure du 10 février 2022 concernant l’utilisation de Google Analytics.
D’après l’article 44 du RGPD, seules une décision d’adéquation (article 45 du RGPD), des garanties appropriées (articles 46 et 47 du RGPD) ou des exceptions (consentement ou exécution du contrat, les autres dispositions de l’article 49 du RGPD ne sont pas applicables dans le présent contexte) peuvent autoriser ces transferts de données personnelles en dehors de l’UE.
À ce jour, il n’existe plus de décision d’adéquation entre l’UE et les États-Unis, l’arrêt Schrems II de la Cour de Justice de l’Union européenne (CJUE) ayant invalidé la dernière décision, le Privacy Shield.
Comme l’EDPS (décision numéro 2020-1013) et vous-même (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’analysez, les clauses contractuelles types, et toutes les garanties appropriées ont été indirectement invalidées par l’arrêt Schrems II de la CJUE au motif de la surveillance de l’État fédéral états-unien, de l’absence de recours effectif et de l’absence de démonstration de l’efficacité à garantir un niveau de protection adéquat au droit de l’UE de toute mesure contractuelle, organisationnelle ou technique.
De plus, on peut avoir la certitude qu’OVH met en œuvre aucune mesure technique complémentaire car le navigateur web du client OVH qui clique sur un lien contenu dans l'email émis par OVH télécharge implicitement et directement une page web auprès de l’infrastructure technique de l’hébergeur informatique états-unien choisi par Commander Act, le prestataire d’OVH. Dès lors, la requête web émise par le navigateur web du client OVH ne chemine pas par l’infrastructure technique d’OVH ni par celle de son prestataire (dit autrement, il y a un contact direct entre le terminal du client OVH et les serveurs informatiques du prestataire états-unien de Commander Act), donc elle échappe totalement à OVH et à son prestataire direct, Commander Act, qui peuvent, de ce seul fait, prendre aucune mesure technique.
Enfin, comme l’analyse l’autorité de protection des données personnelles autrichienne (décision numéro 2021-0.586.257), le RGPD ne prévoit pas d’approche fondée sur les risques en matière de transfert de données personnelles à un pays tiers non adéquat.
OVH ne recueille pas explicitement le consentement de son client pour le transfert de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ce transfert peut comporter pour lui, comme l’impose l’article 49.1a du RGPD.
La nécessité du transfert des données personnelles sus-énumérées aux États-Unis au motif de l’exécution du contrat (article 49.1b du RGPD) est irrecevable, car un outil de ciblage, de traque, et de suivi du parcours client (c’est ainsi qu’il est présenté par son éditeur, Commanders Act) ne peut pas être regardé comme étant nécessaire à l’exécution d’un contrat. En tout état de cause, il est techniquement possible de proposer, dans un email, des liens dénués de traceur ou d’utiliser des liens de traçage via un prestataire européen hébergé (informatiquement) au sein de l'Union européenne.
De plus, je constate que l'email d'OVH contient plusieurs images externes transparentes de dimensions un pixel sur un pixel au format png, autrement dit d’images invisibles (voir PJ 4, pages 1-3). Il s’agit d’une méthode habituellement utilisée pour traquer les visiteurs d’un site web. Ces images sont téléchargées automatiquement à l'ouverture de l'email par le logiciel lecteur d'emails du client OVH.Cela renforce le premier grief de la présente plainte (traçage de la lecture de l'email).
Ces images sont diffusées depuis :
un domaine Internet (ovh.slgnt.eu) propriété de la société commerciale belge Selligent, filiale du groupe états-unien CM Group (https ://cmgroup.com/), qui, elle-même a recours au CDN de la société commerciale états-unienne Cloudflare pour l’héberger ;
- le service Azure de la société commerciale états-unienne Microsoft.
Cela renforce le deuxième grief de la présente plainte (transfert illégal de données personnelles vers les États-Unis).
Je constate que les emails de la société OVH du 13/04 et du 28/04 concernant la fermeture des commandes Kimsufi contenaient déjà des liens de traçage (voir PJ 5, pages 1-2) et une ou plusieurs des images traçantes sus-énumérées (voir PJ 4, pages 4-5). Idem pour l'email du 02/12/2021 (voir PJ 5, page 3 pour le lien, et PJ 4, pages 6-7 pour l'image).En revanche, seul cet email du 02/12/2022 contient un lien (parmi plusieurs) passant par Commanders Act.
Les manquements au RGPD sus-référencés sont donc répétés par la société OVH depuis au moins plus de six mois.
Je constate que, depuis le 13/04 inclus, les emails envoyés par OVH à ses clients n'incluent plus de version texte, mais uniquement une version HTML. La version texte contient uniquement un lien, avec un traceur, permettant d'aller consulter la « version en ligne » de l'email.Je l'interprète comme une volonté de la société OVH de tracer ses clients, sans leur laisser le choix, de les contraindre toujours plus.
Cela constitue donc une circonstance aggravante aux manquements au RGPD sus-énumérés.
Je vais signaler, au DPO d'OVH, ces manquements récurrents au RGPD afin qu’il s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’il entreprendrait, les faits relatés ci-dessus constituent en soi des violations répétées du Règlement qui justifient à elles seules le dépôt d’une plainte auprès de l’autorité de contrôle que vous êtes.Je vous rappelle l'arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a jugé qu'une APD peut agir même si la personne physique concernée par un traitement de données personnelles n'a pas fait valoir ses droits auprès du responsable du traitement en question.
Bonne journée.P.-S. : votre formulaire de saisie d'une plainte devrait autoriser les formats de fichiers eml et/ou html. Cela permettrait de vous montrer le contenu "caché" d'un email sans perte d'information (ce que ne permet pas le changement d'extension « eml » pour « txt ») et sans devoir recourir à trouzemilles captures d'écran chronophages à effectuer. De même, dans ma plainte 44-965, j'ai dû copier les entêtes d'un email dans un traitement de texte… alors qu'il m'aurait suffi de vous transmettre le fichier eml lui correspondant.
Complément envoyé le même jour :
Bonjour,
J'amende ma plainte sur deux points :
1) Au premier grief (liens traçants), j'ajoute que « services.ovhcloud.com », qui est le nom de domaine utilisé dans les liens traçants des emails d’OVH est un sous-domaine Internet qui est délégué par OVH à son prestataire d'e-mailing, la société commerciale belge Selligent :
$ whois $(dig +short services.ovhcloud.com) | grep -i netname
netname: SELLIGENTSelligent se présente comme une « plateforme de marketing omnicanal qui personnalise le marketing en activant les données pour des expériences client plus pertinentes » (source : balise HTML « meta property="og:description" ». Cela tend à confirmer la finalité de suivi des clients OVH et l’aspect facultatif des traitements de données personnelles énumérés dans ma plainte.
2) Dans mon deuxième grief (transfert illégal de données personnelles vers les États-Unis), dans la phrase : « En tout état de cause, il est techniquement possible de proposer, dans un email, des liens dénués de traceur ou d’utiliser des liens de traçage via un prestataire européen hébergé (informatiquement) au sein de l'Union européenne. », je rétracte « ou d’utiliser des liens de traçage via un prestataire européen hébergé (informatiquement) au sein de l'Union européenne. ».
Il s’agit d’une erreur, tout lien traçant sans consentement est contraire au RGPD comme je l'expose dans le premier grief de ma plainte.
Bonne fin de semaine.
« Se présente à nous pour demander de l’aide » c’est sur ce motif qu’un vieux monsieur marocain s’est vu subir un contrôle d’identité, puis une retenue de + de 22h ds les locaux de la PAF et enfin une OQTF, IRTF et assignation à résidence.
C’est ça la France de 2022.
C'était déjà la France des années 1970, cf. le flic de Coluche. Demander de l'aide à un flic ou au fisc ou à… , c'est comme tendre une capote à Rocco Siffredi : ça ne va pas bien se passer, ça ne peut pas bien se passer. Quand tu vois un flic, fuis, loin, très loin.
OpenDNSSEC a légèrement changé depuis mon article de blog (plus de 9 ans déjà :O). Notamment, la commande ods-ksmutil
a été remplacée par ods-enforcer key
.
Comme ça me gonfle de retrouver à tâtons chaque année les commandes à partir de mon tuto, je rédige ici la procédure 2022 pour un roulement de KSK avec OpenDNSSEC :
ods-enforcer key list -v
affiche « ds-seen » sur une KSK. Perso, je note dans mon agenda la date à laquelle cela va arriver ;ods-enforcer key export --zone guiguishow.info --keytype KSK --keystate ready
;dig @a0.info.afilias-nst.info. DS guiguishow.info
. Pour obtenir le nom du serveur qui fait autorité sur la zone parente, utiliser dig SOA info.
. Attention, certains registres, comme fr., utilise un master caché, donc il faut interroger les serveurs publics, identifiables avec dig NS <TLD>
;ods-enforcer key ds-seen --zone guiguishow.info --keytag <ID_NOUVELLE_CLÉ>
;ods-enforcer key ds-gone --zone guiguishow.info --keytag <ID_ANCIENNE_CLÉ>
;Plus que quelques jours pour mandater la Quadrature pour déposer une plainte collective auprès de la CNIL concernant le vidéoflicage, la reconnaissance faciale, le vidéoflicage algorithmique, et une infime partie du fichage étatique (fichiers Titres Électroniques Sécurisés ‒ TES ‒ et Traitement des Antécédents Judiciaires ‒ TAJ ‒ qui fiche les victimes, les témoins, les suspects, les coupables, qui contient 80 % d'erreurs et à l'encontre duquel l'exercice des droits est une plaie).
Aucun risque juridique ni financier à mandater LQDN.
Quasi 13 000 mandats récoltés.
Ooook, la nèfle, que l'on retrouve dans l'expression « j'ai fait tout ça pour des nèfles », est un fruit.
Merci, Claire.
Au deuxième semestre 2019, le Ravi proposait de signer une pétition de soutien éditée et hébergée par We Sign It. En 2022, j'ai reçu deux emails émis par le Ravi via Sendinblue portant sur un appel au don. Ils ont été envoyés à l'adresse emails dérivée dédiée à la signature de la pétition de 2019. We Sign It collecte (et utilise) une adresse emails essentiellement pour fiabiliser une pétition en évitant les fausses signatures par des robots (j'ai refusé la newsletter). Il s'agit donc d'un détournement de finalité (fiabilité / sécurité -> appel au don) pour laquelle le consentement était obligatoire (ça ne relève pas de l'exécution d'un contrat ni de l'intérêt légitime). Comment l'adresse emails et le pseudo des signataires de 2019/2020 ont pu être exportés par le Ravi et réutilisés deux ans plus tard via un autre prestataire ? Deux ans est une durée de conservation démesurée pour le motif « validation d'une signature ».
ÉDIT DU 23/11/2022 : suite à la liquidation judiciaire du Ravi, j'ai demandé à la CNIL de clôturer ma plainte. FIN DE L'ÉDIT.
Du coup, hop, plainte à la CNIL :
Bonjour
À partir de 2019 et jusqu'à mi 2020 (environ), le journal Le Ravi, édité par l'association La Tchatche, ci-après « Le Ravi », proposait de signer une pétition accessible à l'adresse http://leravienproces.wesign.it/fr (elle n'est plus accessible aujourd'hui, voir https://web.archive.org/web/20190701000000*/http://leravienproces.wesign.it/fr pour une version archivée).
Lors de la signature de cette pétition, je n'ai pas accepté la newsletter et je l'ai, de ce fait, jamais reçue.
Notons que la pétition est publiée via le prestataire « WE SIGN IT POUR LA PARTICIPATION CITOYENNE », ci-après « We Sign It », qui émet ses emails depuis l'hébergeur informatique Octopuce (sources : mentions légales + constat pratique).
Le 04/03/2022 et le 08/03/2022, j'ai reçu un email du Ravi concernant un appel au don (PJ 1). Ils ont été envoyés à l'adresse emails « <CENSURE>+wesign @ <CENSURE> » qui est une adresse emails dérivée dédiée à ma signature de la pétition du Ravi auprès de We Sign It. Je ne l'ai pas utilisé pour quoi que ce soit d'autre.On notera que le pied de page des emails indique « You've received this email because you've subscribed to our newsletter », ce qui n'est pas le cas, j'ai été inscrit de force, il s'agit du modèle de pied de page par défaut.
Les informations techniques de ces emails (PJ 2) montrent qu'ils sont envoyés via la société commerciale Sendinblue, pas via l'association We Sign It. Mon adresse email et le nom que j'ai donné (voir sujet de l'email du 08/03/2022) ont été extrait de la liste des signataires de la pétition We Sign It par Le Ravi, puis exportés chez un autre prestataire pour envoyer un appel au don.
Il s'agit d'un détournement de finalité. We Sign It collecte (et utilise) une adresse emails essentiellement pour fiabiliser une pétition en évitant les fausses signatures par des robots. (Les autres cas prévus par la politique de confidentialité, https://news.wesign.it/index.php/charte-de-confidentialite/, newsletter et facilité de navigation ne s'appliquent pas ici puisque j'ai décliné la newsletter.) Quand j'ai communiqué mon adresse emails à cette fin, je ne pouvais pas légitimement m'attendre à recevoir un appel au don.De plus, la temporalité interpelle : je signe une pétition fin 2019 et je reçois un appel au don début 2022, soit plus de deux ans plus tard. Il s'agit d'une durée de conservation excessive pour une validation de pétition, c'est-à-dire pour un motif de sécurité / fiabilité.
J'ai utilisé les liens de désinscription contenus dans les emails du 04/03/2022 et du 08/03/2022. À ce jour, je n'ai pas reçu de nouvelle sollicitation sur cette adresse emails dérivée.Le 11/03/2022, j'ai exposé les griefs ci-dessus au Ravi. La concision et la légèreté de la réponse (PJ 3), « Pour le RGPD on reste vigilent grâce aussi à vos retours, alors merci », rédigée par la « Responsable marketing » (ce qui illustre l'absence, en interne, d'une personne compétente sur le sujet des données personnelles), me convainc que des abus auront à nouveau lieu car la problématique n'est pas maîtrisée.
Le Ravi est fautif puisqu'il est le donneur d'ordre, mais une faute de l'association We Sign It pourrait également être à rechercher en cela qu'elle permet, à l'auteur d'une pétition, l'exportation des signataires d'une pétition pour des finalités visiblement très larges (premier grief), au-delà d'un délai raisonnable (deuxième grief). Ou alors, Le Ravi a extrait hâtivement la liste des signataires et l'a conservé "au cas où" (donc sans motif valable) pendant deux ans ?Les faits relatés ci-dessus, détournement de finalité non consenti deux ans après la dernière interaction consentie, constituent des manquements au RGPD qui justifient à eux seuls le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes.
Bonne journée.
Vitaline se met à m'envoyer une newsletter après onze mois de silence depuis ma commande. Je n'y ai pas consenti durant ma commande, ce qui n'est pas conforme au RGPD. Recevoir la newsletter onze mois après, ça ressemble à la création d'une newsletter postérieurement à ma commande et à l'abonnement forcé de tous les clients, y compris passé, ce qui constitue un détournement de finalité pour une dont le consentement est obligatoire (l'inscription à une newsletter n'est pas nécessaire à l'exécution du contrat puisque ma commande s'est bien déroulée sans elle, et cela ne valide pas les critères de l'intérêt légitime).
Du coup, hop, plainte à la CNIL (ÉDIT DU 16/09/2022 : j'ai versé un complément à ma plainte après avoir capté que ces emails contiennent deux autres manquements au RGPD. FIN DE L'ÉDIT.) :
Bonjour,
Le 18/08/2021, j'ai passé commande auprès de la marque Vitaline de la société commerciale Source Nutrition, ci-après Vitaline. À ce titre, j'ai bien reçu les emails de confirmation de ma commande et de suivi de la livraison, qui répondent à la finalité de l'exécution du contrat. C'est ma dernière interaction consentie avec cette société.
Entre août 2021 et juillet 2022, j'ai reçu aucun email en provenance de Vitaline. Je peux l'affirmer, car j'ai dédié une adresse emails dérivée à ce commerçant (<CENSURE>+vitaline @ <CENSURE>). La PJ 1 contient une extraction des journaux de mon serveur emails personnel entre le 01/09/2021 et le 31/08/2022 qui atteste cela.
Le 08/07/2022, le 27/07/2022, le 26/08/2022 et le 31/08/2022, j'ai reçu un email en provenance de « bounces-40pyk-newsletter=vitaline.fr@ie.d.sender-sib.com ». Je n'ai pas conservé les emails du 08/07 et du 27/07, mais vous trouverez les deux autres dans la PJ 2.
Je n'ai pas pu consentir à recevoir cette newsletter. Je suis vigilant lors du passage de commande et je refuse systématiquement.Donc, soit il s'agit d'un dark pattern qui m'a échappé lors de ma commande, soit il s'agit d'une réutilisation d'une donnée personnelle, mon adresse emails, pour une finalité à laquelle je n'ai pas consenti, qui n'est pas nécessaire à l'exécution d'un contrat, et qui ne répond pas aux critères de l'intérêt légitime. Dans les deux cas, ce n'est pas conforme au RGPD.
Le début de l'envoi de cette newsletter quasiment onze mois après ma commande tend à montrer que la deuxième hypothèse est la bonne : être inscrit à une newsletter commerciale et rien recevoir pendant onze mois est improbable. Une explication plus crédible est que la newsletter n'existait probablement pas lors de ma commande, qu'elle a été créée par la suite, et que tous les clients, y compris passés, y ont été abonnés de force.
J'ai cliqué sur les liens de désinscription contenus dans les emails du 26/08/2022 et du 31/08/2022. J'estime avoir exercé mon droit d'opposition.Je n'ai pas envie de contacter leur pseudo-DPO :
- aucun DPO avouera une réutilisation en douce de données personnelles, il préférera débiter les navrantes excuses habituelles ;
- dans sa politique de confidentialité, Vitaline renvoie vers une adresse « contact@ », à laquelle j'ai écrit en août 2021 (immédiatement après ma commande, pour signaler des fautes de frappe dans leur brochure), sans retour à ce jour (filtre anti-spam ?) ;
- une adresse emails générique signifie trop souvent qu'il n'y a pas de DPO ni même de personne compétente en interne.
En tout état de cause, je vous rappelle l'arrêt TS 1039/2022 dans lequel le Tribunal Supremo espagnol a jugé qu'une APD peut agir même si la personne physique concernée par un traitement de données personnelles n'a pas fait valoir ses droits auprès du responsable du traitement en question.
Les faits relatés ci-dessus, inscription forcée à une newsletter (opt-out), réutilisation d'une donnée personnelle pour une finalité facultative non consentie, et un premier envoi d'emails onze mois après la dernière interaction consentie, constituent des manquements au RGPD qui justifient à eux seuls le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes.Bonne journée.
L'opérateur d'opérateurs Cogent continuent à m'envoyer des emails (sondage, démarchage pour de nouveaux projets, activation de nouveaux services, etc.) sur mon adresse emails personnelle alors que je ne suis plus le contact technique / administratif de deux de ses clients depuis janvier 2019. Mon droit d'opposition, exprimé à deux reprises en 2020, n'a pas été mis en œuvre. D'ailleurs, en 2020, j'ai reçu un email dont notre ingénieur commercial me dit que ça n'aurait pas dû arriver puisque je n'étais déjà plus contact d'un quelconque service d'après leur outil d'avitaillement… Paye ton système d'information daubé.
Cogent est connu pour son démarchage agressif, surtout aux États-Unis, cf. le liste de discussion des opérateurs NANOG.
ÉDIT DU 24/11/2022 : réponse de la CNIL. Voir ci-dessous. FIN DE L'ÉDIT du 24/11/2022.
Du coup, hop, plainte à la CNIL :
Bonjour,
Entre 2015 et 2019, j'étais membre de deux associations loi 1901, Grifon et Alsace Réseau Neutre (« ARN » ci-après). Elles ont souscrit des contrats auprès de la société commerciale Cogent Communications France, filiale de Cogent Communications (États-Unis), « Cogent » ci-après. J'étais l'un des contacts techniques et/ou administratifs de ces contrats, pour le compte des deux assos.
Le 10/04/2020, j'ai reçu un email de notre ingénieur commercial Cogent. Par retour d'email, je l'ai informé ne plus faire partie de l'association et je lui ai demandé à ne plus recevoir d'emails de Cogent. Le 14/04/2020, il me confirme m'avoir retiré de leurs bases (PJ 1).Le 25/04/2020, j'ai reçu un email de surveillance auto des services numériques de l'asso (objets des contrats avec Cogent). J'ai demandé au même ingénieur commercial de me retirer de cette base de données. Le 27/04/2022, il m'informe que je n'étais déjà plus enregistré comme contact, qu'à ce titre, je n'aurais pas dû recevoir l'email, et qu'il a effectué les démarches pour me faire retirer de ladite base (PJ 2).
Le 14/10/2020, j'ai reçu un email de Cogent m'invitant à remplir un sondage. J'ai utilisé le lien pour me désinscrire (PJ 3, page 1).
Le 09/02/2021, j'ai reçu un email de démarchage de la responsable du compte client de l'asso chez Cogent. J'ai pris aucune action (PJ 3, page 2).
Le 12/07/2022, j'ai reçu un email du service européen de facturation de Cogent. J'y ai, une nouvelle fois, demandé à ne plus recevoir d'emails et à être effacé de toutes les bases de données (PJ 4).
Tous les emails sus-référencés m'ont été envoyé en tant que contact de l'asso Grifon. J'ai également reçu l'email du 12/07/2022 en tant que contact de l'asso ARN, comme l'atteste le journal de mon serveur emails personnel (PJ 5, page 1). Il est probable que j'ai également reçu les emails du 14/10/2020 et du 09/02/2021, mais je ne conserve pas aussi longtemps le journal de mon serveur emails pour l'affirmer (et, depuis 2019, j'ai désactivé l'adresse emails dérivée qui me servait dans l'asso ARN, donc je n'ai pas de copie de ces emails).
Je précise que tous ces emails ont été reçus sur mon adresse emails personnelle, que j'ai communiquée à Cogent en tant que contact technique et/ou administratif des associations.
Sur l'espace français de son site web (https://www.cogentco.com/fr/), Cogent déclare un DPO états-unien. Dans sa page « GDPR », seules des adresses postales sont listées. Pas question que j'envoie un courrier. Je n'ai pas trouvé de contact français dans la liste des DPO déclarés à la CNIL (https://www.data.gouv.fr/fr/datasets/organismes-ayant-designe-un-e-delegue-e-a-la-protection-des-donnees-dpd-dpo/).Les associations dont j'étais membre ont contracté avec Cogent Communications France (PJ 5, pages 2-3 et 4-5), donc je dois pouvoir faire valoir mes droits, par email, et en français.
Je constate que mon opposition à la réception d'emails Cogent et/ou mon effacement des bases de données Cogent, pourtant réclamés à deux reprises, n'ont pas été respectés ni mises en œuvre en avril 2020.Cet historique illustre un manque de volonté de Cogent en matière de bon traitement des données personnelles, et/ou un manque de formation aux outils internes, ou un système d'information inadapté ou dysfonctionnel.
Dans tous les cas, il s'agit de manquements au RGPD qui justifient à eux seuls le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes.
Bonne journée.
Pour info, mon email envoyé à Cogent le 09/09/2022 en réponse à celui du 12/07/2022 :
Bonjour,
Je ne fais plus partie de Grifon depuis janvier 2019.
En avril 2020, j'ai demandé, à deux reprises, à <CENSURE, nom de notre ingénieur commercial>, de ne plus recevoir d'emails de Cogent et d'être effacé de toutes vos bases de données. Il avait fait les démarches nécessaires auprès du support UE, cf. PJ. Mais, ça ne suffit pas…
J'ai reçu un email "répondez à notre questionnaire" le 14/10/2020, un email de nouvelle année / démarchage en février 2021, et désormais, cet email.
Ça commence à faire beaucoup. Je vous rappelle que ceci est mon adresse emails personnelle.
Pouvez-vous, svp, me retirer effectivement de toutes vos bases de données et faire en sorte que je ne reçoive plus d'emails provenant de Cogent ?
Attention : j'ai également reçu les emails sus-cités en tant que contact d'ARN (Alsace Réseau Neutre), dont je ne fais plus partie non plus depuis 2019. Merci donc de procéder à ma demande ci-dessus à la fois en tant que contact de Grifon ET en tant que contact d'ARN.
Bonne fin de semaine.
P.-S. : pour l'entité Alsace Réseau Neutre, mon adresse emails (que vous utilisez et qu'il faut supprimer de vos bases) est <CENSURE>. À des fins d'autorisation, le présent email est émis avec ladite adresse.
ÉDIT DU 24/11/2022 :
Après deux mois sans réponse de la CNIL (ma plainte était toujours au greffe) ni de Cogent, j'ai relancé la CNIL. Ma plainte a été traitée. Réponse (morceau utile) :
La CNIL est intervenue à l’appui de votre demande auprès de l’organisme mis en cause. Elle lui a rappelé ses obligations et lui a demandé d’effacer les données vous concernant de ses fichiers de prospection conformément à l’article 21 alinéa 2 du règlement général 2016/679 sur la protection des données (RGPD).
Il ne s'agit pas d'emails de prospection, mais bon… On va voir ce qu'en pense Cogent…
FIN DE L'ÉDIT du 24/11/2022.
ÉDIT DU 19/07/2023 :
Suite à une demande de communication de documents, la CNIL m'a transmis, le 30/01/2023, la prose qu'elle a envoyée à Cogent le 18 novembre 2022 :
Madame, Monsieur,
La Commission nationale de l’informatique et des libertés (CNIL) a reçu une réclamation à l'encontre de votre organisme de la part d’un usager rencontrant des difficultés dans l’exercice de son droit d'opposition à recevoir de la prospection commerciale.
En effet, l’usager nous informe qu’il ne souhaite pas recevoir de prospection commerciale de votre organisme et demande que ses données soient supprimées de vos bases de prospection commerciale. Il indique avoir tenté, sans succès, de s’opposer à ces sollicitations commerciales en adressant une demande à vos services dont vous trouverez une copie jointe au présent courrier.
Dans ce contexte, je vous informe que toute personne a le droit de s'opposer à tout moment au traitement des données à caractère personnel la concernant à des fins de prospection commerciale en application de l’article 21 2. du règlement général 2016/679 sur la protection des données (RGPD).
Lorsque vous êtes saisis d’une telle demande d’opposition, vous devez supprimer les données de la personne concernée de l’ensemble de vos fichiers de prospection (article 17 1. c du RGPD). Vous devez également notifier cette demande d'opposition aux partenaires commerciaux auxquels votre organisme a communiqué les données de la personne concernée (article 19 du RGPD).
Vous devez enfin fournir à cette personne des informations sur les mesures prises dans les meilleurs délais et, en tout état de cause, dans un délai d’un mois à partir de la réception de sa demande (article 12 3. du RGPD). Ce délai peut être prolongé de deux mois en raison de la complexité de la demande ou du nombre de demandes. Dans ce cas, vous devez en informer la personne concernée et lui indiquer les motifs de ce report.
Si vous ne donnez pas une suite favorable à sa demande, vous devez l’informer des motifs de votre inaction, de la possibilité d'introduire une réclamation auprès de la CNIL et de former un recours juridictionnel (article 12 4. du RGPD).
Par conséquent, je vous remercie de bien vouloir supprimer de vos fichiers de prospection les données personnelles de l’usager dont l’identité figure dans la pièce jointe au présent courrier, le cas échéant, de notifier cette demande à l’ensemble de vos partenaires destinataires de ses données et d'informer l’usager des mesures prises.
L’usager va être informé de la présente intervention auprès de votre organisme et être invité à revenir vers la CNIL s’il ne reçoit pas de réponse satisfaisante de votre part.
Afin de vous aider à assurer la conformité de vos traitements de données à caractère personnel, la CNIL met à votre disposition une fiche pratique qui vous rappelle vos obligations en matière de prospection commerciale également jointe au présent courrier.
A ce stade, ce courrier n’appelle pas de réponse de votre part auprès de la CNIL. Sachez néanmoins que si la CNIL est saisie de nouvelles réclamations concernant votre organisme, elle pourrait procéder à la vérification de vos traitements de données à caractère personnel, notamment en effectuant un contrôle et, si la situation l’exige, fera usage de ses pouvoirs de sanction.
Je vous prie d'agréer, Madame, Monsieur, l'expression de mes salutations distinguées.
Je constate :
Cogent ne m'a jamais informé de la suite qu'elle avait donnée. Je n'ai plus reçu d'emails non plus, ce qui laisse à penser qu'elle a traité ma demande. Affaire à suivre.
FIN DE L'ÉDIT DU 19/07/2023.
J'ai assisté à la 24e édition de ce festival.
Il faut commencer par dissiper un malentendu (que j'ai subi) : « arts de la rue », ça veut dire théâtre, contes, musique, etc. Ça ne veut pas dire art urbain, graffs, sculptures, etc. Du coup, Font'arts, c'est un festival d'Avignon miniature.
J'ai assisté à trois spectacles :
Certains gens du cru présentent ce festival comme un tremplin pour les débutants. Je ne partage pas cet avis. Il y a une programmation in, off et Fest'Ici (artistes locaux), mais le ratio est d'un débutant local pour cinq spectacles, et tout se déroule en parallèle sur trois jours, donc la visibilité des petits n'est pas acquise. De plus, le niveau est disparate : oui, un conteur peut être un débutant, mais le niveau d'exigence (préparation, accessoire, etc.) de la majorité des spectacles dépasse l'amateurisme. Enfin, dans le programme, il y a une photo de chaque spectacle, donc ils tournent déjà…
La rue, par opposition à un lieu fermé, c'est agréable (plein-air, etc.), mais il faut prévoir un minimum : Les conteurs du trac (du Fest'Ici, justement), installés dans un jardin public sans sonorisation, forcément, leur voix ne porte pas loin et elle se fait pourrir par le bruit ambiant des rues…
Les descriptions des spectacles dans le programme sont floues voire lunaires, donc elles ne permettent pas un choix éclairé. À titre d'exemple, Deux secondes ! est présenté comme « Que contiendrait aujourd’hui la boîte de Pandore, si ce n’est un de ces nouveaux objets qui ont envahi notre quotidien ? Technologiquement brillant, incroyablement confortable, mais tellement sournois. ». Du coup, je m'attendais à une critique de la technologie.
Ce festival est cher. Il y a de gros partenaires (Crédit Agricole) et des pubs dans le programme. En plus de cela, le programme papier est à 3 €, le verre en plastique consigné (intérêt ?) est à 1 €, le soda est à 2 € et les boissons alcoolisées sont à 3 €. Évidemment, il faut convertir de l'argent en jetons… Pourquoi faire simple quand on peut faire compliqué ? Comme ça, quand on change d'avis, que l'on veut une boisson d'un autre type, le jeton devient inutile. J'ai fini par consommer auprès des commerçants du coin hors festival.
Mention spéciale à la boulangerie pâtisserie artisanale de la place Aristide Briand dont les glaces maison sont vraiment délicieuses. :D
C'est la première fois que j'pisse dans des toilettes sèches. Pour le « tkt les toilettes sèches c'est sans odeur, si, si, j't'y jure tranquille", on repassera. Y'a peut-être une explication genre chaque usager n'a pas recouvert ses déjections d'une pelle de copeaux ?
Tout commence par la lecture d'une causerie sur Twitter qui mentionne un testeur TLS qui marque au fer rouge les configurations TLS qui n'utilisent pas les groupes prédéfinis dans leurs paramètres Diffie-Hellman (DH) utilisés, pour rappel, lors de l'échange des clés de chiffrement symétrique. Surtout, ce fil m'apprend qu'une manip' « résout le problème ».
Or, depuis le renforcement de mes configurations TLS de 2020, j'attendais que la fonction « SSL_CONF_cmd() » d'OpenSSL, qui est utilisée par la directive de configuration « SSLOpenSSLConfCmd » d'Apache httpd, prenne en charge les groupes prédéfinis lors d'une génération à la volée des paramètres DH. Or, même la version 1.1.1n empaquetée dans Debian 11 Bullseye ne permet pas cela (Apache httpd ne redémarre pas quand j'utilise la directive SSLOpenSSLConfCmd Groups ffdhe4096
… alors que cette valeur est référencée dans la doc' depuis 2019).
J'ai fini par comprendre que les paramètres DH avec groupes prédéfinis du RFC 7919 sont… des paramètres DH connus à l'avance. Rien de plus. Ils sont disponibles au téléchargement chez plusieurs acteurs. Mozilla : https://ssl-config.mozilla.org/ffdhe4096.txt ; Internet.nl : https://raw.githubusercontent.com/internetstandards/dhe_groups/main/ffdhe4096.pem.
On peut également demander à OpenSSL de nous les sortir : openssl genpkey -genparam -algorithm DH -pkeyopt dh_param:ffdhe4096 -out /etc/ssl/ffdhe4096.pem
.
J'étais donc totalement dans l'erreur. Le but du RFC 7919 est précisément de normaliser des paramètres DH fiables, c'est-à-dire dont les détails mathématiques (les groupes, etc.) sont connus et semblent être robustes, et de les utiliser partout. Par opposition aux paramètres DH générés à la volée (Dovecot faisait ça à une époque, Apache httpd fait ça si l'on ne configure pas explicitement des paramètres DH) qui peuvent être daubés.
Les paramètres DH normalisés s'utilisent comme tous les paramètres DH.
Du coup, avec nginx, il suffit d'utiliser la directive de configuration ssl_dhparam
avec, comme valeur, le chemin vers le fichier récupéré (ou généré) à l'étape précédente. Postfix : smtpd_tls_dh1024_param_file
. Dovecot : ssl_dh
. Ejabberd : c2s_dhfile
et s2s_dhfile
.
Et avec Apache httpd ? Il faut ajouter les paramètres DH au fichier qui contient les certificats x509 (feuille et intermédiaires) que l'on passe à la directive de configuration SSLCertificateFile
… Paye ton gloubi-boulga…
Avant de commencer mes manipulations, plusieurs testeurs TLS m'indiquaient que j'utilisais des paramètres DH de 3072 bits alors que, d'après ma configuration, j'ordonnais l'utilisation de paramètres de 4096 bits. En commentant la directive de configuration SSLOpenSSLConfCmd DHParameters
, j'obtenais le même résultat, ce qui prouve son inertie. C'est ici que l'on voit à l'œuvre les paramètres DH générés à la volée par un logiciel. ;)
Une recherche sur le web m'a appris que la directive SSLOpenSSLConfCmd DHParameters
ne produit pas (plus ?) l'effet escompté, et que ça serait la faute à OpenSSL (tous les logiciels serveur sus-cités parviennent à utiliser une directive de configuration séparée pour passer les paramètres DH, mais c'est la faute à OpenSSL… :- ). Source.
Comment tester mes changements ? Ma liste de testeurs de configurations TLS.
https://internet.nl/ permet de tester web et SMTP.
https://xmpp.net/ permet de tester XMPP. Même s'il n'évalue pas la robustesse des paramètres DH, il affiche « Group: draft-ietf-tls-negotiated-ff-dhe-10 ffdhe4096 » quand ils sont utilisés.
Et pour tester IMAP, alors ? Je n'ai pas trouvé d'outil, donc je l'ai fait à la main : openssl s_client -connect <server.example>:143 -starttls imap -tls1_2 -cipher 'DHE' -msg
. « msg » permet d'afficher les messages de la poignée de main TLS. Il suffit de constater que le contenu du message TLS « ServerKeyExchange » a changé… et qu'il contient, en partie, le même contenu que celui de tout serveur utilisant les groupes DH prédéfinis (« ff ff ff ff ff ff ff ff ad f8 54 58 a2 bb 4a 9a af dc 56 20 27 3d 3c f1 d8 b9 », etc.).
J'ai récupéré un ordinateur portable HP Zbook. Entre le touchpad, que j'ai désactivé, et le clavier, il y a trois boutons qui émulent une souris, que je ne parviens pas à désactiver.
Le mode d'emploi m'apprend qu'il s'agit des « {left,center,right} pointing stick buttons » et que le « pointing stick », c'est le nom de la bouboule au centre du clavier, là, typique des Thinkpad.
Listons tous les périphériques d'entrée pour le serveur X :
$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ DELL DELL USB Laser Mouse id=10 [slave pointer (2)]
⎜ ↳ PS/2 Generic Mouse id=12 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=14 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Video Bus id=7 [slave keyboard (3)]
↳ Video Bus id=8 [slave keyboard (3)]
↳ Sleep Button id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=11 [slave keyboard (3)]
↳ HP WMI hotkeys id=13 [slave keyboard (3)]
Si xinput
n'est pas installé, il est dans le paquet logiciel du même nom dans Debian stable.
Au préalable, j'avais regardé la sortie de lsusb
(il y avait rien) et j'avais consulté mes journaux /var/log/kern.log
, mais le plus ancien était postérieur au démarrage de mon ordi, donc il ne pouvait pas consigner l'initialisation du matériel au démarrage.
Dans la rubrique pointeurs, je vois ma souris externe USB (« DELL USB Laser Mouse »), mon Touchpad, et une souris PS/2 (« PS/2 Generic Mouse »).
Le TouchPad est bien désactivé (14 = id du périphérique) :
$ xinput list-props 14 | grep 'Device Enabled'
Device Enabled (156): 0
En revanche, la souris PS/2 est activée. Désactivons-la :
$ sudo xinput --set-prop 12 "Device Enabled" 0
(Oui, xinput disable 12
est plus concis.)
Le pointeur est bien désactivé, et les trois boutons aussi. \o/
Comment rendre ça permanent ? Dans la configuration du serveur X, bien entendu (source).
J'ai créé le fichier /etc/X11/xorg.conf.d/guigui-disable-pointing-stick-buttons.conf
(mon pseudo dans le nom, c'est pour me souvenir que ce fichier est mon œuvre) avec le contenu suivant :
Section "InputClass"
Identifier "disable pointing stick"
MatchProduct "PS/2 Generic Mouse"
Option "Ignore" "true"
EndSection
Attention, ce bloc va ignorer tous les périphériques d'entrée dont le nom est « PS/2 Generic Mouse ». ;) Je pourrais être plus précis, il existe d'autres directives « Match* », mais boarf, la probabilité de me retrouver avec une souris PS/2 sur un ordinateur dépourvu d'un tel port est faible. :)
Alors que Johndescs relisait mes plaintes auprès de la CNIL, il me demanda ce que l'on peut faire.
Ben. Comme d'hab. C'est-à-dire :
Non. Plus les plaintes sont nombreuses pour un même acteur, plus la CNIL priorisera son action et ajustera sa sanction (XXXX personnes qui se signalent incitent à plus de sévérité que XXXX victimes théoriques / potentielles).
Il est tentant de vouloir diviser le travail afin de couvrir plus de terrain (= porter plainte contre + d'acteurs), mais je pense que la meilleure stratégie à l'heure actuelle est de faire nombre.
Non. Agis contre ce qui t'arrive et/ou que tu aimerais voir changer.
Le plus simple :
(Pour retrouver toi-même ce formulaire depuis la page d'accueil du site web de la CNIL : « Découvrez nos moyens d'actions », « Adressez une plainte à la CNIL », dérouler le point 2 (« Préparez et envoyez votre plainte à la CNIL »), « Accéder au service de plainte en ligne », « Autre cas », « service d’aide en ligne », « Autres » (mais peu importe), « Transférer des données personnelles hors de l'Union Européenne, c'est possible ? » (mais peu importe), « adresser votre plainte ». Ouf \o/
Ce genre de procédure à rallonge, avec trouzemilles clics, dissuade de porte plainte. C'est fait à dessein et c'est dommage. :( )
ÉDIT DU 28/11/2022 : j'ajoute la section « Conseils » ci-dessous. FIN DE L'ÉDIT DU 28/11/2022.
Même topo que d'habitude : le site web de la DGFIP (www.impots.gouv.fr) et son espace particuliers embarquent des scripts, des feuilles de style, des images, etc. hébergées sur des serveurs informatiques, un CDN, détenus par des sociétés de droit états-unien, ce qui est incompatible avec le RGPD. L'espace particuliers et l'espace professionnels téléchargent également l'outil de mesure des audiences Xiti (de la société commerciale française AT Internet) depuis une société commerciale états-unienne. Juste pour rire jaune : la DGFIP est rattachée au sinistère de l'Économie, des finances et de la souveraineté industrielle et numérique. Tartufes…
Du coup, hop, plainte à la CNIL.
Le raisonnement juridique reste inchangé depuis les fois précédentes.
Nouveauté : je tente d'expliquer simplement les différents types de CDN, car, pour la première fois depuis le début de mes plaintes CNIL, c'est le responsable du traitement (le fisc) qui a recours à un CDN et pas l'un de ses "sous-traitants" (Google Fonts, cdnjs, etc.), donc ça me servira dans de futures plaintes. Je différencie un CDN qui héberge une copie du contenu (et accède, de ce fait, aux entêtes HTTP et donc à l'ensemble des données personnelles) d'un CDN qui nettoie les communications, comme les atténuateurs DDoS et les optimisateurs BGP, sans pour autant accéder aux entêtes HTTP (mais qui voient tout de même passer l'adresse IP, donnée personnelle s'il en est) ni les consigner.
ÉDIT DU 23/11/2022 : en novembre 2022, j'ai déposé un complément afin d'exposer que Xiti est probablement soumise au CLOUD Act. FIN DE L'ÉDIT DU 23/11/2022.
Merci à Aeris et à Johndescs pour leur relecture. Merci à Aeris de défricher le terrain (c'est lui qui a débusqué quasiment toutes les décisions que je cite).
Ma plainte à la CNIL :
ÉDIT DU 25/11/2022 : Elle contient au moins une erreur : c'est dans sa décision du 22/04/2022 que l'APD autrichienne rappelle que le RGPD ne prévoit pas d'approche basée sur le risque en matière de transferts de données personnelles hors de l'UE, pas dans sa décision 2021-0.586.257 (qui en est tout de même la première partie du film). FIN DE L'ÉDIT.
Elle contient une erreur : la décision TS 1039/2022 est celle du tribunal suprême espagnol, pas de l'APD espagnole.
Bonjour,
Le site web de la Direction Générale des Finances Publiques (https: //www.impots.gouv.fr) ainsi que son espace dédié aux particuliers (https: //cfspart.impots.gouv.fr) enfreignent le RGPD pour les motifs suivants :
- Téléchargement automatique de l'outil de mesure des audiences Xiti de la société commerciale française AT Internet. Cela se produit aussi sur l'espace dédié aux professionnels (https: //cfspro.impots.gouv.fr). Or, pour héberger son produit, AT Internet a recours aux services d'hébergement informatique de la société commerciale Amazon. Donc, le téléchargement de Xiti, indépendamment de la collecte de données personnelles effectuée par l'outil Xiti en lui-même (qui n'est pas le sujet de la présente), constitue de facto un transfert illégal de données personnelles vers les États-Unis au regard de l'arrêt dit Schrems II de la CJUE, de la décision 3_O_17493/20 de la Cour régionale de Munich, de votre mise en demeure du 10/02/2022 relative à l'utilisation de Google Analytics, de la décision 2020-1013 de l'EDPS, et de la décision 2021-0.586.257 de l'Autorité de Protection des Données (APD) autrichienne ;
- Téléchargements automatiques de ressources web (images, feuilles de style, scripts JavaScript, etc.) hébergées sur l'infrastructure informatique de la société commerciale de droit états-unien Edgecast Networks (qui semble elle-même la déléguer à la société commerciale Microsoft et à son produit Azure). Ces téléchargements constituent de facto des transferts illégaux de données personnelles vers les États-Unis au regard des mêmes décisions qu'au point précédent ;
Vous trouverez, en PJ, ma plainte détaillée.
Je vais signaler, au DPO du ministère de l'Économie, des finances et de la souveraineté industrielle et numérique, les manquements au RGPD énumérés dans la présente afin qu’il s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’il entreprendrait, les faits relatés ci-dessus constituent en soi des violations du RGPD qui justifient à elles seules le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes (article 77 du RGPD et décision TS 1039/2022 de l’APD espagnole).
Cordialement.
Plainte détaillée (la fameuse pièce jointe du blabla ci-dessus) :
Bonjour,
Le site web de la Direction Générale des Finances Publiques (www.impots.gouv.fr) ainsi que son « espace particulier » (cfspart.impots.gouv.fr) contreviennent au RGPD sur deux points.
Premier point. Lors de sa consultation, cet espace personnel, tout comme l’espace professionnel (cfspro.impots.gouv.fr), fait automatiquement télécharger, au navigateur web du contribuable, un script JavaScript (depuis logs1407.xiti.com avant authentification et depuis logs2.xiti.com après) propriété de la société commerciale française AT Internet. Or, cette dernière a recours au service de diffusion de contenus (CDN) de la société commerciale états-unienne Amazon.
Comme l’ont jugé la Cour de Justice de l’Union européenne (arrêt C-311/18 dit « Schrems II ») et la Cour régionale de Munich (décision 3_O_17493/20), et comme vous l’avez analysé (mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics), ces téléchargements en eux-mêmes génèrent de facto un transfert hors de l’Union européenne (UE) de plusieurs données personnelles du contribuable : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de ses consultations de l’espace personnel du fisc (les entêtes HTTP Referer et CORS Origin consignent pour le compte de quel site une ressource web externalisée est téléchargée), la marque et le modèle de son navigateur web (entête HTTP User-Agent), etc.
Ces données personnelles renforcent entre elles leur caractère discriminant / individualisant (voir l’étude Panopticlick de l’Electronic Frontier Foundation qui, depuis plus d’une décennie, identifie de manière unique un navigateur web à partir, entre autres, des entêtes sus-mentionnés) et rendent identifiable une personne, surtout par un acteur hégémonique qui, par sa présence sur de nombreux sites web, peut suivre une personne entre les sites web et parvenir à l’identifier. On retrouve cette analyse dans votre mise en demeure du 10 février 2022 concernant l’utilisation de Google Analytics.
Jusqu’à présent, j’ai évoqué les données personnelles transférées automatiquement lors du téléchargement de l’outil Xiti lui-même, pas la collecte et le traitement des données personnelles effectués par cet outil pour la finalité de mesure de l’audience. Mais, il est évident que cette deuxième collecte de données personnelles transite également par le CDN d’Amazon, comme le reconnaît AT Internet (j’y reviendrai). Il est impossible de dire, techniquement, depuis l’extérieur et en dehors des déclarations d’AT Internet, où est effectué le traitement réalisé par l’outil Xiti et où sont stockées les analyses qu’il produit, donc ça ne sera pas le sujet de la présente.
Il existe plusieurs modes de fonctionnement d’un CDN :
- Dans le premier, le CDN est uniquement un intermédiaire de transport, c’est-à-dire qu’il n’est pas destinataire des communications, donc il les répartit, sans les déchiffrer ni accéder à la requête web, sur un ensemble de serveurs appartenant au client final. Il reçoit alors uniquement l’adresse IP du visiteur et le nom du site web de destination, mais pas les entêtes HTTP sus-référencées ;
- Dans l’autre mode de fonctionnement, bien plus courant, le CDN possède le contenu à servir, il est le destinataire des communications, donc il les déchiffre, il accède à la requête web, il reçoit et consigne (journalise) les entêtes HTTP sus-énumérées, et il distribue le contenu web au visiteur.
Dans le cas présent, il s’agit du deuxième mode : Amazon est destinataire de la communication, elle reçoit les entêtes HTTP, et elle distribue le contenu en ajoutant des entêtes HTTP (« x-cache », « x-amz-cf-pop », « x-amz-cf-id »), ce qui démontre qu’elle a bien eu accès à la requête (et à la réponse) web.
D’après l’article 44 du RGPD, seules une décision d’adéquation (article 45 du RGPD), des garanties appropriées (articles 46 et 47 du RGPD) ou des exceptions (consentement ou exécution du contrat, les autres dispositions de l’article 49 du RGPD ne sont pas applicables dans le présent contexte) peuvent autoriser ces transferts de données personnelles en dehors de l’UE.
À ce jour, il n’existe plus de décision d’adéquation entre l’UE et les États-Unis, l’arrêt Schrems II de la Cour de Justice de l’Union européenne (CJUE) ayant invalidé la dernière décision, le Privacy Shield.
Comme l’EDPS (décision numéro 2020-1013) et vous-même (mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’analysez, les clauses contractuelles types, et toutes les garanties appropriées ont été indirectement invalidées par l’arrêt Schrems II de la CJUE au motif de la surveillance de l’État fédéral états-unien, de l’absence de recours effectif et de l’absence de démonstration de l’efficacité à garantir un niveau de protection adéquat au droit de l’UE de toute mesure contractuelle, organisationnelle ou technique.
Dans sa politique de confidentialité (https://cfspart.impots.gouv.fr/enp/ensu/confidentialite.do ), la Direction Générale des Finances Publiques (DGFIP) ne mentionne pas ce transfert de données personnelles à destination des États-Unis. De ce fait, elle ne mentionne pas non plus avoir recours à des instruments juridiques et/ou à des mesures supplémentaires prévus aux articles 46 et 47 du RGPD.
Dans sa politique de confidentialité (https://www.atinternet.com/rgpd-et-vie-privee/collecte-de-donnees-sur-les-sites-de-nos-clients/#traitees-et-stockees), AT Internet, le prestataire de la DGFIP, déclare « Toutes les données d’audience sont stockées et traitées en Union Européenne. Nous utilisons un réseau de diffusion de contenu (CDN) pour améliorer la performance du temps de collecte des données. ». Ainsi, elle ne mentionne pas avoir recours à des instruments juridiques ni à des mesures supplémentaires prévus aux articles 46 et 47 du RGPD.
On peut avoir la certitude que la DGFIP met en œuvre aucune mesure technique complémentaire, car son site web inclut une instruction technique ordonnant au navigateur web du contribuable le téléchargement d’une image directement auprès de l’infrastructure technique du CDN états-unien choisi par AT Internet, Amazon. Dès lors, la requête de téléchargement émise par le navigateur web du contribuable ne chemine pas par l’infrastructure technique de la DGFIP ni par celle de son prestataire (dit autrement, il y a un contact direct entre le terminal du contribuable et les serveurs informatiques du prestataire états-unien de AT Internet), donc elle échappe totalement à la DGFIP et à son prestataire direct, qui peuvent, de ce seul fait, prendre aucune mesure technique.
Comme l’analyse l’autorité de protection des données personnelles autrichienne (décision numéro 2021-0.586.257), le RGPD ne prévoit pas d’approche fondée sur les risques en matière de transfert de données personnelles à un pays tiers non adéquat.
La DGFIP (et AT Internet) ne recueille pas explicitement le consentement du contribuable pour le transfert de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ce transfert peut comporter pour lui, comme l’impose l’article 49.1a du RGPD, donc, en l’état, ce transfert ne peut pas reposer sur le consentement.
La nécessité du transfert des données personnelles sus-énumérées aux États-Unis au motif de l’exécution du contrat (article 49.1b du RGPD) est irrecevable, car un outil de mesure d’audience (c’est ainsi qu’il est présenté par son éditeur, AT Internet, et par la politique de confidentialité de la DGFIP sus-référencée) ne peut pas être regardé comme étant nécessaire à l’exécution d’un contrat, car le service peut être fourni sans : si l’on bloque les requêtes web de téléchargement de cet outil avec l’extension pour navigateur web uMatrix, par exemple, le site web de la DGFIP reste intégralement fonctionnel.
Quel est l’intérêt réel d’une mesure de l’audience sur un espace personnel dédié à des démarches administratives légalement obligatoires ? L’audience est connue d’avance et la popularité d’une démarche parmi celles proposées n’a pas de signification particulière (c’est obligatoire, ce n’est pas un produit parmi d’autres).
En tout état de cause, il est techniquement possible de réaliser une mesure des audiences sans transférer des données personnelles à des sociétés tierces hébergées (techniquement) aux États-Unis. Plusieurs sociétés commerciales européennes proposent ce type de solutions, y compris en s’appuyant sur un CDN de droit européen. En dernier ressort, ces solutions peuvent être internalisées (hébergées sur les infrastructures techniques de la DGFIP). Le recours à un CDN états-unien constitue un déséquilibre fort entre le faible intérêt, pour la DGFIP, d’effectuer ce traitement de mesure d’audience, et l’atteinte disproportionnée aux droits des contribuables qu’il représente.
Le téléchargement automatique de l’outil de mesure d’audience Xiti de la société AT Internet lors de l’utilisation de l’espace personnel ou de l’espace professionnel du site web de la DGFIP, et le transfert de données personnelles vers les États-Unis qui en découle est donc illégal.
Deuxième point. Sur plusieurs pages de l’« espace particulier » du site web de la DGFIP (correction en ligne de la déclaration automatique de revenus, gestion du prélèvement à la source, paiement des impôts, etc.), des ressources web (images, feuilles de style, scripts JavaScript, etc.) sont téléchargées depuis le sous-domaine « static.impots.gouv.fr » (dont un autre nom est « static-impots.dgfip.cdn-tech.net », dont le vrai nom est « cs1003.wpc.omicroncdn.net »).Son hébergement semble être délégué à la société commerciale française Écritel (qui a racheté, en 2016, CDN Technologies, cdn-tech.net) qui semble l’avoir délégué à la société commerciale états-unienne Omicron Media (omicroncdn.net), qui elle-même utilise le réseau de distribution de contenus (CDN) de la société commerciale états-unienne Edgecast Networks (ci-après Edgecast). Il en est de même pour le site web www.impots.gouv.fr (page d’accueil, documentation / foire aux questions, etc.).
Comme au premier point, nous sommes en présence d’un type de CDN qui est destinataire des requêtes web, qui y répond directement en servant le contenu, qui, de ce fait, accède aux entêtes HTTP et donc à l’ensemble des données personnelles énumérées au premier point. Pour preuve, il dépose, dans la réponse, un entête « server » dont la valeur est, ce jour, « ECAcc (ama/8B6F) » (« ECAcc » = Microsoft Azure, « ama » est la zone géographique, suivie d’un identifiant unique du serveur).
Le raisonnement est similaire à celui déroulé au premier point : ces téléchargements, déclenchés automatiquement lors de la consultation de l’espace personnel de la DGFIP, génèrent des transferts de données personnelles (liste dans le premier grief) à destination des États-Unis ; il n’existe plus de décision d’adéquation entre l’UE et les États-Unis ; toutes les garanties appropriées, et les mesures complémentaires sont irrecevables ; et le consentement du contribuable (au sens de l’article 49.1a du RGPD) n’est pas recueilli.
La nécessité du transfert des données personnelles au motif de l’exécution d’un contrat (article 49.1b du RGPD) et/ou d’une mission de service public n’est pas recevable :
- De ce que j’en connais, la DGFIP ne semble pas avoir recours à un quelconque CDN externalisé sur l’espace dédié aux professionnels (cfspro.impots.gouv.fr) ;
- La DGFIP n’a pas recours à un CDN sur toutes les pages de son espace particulier dont on peut pourtant prédire qu’elles reçoivent la même quantité de trafic et dont la tenue de la charge est tout aussi indispensable pour le bon déroulement des démarches administratives. Exemples : le portail d’authentification ou le tableau de bord après authentification, sans lesquels l’accès au service (et donc les démarches administratives) est impossible. La nécessité d’un CDN sur des pages consultées dans un deuxième temps par les contribuables n’est donc pas démontrée ;
- D’une manière générale, les ressources web statiques (images, feuilles de style, scripts) peuvent être mises en cache du côté des serveurs informatiques et du côté des navigateurs web (et ainsi soulager une infrastructure d’hébergement web et les réseaux de communication), alors que les pages web elles-mêmes, le texte, sont générées dynamiquement à la volée pour chaque contribuable (en fonction de sa situation, de ses informations fiscales, etc.) et elles ne peuvent pas être mises en cache (ou de manière limitée), ce qui nécessite la détention d’une capacité de traitement. Or, pour ces pages, la DGFIP n’a pas recours à un prestataire. Il y a donc une incohérence : qui peut le plus peut le moins ;
- En tout état de cause, des sociétés commerciales françaises et européennes proposent des réseaux de distribution de contenus équivalents. La DGFIP ne saurait justifier du recours à un CDN international pour offrir une qualité de service satisfaisante aux seuls contribuables français, y compris à la minorité de Français qui résident en dehors du territoire national. Dit autrement : la solution technique retenue n’est pas en adéquation avec le besoin réel.
- De plus, le recours à un CDN états-unien constitue un déséquilibre fort entre le faible intérêt technique dont peut se prévaloir la DGFIP (voir points précédents) et l’atteinte disproportionnée aux droits des contribuables que ce choix de prestataire représente ;
- Enfin, ce choix de prestataire fait mauvais genre dans le contexte actuel de souveraineté numérique (le nom du ministère de rattachement de la DGFIP est « ministère de l’Économie, des finances et de la souveraineté industrielle et numérique » !), de cloud souverain, de la doctrine étatique « Cloud au Centre », des recommandations et des notes de la Direction interministérielle du numérique à ce sujet, etc.
Lors de la navigation sur le site web www.impots.gouv.fr et sur l’« espace particulier » du site web de la DGFIP, le téléchargement automatique de ressources web (images, feuilles de style, scripts JavaScript, etc.) hébergées sur des infrastructures techniques situées aux États-Unis et/ou détenues par des organisations de droit états-unien, et le transfert de données personnelles vers les États-Unis qui en découle, est donc illégal.
Je vais signaler, au DPO du ministère de l’Économie, les manquements au RGPD énumérés dans la présente afin qu’il s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’il entreprendrait, les faits relatés ci-dessus constituent en soi des violations du Règlement qui justifient à elles seules le dépôt d’une plainte auprès de l’autorité de contrôle que vous êtes (article 77 du RGPD et décision TS 1039/2022 de l’APD espagnole).Cordialement.
ÉDIT DU 23/11/2022 :
Complément déposé en novembre 2022 :
Bonjour,
Dans ma plainte, je mentionne l'utilisation, par la DGFIP, de l'outil de mesure d'audience Xiti de la société commerciale AT Internet en indiquant qu'il est automatiquement téléchargé depuis les serveurs informatiques de la société commerciale états-unienne Amazon (comme l'indique elle-même AT Internet sur son site web), ce qui constitue un contact direct entre le terminal du contribuable et les serveurs d'Amazon qui génère un transfert de données personnelles (adresse IP, marque, modèle et paramètres du terminal, données collectées par Xiti, etc.) vers Amazon et donc vers les États-Unis.
En sus, depuis mars 2021, l’unique actionnaire d'AT Internet est la société commerciale états-unienne Piano Software Inc. (cf. https://www.atinternet.com/presses/at-internet-sassocie-a-piano-pour-creer-la-premiere-plateforme-dexperience-client-basee-sur-lanalyse-contextuelle/). Cette dernière est toujours immatriculée dans le Delaware (cf. https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx) et elle dispose toujours de plusieurs bureaux aux États-Unis (cf. https://resources.piano.io/about/). Le mémorandum concernant l’application du Cloud Act à des entités européennes commandé par le ministère de la Justice des Pays-Bas (https://www.ncsc.nl/documenten/publicaties/2022/augustus/16/cloud-act-memo) tend à montrer que, de ces faits, AT Internet est soumise au Cloud Act. Votre analyse appuyant votre mise en demeure du 10 février 2022 portant sur l’utilisation de Google Analytics est de pleine application ici.
Bonne journée.
FIN DE L'ÉDIT du 23/11/2022.
Même topo que d'habitude : le site web de La Poste embarque trouzemilles tonnes de scripts, de polices de caractères, de feuilles de style, d'images, etc. hébergées sur des serveurs informatiques détenus par une palanquée de sociétés de droit états-unien, ce qui est incompatible avec le RGPD. L'outil de suivi d'un envoi est dysfonctionnel sans le téléchargement d'un outil de ciblage, de traque, et de suivi du parcours client (il est ainsi présenté par son éditeur) hébergé sur les serveurs informatiques d'une société commerciale états-unienne. Ils ont belle mine, l'ancrage local de La Poste et le symbole de la France du terroir d'autrefois, non ?
Du coup, hop, plainte à la CNIL. Aeris en a fait de même fin juillet.
Le raisonnement juridique reste identique aux fois précédentes.
Nouveautés :
ÉDIT DU 23/11/2022 : en novembre 2022, j'ai déposé un complément afin d'exposer que Xiti est probablement soumise au CLOUD Act. FIN DE L'ÉDIT DU 23/11/2022.
Merci à Aeris et à Johndescs pour leur relecture. Merci à Aeris de défricher le terrain (c'est lui qui a débusqué quasiment toutes les décisions que je cite).
Ma plainte à la CNIL :
ÉDIT DU 25/11/2022 : Elle contient au moins une erreur : c'est dans sa décision du 22/04/2022 que l'APD autrichienne rappelle que le RGPD ne prévoit pas d'approche basée sur le risque en matière de transferts de données personnelles hors de l'UE, pas dans sa décision 2021-0.586.257 (qui en est tout de même la première partie du film). FIN DE L'ÉDIT.
Elle contient une erreur (en plus d'une faute de frappe) : la décision TS 1039/2022 est celle du tribunal suprême espagnol, pas de l'APD espagnole.
Bonjour,
Le site web de la société commerciale La Poste (https ://www.laposte.fr/), et notamment son outil de suivi des envois (https ://www.laposte.fr/outils/suivre-vos-envois), enfreint le RGPD pour les motifs suivants :
- Le suivi de courrier dépend du téléchargement automatique et forcé d'un outil de ciblage, de traque, et de suivi du parcours client (présenté en ces teres par son éditeur) hébergé (techniquement, informatiquement) par des sociétés commerciales de droit états-unien. Ce téléchargement constitue de facto un transfert illégal de données personnelles vers les États-Unis au regard de l'arrêt dit Schrems II de la CJUE, de la décision 3_O_17493/20 de la Cour régionale de Munich, de votre mise en demeure du 10/02/2022 relative à l'utilisation de Google Analytics, de la décision 2020-1013 de l'EDPS, de la décision 2021-0.586.257 de l'Autorité de Protection des Données (APD) autrichienne, et des lignes directrices du CEPD 2/2019 sur le traitement des données à caractère personnel au titre de l’article 6, paragraphe 1, point b), du RGPD ;
- Le site web de La Poste dans son ensemble télécharge automatiquement une palanquée de ressources web (scripts JavaScript, polices de caractères, feuilles de style, images, etc.), qui sont la propriétés d'une multitude de sociétés commerciales, et qui sont hébergés (techniquement, informatiquement) par des sociétés commerciales de droit états-unien. Cela constitue des transferts illégaux de données personnelles vers les États-Unis au regard des mêmes décisions qu'au point précédent ;
- L'utilisation, sans consentement, d'un cookie facultatif de suivi du parcours client (selon son éditeur). Absence d'information (seul cookie absent de la politique de confidentialité du site web La Poste). Le bandeau cookie ne permet pas de s'y opposer. Durée de vie (1 an) excessive. Il est transmis à un hébergeur de droit états-unien, ce qui constitue un transfert illégal de données personnelles vers les États-Unis au regard des mêmes décisions qu'aux points précédents.
Vous trouverez, en PJ, ma plainte détaillée.
Je vais signaler, à la DPO de La Poste, les nombreux manquements au RGPD énumérés dans la présente afin qu’elle s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’elle entreprendrait, les faits relatés ci-dessus constituent en soi des violations du RGPD qui justifient à elles seules le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle que vous êtes (article 77 du RGPD et décision TS 1039/2022 de l’APD espagnole).
Cordialement.
Plainte détaillée (la fameuse pièce jointe du blabla ci-dessus) :
Bonjour,
Le site web de La Poste (www.laposte.fr) et notamment sa page de suivi d’un envoi (https ://www.laposte.fr/outils/suivre-vos-envois) contrevient au RGPD sur au moins trois points.
Premier point / grief. L’outil de suivi d’un envoi ne fonctionne pas tant que l’on bloque, avec une extension pour navigateur web telle uMatrix, les requêtes web destinées à la société commerciale française Commanders Act (cdn.tagcommander.com) : l’erreur « tC is not defined » s’affiche lors de la validation du formulaire.Ces requêtes web téléchargent des scripts JavaScript auprès des infrastructures techniques de ladite société. Or, pour son hébergement web, celle-ci a recours aux services des sociétés commerciales de droit états-unien Edgecast Networks et Amazon.
Comme l’ont jugé la Cour de Justice de l’Union européenne (arrêt C-311/18 dit « Schrems II ») et la Cour régionale de Munich (décision 3_O_17493/20) et comme vous l’avez analysé (mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics), ces téléchargements en eux-mêmes génèrent de facto un transfert hors de l’Union européenne (UE) de plusieurs données personnelles du client La Poste (LP) : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de ses consultations du site web LP, les pages du site web LP qu’il a consulté (entêtes HTTP Referer et CORS Origin), la marque et le modèle de son navigateur web (entête HTTP User-Agent), etc. Notons que le site web de LP positionne un entête HTTP « Referrer-Policy » avec la valeur « no-referrer-when-downgrade », ce qui a pour effet d’amoindrir la politique par défaut des navigateurs web modernes et de transmettre aux tiers (prestataires de LP) l’URL complète des pages web du site web LP consultées par le client LP, ce qui permet à ces tiers de suivre la navigation du client LP à travers les différentes rubriques du site web LP.
Ces données personnelles renforcent entre elles leur caractère discriminant / individualisant (voir l’étude Panopticlick de l’Electronic Frontier Foundation qui, depuis plus d’une décennie, identifie de manière unique un navigateur web à partir, entre autres, des entêtes sus-mentionnés) et rendent identifiable une personne, surtout par un acteur hégémonique qui, par sa présence sur de nombreux sites web, peut suivre une personne entre les sites web et parvenir à l’identifier. On retrouve cette analyse dans votre mise en demeure du 10 février 2022 concernant l’utilisation de Google Analytics.
D’après l’article 44 du RGPD, seules une décision d’adéquation (article 45 du RGPD), des garanties appropriées (articles 46 et 47 du RGPD) ou des exceptions (consentement ou exécution du contrat, les autres dispositions de l’article 49 du RGPD ne sont pas applicables dans le présent contexte) peuvent autoriser ces transferts de données personnelles en dehors de l’UE.
À ce jour, il n’existe plus de décision d’adéquation entre l’UE et les États-Unis, l’arrêt Schrems II de la Cour de Justice de l’Union européenne (CJUE) ayant invalidé la dernière décision, le Privacy Shield.
Comme l’EDPS (décision numéro 2020-1013) et vous-même (mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics) l’analysez, les clauses contractuelles types, et toutes les garanties appropriées ont été indirectement invalidées par l’arrêt Schrems II de la CJUE au motif de la surveillance de l’État fédéral états-unien, de l’absence de recours effectif et de l’absence de démonstration de l’efficacité à garantir un niveau de protection adéquat au droit de l’UE de toute mesure contractuelle, organisationnelle ou technique.
Dans sa politique de confidentialité (https://www.laposte.fr/donnees-personnelles-et-cookies), La Poste ne mentionne pas avoir recours à d’autres instruments juridiques que ceux qui viennent d’être énoncés, ni à des mesures supplémentaires. De plus, on peut avoir la certitude que LP met en œuvre aucune mesure technique complémentaire, car son site web inclut une instruction technique ordonnant au navigateur web du client LP le téléchargement de scripts directement auprès de l’infrastructure technique de l’hébergeur informatique états-unien choisi par Commander Act, le prestataire de LP. Dès lors, la requête de téléchargement émise par le navigateur web du client LP ne chemine pas par l’infrastructure technique de LP ni par celle de son prestataire (dit autrement, il y a un contact direct entre le terminal du client LP et les serveurs informatiques du prestataire états-unien de Commander Act), donc elle échappe totalement à La Poste et à son prestataire direct, qui peuvent, de ce seul fait, prendre aucune mesure technique.
Comme l’analyse l’autorité de protection des données personnelles autrichienne (décision numéro 2021-0.586.257), le RGPD ne prévoit pas d’approche fondée sur les risques en matière de transfert de données personnelles à un pays tiers non adéquat.
La Poste ne recueille pas explicitement le consentement de son client pour le transfert de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ce transfert peut comporter pour lui, comme l’impose l’article 49.1a du RGPD. Quand bien même LP le recueillerait, il serait vicié car, en l’absence de TagCommander (nom de l’outil, du script de la société Commanders Act dont il est question depuis le début), l’outil de suivi des envois de LP est totalement inutilisable (impossible d’obtenir le suivi d’un envoi), ce qui contraindrait le client LP à accepter de force le traitement de données personnelles sus-présenté réalisé par l’hébergeur de Commanders Act, et donc le transfert de ses données personnelles aux États-Unis.
La nécessité du transfert des données personnelles sus-énumérées aux États-Unis au motif de l’exécution du contrat (article 49.1b du RGPD) est irrecevable, car un outil de ciblage, de traque, et de suivi du parcours client (c’est ainsi qu’il est présenté par son éditeur, Commanders Act) ne peut pas être regardé comme étant nécessaire à l’exécution d’un contrat. De plus, la requête web qui permet au client LP de fournir le numéro de son envoi via un formulaire, et d’obtenir, en retour, le suivi dudit envoi, est envoyée aux serveurs LP qui opèrent derrière le nom « api.laposte.fr ». Cet échange, et donc le suivi d’un envoi, est indépendant / décoléré / disjoint du script TagCommander qui n’intervient donc pas pour fournir le service. En tout état de cause, il est techniquement possible de proposer le suivi d’un envoi sans transférer des données personnelles à des sociétés tierces hébergées (techniquement) aux États-Unis.
Le téléchargement automatique et obligatoire du script TagCommander de la société Commanders Act, prestataire de La Poste, afin de pouvoir utiliser l’outil de suivi des envois du site web de LP, et le transfert de données personnelles vers les États-Unis qui en découle, est donc illégal.
Deuxième point / grief. La page de suivi d’un envoi du site web de La Poste, et plus généralement le site web de La Poste, fait automatiquement télécharger, au navigateur web du client LP, des ressources web (scripts JavaScript, polices de caractères, feuilles de style, images, etc.) qui sont la propriété de sociétés commerciales de droit européen ou états-unien et qui sont hébergées sur des infrastructures techniques situées aux États-Unis et/ou détenues par des organisations de droit états-unien.Ces téléchargements ont lieu même après le refus, par le client LP, de tous les cookies dans le bandeau dédié, ce n’est pas lié.
L’essentiel du raisonnement est commun à tous les prestataires que je vais énumérer ci-dessous et il est identique à celui exposé dans le premier grief ci-dessus : ces téléchargements, déclenchés automatiquement lors de la consultation du site web LP, génèrent, de facto, des transferts de données personnelles (liste dans le premier grief) à destination des États-Unis ; il n’existe plus de décision d’adéquation entre l’UE et les États-Unis ; toutes les garanties appropriées, et les mesures complémentaires sont irrecevables ; le consentement du client La Poste (au sens de l’article 49.1a du RGPD) n’est pas recueilli et la nécessité du transfert des données personnelles au motif de l’exécution d’un contrat (article 49.1b du RGPD) n’est pas recevable.
Seul le motif de cette irrecevabilité varie en fonction de la ressource web et du prestataire de LP, et c’est ce motif que je vais présenter ci-dessous sans rappeler la partie commune du raisonnement à chaque fois :
- Autres scripts JavaScript de la société commerciale française Commanders Act (trustcommander.net, commander1.com) hébergés par les sociétés commerciales états-uniennes Edgecast Networks et Amazon. Ils sont de plusieurs types : plateforme de gestion du consentement (CMP) d’un côté, suivi et analyse marketing de l’autre. La nécessité du transfert de données personnelles pour l’exécution du contrat est irrecevable : à quoi sert le téléchargement d’images transparentes de dimensions un pixel sur un pixel au format gif lors de la validation du formulaire de suivi d’un envoi (c’est ce qui se produit), si ce n’est à traquer le client La Poste, ce qui a rien à voir avec l’objet du contrat ? De même, il n’est pas nécessaire d’externaliser sa CMP chez un hébergeur / distributeur de contenus (CDN) états-unien : elle peut être hébergée dans l’UE tout en restant externalisée (plusieurs fournisseurs de ce type de solutions procèdent ainsi) ;
- Police de caractères hébergée par le service Google Fonts (fonts.googleapi.com et fonts.gstatic.com) de la société états-unienne Google (ci-après Google). Cette société reconnaît la réception et la conservation, lors de l’utilisation de son service Fonts, des données personnelles énumérées au premier grief (https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users). De plus, sa mise en œuvre des clauses contractuelles types ne couvre pas son service Fonts (https://policies.google.com/privacy/frameworks). La nécessité du transfert pour l’exécution du contrat est irrecevable puisque un hébergement internalisé (sur les infrastructures de La Poste) de la police de caractères est techniquement et juridiquement possible à un coût nul alors que son hébergement par Google porte une atteinte disproportionnée aux droits des clients LP. De même, il est possible d’utiliser un fournisseur européen de polices ou même une police de base embarquée dans tous les navigateurs web. Notons que l’un des prestataires auquel a recours LP, Inbenta, sur lequel je reviendrai, fait également télécharger une police de caractères depuis le service Fonts de Google, donc que le raisonnement qui vient d’être déroulé dans ce point s’y applique ;
- Cours actuel du taux de change de devises présentés au format JSON. Ce fichier est téléchargé par le prestataire Adverline (cdn.adnext.fr), filiale du groupe La Poste (via Mediapost), depuis les infrastructures techniques du projet jsDelivr (jsdelivr.net), mises à disposition par les sociétés commerciales états-uniennes Cloudflare et Fastly. La nécessité du transfert pour l’exécution d’un contrat est irrecevable puisque un hébergement internalisé, sur les infrastructures techniques du prestataire Adverline ou sur celles de LP, de ce fichier JSON est techniquement et juridiquement possible à un coût nul, et que ces données peuvent être récupérées, dans le même format, auprès d’un fournisseur hébergé techniquement dans l’UE. De même, ces informations de conversion sont utiles uniquement pour quelques services précis proposés par LP, donc elles ne devraient pas être téléchargées en dehors / au préalable de l’utilisation de ces services par le client LP ;
- Scripts JavaScript et images de la société commerciale française AB Tasty (abtasty.com) hébergés par la société commerciale états-unienne Cloudflare (ci-après Cloudflare). Il s’agit d’outils de tests A/B, d’analyse et d’optimisation du parcours client. Le Comité européen de la protection des données (CEPD) ne considère pas qu’un traitement destiné à améliorer un service est nécessaire à l’exécution d’un contrat (cf. Lignes directrices 2/2019 sur le traitement des données à caractère personnel au titre de l’article 6, paragraphe 1, point b), du RGPD dans le cadre de la fourniture de services en ligne aux personnes concernées). De plus, des sociétés commerciales européennes proposent un service équivalent depuis des infrastructures situées dans l’UE, et, en dernier ressort, un hébergement internalisé de ce type de solution est techniquement et juridiquement (avec accord de l’éditeur) possible à un coût quasi nul ;
- Scripts Google Tag Manager (googletagservices.com). Un outil de suivi du client et de marketing n’est pas nécessaire à l’exécution du contrat, et des sociétés commerciales européennes proposent un service équivalent ;
- Scripts des sociétés commerciales états-uniennes Heroku (herokuapps.com) et Inbenta (inbenta.io) hébergés par la société commerciale états-unienne Amazon (ci-après Amazon). Un outil d’assistance au client et de foire aux questions n’est pas nécessaire à l’exécution du contrat, et des sociétés commerciales européennes proposent un service équivalent. Le chargement de l’outil d’Inbenta provoque, en cascade, le téléchargement d’une police de caractères auprès de Google Fonts, ce qui constitue un deuxième transfert illégal des mêmes données personnelles (lire ci-dessus l’analyse concernant Google Fonts) ;
- Scripts, feuilles de style et images de la société commerciale française PubStack (pbstck.com) hébergés par Cloudflare. Un outil d’analyse des revenus publicitaires et de gestion de la publicité n’est pas nécessaire à l’exécution d’un contrat portant sur un service payant (dont la contrepartie n’est pas l’affichage de publicités, s’entend), et des sociétés commerciales européennes hébergées sur des infrastructures situées dans l’UE proposent un service équivalent ;
- Scripts Xiti de la société commerciale française AT Internet (logs4.xiti.com) hébergés par Amazon (CDN, https://www.atinternet.com/rgpd-et-vie-privee/collecte-de-donnees-sur-les-sites-de-nos-clients/#traitees-et-stockees). Un outil d’analyse des audiences n’est pas nécessaire à l’exécution du contrat, et il est possible d’héberger ce type de solutions sur des infrastructures situées dans l’UE (des concurrents d’AT Internet le proposent) ou en interne de LP ;
- Scripts Google Maps (maps.googleapis.com). Un outil de cartographie n’est pas nécessaire à l’exécution du contrat (proposer une localisation est une fonctionnalité supplémentaire), et des sociétés commerciales européennes proposent un service équivalent hébergé sur des infrastructures européennes ;
- Scripts de la société commerciale états-unienne BazaarVoice (bazaarvoice.com) hébergés par Amazon. Un outil d’affichage de l’avis des clients concernant les produits La Poste et un outil de production de statistiques (https ://analytics-static.ugc.bazaarvoice.com/prod/static/latest/bv-analytics.js) ne sont pas nécessaires à l’exécution du contrat, et des sociétés commerciales européennes proposent un service équivalent hébergé techniquement dans l’UE ;
- Scripts Google DoubleClick. Une régie publicitaire n’est pas nécessaire à l’exécution d’un contrat payant (dont la contrepartie n’est pas l’affichage de publicités, s’entend), surtout quand il recouvre une mission de service public. De plus, plusieurs sociétés commerciales européennes proposent un service équivalent hébergé techniquement dans l’UE (certes moins rentable) ;
- Les autres régies publicitaires et prestataires assimilés (Adnxs, Criteo, Adscale, SmartAdserver, etc.) intégrés sur le site web de LP sont totalement inhibées (aucune requête est émise) tant que le client LP n’a pas exprimé son consentement dans le bandeau cookies. Concernant les scripts de DoubleClick, de PubStack, et d’une bonne partie des prestataires qui viennent d’être énumérés, qui sont téléchargés par défaut et qui continuent à l’être après le refus de tous les cookies, peut-être s’agit-il d’un oubli dans la configuration et/ou le code du site web LP de les inhiber tant que le client LP n’a pas accepté ? ;
- Je n’ai pas vérifié la conformité au présent grief (transfert illégal de données personnelles vers les États-Unis) des très (trop) nombreuses régies publicitaires et prestataires assimilés utilisées par LP sur son site web (après consentement du client, cf. point précédent). Je n’ai pas l’énergie pour ce faire.
Lors de la navigation sur le site web de La Poste, le téléchargement automatique de ressources web (scripts JavaScript, polices de caractères, feuilles de style, images, etc.), propriétés de prestataires européens ou états-uniens de La Poste et hébergées sur des infrastructures techniques situées aux États-Unis et/ou détenues par des organisations de droit états-unien, et le transfert de données personnelles vers les États-Unis qui en découle est donc illégal.
Les multiples transferts auprès de (trop) nombreuses organisations états-uniennes aggrave le manquement au RGPD, surtout qu’il est commis par une société commerciale chargée d’une mission de service public jouissant d’un ancrage local et d’une image « France du terroir d’autrefois ». La divergence entre l’image dont se prévaut La Poste et ses actes sus-énumérés constitue un abus de confiance caractérisé.
Troisième et dernier point / grief. En naviguant sur la page de suivi d’un envoi du site web de La Poste, et plus généralement sur le site web de LP, et avant le recueil du consentement du client LP, un cookie tiers est déposé (et lu) par l’un des prestataires de LP, la société commerciale française Commanders Act (commader1.com) pourtant fournisseuse de la plateforme de gestion du consentement utilisé par LP. Nom de ce cookie : « tc_cj_v2 ».Même après le refus de tous les cookies dans le bandeau dédié, Commanders Act (commander1.com) continue de le lire et de le déposer sur le terminal du client La Poste, notamment lors de l’utilisation de l’outil de suivi des envois.
Il découle du deuxième grief, que ce cookie transite par la société commerciale de droit états-unien Amazon, puisque la française Commanders Act a recours à ses prestations d’hébergement.
Contrairement aux autres cookies, celui-ci n’est pas consigné dans la politique de confidentialité de La Poste (https://www.laposte.fr/information-sur-les-cookies).
Ce cookie, d’une durée de vie d’un an (ce qui est excessif au regard de sa finalité que l’on va découvrir), ne peut pas être regardé comme étant nécessaire à la fourniture du service ni comme facilitant la communication électronique :
- Le site web de LP, et notamment le formulaire de suivi d’un envoi, reste totalement fonctionnel si l’on bloque l’utilisation de ce cookie et/ou les requêtes web destinées à « *.commander1.com » (avec l’extension pour navigateur web uMatrix, par exemple) : on obtient bien le suivi de son envoi ;
- Il est lu et déposé lors du téléchargement d’images transparentes de dimensions un pixel sur un pixel au format gif, autrement dit d’images invisibles. Il s’agit d’une méthode habituellement utilisée pour traquer les visiteurs d’un site web ;
- Dans sa documentation (https://community.commandersact.com/platform/knowledge-base/cookies), la société Commanders Act explique que ce cookie est « Used for user customer journey storage for tag deduplication (channel and source storage). ». Il s’agit donc bien d’un cookie de suivi du parcours client.
On notera que le refus de tous les cookies et l’absence de consentement produit bien l’effet escompté (aucun dépôt de cookie) sur la palanquée de régies publicitaires et assimilées. Peut-être que l’inhibition de ce cookie a été oubliée dans la configuration et/ou dans le code du site web LP ?
L’utilisation d’un cookie tiers par un prestataire de La Poste lors de la consultation du site web de LP, et notamment lors de l’utilisation de l’outil de suivi d’un envoi, est donc illégale : cookie facultatif déposé et lu par défaut (opt-in), absence d’information, impossible de s’y opposer, transfert illégal aux États-Unis.
Je vais signaler, à la DPO de La Poste, les nombreux manquements au RGPD énumérés dans la présente afin qu’elle s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’elle entreprendrait, les faits relatés ci-dessus constituent en soi des violations du Règlement qui justifient à elles seules le dépôt d’une plainte auprès de l’autorité de contrôle que vous êtes (article 77 du RGPD et décision TS – 1039/2022 de l’APD espagnole).Cordialement.
ÉDIT DU 23/11/2022 :
Complément déposé en novembre 2022 :
Bonjour,
Dans ma plainte, je mentionne l'utilisation, par La Poste, de l'outil de mesure d'audience Xiti de la société commerciale AT Internet en indiquant qu'il est automatiquement téléchargé depuis les serveurs informatiques de la société commerciale états-unienne Amazon (comme l'indique elle-même AT Internet sur son site web), ce qui constitue un contact direct entre le terminal du client La Poste et les serveurs d'Amazon qui génère un transfert de données personnelles (adresse IP, marque, modèle et paramètres du terminal, données collectées par Xiti, etc.) vers Amazon et donc vers les États-Unis.
En sus, depuis mars 2021, l’unique actionnaire d'AT Internet est la société commerciale états-unienne Piano Software Inc. (cf. https://www.atinternet.com/presses/at-internet-sassocie-a-piano-pour-creer-la-premiere-plateforme-dexperience-client-basee-sur-lanalyse-contextuelle/). Cette dernière est toujours immatriculée dans le Delaware (cf. https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx) et elle dispose toujours de plusieurs bureaux aux États-Unis (cf. https://resources.piano.io/about/). Le mémorandum concernant l’application du Cloud Act à des entités européennes commandé par le ministère de la Justice des Pays-Bas (https://www.ncsc.nl/documenten/publicaties/2022/augustus/16/cloud-act-memo) tend à montrer que, de ces faits, AT Internet est soumise au Cloud Act. Votre analyse appuyant votre mise en demeure du 10 février 2022 portant sur l’utilisation de Google Analytics est de pleine application ici.
Bonne journée.
FIN DE L'ÉDIT du 23/11/2022.
Depuis le début de l'année 2022, Twitter impose de se connecter quand on scrolle "trop" dans un fil.
Depuis lors, j'utilise les règles uBlock Origin suivantes :
twitter.com##.r-1upvrn0.r-l5o3uw.css-1dbjc4n
twitter.com##div[role='dialog']
twitter.com##[id$='PromoSlot']
twitter.com##html->body:style(overflow:visible !important;)
twitter.com##html:style(overflow:visible !important;)
Parfois, ça ne fonctionne pas : je vois, dans l'URL, que Twitter a tenté de me rediriger vers la mire de connexion, mais un simple retour en arrière suivi d'un « F5 » suffit à tout remettre en ordre.