GuiGui's Show

J'achète un nouveau disque dur externe USB, et je copie mes données depuis mon "ancien" disque dur externe USB. Le débit plafonne à 35 mo/s sur des fichiers de plusieurs dizaines de gigaoctets.

htop montre que le CPU se touche, ce qui innocente la couche de chiffrement. dstat et usbtop mettent en évidence que le disque source lit quelques ko/s en permanence, et que le disque de destination est au taquet à 35 mo/s en permanence. Donc, a priori, le problème provient bien du disque de destination ?

lsusb -t (découverte ici) affiche les bus et les ports USB sous forme hiérarchique (un arbre). Ainsi que leur vitesse. Tiens, j'ai un bus à 5 Gbps (USB 3.2 Gen 1x1) et les trois autres en 480 Mbps (USB 2). Tiens, le disque source est sur un port USB 2 alors que le disque destination est sur un port USB 3.2.

Je branche le disque source sur un port USB 3 et je relance la copie. > 90 mo/s. \o/ La solution n'est pas raccord avec ce que montraient dstat et usbtop, mais bon…

Chercher des morceaux de texte en fonction de leur formatage (italique, gras, etc.) avec Writer ? Outil « Rechercher et remplacer » (ctrl + h), bouton « Format… ».

Attention, ce critère de recherche sera appliqué aux futures recherches, même celles effectuées avec l'outil « Recherche » simple (ctrl + f), même après la fermeture de Writer. Pour le supprimer, utiliser le bouton « Aucun format » de l'outil Rechercher et remplacer.

Chercher en ligne de commande dans l'historique et dans les téléchargements Firefox : echo 'SELECT url FROM moz_places ORDER BY last_visit_date ASC;' | sqlite3 places.sqlite | grep […].

Chercher en ligne de commande dans les favoris Firefox : echo 'SELECT url FROM moz_bookmarks INNER JOIN moz_places ON moz_bookmarks.fk = moz_places.id ORDER BY lastModified ASC;' | sqlite3 places.sqlite | grep […].

Le fichier « places.sqlite » se trouve à la racine du profil Firefox (généralement : .mozilla/firefox/*.default/places.sqlite).

Le schéma de cette base de données est disponible ici.

‒ Il s'agit tout de même d'une forme de violence sur des personnes vulnérables, d'acte de domination, une volonté de passer en force et sans consentement pour des questions bassement financières. Maintenant, concernant les retraites…

Via https://www.nextinpact.com/article/70120/flock-regarde-dans-miroir-aux-alouettes.

Première plainte il y a quelques semaines concernant l'impossibilité d'utiliser l'outil de suivi d'un envoi du site web de La Poste sans accepter le téléchargement d'un outil de ciblage et de suivi du parcours client hébergé sur les serveurs informatiques d'une société commerciale états-unienne. De même, le site web La Poste est gavé de ressources web facultatives téléchargées depuis de tels serveurs.

Aujourd'hui, deuxième plainte. Lors d'une livraison d'un achat en ligne par Colissimo, La Poste envoie un email « Votre Colissimo arrive ! » dont tous les liens sont traçants (identifiant unique + rebond via un intermédiaire avant d'atteindre la destination, afin d'enregistrer le clic sur tel lien) et qui contient une image traçante (1 x 1 pixel, transparente, avec un identifiant unique dans son nom, afin de détecter l'ouverture de l'email). Ni nécessité ni consentement.

L'envoi de l'email, le téléchargement de l'image traçante, et les redirections des liens traçants sont effectués depuis des serveurs chez Microsoft Azure par la société commerciale Isoskele, l'« agence data marketing et communication » du groupe La Poste. Sur ce grief, le même raisonnement juridique que d'habitude s'applique.

Du coup, hop, plainte à la CNIL.

Le raisonnement juridique reste identique aux précédentes plaintes.

Plainte irrecevable ? Non.

Pour la première fois, le greffe de la CNIL a classé irrecevable ma plainte au motif que je devais d'abord contacter la DPO de La Poste.

Or, lors d'une violation du RGPD, celui-ci n'impose pas d'exercer ses droits (accès, rectification, opposition, limitation, etc.) au préalable ni même de contacter le DPO. Cela est confirmé par le Tribunal Supremo (Cour suprême) d'Espagne dans sa décision TS 1039/2022.

J'ai posé une demande « Où en est mon dossier ? » pour débloquer ma plainte. Elle a été transmise au service des plaintes. Ouf.

Voyons ça en détail.

Réponse de la CNIL du 03/10/2022 à 9 h 16

Je vous confirme que le groupe La Poste a désigné un Délégué à la protection des données (DPO). Pour toute question relative aux traitements de données mis en oeuvre au sein de cet organisme, je vous invite, dans un premier temps, à prendre contact avec lui à l'adresse suivante : Madame la Déléguée à la Protection des Données CP C703 9 rue du Colonel Pierre Avia 75015 PARIS.

J'ajoute que le responsable d'un fichier dispose d'un délai maximal d'un mois à compter de la réception de votre demande pour vous répondre (article 12 3. du RGPD).

Vous pourrez nous adresser une réclamation, en joignant une copie de vos échanges, afin que l'on intervienne à l'appui de votre demande si au terme de ce délai aucune réponse ne vous est parvenue.

Ma réponse à la CNIL du 03/10/2022 à 10 h 08

L'outil web de suivi des plaintes de la CNIL ne permet pas d'interagir quand sa plainte est clôturée. :(

Formulaire de contact que j'ai utilisé. (Pour le retrouver depuis la page d'accueil du site web de la CNIL : « Contact » dans le pied de page, puis lien « Je demande où en est mon dossier en cours » dans l'encart « Pour les professionnels » de la section « En ligne ».)

Objet : « Où en est mon dossier ? » ; Type de dossier : plainte ; Remplir le numéro de plainte.

Corps de la demande :

Bonjour,

Ce matin, ma récente plainte numéro <CENSURE> a été classée irrecevable. Il m'est demandé de contacter la DPO de La Poste.

Je pense qu'il s'agit d'une erreur, car, comme écrit dans ma plainte :

• Je vais contacter la DPO de La Poste en parallèle ;
  
  
• Quelles que soient la réponse et les actions, y compris correctrices, que la DPO La Poste entreprendrait, les faits relatés dans ma plainte constituent en soi des violations du RGPD qui justifient, à elles seules, le dépôt d’une plainte pour sanction auprès de l’autorité de contrôle (APD) que vous êtes ;
  
  
• Dans son arrêt TS 1039/2022, le Tribunal Supremo espagnol a confirmé que l'exercice des droits n'est pas un pré-requis à une plainte auprès d'une APD en cas de violation du RGPD et qu'une APD peut donc agir même si la personne physique concernée par un traitement de données personnelles n'a pas encore fait valoir ses droits auprès du responsable du traitement en question.

Pouvez-vous, svp, re-examiner la recevabilité de ma plainte numéro <CENSURE> ?

Bonne journée.

Réponse de la CNIL du 03/10/2022 à 13 h 57

Bonjour <CENSURE>,

Nous vous remercions de nous avoir contactés.

Je vous informe qu'après une nouvelle analyse avec les agents en charge du greffe, votre demande n°<CENSURE> a été transmise au service des plaintes.

Cordialement,

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,

Le 28/09/2022, j’ai acheté des produits sur la boutique web d’un commerçant. Livraison via Colissimo de La Poste (LP).

Le 30/09/2022, j’ai reçu un email « Votre Colissimo arrive ! » émis par La Poste (cf. PJ 1 pages 1 à 5 ; apparence étrange, car je désactive le HTML dans ma messagerie). C’est cet email qui fait l’objet de la présente plainte.

D’abord, je doute du bien-fondé de la base légale de ce traitement de données personnelles.

En effet, cet email est-il vraiment nécessaire à l’exécution d’un contrat / d’une mission de service public (base légale sur laquelle repose ce traitement, cf. https://www.laposte.fr/pages/recevoir-un-colissimo/courriel#1) ?

    Un achat auprès d’un commerçant web se déroule toujours en plusieurs étapes : commande, confirmation de celle-ci, paiement et émission d’une facture, envoi des produits. À chaque étape, le commerçant informe lui-même son client par email, car la date d’envoi peut différer de la date de paiement, qui peut différer de la date de commande, en fonction du moyen de paiement et/ou de la disponibilité des produits commandés, par exemple. Le numéro de l’envoi est toujours communiqué par le commerçant. L’email de LP est donc redondant.

    L’email de LP est une information supplémentaire, du confort, mais, qu’il soit reçu ou non, lu ou non, le colis sera acheminé jusqu’au client du commerçant. Dit autrement, la prestation de livraison ira à son terme indépendamment de cet email. Email facultatif.

    La Poste répliquera peut-être que son email est une mesure de sécurité puisqu’il contient un code qu’il faudrait communiquer au livreur afin de s’authentifier auprès de lui. Dans la pratique, les livreurs LP ne vérifient pas ledit code, mais un justificatif d’identité. Ce fonctionnement est par ailleurs plus sain puisqu’il minimise le nombre de traitements de données personnelles : l’identité du destinataire est déjà connue du livreur puisqu’elle figure sur le colis, inutile d’effectuer un traitement supplémentaire (l’email). Ce traitement, cet email n’est donc pas nécessaire, voire il est contre-productif.

Vu les infractions au RGPD contenues dans l’email LP (je vais développer ci-dessous) alors que mon commerçant en a commis aucune dans ses emails de suivi, une base légale fondée sur l’intérêt légitime est irrecevable : l’intérêt de l’email LP est faible (cf. ci-dessus) alors que l’atteinte aux droits des personnes qu’il constitue à date est forte.

Il apparaît que cet email est non-nécessaire à l’exécution d’un contrat / d’une mission de service public et qu’il ne peut pas être justifié par l’intérêt légitime de LP. Son envoi devrait donc être soumis au consentement du client d’un vendeur. Ce n’est pas le cas.

Il semble que les outils et les procédures de LP ne permettent pas à un commerçant en ligne de s’opposer à l’envoi de l’email litigieux tant que son client ne consent pas à le recevoir. La faute ne semble donc pas être du côté des commerçants, mais de LP.

Ensuite, tous les liens hypertextes contenus dans l’email envoyé par LP (même celui pour consulter les mentions légales / RGPD), notamment celui permettant de consulter le suivi en ligne de son envoi (cet outil publié sur le site web de LP est l’objet de ma plainte CNIL distincte numéro <CENSURE>) 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), cf. PJ 4. Exemple : « http ://t.notif-colissimo-laposte.info/TrackActions/NGJlYjE5NjZhZDlkODU0NzE3Yzg3Zjk3ODJkMmMxZWRjYTVkYmM2Yjg1NjZkNDI3NDI2OGU5MTFkOWVlODQzZDFmNzQ0MGM1OGMyYTYxYzM2MDc3NWNjMDU5YzFiYjQ3NTA4YjQ2OTUyMzg5ZmYwYTczOTdhMGM3NjEwNWIxYzFjMzAwMjQxODRiNjc1ZjcwMjFhNWNiM2NkNTczNTQxYTNkYTJhYjJlMjU5MmJlZTE0NDdjYzNlZjc3YzM0ZTRjNzI2MDdlN2VkY2Y4MWVmOGJiZjQ3MDQ0Yjk5NmY2Zjc3NzI0MDRiZjAyYzBmMzFiYmM1NDFhYjk2Zjk0ZjE5Nw ».

Constatons :

• Un identifiant unique dans l’URL dont les 42 premiers caractères sont identiques entre tous les liens de l’email et qui doivent, à ce titre, servir à identifier ledit email. Le reste des caractères sert à identifier un lien précis dans l’email et à coder la véritable destination du lien, vers laquelle il convient de rediriger ;
  
  
• Le motif « TrackActions » dans l’URL parle de lui-même ;
  
  
• Le nom de domaine Internet dédié (« t.notif-colissimo-laposte.info ») est loué par LP et il est hébergé par les serveurs de noms du domaine internet « apostello.io » (cf ci-dessous). Apostello est un projet de la société commerciale Isoskele, filiale du groupe La Poste qui, sur son site web (www.isoskele.fr), se présente comme une « agence data marketing et communication » (source : je vais y revenir). Ce nom de domaine est donc dédié au traçage par sa filiale idoine (sinon LP aurait utilisé ses domaines conventionnels).

    $ whois notif-colissimo-laposte.info | grep -E 'Registrant Organization|Name Server'
    Registrant Organization: LA POSTE
    Name Server: dns1.apostello.io
    Name Server: dns2.apostello.io

Pour deux des liens (« CREER MON ESPACE CLIENT LA POSTE » et « Mon espace client La Poste »), l'URL finale (après redirection) contient un code postal obscurci (« state=e71f2e36-73c5-4331-860a-7d057749a0ef ») et un identifiant client (« client_id=cf8351d661a11d883311306c36c4542e »), cf. PJ 3.

    Si je cliquais sur ces liens, mon adresse IP, cette URL, les informations qu'elle véhicule, et plusieurs caractéristiques techniques de mon navigateur web seraient donc consignées dans le journal des serveurs web de LP qui hébergent cette page web, et elles seraient transmises à l’outil de ciblage et de suivi du parcours client (c’est ainsi qu’il est présenté par son éditeur) de Commanders Act, intégré par LP sur son site web. Toutes ces données pourraient donc être utilisées lors d’analyses (d’audience, statistiques, etc.) et de recoupements ultérieurs.

De même, l’email contient une image de traçage (cf. PJ 4, page 34) : « <img src="http ://t.notif-colissimo-laposte.info/cdn/content/3365c92347e1229f46fba86146eff8337b893f3acce7867684aa894b8d44abb64ff0c51216d5ce5cc83a06407904038b4e894506733d1a4cf2b78075f1c6e93c.png" height="1" width="1" alt=""> ».

Il s’agit d’une image transparente de dimensions un pixel sur un pixel au format png, autrement dit d’une image invisible. Il s’agit d’une méthode habituellement utilisée pour traquer les visiteurs d’un site web. Cette image est téléchargée automatiquement à l'ouverture de l'email.

Le pied de page de l’email contient un lien « Informations sur vos données personnelles » (https://www.laposte.fr/pages/recevoir-un-colissimo/courriel). Pour ma situation, « Vous avez reçu une notification pour un colis expédié depuis La France. », LP déclare : « Vos coordonnées nous ont été communiquées par l’expéditeur de votre envoi, pour les besoins exclusifs du suivi de votre colis, de sa livraison et la gestion des réclamations le cas échéant. Colissimo s’engage à en assurer la confidentialité et à ne pas les utiliser à d’autres fins. ». Pourtant, mon adresse emails est bien associée à mon ouverture de l’email LP et à mes éventuels clics sur les liens qu’il contient, ce qui dépasse le cadre de la finalité déclarée sur la même page web, à savoir : m’« informer des différentes étapes du parcours de votre colis conformément au mode de livraison choisi. »

La nécessité de ce traçage (par l’image et les liens) n'est pas établie : il est techniquement possible d'utiliser des liens directs (qui pointent sans détour sur le contenu web final, comme l’outil de suivi des envois). De plus, la consultation du suivi d’un colis étant un service facultatif, complémentaire et incidente à l’envoi d’un colis, LP ne peut se prévaloir d’une quelconque obligation légale pour procéder à ce traçage.

Le client d’un commerçant, destinataire de cet email, n'est pas informé de l’aspect traçant des liens et de l’image qu’il contient 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).

Enfin, l’email fait télécharger deux polices de caractères depuis le service Fonts de la société commerciale états-unienne Google, cf. PJ 4 pages 1, 4, et 5. Ces téléchargements sont automatiques à l’ouverture de l’email.

De même, l’image traçante sus-analysée est hébergée sur le service Azure de la société commerciale états-unienne Microsoft :

    $ dig +short t.notif-colissimo-laposte.info
    apo7prd-af-tracking.azurewebsites.net.
    waws-prod-am2-261.sip.azurewebsites.windows.net.
    waws-prod-am2-261.cloudapp.net.
    13.69.68.5

    $ whois 13.69.68.5 | grep Organization
    Organization: Microsoft Corporation (MSFT)

De même, les liens traçants sus-analysés pointent d’abord vers un site web hébergé chez Microsoft Azure qui, lui, redirige vers la destination finale du lien (l’outil de suivi des envois du site web LP, par exemple) après avoir procédé au traçage. Même nom de domaine internet que pour l’image traçante, donc même preuve que ci-dessus.

De même, d’après ses entêtes « Received », « X-Mailer », et « Message-ID » (cf. PJ 1, pages 6 et suivantes), l’email est envoyé par l’infrastructure technique, hébergée chez Microsoft Azure, du projet Apostello de la société commerciale Isoskele, filiale du groupe La Poste qui, sur son site web (www.isoskele.fr), se présente comme une « agence data marketing et communication ». Cela crédibilise les analyses déroulées aux points précédents selon lesquelles les liens et l’image traçants servent une finalité dissimulée de mesure statistique, d’amélioration du parcours client, et de marketing qui ne peut pas être regardée comme étant nécessaire à l’exécution d’un contrat.

« Received: from mail29247.apostello.io » :
    $ dig +short mail29247.apostello.io
    51.137.29.247

    $ whois 51.137.29.247 | grep -E 'org-name|country' | sort -ru
    org-name: Microsoft Limited
    country: GB

Si « apostello.io » est un site web qui répond du contenu JSON (probablement une API), « www.apostello.io » redirige, lui, vers le site web « www.isoskele.fr » :
    $ wget -O /dev/null www.apostello.io |& grep -E 'Emplacement|Connexion'
    Connexion à www.apostello.io (www.apostello.io)|217.70.184.56|:80… connecté.
    Emplacement : https://www.isoskele.fr/ [suivant]
    Connexion à www.isoskele.fr (www.isoskele.fr)|195.60.188.85|:443… connecté.
    Emplacement : https://isoskele.fr/ [suivant]
    Connexion à isoskele.fr (isoskele.fr)|195.60.188.85|:443… connecté.

De plus, le nom de domaine apostello.io est loué par la société commerciale Cabestan…
    $ whois apostello.io | grep Organization
    Registrant Organization: Cabestan

… qui est l’une des ex-filiales de La Poste qui ont fusionné pour devenir Isoskele : https://lehub.laposte.fr/reperes/poste-lance-isoskele-nouvelle-marque-data-marketing-communication.

Enfin, le projet Apostello est « la migration de notre infrastructure de routage sur le PaaS Azure » d’après le directeur général adjoint d’Isoskele, cf. https://customers.microsoft.com/en-ca/story/849836-la-poste-isoskele-national-government-azure-fr-france.

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), le téléchargement automatique, à l’ouverture de l’email envoyé par LP, de polices de caractères Google Fonts et de l’image traçante, puis le téléchargement d’une page web de traçage et de redirection lors d’un clic sur l’un des liens traçants contenus dans l’email, génèrent, de facto et à l’insu du client d’un commerçant web, des transferts hors de l’Union européenne (UE) de plusieurs données personnelles dudit client : son adresse IP, sa langue (entête HTTP Accept-Language), la date et l’heure de son ouverture de l’email et de ses clics sur les liens, la marque et le modèle de son logiciel de messagerie ainsi que, s’il clique sur un lien, la marque et le modèle de son navigateur web (entête HTTP User-Agent dans les deux cas), etc.

    Pour rappel, la société commerciale Google reconnaît la réception et la conservation, lors de l’utilisation de son service Fonts, des données personnelles énumérées ci-dessus (cf. https://developers.google.com/fonts/faq#what_does_using_the_google_fonts_api_mean_for_the_privacy_of_my_users).

    De plus, l’hébergement du logiciel d’e-mailing et de traçage d’Isoskele et de ses serveurs émetteurs d’emails (MTA) sur le service Azure de Microsoft génère des transferts hors de l’Union européenne (UE) de plusieurs données personnelles supplémentaires du destinataire d’un colis, comme l’association de son adresse emails à un commerçant (il est nommé dans l’email), à un numéro de colis (idem), et à une date d’envoi et de réception estimée dudit colis (idem + horodatage de l’email).

    Quand bien même des mesures complémentaires, comme du chiffrement, seraient mises en œuvre par Isoskele (ce qui reste à vérifier), une partie de ces données personnelles est forcément traitée en clair par Microsoft Azure (contrairement à du stockage inerte avec lequel le traitement peut être déporté), notamment lors des interactions entre le logiciel d’e-mailing et de traçage développé par Isoskele et le logiciel serveur d’emails (MTA) pour l’envoi des emails, fourni par Azure. Cette analyse est confortée par les propos du directeur général d’Isoskele qui déclare avoir recours au « PaaS Azure » (cf. ci-dessus), ce qui signifie que Microsoft fournit et maintient une partie du système et de l’environnement d’exécution sur et avec lesquels fonctionnent les logiciels développés par Isoskele, dont le logiciel serveur d’emails (MTA), les bases de données, les serveurs web, l’équilibreur de charge, et que plusieurs d’entre eux traitent nécessairement les données personnelles en clair.

    Quand bien même Isoskele serait hébergée sur des serveurs de Microsoft Azure situés dans l’UE (cf. ci-dessus, l’IP du serveur emails qui m’a envoyé l’email litigieux est déclarée comme étant louée par la société anglaise Microsoft Limited), Microsoft est une société de droit états-unien, donc le Cloud Act est de pleine application.

Toutes les données personnelles sus-mentionnées 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 ses emails, dans le cas présent de Google Fonts) 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.

    Pour rappel, la mise en œuvre des clauses contractuelles types par Google ne couvre pas son service Fonts, cf. https://policies.google.com/privacy/frameworks.

    Dans leurs politiques de confidentialité (https://www.laposte.fr/donnees-personnelles-et-cookies et https://isoskele.fr/politique-de-confidentialite/), La Poste et Isoskele ne mentionnent pas avoir recours à d’autres instruments juridiques que ceux, invalidés, qui viennent d’être énoncés, ni à des mesures supplémentaires. De ce fait, nous pouvons avoir la certitude qu’elles ne recourent 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 LP (dont Isoskele) met en œuvre aucune mesure technique complémentaire, car le téléchargement des polices de caractères auprès de Google Fonts lors de l’ouverture de l’email envoyé par LP s’effectue directement auprès de l’infrastructure technique de Google. Dès lors, les requêtes web émises par un logiciel de messagerie ne cheminent pas par l’infrastructure technique de LP (dit autrement, il y a un contact direct entre le terminal de l’internaute et les serveurs informatiques de Google), donc elles échappent totalement à LP, qui peut, de ce seul fait, prendre aucune mesure technique.

    Il en va de même pour la requête de téléchargement automatique de l’image traçante à l’ouverture de l’email. Il en va de même pour les requêtes de consultation des pages de redirection lors d’un clic sur l’un des liens traçants contenus dans l’email.

    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.

LP ne recueille pas explicitement le consentement du client d’un commerçant pour les transferts de ses données personnelles sus-référencées vers les États-Unis et ne l’informe pas des risques que ces transferts peuvent comporter pour lui, comme l’impose l’article 49.1a du RGPD. Donc, en l’état, ces transferts de données personnelles ne peuvent pas reposer sur le consentement.

La nécessité des transferts des données personnelles sus-énumérées vers les États-Unis au motif de l’exécution d’un contrat (article 49.1b du RGPD) est irrecevable :

• Les traitements que constitue l’image traçante et les liens traçants sont non-nécessaires et illégaux par absence de base légale (cf. analyse du point précédent), donc les transferts de données personnels vers les États-Unis que génèrent, de facto, les récupérations de l’image et des pages web de redirection aggravent l’infraction initiale ;
  
  
• Un hébergement internalisé (sur les serveurs informatiques de LP) des polices de caractères est techniquement et juridiquement possible à un coût nul alors que leur hébergement par Google porte une atteinte disproportionnée aux droits des usagers de LP. De même, il est possible d’utiliser un fournisseur européen de polices de caractères ou même une police de base embarquée dans toutes les messageries ;
  
  
• L’envoi de l’email en lui-même pourrait être illégal par absence de base légale fondée (cf. le premier point de la présente plainte), auquel cas le transfert de données personnelles vers les États-Unis pour effectuer cet envoi aggrave l’infraction initiale. En tout état de cause, le logiciel de « data marketing » et les serveurs emails pourraient être hébergés sur l’infrastructure technique interne à LP et/ou sur celle d’un prestataire européen.

L’envoi, par LP, de ses emails « Votre Colissimo arrive ! » depuis des serveurs détenus par Microsoft, l’hébergement, par Microsoft, des images et des pages de redirection des liens traçants contenus dans l’email, et par Google de leurs polices de caractères, ainsi que les transferts de données personnelles vers les États-Unis qui en découlent, sont donc illégaux.

Je vais signaler, à la DPO de La Poste, ces manquements au RGPD afin qu’elle s’explique, mais quelles que soient la réponse et les actions, y compris correctrices, qu’elle entreprendrait, les faits relatés ci-dessus constituent en soi des violations du Règlement qui justifient à elles seules le dépôt d’une plainte 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.

(Voix off) ‒ Effet du confinement, prise de conscience collective, en cette rentrée, la pénurie dans certains secteurs d'activités ne se résorbe pas… au grand désarroi de ceux qui travaillent et qui ne comprennent pas ce nouveau comportement.
(Un serveur) ‒ Franchement, j'comprends pas, j'comprends pas qu'il y a des gens qui refusent de se faire parler comme de la merde à la longueur de journée et en plus pour un salaire pourri
(Le patron du serveur) ‒ Hého… hého… hého, t'es pas là pour bavasser, alors tu t'bouges le cul. On n'est pas là pour sponsoriser des feignasses comme toi.
(Voix off) ‒ Et des témoignages comme celui-ci, on en trouve à la pelle.
(Agente d'entretien) ‒ Mais comment peut-on détester se lever à 5 h du mat' pour nettoyer les chiottes ? Ça me dépasse.
(Voix off) ‒ Même son de cloche pour cette caissière qui habite à plus de 60 km de son travail parce qu'elle n'a pas les moyens d'habiter plus près.
(Caissière) ‒ Qu'est-ce qui rebute les gens de dépenser plus d'un tiers de leur salaire en carburant juste pour aller au turbin ? C'est incompréhensible.
(Voix off) ‒ Mais également chez cette infirmière.
(Infirmière) ‒ Ben, 85 heures par semaine à 1700 euros, ça s'refuse pas, hein.
(Voix off) ‒ Ou encore chez ce chauffeur de taxi incrédule.
(Chauffeur de taxi) ‒ Quel est le problème de jamais voir ses enfants réveillés ? Faut juste prendre le pli et après ça va tout seul. C'est tout.
(Voix off) ‒ Oui, pourquoi de plus en plus de gens ne veulent plus aller bosser ? Cela reste un grand mystère sur lequel il faudra bien sérieusement se pencher un jour.

Oui, oui, un jour. :))))
Je crois moyen au grand chambardement. Tout va vite rentrer dans l'ordre établi. Trop d'intérêts divergents (ma pomme d'abord) et pas assez d'imaginaire et de foi en l'humain pour concevoir et croire en une autre organisation ("tous les systèmes sont pourris") pour que ça tienne.

Tract du « Pôle de Renaissance Communiste en France » (qui veut « reconstruire […] un vrai parti communisme ») reçu hier en manif' :

• « […] une bonne partie du budget de l'Etat [ sic, ils ne savent pas écrire un « É » ] passe désormais dans le financement de l'OTAN et d'armes pour les nationalistes pro-nazis de Kiev » ;
  
  
• « Les choix suicidaires de l'[UE] de sanctionner la Russie se retournent contre elle. […] Mais il faut bien obéir aux maîtres américains..! [ sic la ponctuation ] » ;
  
  
• « Et tant pis s'il faut dire merde à l'€uro [ sic ], merde à l'UE, et merde à l'OTAN ! » ;
  
  
• Et j'en passe, on a compris la tonalité.

Et là, le drame : « pour nous rejoindre, nous contacter, avoir des infos sur le PRCF […], une adresse électronique […] : prcf<CENSURE>@gmail.com ».
Site web, certes hébergé chez OVH mais contenant du Google YouTube, du Automattic Gravatar, etc. Le blog ? Du Google Analytics, du Cloudflare, etc. Certaines sections départementales sont hébergées chez Google Blogger.

Fuck les américains, on est communiste, mais qu'est-ce qu'on ferait sans eux. :) Crédibilité, j'écris ton nom.
Sans compter que le chargement automatique des ressources web sus-citées n'est pas conforme au RGPD. Mais bon, comme le dit le tract « contre l'Etat [ sic ] fédéral européen du capital ! » :)

Autre tract, celui du NPA :

• Emails chez Gandi. (En apparence, si ça se trouve, ça renvoie vers du GMail.) ;
  
  
• Sites web hébergés chez OVH contenant du Google YouTube, du Vimeo, du Mailjet. Certaines sections départementales sont hébergées chez Google Blogger ou Facebook.

Même remarque concernant la non-conformité au RGPD.

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 (https://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.

Il existe également https://fr.pgpkeys.eu, qui fait partie du réseau https://spider.pgpkeys.eu/sks-peers (attention : les serveurs sont synchronisés entre eux, mais, contrairement à sks-keyserveurs, il n'y a pas un nom DNS unique qui pointe sur l'ensemble des serveurs, afin de ne pas recréer les fragilités du passé).

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.