GuiGui's Show

Depuis sa version 78, Thunderbird dispose de sa propre implémentation interne d'OpenPGP pour le chiffrement des emails. Il n'utilise plus GnuPG via l'excellente extension Enigmail.

Cette implémentation interne ne répond pas à mes attentes sur six points :

• Il faut définir un mot de passe principal pour le gestionnaire de mots de passe interne à Thunderbird. Sinon, la phrase de passe de la clé OpenPGP est stockée en clair dans le profil Thunderbird. Lire ici. Une phrase de passe pour en protéger une autre… … … ;
  
  
• La phrase de passe du gestionnaire de mots de passe de Thunderbird est conservée en RAM depuis sa saisie jusqu'à la fermeture de Thunderbird. Pour les personnes qui utilisent l'hibernation ou le suspend-to-ram de leur système, ça signifie qu'elle est toujours en RAM. L'agent GnuPG permettait, lui, de configurer la durée de conservation en RAM ;
  
  
• Si l'on utilise sa clé OpenPGP pour d'autres usages que l'email avec Thunderbird, deux trousseaux de clés hermétiques cohabitent : celui interne à Thunderbird et celui de GnuPG. Il faut donc mettre à jour la clé de ses contacts deux fois (dans Thunderbird et dans GnuPG), repousser deux fois la date d'expiration de sa propre clé (pour éviter les erreurs, je repousse l'expiration depuis GnuPG, j'exporte ma clé privée sous forme de fichier, je l'importe dans le gestionnaire de clés OpenPGP de Thunderbird), etc. C'est relou ;
  
  
• Absence d'une option dans l'interface permettant d'associer une clé de chiffrement précise à une adresse emails. C'est nécessaire quand un correspondant n'a volontairement pas déclaré une adresse emails dans les identités de sa clé OpenPGP (vie privée, tout ça) et/ou quand il utilise des adresses emails contenant un délimiteur / tag (on peut donc avoir une adresse emails par couple { destinataire ; sujet de la causerie }, très pratique pour trier automatiquement ses emails et prioriser leur lecture). Une solution peu intuitive existe, mais ce n'est pas optimal… ;
  
  
• Pour chercher une clé sur un serveur de clés, Thunderbird utilise le protocole VKS. Pas moyen d'utiliser le traditionnel HKP / HKPS. Or, à ce jour, un seul serveur VKS semble être disponible, celui d'OpenPGP.org. Résilience ? Pas cool. D'autant que tout le monde n'est pas sur ce serveur, et il faut alors télécharger la clé en web ou avec GnuPG et l'importer dans Thunderbird… Note : VKS est, un peu, une API HTTPS, donc, si comme moi tu désactives les autorités de certification x509 inutiles, penses à activer celle de Let's Encrypt (ISRG Root X1). Sans cela, la recherche d'une clé échouera sans message d'erreur ;
  
  
• Je n'ai pas trouvé comment mettre à jour les clés de mon trousseau Thunderbird (nouvelles signature, identités, date d'expiration repousée, etc.). Je mets à jour mon trousseau GPG puis j'exporte les clés et je les importe dans Thunderbird.

J'ai déjà développé les trois premiers points en juin 2021. Cependant, j'ai écrit une fausse information : configurer Thunderbird pour utiliser à nouveau GnuPG ne résout pas tous les problèmes sus-énoncés, car GnuPG sera utilisé uniquement pour les opérations de signature et de déchiffrement (source).

Pour le chiffrement et la vérification d'une signature, c'est toujours l'implémentation interne de Thunderbird qui sera utilisée. Cela s'explique : cette fonctionnalité d'externalisation est prévue pour prendre en charge les smartcards, c'est-à-dire les cartes à puce qui contiennent une clé privée OpenPGP (comme une Yubikey). Or, on utilise une clé privée uniquement pour signer ou pour déchiffrer (le chiffrement et la vérification d'une signature s'effectuent avec une clé publique).

Donc, il faut quand même synchroniser les trousseaux Thunderbird et GnuPG (Thunderbird a besoin de ta clé publique pour déchiffrer la copie des emails envoyés), surtout si tu utilises ta paire de clés OpenPGP pour d'autres usages que l'email avec Thunderbird (besoin des clés publiques de tes correspondants des deux côtés). En revanche, en utilisant GnuPG, ta clé privée sera alors protégée par celui-ci (et éventuellement son agent) plutôt que par Thunderbird, ce qui contrecarre bien les deux premiers points énoncés ci-dessus.

La bonne nouvelle, c'est l'ajout d'automates pour photocopier ou imprimer / scanner depuis / vers une clé USB.

En revanche, la fonctionnalité de numérisation vers une clé USB est une plaie :

• 0,20 € la page. Quelle justification ? :O ;
  
  
• Possibilité d'effectuer une numérisation multi-pages… mais elle sera stockée au format "un fichier PDF par page". Pas un problème pour un informaticien qui utilisera un logiciel pour les fusionner, mais galère pour la personne lambda… Sans compter qu'il n'y a pas de bac d'alimentation, donc il faut déposer chaque page sur la vitre du scanner… ;
  
  
• La qualité est médiocre : bande verticale à gauche, déformations localisées comme si le papier était ondulé (défaut optique ?), niveau de compression du PDF trop élevé ;
  
  
• Ergonomie foireuse : dans l'interface principale, il y a un écran de temporisation qui permet de mettre le document sur la vitre avec un bouton qui permet de lancer la numérisation quand on est prêt. Après la numérisation, il y a un bouton "continuer" (ma mémoire n'a plus son libellé exact)… qui, lui, lance directement la numérisation, alors qu'on s'attend à retourner sur l'écran de temporisation…

La DILA publie les sites web Légifrance, Journal-Officiel, Service-Public, Vie-Publique, etc. Pour diffuser Légifrance, elle a recours au CDN de la société commerciale états-unienne Imperva (alors que sur ses autres sites à l'affluence similaire, comme le JO, elle utilise celui de la société française Worldline, son hébergeur). De même, sur ses sites web, la DILA intègre des ressources web (mesure d'audience, tests A/B, vidéos, infographies) qui sont hébergées par des CDN états-uniens. Tout cela est incompatible avec le RGPD.

Cela signifie que nous dépendons des ricains pour publier notre droit… Pourtant, dans ses mentions légales, la DILA l'assure : « Aucun transfert de données à caractère personnelles n’est effectué vers un Etat non membre de l’Union Européenne. ». Guignols…

Du coup, hop, plainte à la CNIL.

Le raisonnement juridique reste identique aux précédentes fois. Pour Xiti, c'est ce raiso-là.

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 diffuser le site web Légifrance (https://www.legifrance.gouv.fr/), la Direction de l’Information Légale et Administrative (DILA) a recours au CDN (définition ci-dessous) de la société commerciale états-unienne Imperva (ex-Incapsula) :

    $ dig +short www.legifrance.gouv.fr
    p69gwj5.x.incapdns.net.
    45.60.14.53

    $ whois 45.60.14.53 | grep OrgName
    OrgName: Incapsula Inc

Un réseau de distribution de contenus (CDN) est un hébergeur informatique qui disposent de serveurs informatiques répartis dans une zone géographique donnée (pays, continent, monde). 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 et/ou les transmet, sans les déchiffrer ni accéder à la requête web, à un ensemble de serveurs appartenant au client final (ce pourrait être la DILA dans le cas présent). Il reçoit alors uniquement l’adresse IP du visiteur et celle du site web de destination, mais pas les entêtes HTTP. Il ne consigne (journalise) pas les communications. Exemples de prestations de ce type : atténuateurs d’attaques par déni de service distribué (DDoS), optimisateur BGP, IP flottante / répartition passive de la charge ;
  
  
• Dans l’autre mode de fonctionnement, bien plus courant, le CDN possède plusieurs copies du contenu à servir, il est le destinataire des communications, donc il les déchiffre, il accède à la requête web, il l’exécute, il reçoit et consigne (journalise) l’adresse IP du visiteur et les entêtes HTTP (qui contiennent des données personnelles), et il sert le contenu web à l’internaute.

Imperva Incapsula est un CDN du deuxième type. Pour s’en assurer, on peut consulter les entêtes HTTP qu’il insère dans ses réponses aux requêtes web (cf. la documentation officielle d’Imperva : https://docs.imperva.com/bundle/cloud-application-security/page/settings/caching.htm) :

    $ curl -s -o /dev/null -D - https://www.legifrance.gouv.fr/ | grep '^x-'
    x-cdn: Imperva
    x-iinfo: 11-96880604-0 0CNN RT(1663522566950 34) q(0 -1 -1 -1) r(0 -1)

Il y a donc transfert, traitement et conservation de données personnelles (adresse IP, entêtes HTTP), autant qu’avec un hébergeur informatique final.

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 l’intégration de Google Fonts à un site web), et comme vous l’avez analysé (votre mise en demeure du 10 février 2022 relative à l’utilisation de Google Analytics), chaque consultation d’une page web du site web Légifrance génère de facto et à l’insu du citoyen, des transferts hors de l’Union européenne (UE) de plusieurs données personnelles dudit citoyen : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de ses consultations de Légifrance (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.

    En tant qu’intermédiaire technique obligatoire, Imperva Incapsula reçoit, bien évidemment, l’URL complète. Elle reçoit et consigne donc l’historique des lectures de Légifrance d’un citoyen (telle loi, telle décret, tel article de telle loi, quelle révision / version de tel article de telle loi, et autres informations véhiculées par l’URL).

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://www.legifrance.gouv.fr/contenu/pied-de-page/politique-de-confidentialite), la DILA assure « Aucun transfert de données à caractère personnelles n’est effectué vers un Etat non membre de l’Union Européenne. ». De ce fait, nous pouvons avoir la certitude qu’elle ne recourt pas à des instruments juridiques et/ou à des mesures supplémentaires prévus aux articles 46 et 47 du RGPD.

    On peut également avoir la certitude que la DILA met en œuvre aucune mesure technique complémentaire, car la consultation des pages web de Légifrance par un navigateur web s’effectue directement auprès de l’infrastructure technique de son prestataire, Imperva. Dès lors, les requêtes de consultation émises par le navigateur web de tout citoyen ne cheminent pas par l’infrastructure technique de la DILA (dit autrement, il y a un contact direct entre le terminal de l’internaute et les serveurs informatiques d’Imperva), donc elles échappent totalement à la DILA, qui peut, 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.

La DILA ne recueille pas explicitement le consentement du citoyen 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.

    Quand bien même la DILA le recueillerait, il serait vicié car, en cas de refus, le citoyen ne pourrait pas consulter le « service public de la diffusion du droit », conséquence disproportionnée qui contraindrait le citoyen à accepter de force le traitement de données personnelles sus-présenté réalisé par Imperva, et donc le transfert de ses données personnelles aux États-Unis.

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. La DILA pourrait recourir à des CDN européens hébergés informatiquement dans l’UE (comme elle le fait pour plusieurs de ses sites à fort trafic : Service-public, Vie-publique, Journal-Officiel, etc.). La DILA pourrait également héberger Légifrance sur une infrastructure interne ou européenne correctement dimensionnée.

    D’un point de vue technique, un CDN apporte un gain limité en ce qui concerne la tenue de la charge. En effet, les pages web elles-mêmes, le texte, sont générées dynamiquement (à la volée) en fonction de paramètres et d’informations qui fluctuent, donc elles peuvent difficilement être mises en cache. En pratique, grâce aux entêtes HTTP ajoutés dans ses réponses par le CDN d’Imperva (exemple : « x-iinfo: 8-43876971-43876976 NNNY CT(10 11 0) RT(1663524799419 34) q(0 0 0 -1) r(1 1) U1 »), on constate que les requêtes web portant sur un certain nombre d’articles de décret / loi encore en vigueur sont transmises à l’hébergeur final de la DILA (Worldline, d’après ses mentions légales), car elles ne sont pas mises en cache (cf. la documentation d’Imperva pour interpréter l’entête sus-rapportée https://docs.imperva.com/bundle/cloud-application-security/page/settings/caching.htm). Du coup, l’intérêt réel du CDN d’Imperva est limité puisque l’hébergeur final de la DILA encaisse tout de même la charge dans ces cas-là.

    De même, les ressources web statiques (images, feuilles de style, polices de caractères, certains scripts) qui sont également diffusées par Imperva (ce qui soulage effectivement l’hébergeur de la DILA), peuvent être mises en cache nativement du côté des serveurs informatiques et du côté des navigateurs web et ainsi soulager une infrastructure d’hébergement web sans recourir à un CDN. De plus, la génération dynamique des pages requiert une puissance de calcul supérieure à celle nécessaire pour servir des ressources statiques. Là encore, l’intérêt réel du CDN d’Imperva apparaît être limité.

    Il découle des deux points précédents que 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 DILA et l’atteinte disproportionnée aux droits des citoyens que ce choix de prestataire constitue.

L’utilisation, par la DILA, d’un CDN états-unien pour diffuser le site web Légifrance, et le transfert de données personnelles vers les États-Unis qui en découle, est donc illégale.

De plus, sur plusieurs de ses sites web (https://www.legifrance.gouv.fr/, https://www.service-public.fr/, https://www.journal-officiel.gouv.fr/, https://www.bodacc.fr/, https://www.boamp.fr/, www.vie-publique.fr, etc.), même si l’on refuse tous les cookies dans le bandeau dédié et avant même l’expression d’un consentement, la DILA fait télécharger automatiquement l’outil de mesure d’audience Xiti de la société commerciale française AT Internet.

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 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, qui est incompatible avec le RGPD.

En tout état de cause, la société AT Internet a recours au CDN de la société commerciale états-unienne Amazon (cf. https://www.atinternet.com/rgpd-et-vie-privee/collecte-de-donnees-sur-les-sites-de-nos-clients/#traitees-et-stockees) :

    $ dig +short logs4.xiti.com # sur Légifrance
    13.224.62.239

    $ dig +short logs1241.xiti.com # sur Service-public
    13.224.62.239

    $ dig +short logs1187.xiti.com # sur Journal-Officiel
    13.224.62.239

    $ whois 13.224.62.239 | grep OrgName
    OrgName: Amazon Technologies Inc.
    OrgName: Amazon.com, Inc.

    $ dig +short logs2.xiti.com # sur le BODACC, le BOAMP et Vie-publique
    52.222.163.219

    $ whois 52.222.163.219 | grep OrgName
    OrgName: Amazon Technologies Inc.
    OrgName: Amazon.com, Inc.

Le raisonnement est identique à celui déroulé au premier point de cette plainte : le téléchargement de Xiti déclenché automatiquement lors de la consultation des sites web de la DILA sus-énumérés, génère de facto et à l’insu du citoyen, un transfert de plusieurs de ses données personnelles (cf. liste au premier point) à destination des États-Unis et pour le compte d’une société commerciale soumise au Cloud Act ; 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 ; la DILA ne prévoit pas de mesures complémentaires ; le consentement du citoyen (au sens de l’article 49.1a du RGPD) n’est pas recueilli ; et la nécessité des transferts des données personnelles vers les États-Unis n’est pas établie pour les mêmes raisons : la DILA pourrait recourir à un prestataire européen hébergé informatiquement dans l’UE ou internaliser son outil de mesure d’audience, c’est-à-dire l’héberger chez son hébergeur informatique français Wordline.

    De plus, dans la politique de confidentialité de Legifrance, la DILA informe que les cookies d’audience permettent « d'établir des mesures statistiques de fréquentation et d'utilisation du site, afin d'en améliorer l'usage, les parcours et les fonctionnalités proposés. La DILA et les tiers émetteurs, AT Internet et Hotjar, sont soumis à la loi informatique et libertés du 6 janvier 1978 modifiée. ». Sur le BODACC et le BOAMP : « La DILA collecte également par l’intermédiaire des cookies AT Internet des données personnelles pour réaliser des statistiques d’audience dans le but d’améliorer le site, ainsi que les services proposés. ». Sur Vie-publique : « ces cookies permettent d’obtenir des statistiques de fréquentation anonymes du site afin d’optimiser son ergonomie, sa navigation et ses contenus ».

    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. Donc le transfert de données personnelles vers les États-Unis permettant de télécharger Xiti ne peut pas être regardé comme étant nécessaire à l’exécution d’un contrat.

Lors de la consultation de différents sites web de la DILA, le téléchargement automatique de l’outil de mesure d’audience Xiti auprès de la société commerciale états-unienne Amazon, et le transfert de données personnelles vers les États-Unis qui en découle est donc illégal.

Enfin, sur plusieurs de ses sites web, et notamment Service-public et Vie-publique, la DILA fait télécharger, en sus :

• L’outil de tests A/B de la société commerciale française AB Tasty, diffusé via les sociétés commerciales états-uniennes Google et Amazon.

  • Sur Service-public, l’outil est téléchargé par défaut, sans consentement, et il n’est plus téléchargé après le refus des cookies facultatifs. Cela constitue une non-conformité au RGPD supplémentaire, d’autant que ça génère un transfert illégal de données personnelles aux États-Unis ;
    
    
  • Sur les autres sites web, le téléchargement est conditionné à l’acceptation des cookies dans le bandeau dédié ;
• Scripts de la société commerciale anglaise Polyfill diffusés via le CDN de la société commerciale états-unienne Fastly ;
  
  
• Scripts du projet unpkg diffusés via le CDN de la société commerciale états-unienne Cloudflare ;
  
  
• Vidéos hébergées par Google YouTube ;
  
  
• Infographies proposées via Datawrapper, société commerciale allemande dont les ressources web sont diffusées par le CDN de la société Cloudflare ;

Le raisonnement est identique à ceux déjà déroulés dans la présente plainte : les téléchargements de ces ressources web déclenchés automatiquement lors de la consultation des sites web de la DILA, génèrent de facto et à l’insu du citoyen, des transferts de plusieurs de ses 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 ; la DILA ne prévoit pas de mesures complémentaires ; le consentement de l’internaute (au sens de l’article 49.1a du RGPD) n’est pas recueilli ; et la nécessité des transferts des données personnelles vers les États-Unis n’est pas établie pour les mêmes raisons : la DILA pourrait recourir à des prestataires européens hébergés informatiquement dans l’UE ou internaliser les outils et scripts, c’est-à-dire les héberger chez son hébergeur informatique Wordline ou charger les présentes ressources (surtout les vidéos et les infographies) après un clic sur un bouton / encart qui informerait l’internaute du transfert de ses données personnelles vers les États-Unis et des risques encourus.

Je vais signaler, au DPO de la DILA, 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.

P.-S. : je vous joins une version PDF correctement mise en forme de la présente plainte.

ÉDIT DU 20/07/2023 :

Le 16/04/2023, j'ai envoyé à la CNIL le complément de réclamation suivant :

Bonjour,

Suite à une déclaration publique de la DILA, vous trouverez, PJ, un complément à ma réclamation.

Bonne journée.

Bonjour,

Le 21/03/2023, la DILA a communiqué sur le fait que, lors de la navigation sur le site web Légifrance, « il n'y a pas de transfert d'IP hors UE » lié à son recours au CDN de la société commerciale états-unienne Imperva / Incapsula. Source : https://twitter.com/DILA_officiel/status/1638181524775358465 ou PJ 1.

Si les serveurs informatiques semblent être localisés au sein de l’UE (outil traceroute), la société Imperva / Incapsula demeure une société commerciale états-unienne. Son siège social est en Californie (source : https://www.imperva.com/company/about/).

Elle doit, de fait, compter de nombreux clients aux États-Unis. Elle le présente même comme un argument marketing : « 6,200+ Enterprise customers […] 7 of 10 top US commercial banks / 7 of 10 top global financial services firms ». Source : https://www.imperva.com/company/about/.

Ce 16/04/2023, la société commerciale propose 33 offres d’emplois, en grande majorité dans des États non adéquats : États-Unis, Mexique, Inde, Brésil, Canada, etc. Source : https://www.imperva.com/company/careers/#career-section (archive : https://web.archive.org/web/20230416101645/https://www.imperva.com/company/careers/).

Il existe une unique infrastructure technique mondiale Incapsula administrée depuis des États non adéquats. D’une part, les emplois en informatique sont à pourvoir majoritairement dans ce type d’États, cf. ci-dessus. D’autre part, le numéro de téléphone des informaticiens d’Incapsula en charge de l’exploitation de son réseau informatique, référencés dans sa déclaration dans la base de données de l’ARIN pour louer ses adresses IP (dont celle du CDN qui diffuse Légifrance), sont, en écrasante majorité (10 sur 12), états-uniens, cf. :

$ whois 45.60.14.53 | grep -C2 'OrgTechPhone'
OrgTechHandle: ARIGO-ARIN
OrgTechName:   Arigo, Francis 
OrgTechPhone:  +1-650-345-9000 
OrgTechEmail:  FRANCIS.ARIGO@IMPERVA.COM
OrgTechRef:    https://rdap.arin.net/registry/entity/ARIGO-ARIN
--
OrgTechHandle: LIROZ-ARIN
OrgTechName:   liroz, yanay 
OrgTechPhone:  +972723771700 
OrgTechEmail:  yanay.liroz@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/LIROZ-ARIN
--
OrgTechHandle: WOODE23-ARIN
OrgTechName:   Wooderson, Lee 
OrgTechPhone:  +44 2890446293 
OrgTechEmail:  lee.wooderson@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/WOODE23-ARIN
--
OrgTechHandle: RIR7-ARIN
OrgTechName:   rir
OrgTechPhone:  +1-650-345-9000 
OrgTechEmail:  rir@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/RIR7-ARIN
--
OrgTechHandle: GILKI1-ARIN
OrgTechName:   Gilkis, Nitzan 
OrgTechPhone:  +1-650-345-9000 
OrgTechEmail:  nitzan.gilkis@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/GILKI1-ARIN
--
OrgTechHandle: CLNSC-ARIN
OrgTechName:   Chitturi, Lakshmi Naga Sri Charan 
OrgTechPhone:  +93520896 
OrgTechEmail:  lakshmi.chitturi@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/CLNSC-ARIN
--
OrgTechHandle: TEWKS25-ARIN
OrgTechName:   Tewksbury, Carl 
OrgTechPhone:  +1-855-574-9831 
OrgTechEmail:  carl.tewksbury@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/TEWKS25-ARIN
--
OrgTechHandle: IMPER9-ARIN
OrgTechName:   Imperva
OrgTechPhone:  +1-450-405-4945 
OrgTechEmail:  neteng@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/IMPER9-ARIN
--
OrgTechHandle: BLACK1033-ARIN
OrgTechName:   Black, Nicole 
OrgTechPhone:  +1-855-574-9831 
OrgTechEmail:  knack.black@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/BLACK1033-ARIN
--
OrgTechHandle: CASEI7-ARIN
OrgTechName:   Caseiro, Nelson 
OrgTechPhone:  +1-866-926-4678 
OrgTechEmail:  nelson.caseiro@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/CASEI7-ARIN
--
OrgTechHandle: KLINK18-ARIN
OrgTechName:   Klink, Aaron 
OrgTechPhone:  +1-650-345-9000 
OrgTechEmail:  aaron.klink@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/KLINK18-ARIN
--
OrgTechHandle: LOHBE-ARIN
OrgTechName:   LOH, BENEDICT 
OrgTechPhone:  +1-658-812-4661 
OrgTechEmail:  benedict.loh@imperva.com
OrgTechRef:    https://rdap.arin.net/registry/entity/LOHBE-ARIN

Dans sa politique de protection de la vie privée (https://www.imperva.com/trust-center/privacy-statement/), Imperva reconnaît de possibles transferts de données personnelles, dont l’adresse IP des visiteurs des sites web que son CDN diffuse (cf. https://www.imperva.com/trust-center/transfer-impact-assessment-tia/), vers les États-Unis et d’autres États qui peuvent ne pas avoir le même niveau de protection des données personnelles que ceux de l’UE.

Elle indique également se reposer sur les clauses contractuelles-types (https://www.imperva.com/trust-center/gdpr/) qui ont été indirectement invalidées par l’arrêt Schrems II de la CJUE, le CEPD et les APD qui exigent des garanties supplémentaires que les entités états-uniennes ne peuvent satisfaire compte-tenu du droit états-unien qui s’impose à elles (ce que le cas d’espèce ne dément pas : les mesures complémentaires mises en œuvre par Imperva sont insuffisantes, cf. https://www.imperva.com/trust-center/transfer-impact-assessment-tia/).

Enfin, elle stipule qu’elle peut divulguer les données personnelles lors d’une assignation ou d’une requête des forces de l’ordre (et des tribunaux) états-uniens.

Le mémorandum concernant l’application du Cloud Act 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, Imperva / Incapsula est soumise au Cloud Act, qui est incompatible avec le RGPD, peu importe la localisation effective des serveurs informatiques et des données personnelles.

Quoi qu’il en soit, lorsqu’Incapsula soupçonne un usager de Légifrance d’être un robot ou un logiciel malveillant, il lui fait télécharger automatiquement et sans consentement le produit Google reCAPTCHA. Cf. PJ 2.

Cela génère des transferts illégaux de données personnelles, dont l’adresse IP dudit usager, vers la société commerciale états-unienne Google. Illégaux au sens des articles 44 et suivants du RGPD.

De plus, le chargement de Google reCAPTCHA se fait sans recueil du consentement de l’usager alors que, selon vos décisions passées, seule cette base légale est applicable. Cf. vos décisions contre l’IGPN, l’Assurance-Maladie, la première version de l’application StopCovid ou, plus récemment contre la société commerciale CityScoot (délibération SAN-2023-003 du 16 mars 2023).

En conclusion, la communication de la DILA du 21/03/2023 est mensongère : son recours au CDN de la société Imperva / Incapsula génère des transferts illégaux de données personnelles en dehors de l’UE, à destination d’États non adéquats.

Cela illustre une carence de la DILA dans le choix, le pilotage et l’audit de ses prestataires en matière de données personnelles.

Enfin, les autres infractions relevées dans ma réclamation initiale perdurent à date : chargement de Piano AT Internet Xiti, Google Fonts, AB Tasty, etc. sur plusieurs sites web dont la DILA a la charge.

Je maintiens donc ma réclamation, car elle est fondée en fait et en droit, et sollicite à nouveau l’intervention de la CNIL dans ce dossier.

Bonne journée.

FIN DE L'ÉDIT du 20/07/2023.

… Puis arrivent Musk, Bezos, et tous les autres. Youpi.

Via https://www.nextinpact.com/article/69980/flock-aspire-tout-ce-qui-bouge-et-samuse-dun-rien.

Le bon vieux temps.

+1.

Via https://www.nextinpact.com/article/69980/flock-aspire-tout-ce-qui-bouge-et-samuse-dun-rien.

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.

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 :

• Oui, la directive de 1995 qui fonde WP 118 a été abrogée, oui, le CEPD a approuvé une liste limitée des travaux du G29 qui n'inclut pas WP 118, mais le G29 a été remplacé par le CEPD… qui ne renie ses travaux et s'appuie dessus : la section III.B.2 de WP187 reprend et référence WP118. WP 187 sont elles-mêmes référencés dans les lignes directrices 05/2020 du CEPD.
  
  
• WP 118 est cité dans l'avis 6/2017 de l'EDPS (autorité de contrôle des institutions européennes ;
  
  
• Article 94(2) du RGPD : les références faites au G29 s'entendent comme faites au CEPD ;
  
  
• Le raisonnement de WP 118 se refait à partir des obligations du RGPD (base légale, intérêt légitime, nécessité, proportionnalité, attente raisonnable de la personne concernée, etc.) ;
  
  
• Oui, WP 118 énonce une « strong opposition » qui peut paraître ambiguë, mais les avis et les lignes directrices du CEPD (et de la CNIL) ne peuvent formuler une interdiction générale, car il s'agit de droit souple. Source.
  
  
• ÉDIT DU 23/12/2023 : nouvelles lignes directrices du CEPD qui complètent WP 118 en faisant tomber les images et liens traçants dans le giron de l'article 5(3) ePrivacy. FIN DE L'ÉDIT DU 23/12/2023.

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: SELLIGENT

Selligent 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.

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 :

• Un roulement de KSK est prêt quand ods-enforcer key list -v affiche « ds-seen » sur une KSK. Perso, je note dans mon agenda la date à laquelle cela va arriver ;
  
  
• Le bureau d'enregistrement Gandi veut la clé publique, pas un enregistrement DNS de type DS. Pour l'obtenir : ods-enforcer key export --zone guiguishow.info --keytype KSK --keystate ready. BookMyName veut un enregistrement DS. Pour l'obtenir : ods-enforcer key export --zone guiguishow.info --keytype KSK --keystate ready --ds ;
  
  
• Ajouter la nouvelle KSK via l'interface web de Gandi. Ne pas se déconnecter après la manip' ;
  
  
• Attendre que la nouvelle clé soit communiquée au registre (entre 5 et 30 minutes). Vérifier avec 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> ;
  
  
• Quand la nouvelle clé est publiée dans la zone parente, l'indiquer à OpenDNSSEC : ods-enforcer key ds-seen --zone guiguishow.info --keytag <ID_NOUVELLE_CLÉ> ;
  
  
• Supprimer l'ancienne clé auprès du bureau d'enregistrement ;
  
  
• Attendre sa suppression de la zone parente en vérifiant comme ci-dessus ;
  
  
• Quand l'ancienne clé n'est plus publiée dans la zone parente, l'indiquer à OpenDNSSEC : ods-enforcer key ds-gone --zone guiguishow.info --keytag <ID_ANCIENNE_CLÉ> ;
  
  
• Tadaaaa.

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.

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.