GuiGui's Show

Une carte interactive et un poster de quelques fichiers contenant des données persos constitués et utilisés par l'État.

Dans la nuit du 25 au 26 septembre 1983, le lieutenant-colonel russe affecté à un centre de surveillance prévient sa hiérarchie d'une fausse alerte quand 5 missiles ricains sont signalés par le système informatique, alors que ses ordres sont de relayer les alertes, pas de déblatérer à leur sujet. Il s'agissait de reflets du soleil dans les nuages mal interprétés par le logiciel d'analyse des images satellites. Plus d'infos : BBC et Wikipedia.

En novembre 83, l'OTAN fait son exercice annuel en ayant prévenu les Russes… qui, a cause de nouveautés dans l'exercice, l'interprètent comme une attaque imminente dissimulée et déplacent les missiles nucléaires du stockage vers les pas de tir. Un chef d'état-major ricain adjoint au renseignement en est informé et décide de ne pas relever le niveau d'alerte afin de ne pas attiser la conviction ruskov qu'une attaque réelle était en cours. Plus d'infos.

Comme quoi, les procédures et la hiérarchie… Dans les deux cas, ils y sont allés à l'intuition.

ÉDIT DU 29/12/2023 : le Canard du 15/11/2023, commentant le documentaire L'Horloge de l'apocalypse, quelques secondes pour sauver le monde, nous relate une autre histoire du genre. En octobre 1962, pendant la crise des missiles de Cuba, le capitaine de la 69^e brigade de la marine soviétique, Vassili Arkhipov patrouille autour de Cuba et a pour ordre de répondre à une attaque ricaine par l'envoi d'une torpille à ogive nucléaire. Son sous-marin se fait attaquer par l'armée ricaine. Arkhipov refuse de lancer la torpille, évitant l'escalade. FIN DE L'ÉDIT DU 29/12/2023.

#chefs #Russie #URSS #Union Soviétique #désobéir

Ma paire de clés OpenPGP a une date d'expiration d'un an. C'est pratique pour informer tacitement mes correspondants de la perte de ma clé privée (normalement, on est censé avoir généré à l'avance un certificat de révocation et le publier à cette occasion) ou de ne plus utiliser ce mode de chiffrement pour me contacter (car, manifestement, je ne l'utilise plus) ou…

Depuis deux ans, lors du premier échange postérieur au recul de la date d'expiration de ma clé, un contact m'informe, en clair, qu'elle est expirée. Pourtant, je l'ai bien mise à jour sur le serveur de clés. Oui, mais… lequel ?

Le réseau sks-keyserveurs (qui utilisait le protocole HKPS, HKP sur TLS) a fermé suite à l'attaque par déni de service de mi-2019 (qui consiste à ajouter trouzemilles signatures illégitimes à une clé). J'ai l'impression que ce réseau faisait consensus, qu'il était massivement utilisé.

Le serveur keys.openpgp.org est apparu. Il empêche l'attaque sus-citée en ne diffusant pas les signatures d'une clé. Il tente également d'empêcher la diffusion de clés illégitimes pour une adresse emails (exemple) en envoyant un email de confirmation. Enfin, il tente de protéger la vie privée en ne diffusant pas les signatures (qui consignent tes connaissances, ton graphe social), en retirant les infos superflues d'une clé, en ne permettant pas une recherche de clés avec un joker, etc. Il est volontairement isolé des autres serveurs de clés, donc il n'y a pas de synchronisation des clés. Or, tout le monde n'utilise pas ce serveur.

L'historique serveur pgp.mit.edu était souvent en panne quand j'ai eu besoin de lui ces dernières années.

Je me suis donc tourné vers le serveur de clés d'Ubuntu (keyserver.ubuntu.com). J'ai relativement confiance, et il fonctionne quand j'ai besoin de lui. Mais, tout le monde ne l'utilise pas et il ne semble pas synchroniser son contenu avec d'autres serveurs.

Cela explique pourquoi mes correspondants me signalent une prétendue expiration de ma clé : je la mets à jour sur un serveur, mais eux en utilisent un autre, et les deux ne synchronise pas leur contenu…

À ce jour, il me suffit de téléverser ma clé sur le vénérable pgp.mit.edu pour satisfaire mes contacts, donc j'arrête-là ma réflexion. S'il dysfonctionne à l'heure de repousser la date d'expiration de ma clé, j'ajouterai un rappel dans mon agenda pour téléverser ma clé quelques jours / semaines plus tard… Pratique.

Au long cours, je pourrais réfléchir…

Quelle est la pertinence d'une date d'expiration pour une personne lambda comme moi, au fond ? Aucune. Jouer au crypto-gourou, ça va deux minutes…

En 2020, quand j'ai appris le bazar sus-relaté avec le réseau SKS, je n'ai pas migré vers keys.opengpg.org par désaccord : supprimer les signatures de tiers apposées à une clé revient à mettre un terme au modèle de la toile de confiance au profit d'un tiers centralisé. Avec du recul, l'utilisation de la toile de confiance a toujours été vivement déconseillée, il faut rencontrer la personne physiquement (ou échanger via un deuxième canal), blablabla. Je pourrais évoquer l'opacité de keys.openppg.org, mais, bon, tous les services sont toujours administrés par un groupe restreint de personnes… En revanche, le grief du tiers centralisé (par rejet du modèle de la fédération ouverte) demeure.

Je n'ai pas identifié de moyen simple d'informer mes contacts de la source pour la mise à jour de ma clé. Il est possible d'insérer un commentaire dans une identité associée à une clé, mais c'est plutôt prévu pour indiquer si c'est une clé perso ou pro. Il est possible de dédier une identité à cet usage. Mais bon… C'est du taff, sans aucune certitude que ce conseil sera suivi par mes correspondants, donc bon, la flemme… Vu mon peu de contacts qui utilisent OpenPGP, je pourrais tout aussi bien leur envoyer un email pour le leur rappeler avant l'expiration, mais bon, ça ressemble à du spam… Dommage qu'il n'existe pas un moyen standard d'associer une clé OpenPGP à plusieurs sources de mise à jour (ouiiii, il existe DANE OPENDNSKEY, mais personne l'utilise).

Bref, OpenPGP est encore moins pratique à utiliser qu'avant (si c'était possible)… Déjà que l'implémentation de Thunderbird qui remplace Enigmail comporte de sérieuses carences… Ça fait beaucoup en peu de temps.

Concert initiatique de musique classique joué dans un théâtre par l'orchestre national Avignon Provence.

Contenu :

Wolfgang Amadeus Mozart, Petite musique de nuit (mouvements 1, 2 & 3)
Antonín Dvořák, Sérénade en ré mineur, op. 44 pour vents, violoncelle et contrebasse, dite « Grande sérénade »
Joseph Haydn, Symphonie n° 8 dite « Le Soir »

C'était pas seulement un concert, la cheffe d'orchestre était pédagogue : elle a énoncé et expliqué la thématique du concert (la nuit, l'amour), les sensations que l'orchestre cherchait à véhiculer, ce qu'est une sérénade, une brève histoire des morceaux joués, une présentation des instruments impliqués, etc. Comme elle l'a dit elle-même, il est rare qu'elle prenne la parole, d'où l'originalité de ce concert, qui me fait le classer comme concert d'initiation.

Des enfants de banlieue sont membres de l'orchestre (après avoir participé à un long atelier). À travers des enregistrements audio diffusés par la régie, ils nous ont présenté leur instrument, leur vision de ce qu'est la musique, leur définition d'une sérénade, etc. Mention spéciale au gosse qui nous a informé qu'il aime son instrument parce qu'il est gros, et à celui qui, pour présenter son instrument, nous a joué toutes les notes de la gamme (« ça c'est un do [ joue ], ça c'est un… »). :D

La cheffe d'orchestre organisait quelques animations avec le public (test à l'aveugle, claquement rythmé des mains, etc.). Elle était vivante, dynamique et passionnée. J'ai ressenti une certaine douceur avec son orchestre, un certain encouragement. Bien plus qu'avec celle de l'Ukrainian Freedom Tour.

Deux concerts de musique classique en un mois, je m'embourgeoise. :P

Merci Alex pour l'invitation. :)

jDownloader est un gestionnaire de téléchargements qui prend en charge les hébergeurs de fichiers (Mega, 1fichier, Uptobox, Turbobit, Rapidgator) et les protecteurs de liens (ReviveLink, etc.).

Il sait surveiller le presse-papier afin d'identifier automatiquement un ou plusieurs liens de téléchargement dans un pavé (on peut désactiver ce comportement depuis l'écran principal), vérifier automatiquement la disponibilité d'un fichier à partir d'un lien du presse-papier, gérer / ordonnancer une file d'attente, attendre le délai imposé par les hébergeurs entre deux téléchargements (si pas de compte premium), s'authentifier auprès des hébergeurs (si détention d'un compte premium), etc.

Logiciel multi-systèmes (GNU/Linux, winwin, etc.), libre (GNU GPL) et gratuit. Écrit en Java (personne est parfait).

Attention : avec winwin uniquement, jDownloader contient un adware (il est gorgé de pubs, quoi). Il faut décocher les cases kiVontBien lors de l'installation pour le désamorcer.

Ça fait environ 10 ans que je ne l'ai pas utilisé (je préfère Torrent), donc je suis content de voir qu'il fonctionne toujours et qu'il est toujours maintenu. Le monde change assez peu, finalement. \o/

Tiens, je ne connaissais pas Z-library, la plus grande bibliothèque numérique. Plein de livres disponibles.

Malheureusement, cette bibliothèque ne contient pas deux livres plus disponibles que je cherche.

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.