GuiGui's Show

Visualiser les circonscriptions électorales avec OpenStreetMap. \o/

Le 22/04/2022, je me suis connecté à mon espace personnel / client (consultation de mes comptes, virements, etc.) sur le site web de la Banque Populaire (BP). C'était ma première connexion à cet espace modernisé / relooké.

Je constate deux problèmes :

1. plusieurs ressources / composants / éléments des pages web (police, CSS, JavaScript) sont récupérés auprès d'acteurs économiques états-uniens en l'absence de base légale ;
   
   
2. la base légale du chargement de plusieurs ressources / composants / éléments des pages web (JavaScript) me semble irrecevable.

ÉDIT DU 11/07/2022 : suite ici. FIN DE L'ÉDIT.

Droit

Schrems II versus Google Fonts

Dans la première catégorie, le cas le plus problématique est la récupération de polices de caractères / CSS auprès de Google Fonts.

Lors de la consultation de mon espace personnel sur le site web de la BP, mon adresse IP et d'autres éléments techniques permettant d'affirmer que telle adresse IP est cliente de BP (HTTP Referer, HTTP CORS Origin, etc.), à quelles dates+heures (et donc fréquence) elle consulte l'espace client BP, et quelles rubriques (relevé de compte, virements, documents) elles y consulte, sont automatiquement transmis à Google dans le cadre du chargement de ces ressources additionnelles. C'est ainsi que fonctionne le web, on ne peut pas y couper. Et croire qu'un serveur web conserve aucun journal des requêtes reçues est de la folie.

Or, l'arrêt de 2020 dit « Schrems II » de la Cour de Justice de l'Union européenne a rendu caduque le Privacy Shield, acte juridique de la Commission européenne qui disposait que le cadre législatif états-unien en matière de protection des données personnelles était en adéquation avec celui de l'UE, et qui, de ce fait, autorisait, le transfert de données personnelles de manière open-bar (automatique) entre l'UE et les USA. Dès lors, pour transférer des données personnelles aux États-Unis, il faut un consentement explicite et/ou tout un cadre interne à la société commerciale et/ou des accords avec l'autorité de contrôle du coin, et/ou…, voir Transferts de données hors UE.

Or, si je refuse le téléchargement de ressources depuis Google Fonts (avec les extensions pour navigateur web uBlock Origin ou uMatrix), l'espace client BP est inutilisable : tout le contenu utile est décalé vers la gauche au lieu d'être centré ; le même contenu est décalé vers le haut et partiellement tronqué ; l'icône « croix » qui permet de fermer les rubriques comme « Documents » ou « Prélèvements reçus » n'apparaît pas, ce qui complique la navigation (le bouton « page précédente » de tout navigateur web ne répond pas totalement au besoin à cause de protections légitimes contre le rejeu) ; la modification du motif d'un virement bancaire est impossible car les champs de saisie, leur description et les messages d'aide / d'erreurs s'empilent et empêchent la saisie.

Dès lors, l'utilisation de Google Fonts ne peut pas reposer sur la base légale du consentement explicite car les dysfonctionnements engendrés par le refus constitueraient un vice du consentement.

De toute façon, à ce jour, la BP ne demande pas un consentement explicite pour l'utilisation de Google Fonts ni pour le transfert de données personnelles hors de l'UE que cela entraîne. Or, le chargement de Google Fonts peut légalement intervenir une fois ces deux consentements exprimés.

L'utilisation de Google Fonts ne peut pas reposer sur la base légale de l'intérêt légitime car elle a des exigences de nécessité et de proportionnalité entre les intérêts du responsable du traitement et ceux de ceux qui subissent le traitement. Or, un hébergement internalisé des polices de caractères est possible à coût insignifiant, ce qui ne coche pas les cases d'une externalisation nécessaire et proportionnée.

La décision 3 O 17493/20 du 20/01/2022 de la Cour régionale de Munich appuie cette analyse. Cette décision de justice est très finement analysée ici.

Schrems II versus les autres ricains

Dans la première catégorie, on trouve également des frameworks de gestion de la performance (AppDynamics), des tags marketings (Tealium / tiqcdn.com), et de la gestion de la relation client / chatbot (Ibenta). Toutes récupérées depuis des sociétés commerciales ricaines.

Là encore, la BP n'informe pas du transfert de données personnelles hors de l'UE.

La base légale de l'intérêt légitime est bancale (sauf pour Ibenta, peut-être), tout comme celle du consentement explicite (mais ça dépend des implémentations). Les arguments vont arriver ci-dessous, dans l'analyse de la deuxième catégorie.

Base légale des traitements UE

Dans la deuxième catégorie se trouvent des ressources / composants / éléments récupérés depuis des acteurs économiques européens comme KeyCDN (kxcdn.com, gestion de la performance applicative) et Kameleoon (tests A/B).

Puisque ces sociétés commerciales sont européennes, l'arrêt Schrems II n'est pas un argument recevable. En revanche, il n'existe pas d'échappatoire à la nécessité d'une base légale. Traitement prévu par la loi ? Non. Traitement nécessaire à l'exécution d'un contrat ? Non, il tourne sans ça.

Consentement explicite via le panneau de gestion des cookies ? Non, car même en cas de refus des cookies dans ce panneau, ces ressources / composants / éléments seront tout de même téléchargés par le navigateur web du client de la BP. Le refus des cookies les rend inertes / inactifs (en tout cas, on peut l'espérer), mais la récupération en elle-même transmet, sans consentement, des données personnelles à des acteurs économiques tiers (cf début de ce shaarli).

Intérêt légitime ? Pour moi, c'est irrecevable. Un client peut-il légitimement s'attendre au téléchargement d'un système de gestion de la performance (KeyCDN) alors qu'il ignore l'existence de tels produits / services, qu'il n'en comprend pas la définition (sujet extrêmement technique), et qu'il peut n'avoir que faire que son espace client soit performant à la seconde près ? Est-il proportionné d'utiliser simultanément plusieurs systèmes de gestion de la performance (KeyCDN, AppDynamics) sur un même espace client ? Un client peut-il légitimement s'attendre à la récupération d'un système de tests A/B (Kameleoon), approche essentiellement marketing, dans son espace client (qui renvoie à des notions d'intimité, de confort, à une relation individuelle entre une société commerciale et son client) ? Sait-il au moins que ça existe ? En comprend-il les tenants et aboutissements ? Ces traitements sont-ils nécessaires ? Mêmes questions pour les tag marketings de tiqcdn.

ÉDIT DU 08/05/2022 À 23 H 50 : Aeris me signale que je raconte nawak sur l'intérêt légitime. Il s'agit de celui du responsable du traitement (BP, dans le cas présent), pas de celui de l'individu dont les données sont exploitées (le client BP). Osef de savoir ce que le client pense ou est en capacité de comprendre. L'intérêt légitime est justement une base légale pour légaliser une dissonance entre ce que veut le responsable du traitement d'un côté, et l'individu de l'autre, cas qui ne peut pas se régler avec du consentement, du coup.

L'intérêt peut être celui du responsable du traitement ou d'un tiers, commercial ou sociétal, mais, comme je l'ai indiqué dans la section sur Google Fonts, il doit être en adéquation avec l'objectif affiché, nécessaire, et proportionné avec les droits et les libertés des personnes dont les données sont exploitées.

Selon Aeris, un système de gestion de la performance, de test A/B, et de tags marketings ne répond pas à ces critères : il n'y a pas de réel intérêt dans le contexte d'un espace client (j'ajoute qu'on peut même imaginer des solutions moins intrusives, comme un sondage, une prise en compte des retours spontanés auprès des conseillers, etc.), on peut internaliser de telles solutions (le coût induit n'est pas un critère suffisant pour botter en touche, d'après l'EDPB), et le flicage induit par une solution externalisée porte une atteinte (inutile, du coup) aux droits des personnes.

FIN DE L'ÉDIT DU 08/05/2022 À 23 H 50.

Technique

D'un point de vue technique, aussi, le chargement de ressources externes est une calamité.

Dépendance à des acteurs économiques hégémoniques avec lesquels la BP n'a pas contracté. Donc aucune garantie, ni de qualité de service ni de délai avant rétablissement en cas de panne (même Google a été en panne des heures), ni même de pérennité (même Google a déjà fermé des services). Or, comme je l'ai exposé ci-dessus, l'espace personnel BP est inutilisable sans Google Fonts, donc il vaudrait mieux réduire les dépendances inutiles.

Panne. Une mise à jour unilatérale et inattendue d'une bibliothèque de fonctions JavaScript (ou d'une feuille de style ou…) par le tiers peut causer une panne. Pour peu que le développement de l'espace client BP soit sous-traité, le temps de rétablissement peut se compter en jours / semaines. Ouiiii, utiliser une version précise d'une bibliothèque de fonctions permet d'éviter ce risque, mais ce n'est pas toujours possible.

Sécurité. Que se passe-t-il si le composant chargé depuis le tiers est substitué par une version malveillante ? Par le tiers lui-même (employé malveillant, erreur, etc.) ou par un attaquant de celui-ci ? Dans le cas de Google Fonts, ce risque est minime (l'équipe sécurité de Google est balèze), mais ce n'est pas le cas pour toutes les externalisations. D'où SRI, une couche de merde supplémentaire…

Lenteur. Il n'y a plus de mutualisation du cache du navigateur web entre deux sites web qui intègrent une même ressource, donc elle sera téléchargée pour chaque site. Le téléchargement de ressources / éléments web externalisés ralentit mécaniquement le chargement de l’espace client BP, même avec toutes les techniques d’optimisation du temps de chargement (comme le report du JavaScript en fin de page, etc.). En effet, le navigateur web doit effectuer des requêtes DNS supplémentaires, puis des connexions HTTP supplémentaires, etc. Or, l’établissement d’une connexion HTTP reste coûteux en temps, même en 2022. Pour rappel, cela s’explique par la poignée de main en 3 échanges de TCP, puis la poignée de main en 2 échanges minimum de TLS (chiffrement, authentification, intégrité), etc. Sans compter la perte des bénéfices du multiplexage des requêtes web introduit par HTTP/2, puisque ce multiplexage peut avoir lieu uniquement quand les ressources sont logées sur un même nom / grappe de serveurs. Le coût d’une connexion DNS ou HTTP supplémentaire dépend de la latence, donc de la qualité du réseau depuis lequel un client BP accède à son espace personnel : un accès ADSL en fin de ligne à la campagne ou un accès 3G sur une antenne surchargée ne donneront pas le même résultat qu’un accès en fibre optique.

Courriers

J'ai donc envoyé deux courriers recommandés avec accusé de réception à la Banque Populaire. L'un pour le service réclamations. J'y demande le transfert de ma demande aux équipes informatiques de BP et j'y cause essentiellement technique. L'autre est adressé au délégué à la protection des données personnelles. J'y cause exclusivement de droit.

J'ai doublé le tout par deux plaintes auprès de la CNIL. Pourquoi pas une seule ? La CNIL a tendance à faire le strict minimum : dès qu'un des objets d'une plainte est satisfait (selon elle), la plainte est fermée. Sans compter qu'elles n'ont pas tout à fait le même objet. La première plainte concerne le transfert sans base légale de données personnelles aux États-Unis, l'autre de transfert de données personnelles à des acteurs économiques européens selon des bases légales discutables.

Je ne suis pas naïf, je sais que mes démarches sont vaines, mais j'aurai au moins essayé d'améliorer les choses.

Service réclamations BP

Objet : observations sur le nouvel espace client

Bonjour,

Je suis client de l’agence XXXXXXXXXX de la Banque Populaire XXXXXXXXXX (BP XXXXXXXXXX).

Le 22/04/2022, je me suis connecté à mon espace personnel sur le site web de la BP depuis un ordinateur fixe (pas depuis une application mobile). Je suis arrivé sur une nouvelle version de celui-ci.

J’y ai constaté deux problèmes. Pouvez-vous, svp, transmettre le présent courrier aux équipes techniques en charge du développement du nouvel espace personnel BP (I-BP ou BPCE-IT) ?

Premier problème : externalisation.

Plusieurs éléments / ressources qui composent l’espace client / personnel sont téléchargés depuis des acteurs extérieurs à la BP : police de caractères / feuille de style chez Google (Fonts), JavaScript depuis appdynamics.com, ibenta.io, et kxcdn.com. En cascade, ces éléments provoquent eux-mêmes le téléchargement de ressources depuis des acteurs externes supplémentaires.

Certes, l’ancien espace client BP contenait déjà des ressources téléchargées depuis des acteurs externes comme facil-it.com, kameleoon.com et tiqcdn.com. Ce n’était pas folichon, et, pour sûr, cela ne constitue pas une excuse valable pour ajouter de nouveaux acteurs extérieurs sur le nouvel espace client.

Ces contenus / ressources / éléments externalisés posent problèmes à plusieurs titres.

1) En application de l’arrêt « Schrems II » de la Cour de Justice de l’Union européenne, l’utilisation de Google Fonts n’est pas conforme au Règlement Général sur la Protection des Données (RGPD). En effet, lors d’une consultation de l’espace personnel BP, l’adresse IP du client (donnée personnelle) et plusieurs en-têtes techniques permettant d’affirmer que le client consulte l’espace client BP (HTTP Referer, HTTP CORS Origin, etc.), sont transférés automatiquement à Google, société commerciale états-unienne, lors du téléchargement des ressources. Cela constitue un transfert de données personnelles en dehors de l’Union européenne, à destination des États-Unis qui ne disposent pas d’un niveau de protection adéquat des données personnelles.

Ce raisonnement s’applique également aux ressources des sociétés commerciales états-uniennes AppDynamics (appdynamics.com), Tealium (tiqcdn.com), et Ibenta (ibenta.io) que vous utilisez également dans l’espace personnel BP.

Un tribunal allemand a statué en ce sens concernant Google Fonts. Voir :

• Décision originale : https ://s.42l.fr/de-gf ;
  
  
• Analyse https ://s.42l.fr/bpgf qui résume bien en quoi, en sus de l’arrêt Schrems II, l’utilisation de Google Fonts ne peut pas reposer sur la finalité de l’intérêt légitime (car un hébergement en interne est possible à coût quasi-nul) ni sur le consentement explicite (car sans Google Fonts, l’espace client BP dysfonctionne, ce qui contraint le client à accepter le traitement de données personnelles réalisé par Google, ce qui relève du vice de consentement), que vous ne recueillez de toute façon pas ;
  
  
• Un parallèle est à déduire de la décision des CNIL européennes d’une non-conformité RGPD de Google Analytics (voir https ://s.42l.fr/cnil ) et de la position de la CNIL sur le service reCAPTCHA de Google (voir https ://s.42l.fr/cnil-ca et https ://s.42l.fr/cnil-ca2) : la problématique est similaire.

2) Le chargement de ressources / éléments externes fait fuiter une partie de la vie privée de vos clients vers les acteurs économiques sus-cités (Google, AppDynamics, etc.). En effet, ces entités collectent, dans leurs journaux techniques (logs), que telle adresse IP a consulté l’espace client BP à telle date et heure. Ils collectent donc l’information que telle adresse IP est un client BP (puisque les ressources ont été téléchargées pour le compte de l’espace personnel BP). Ils peuvent également déduire, certes par un traitement additionnel, la fréquence de consultation de l’espace client BP par une adresse IP et des comportements (personne stressée par ses finances ou non ?). Pour rappel, le navigateur web communique automatiquement ces informations lors du téléchargement de ressources (adresse IP, en-têtes HTTP Referer, HTTP CORS Origin, etc.).

3) Vous dépendez d’acteurs économiques hégémoniques avec qui vous n’avez pas de contrat, donc aucune garantie, ni de qualité de service, ni de délai avant rétablissement en cas de panne (Google a déjà été en panne plusieurs heures, voir https ://s.42l.fr/pa-go )), ni même de pérennité du service (Google a déjà fermé certains de ces services populaires, voir https://killedbygoogle.com/).

Or, sans Google Fonts, l’espace client BP est inutilisable :

• Tout le contenu est décalé à gauche au lieu d’être centré ;
  
  
• De même, le contenu est décalé vers le haut et le haut des pages est coupé par le menu ;
  
  
• La croix en haut à droite qui permet de fermer les rubriques comme « Documents » ou « Prélèvements reçus » n’apparaît pas, ce qui complique singulièrement la navigation (la fonction « reculer d’une page » de tout navigateur web ne répond pas entièrement au besoin, essayez vous-même, vous verrez) ;
  
  
• La modification du motif d’un virement bancaire est impossible, car la description des champs de saisie et les messages d’erreur / d’aide lors de la saisie s’empilent les uns sur les autres.

Ces problèmes n’apparaissent pas lorsque les ressources sont récupérées depuis Google Fonts.

L’ancien espace personnel restait utilisable en cas de panne de tiqcdn ou de kameleoon. Il s’agit donc d’une régression.

J’ajoute que ce type d’externalisation fait peser un risque de panne : par absence d’historisation (versioning), une mise à jour unilatérale, par le prestataire, d’une bibliothèque de fonctions JavaScript ou d’une feuille de style CSS ou de toute autre ressource externe, provoque des dysfonctionnements sur l’espace personnel BP (aussi impactant que ceux sus-mentionnés). Pour peu que le développement de l’espace personnel BP soit sous-traité, le temps de rétablissement du service se comptera en jours.

Un dernier risque est un risque de sécurité si le contenu chargé par / depuis l’espace personnel BP est substitué par un autre par le prestataire ou par un attaquant de celui-ci. Dans le cas de Google Fonts, ce risque est minime, je vous l’accorde, mais ce n’est pas le cas de tous les acteurs de ce type d’externalisation.

4) Le téléchargement de ressources / éléments web externalisés ralentissent mécaniquement le chargement de l’espace client BP, même avec toutes les techniques d’optimisation du temps de chargement (comme le report du JavaScript en fin de page, etc.). En effet, le navigateur web doit effectuer des requêtes DNS supplémentaires, puis des connexions HTTP supplémentaires, etc. Or, l’établissement d’une connexion HTTP reste coûteux en temps, même en 2022.

Pour rappel, cela s’explique par la poignée de main en 3 échanges de TCP, puis la poignée de main en 2 échanges minimum de TLS (chiffrement, authentification, intégrité), etc. Sans compter la perte des bénéfices du multiplexage des requêtes web introduit par HTTP/2, puisque ce multiplexage peut avoir lieu uniquement quand les ressources sont logées sur le même nom que la page web qui les intègrent.

Le coût d’une connexion DNS ou HTTP supplémentaire dépend de la latence, donc de la qualité du réseau depuis lequel un client BP accède à son espace personnel : un accès ADSL en fin de ligne à la campagne ou un accès 3G sur une antenne surchargée ne donneront pas le même résultat qu’un accès en fibre optique.

En conclusion, vous gagnerez tout autant que vos clients à internaliser au maximum les ressources qui composent l’espace client BP pour les différents motifs exposés ci-dessus.

D’autant qu’il y a aucune difficultés technique pour internaliser certaines ressources, notamment Google Fonts : hébergement de la police de caractères / de la feuille de style sur les serveurs informatiques de BP.

Vous pouvez également délester l’espace personnel / client BP des ressources externes superflues : sur un espace client, un système de tag marketing (tiqcdn) est-il vraiment justifiable ? Un framework pour la gestion de la performance (KeyCDN, AppDynamics) est-il vraiment nécessaire ? Est-il nécessaire d’en cumuler deux ? Même questionnement à propos d’un framework d’A/B testing (Kameleoon). Même interrogation pour les autres ressources.

Ma demande : pouvez-vous, svp, retirer toutes les ressources / éléments externes présents sur l’espace client BP ?

Deuxième problème : […]

Cordialement.

DPO BP

Objet : non-conformité RGPD nouvel espace client / personnel

Bonjour,

Je suis client de l’agence XXXXXXXXXX de la Banque Populaire XXXXXXXXXX (XXXXXXXXXX).

Le 22/04/2022, je me suis connecté à mon espace personnel sur le site web de la BP depuis un ordinateur fixe (pas depuis une application mobile). Je suis arrivé sur une nouvelle version de celui-ci.

Plusieurs éléments / ressources qui composent l’espace client / personnel sont téléchargés depuis des acteurs extérieurs à la BP : police de caractères / feuille de style depuis Google (Fonts), JavaScript depuis appdynamics.com, ibenta.io, et kxcdn.com. En cascade, ces éléments provoquent eux-mêmes le téléchargement de ressources depuis des acteurs externes supplémentaires.

En application de l’arrêt « Schrems II » de la Cour de Justice de l’Union européenne, l’utilisation de Google Fonts n’est pas conforme au Règlement Général sur la Protection des Données (RGPD).

En effet, lors d’une consultation de l’espace personnel BP, l’adresse IP du client (donnée personnelle) et plusieurs en-têtes techniques permettant d’affirmer que le client consulte l’espace client BP (HTTP Referer, HTTP CORS Origin, etc.), sont communiqués automatiquement à Google, société commerciale états-unienne, lors du téléchargement des ressources. Cela constitue un transfert de données personnelles en dehors de l’Union européenne, à destination des États-Unis qui ne disposent pas d’un niveau de protection adéquat des données personnelles.

Le chargement de ressources / éléments externes fait fuiter une partie de la vie privée des clients BP vers les acteurs économiques sus-cités (Google, AppDynamics, etc.). En effet, ces entités collectent, dans leurs journaux techniques (logs), que telle adresse IP a consulté l’espace client BP à telle date et heure. Ils collectent donc l’information que telle adresse IP est un client BP (puisque les ressources ont été téléchargées pour le compte de l’espace personnel BP). Ils peuvent également déduire, certes par un traitement additionnel, la fréquence de consultation de l’espace client BP par une adresse IP et des comportements (personne stressée par ses finances ou non ?). Pour rappel, le navigateur web communique automatiquement ces informations lors du téléchargement de ressources (adresse IP, en-têtes HTTP Referer, HTTP CORS Origin, etc.).

Sans le chargement de ressources depuis Google Fonts, l’espace client BP est inutilisable :

• Tout le contenu est décalé à gauche au lieu d’être centré ;
  
  
• De même, le contenu est décalé vers le haut et le haut des pages est coupé par le menu ;
  
  
• La croix en haut à droite qui permet de fermer les rubriques comme « Documents » ou « Prélèvements reçus » n’apparaît pas, ce qui complique singulièrement la navigation (la fonction « reculer d’une page » de tout navigateur web ne répond pas entièrement au besoin, essayez vous-même, vous verrez) ;
  
  
• La modification du motif d’un virement bancaire est impossible, car la description des champs de saisie et les messages d’erreur / d’aide lors de la saisie s’empilent les uns sur les autres.

Ces problèmes n’apparaissent pas lorsque les ressources sont récupérées depuis Google Fonts.

Un tribunal allemand a statué en ce sens concernant Google Fonts. Voir :

• Décision originale : https ://s.42l.fr/de-gf ;
  
  
• Analyse https ://s.42l.fr/bpgf qui résume bien en quoi, en sus de l’arrêt Schrems II, l’utilisation de Google Fonts ne peut pas reposer sur la finalité de l’intérêt légitime (car un hébergement en interne est possible à coût quasi-nul) ni sur le consentement explicite (car sans Google Fonts, l’espace client BP dysfonctionne, ce qui contraint le client à accepter le traitement de données personnelles réalisé par Google, ce qui relève du vice de consentement), que vous ne recueillez de toute façon pas ;
  
  
• Un parallèle est à déduire de la décision des CNIL européennes d’une non-conformité RGPD de Google Analytics (voir https ://s.42l.fr/cnil ) et de la position de la CNIL sur le service reCAPTCHA de Google (voir https ://s.42l.fr/cnil-ca et https ://s.42l.fr/cnil-ca2) : la problématique est similaire.

Ce raisonnement s’applique également aux ressources des sociétés commerciales états-uniennes AppDynamics (appdynamics.com), Tealium (tiqcdn.com) et Ibenta (ibenta.io) qui sont également chargées par l’espace client BP.

Mes demandes :

• Faire retirer les ressources / éléments / composants de Google Fonts, AppDynamics, Tealium (tiqcdn.com) et Ibenta de l’espace personnel / client de BP. Motif : arrêt Schrems II de la CJUE et déclinaisons ;
  
  
• Faire retirer, de l’espace client / personnel de BP, les ressources / éléments / composants de KeyCDN et de Kameleoon. Sociétés européennes, certes, mais :
  • le consentement n’est pas une finalité applicable (ces ressources seront rendues inertes par le refus des cookies mais seront tout de même chargées, faisant fuiter une partie de la vie privée des clients BP, lire ci-dessus) ;
    
    
  • l’intérêt légitime n’est à mon sens pas recevable : un client peut-il légitimement s’attendre à un système de gestion de la performance (KeyCDN) alors qu’il ignore l’existence de tels produits / services et qu’il n’en comprendra pas la définition ? Est-il proportionné d’en charger plusieurs (KeyCDN, AppDynamics) sur un même espace client ? Idem pour un système de test A/B (Kameleoon) : que vient faire une approche marketing dans un espace client ? Le client BP peut-il légitimement s’y attendre ?

Cordialement.

CNIL - Google Fonts / AppDynamics / tiqcdn.com / Ibenta

Bonjour,

Je suis client de la Banque Populaire XXXXXXXXXX (BP). Le 22/04/2022, je me suis connecté à mon espace client / espace personnel (consultation des comptes, virements, etc.) sur le site web de celle-ci. Je suis arrivé, pour la première fois, sur un espace client modernisé / relooké (avec un tutoriel de présentation et la possibilité de revenir à l'ancienne version via un discret lien dans mon profil).

Plusieurs éléments / composants / ressources qui composent cet espace client sont téléchargés chez des acteurs économiques externes à la BP : police de caractères / CSS chez Google Fonts, JavaScript depuis AppDynamics, Tealium, Ibenta, et KeyCDN qui, eux-mêmes, par cascade, télécharge des ressources chez des acteurs extérieurs supplémentaires.

Or, en application de l'arrêt dit « Schrems II » de la Cour de Justice de l'Union européenne, l'utilisation de Google Fonts n'est pas conforme au RGPD. Lors de la consultation de mon espace personnel BP, mon adresse IP et d'autres éléments techniques qui permettent d'affirmer que telle adresse IP est cliente BP (HTTP Referer, HTTP CORS Origin, etc.) sont transmis automatiquement à la société commerciale Google. Cela constitue un transfert de données personnelles en dehors de l'UE, à destination des États-Unis, qui ne disposent pourtant pas d'un niveau de protection adéquat des données personnelles.

Si je refuse le téléchargement de ressources depuis Google Fonts (avec les extensions pour navigateur web uBlock Origin ou uMatrix), l'espace client BP est inutilisable : tout le contenu utile est décalé vers la gauche au lieu d'être centré ; le même contenu est décalé vers le haut et partiellement tronqué ; l'icône « croix » qui permet de fermer les rubriques comme « Documents » ou « Prélèvements reçus » n'apparaît pas, ce qui complique la navigation (le bouton « page précédente » de tout navigateur web ne répond pas totalement au besoin à cause de protections légitimes contre le rejeu) ; la modification du motif d'un virement bancaire est impossible car les champs de saisie, leur description et les messages d'aide / d'erreurs s'empilent et empêchent la saisie.

L'utilisation de Google Fonts ne peut pas reposer sur l'intérêt légitime car un hébergement interne / internalisé est possible à coût insignifiant ni sur un consentement explicite (qui à ce jour, n'est pas demandé par la BP) car les dysfonctionnements engendrés par le refus constitueraient un vice du consentement. La décision 3 O 17493/20 du 20/01/2022 de la Cour régionale de Munich appuie cette analyse.

Ce raisonnement s'applique également à d'autres ressources / éléments / composants récupérés auprès d'autres sociétés commerciales états-uniennes lors de la navigation dans l'espace client / personnel BP : AppDynamics, Tealium (tiqcdn.com), et Ibenta.

Le 29/04/2022, j'ai signalé, par LRAR, ces infractions au DPO de la Banque Populaire XXXXXXXXXX ainsi qu'au service réclamations de celle-ci.

Cordialement.

CNIL - KeyCDN / Kameleoon

Bonjour,

Je suis client de la Banque Populaire XXXXXXXXXX (BP). Le 22/04/2022, je me suis connecté à mon espace client / espace personnel (consultation des comptes, virements, etc.) sur le site web de celle-ci. Je suis arrivé, pour la première fois, sur un espace client modernisé / relooké (avec un tutoriel de présentation et la possibilité de revenir à l'ancienne version via un discret lien dans mon profil).

Plusieurs éléments / composants / ressources qui composent cet espace client sont téléchargés chez des acteurs économiques externes à la BP mais européens : JavaScript depuis KeyCDN (kxcdn.com) et Kameleoon.

Pour ces deux traitements, le consentement explicite n'est pas une finalité applicable, car, même en cas de refus des cookies dans le bandeau dédié, ces ressources seront tout de même téléchargées par le navigateur web. Le refus des cookies les rend inertes / inactives, mais, lors de la consultation de chaque page de mon espace personnel BP, mon adresse IP et d'autres éléments techniques permettant d'affirmer que telle adresse IP est cliente BP (HTTP Referer, HTTP CORS Origin, etc.) et à quelles dates+heures elle consulte l'espace client BP, sont quand même transmis automatiquement aux sociétés commerciales sus-citées. Certaines de ces informations techniques (HTTP Referer) permettent aux sociétés commerciales sus-citées d'enregistrer, toujours dans le journal de leurs serveurs web, quelles rubriques précises de mon espace client BP (relevé de comptes, virements, etc.) ont été consultées par telle adresse IP à telle heure.

L'intérêt légitime est tout autant inapplicable à mon sens. Un client peut-il légitiment s'attendre au téléchargement d'un système de gestion de la performance (KeyCDN) alors qu'il ignore l'existence de tels produits / services, qu'il n'en comprend pas la définition (sujet extrêmement technique), et qu'il peut n'avoir que faire que son espace client soit performant à la seconde près ? Est-il proportionné d'utiliser simultanément plusieurs systèmes de gestion de la performance (KeyCDN, AppDynamics) sur un même espace client ? Un client peut-il légitimement s'attendre à la récupération d'un système de tests A/B (Kameleoon), approche essentiellement marketing, dans son espace client (qui renvoie à du confort, à de l'intimité, à une relation individuelle entre une société commerciale et son client) ? Sait-il au moins que ça existe ? En comprend-t-il les tenants et aboutissements ? Ces traitements sont-ils nécessaires ?

Le 29/04/2022, j'ai signalé, par LRAR, ces infractions au DPO de la Banque Populaire XXXXXXXXXX ainsi qu'au service réclamations de celle-ci.

Cordialement.

‒ Le dîner est arrivé ! Alors, conformément aux demandes, nous avons donc des pizzas ananas tofu anchois agneau raclette.
‒ Une de chaque ?
‒ Hé non, tout mélangé !
‒ Ooooh !
‒ Ha bah oui quand personne ne fait des concessions, ça fait forcément un résultat dégueulasse. Que ça vous serve de leçon […]
[…]
‒ En tout cas, on est tous réunis aujourd'hui autour d'une même conviction : c'est que pour s'approcher du pouvoir, il faut accepter de s'asseoir sur ses convictions.

Gros +1. C'est exactement ça. :)

Tiroir Hemera multimode upgrader = faire passer du 10 G monomode (OS1/2) sur des fibres multimodes (OM1).
Cas d'usage : rentabiliser les investissements d'il y a 20 ans (on posait des fibres multimodes) et/ou passer au 10 G dans des environnements contraints (bâtiment protégé, etc.).

Boîtier passif 1U 19 pouces pour 4/8/12 fibres OM1. J'avoue que le côté passif (donc un jeu purement physique / optique) me bluffe.

Distance / portée : < 2 km. Au-delà de 800 m, il faut un boîtier à chaque extrémité des fibres multimodes. En deçà, une épissure entre une fibre multimode et une jarretière monomode suffirait.

Fabricant : Acome. SCOP. Produit fabriqué en France (usine FR, a dit le commercial).

Prix : 6 k€ pour un boîtier 12 fibres. En comparaison, nous avons dépensé 8 k€ TTC pour la pose de 24 fibres optiques monomodes sur 4 segments (soit 8 cassettes + soudures, qui est ce qui coûte le plus cher dans une pose de fibres). Et pour un segment, il y avait des contraintes : bâtiment protégé, absence de faux plafonds, plans des chemins de câbles perdus, etc.

Mon avis : bricolage (le commercial a reconnu, sans que je l'y pousse, qu'une fibre monomode est préférable et que leur produit est un palliatif pour les cas où l'on ne peut pas remplacer de la multi par de la mono d'un claquement de doigts) + pas rentable.

Ma liste réduite d'autorités de certification (AC) répond toujours à mes besoins plus de 21 mois après. :)

Fin mars 2022, j'ai constaté la présence des AC suivantes dans mon Firefox et je les ai également désactivé sans conséquence néfaste à ce jour :

ANF Secure Server Root CA
Certum EC-384 CA
Certum Trusted Root CA
certSIGN Root CA G2
e-commercie monitoring GmbH - globaltrust 2020
FNMT-RCM - AC RAIZ GNMT-RCM SEVIDORES SEGUROS
GlobalSign Root R46
GlobalSign Root E46
Microsec Ltd. - e-Szigno Root CA 2017
Microsoft RSA Root Certificate Authority 2017
Microsoft ECC Root Certificate Authority 2017
Naver Global Root Certification Authority
Trustware Global ECC P256 Certification Authority
Trustware Global ECC P384 Certification Authority
Trustware Global Certification Authority

Dans un précédent shaarli sur rsyslog, j'ai consigné comment configurer rsyslog pour créer automatiquement une arborescence variable et un nom de journal selon un template genre /var/log/distant/<ANNÉE>/<MOIS>/<JOUR>/bidule/programme.log.

Par défaut, les dossiers créés par rsyslog ont le mode 0700 (0644 pour les fichiers). Ainsi, un compte utilisateur local non-root ne peut pas parcourir l'arborescence de stockage des journaux.

D'après sa documentation, le module omfile de rsyslog propose un paramètre pour configurer le mode des dossiers créés : « dirCreateMode » (« FileCreateMode » pour les fichiers).

Exemple d'utilisation :

template (name="chemin-prog"  type="string" string="/var/log/distant/%$year:::%/%$month:::%/%$day:::%/bidule/programme.log")

if $hostname == 'machine1' then {
    action(type="omfile" dynaFile="chemin-prog" dirCreateMode="0755")
    stop
}

Une autre façon de faire est de créer un groupe d'utilisateurs dédiés à la consultation des journaux, genre « log » et de configurer rsyslog pour attribuer les dossiers créés à ce groupe.

C'est légèrement plus propre car ça évite de donner un accès en lecture seule aux journaux à tous les comptes utilisateurs de la machine. Mais ça suppose toujours de changer le mode avec lequel les dossiers sont créés (0700 = le groupe n'a pas d'accès non plus).

Le plugin omfile de rsyslog propose les paramètres « dirGroup » / « dirGroupNum » (« fileGroup » / « fileGroupNum » pour les fichiers).

Exemple :

template (name="chemin-prog"  type="string" string="/var/log/distant/%$year:::%/%$month:::%/%$day:::%/bidule/programme.log")

if $hostname == 'machine1' then {
    action(type="omfile" dynaFile="chemin-prog" dirGroup="log" dirCreateMode="0750")
    stop
}

Il est également possible de modifier l'utilisateur propriétaire du journal ou de l'arborescence : « fileOwner », « dirOwner », « fileOwnerNum », « dirOwnerNum ».

Évidemment, ces paramètres du plugin omfile peuvent être utilisés même quand on n'utilise pas de template. ;)

Par défaut dans OpenStreetMap (OSM), les noms des villes et des pays sont dans la langue locale dudit pays (russe, arabe, chinois, etc.). Pas même en anglais et encore moins dans la langue du visiteur.

Pour avoir ces noms en français et en écriture latine, on peut consulter des projets tiers qui réutilisent les données d'OSM. Les deux seuls en français à cet instant sont :

• osMAP FR ;
  
  
• OSM-FR.

Forcément, il y a aussi des inconvénients :

• Lenteur (car moins de ressources informatiques derrière) ;
  
  
• Carte moins détaillée avec moins de points d'intérêts (car il faut que les traductions existent dans les données OSM). Exemple ? Centre-ville de Varsovie (les hôpitaux, l'obélisque, etc.).

On peut supposer que les autres projets apparaîtront sur la page dédiée à l'internationalisation du wiki officiel.

Source : https://mamot.fr/@klorydryk/108185595944513572 via https://mastodon.gougere.fr/@bortzmeyer.

Il y a quelques mois, l'extinction impromptue de l'ampoule a repris. Tout comme la variation de l'intensité lumineuse.

En levant les yeux, je constate que le spot est plus tourné d'un côté que de l'autre. Ben, oui, il y a un axe central. On le voit sur cette photo. Les picots blancs sous les ressorts. Le spot est orientable, comme on le voit ici.

J'utilise le manche d'un balai pour remettre le spot droit : l'ampoule se rallume. Droit = la vitre qui protège l'ampoule (ou l'humain de la chaleur de celle-ci) est parallèle au sol, quoi.

Les jours suivants, le spot change de position et l'ampoule ne s'allume plus. À chaque fois, j'utilise le balai et ça repart. Actuellement, ça tient sans coup d'balai depuis plusieurs semaines. :D

En vrai, je pense qu'il doit y avoir, à nouveau, un faux contact du côté de la douille. Je suppose que bouger le spot dans une certaine position fait pression "comme il faut" sur les fils électriques, ce qui explique que ma méthode sans queue ni tête produit un résultat.

Je crois savoir que l'axe central était bloqué par des languettes en métal (on en voit une ici, en bas, à droite). Je les ai faites tomber lors du premier démontage du spot, fin 2019, et je ne les ai pas remises lors du changement de la douille de mi-2020. Ceci explique aussi cela, je pense. Mais bon, depuis, j'ai jeté lesdites languettes en métal…

Bref, pour l'instant ça chemar, et quand ça ne chemar pas, hop, un p'tit coup de balai et ça repart. :D

TL;DR : l'algorithme ssh-rsa est désactivé dans la version de SSH livrée dans Ubuntu 22.04 car il utilise la fonction cryptographique SHA-1 qui est jugée dangereuse depuis des années.

• Si tu te connectes à de vieux serveurs (< Debian 7) ou à des switchs réseaux, tu auras l'erreur « no matching host key type found ». Il faut ré-activer ssh-rsa dans la configuration du client SSH car ils ne prennent pas en charge des algorithmes plus modernes ;
  
  
• Avec des serveurs plus récents mais pas trop (Debian 7 et 8), tu auras une erreur « WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! » (sauf si t'as tripoté la configuration de ton client SSH pour autoriser uniquement ssh-rsa ou autres algorithmes non pris en charge par ton serveur SSH, auquel cas tu auras l'erreur « no matching host key type found »). Tu pourras soit ré-activer ssh-rsa, soit basculer sur un algorithme plus moderne ;
  
  
• Avec des serveurs >= Debian 9, tu n'auras pas d'erreur du tout car SSH basculera sur un algorithme de la famille RSA plus moderne.

Enfin, il ne faut pas confondre le format d'une clé SSH (RSA) et l'algorithme utilisé pour vérifier cette clé et signer avec (ssh-rsa = RSA + SHA-1). Ce n'est pas donc les clés RSA qui sont dépréciées par SSH et tu peux conserver la tienne (et celle de ton serveur) sans danger.

Constat

Un collègue met à jour sa station de travail à la version 22.04 d'Ubuntu. Il ne parvient plus à se connecter en SSH au serveur depuis lequel nous administrons nos serveurs (je refuse d'utiliser le terme « bastion », car il renvoie l'idée d'un point sécurisé, d'un contrôle d'accès fin, d'une journalisation des accès et des commandes saisies, etc. ce qui n'est pas le cas). L'erreur ? « Unable to negotiate with XXX.XXX.XXX.XXX port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 ».

Explications

Ubuntu 21.10 embarquait la version 8.4 d'OpenSSH (l'implémentation la plus répandue du protocole SSH). Ubuntu 22.04 embarque la version 8.9. (Source.) Or, à partir de sa version 8.8, OpenSSH désactive l'algorithme ssh-rsa. ssh-rsa = RSA + SHA-1. Or, ce dernier est considéré comme très faible depuis 2015, comme je l'ai évoqué dans un article sur le renforcement de mes configurations SSH.

Or, on constate que le serveur ne propose pas mieux que ssh-rsa (si l'on reste dans la famille RSA). Il ne propose pas rsa-sha2-256 ni rsa-sha2-512. C'est normal : il s'agit d'un système Debian 8 avec OpenSSH 6.7 ; les nouveaux algorithmes de la famille RSA sont implémentés à partir de la version 7.2 d'OpenSSH.

Tu vas me dire : « le serveur propose d'autres algorithmes, d'autres familles, le client l'annonce dans son message d'erreur, pourquoi ssh ne bascule pas dessus automatiquement ? ».

En effet… Sur un Ubuntu 22.04, c'est l'algorithme ssh-ed25519 qui est choisi car il est pris en charge par le serveur (dernier choix) et qu'il est premier choix du client après les algorithmes qui utilisent des certificats (cf man ssh_config).
Sur un Debian 10, c'est l'algorithme ecdsa-sha2-nistp256 qui est retenu, pour la même raison.

Sur un Ubuntu 22.04 avec un fichier known_hosts contenant l'empreinte de la clé RSA du serveur SSH, ssh affiche son traditionnel message « WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! » car il a négocié la présentation, par le serveur, de sa clé au format ED25519 (« The fingerprint for the ED25519 key sent by the remote host is »). Il suffit donc de supprimer l'empreinte de la clé de type RSA du fichier known_hosts (la commande est donnée dans le message d'erreur) pour basculer sur l'algorithme ssh-ed25519 et ne plus avoir d'erreur.

Si mon collègue n'a pas eu ce message d'erreur, c'est probablement qu'il devait avoir une configuration de son client SSH qui autorisait uniquement les algorithmes de la famille RSA et, potentiellement, d'autres algorithmes non pris en charge par le serveur. Du coup, son client SSH ne pouvait pas utiliser la famille RSA à cause de la dépréciation de l'algorithme ssh-rsa, et il ne pouvait pas utiliser une autre famille d'algorithmes car on le lui interdit ou le serveur SSH ne les implémente pas.

Solutions

Il y a plusieurs solutions :

• Ré-autoriser l'utilisation de ssh-rsa dans la configuration SSH du client en ajoutant les lignes suivantes dans le fichier ~/.ssh/config :

  Host *
      HostkeyAlgorithms +ssh-rsa
      PubkeyAcceptedAlgorithms +ssh-rsa

  C'est la meilleure solution si t'as encore de vieux serveurs (< Debian 7) ou des swiths, car ils ne prennent pas en charge autre chose que ssh-rsa.
  
  

• Utiliser un autre algorithme, donc un autre format de clé. Pour ce faire, il faut supprimer les empreintes de la clé RSA du serveur du fichier known_hosts :

  ssh-keygen -f ".ssh/known_hosts" -R "<nom_du_serveur>"
  ssh-keygen -f ".ssh/known_hosts" -R "<adresse_IP_du_serveur>"

  Oui, il faut cibler le nom et les adresses IP (si t'as IPv6 en sus d'IPv4, t'as une commande de plus à taper ;) ). Pour le nom, il s'agit du FQDN ou du seul nom de la machine en fonction de ton usage. Il faut s'assurer que le serveur prend en charge d'autres algorithmes (ssh -o 'HostkeyAlgorithms -ssh-rsa' <nom_du_serveur> et que d'autres types de clés sont disponibles : ls -lh /etc/ssh/ssh_host_* (si non, ça se génère avec ssh-keygen, comme d'habitude).

Faut-il cesser d'utiliser des clés au format RSA ?

Comme le dit le changelog d'OpenSSH : non, il est innocent.

Faut-il supprimer sa clé SSH RSA personnelle ? Non, elle est innocente.

Explications.

Lors de l'établissement d'une connexion SSH, une partie de l'échange se déroule ainsi :

1. Le serveur et le client se mettent d'accord sur le format de clé avec lequel le serveur va se présenter. Il s'agit des clés que l'on trouve dans /etc/ssh/ssh_host_* sur le serveur. C'est cette clé dont tu dois valider l'empreinte lors de la première connexion à un serveur SSH (modèle de sécurité TOFU, Trust On First Use). Dans le cas de mon collègue, son client et le serveur décident que le serveur doit se présenter avec sa clé de type RSA (/etc/ssh/ssh_host_rsa_key*) ;
   
   
2. Le serveur et le client se mettent d'accord sur l'algorithme de vérification et de signature des échanges. Vu qu'une clé de type RSA a été choisi à l'étape 1, il faut forcément utiliser un algorithme reposant sur RSA (l'algorithme dépend du format de la clé). Dans le cas présent, le serveur en prend en charge un seul, ssh-rsa. Le client le désactive par défaut donc il n'y a aucun algorithme en commun donc le client met fin à la négociation et affiche le message d'erreur sus-rapporté.

Sur un serveur plus récent (>= Debian 9), mon collègue ne rencontre aucun problème alors que le serveur se présente pourtant avec sa clé au format RSA, car ce serveur prend en charge des algorithmes RSA plus récents qui n'ont pas été dépréciés comme rsa-sha2-256 (RSA + SHA-256) et rsa-sha2-512.

Ce n'est donc pas le format de la clé (RSA) qui n'est plus pris en charge, mais l'algorithme de signature et de vérification car il repose sur la fonction cryptographique SHA-1 qui est considérée comme étant faible / dangereuse depuis des années.

Il est donc vain de jeter / changer / renouveler sa clé SSH personnelle au format RSA à coup de ssh-keygen, car le sujet est la clé du serveur.
Et il est démesuré de jeter la clé SSH RSA du serveur, car le sujet est l'algorithme utilisé, pas le format de la clé.

Ha, au fait, j'ai simplifié ci-dessus : la négociation du format de la clé et de l'algorithme se fait en une seule et même étape. Je l'ai découpé en deux afin de bien appuyer sur la différence entre le format de la clé et les procédures de signature et de vérification cryptographiques effectuées avec cette clé.

• Mésusages de données personnelles durant la campagne présidentielle 2022 :

  • J'ai déjà évoqué Zemmour qui dépose un message vocal sur les mobiles. Le même a adressé, à des Juifs, un SMS dont une URL renvoyait sur un texte titré « Message d'Eric Zemmour aux Français de confession juive ». Message effacé, mais Internet archive n'oublie pas. Cela signifie qu'il dispose d'un fichier à caractère religieux, ce qui est interdit. L'équipe de Zemmour reconnaît « une dizaine de milliers » de SMS, que le fichier provient d'un courtier en données personnelles (ça change rien au mésusage commis avec ce fichier mais soit), et qu'il référence plutôt des personnes « ayant montré un intérêt pour l'antisémitisme en France et en Europe » (pour moi, même si c'est vrai, ça change rien : on passe d'un fichier religieux à un fichier politique tout autant encadré) ;
    
    
  • Afin de leur assurer vouloir leur « donner les moyens de réussir en inventant des solutions adaptées » (peut-être car les actes du quinquennat de l'ont pas illustré ?), Macron a envoyé un courriel sur l'adresse professionnelle de plusieurs milliers d'enseignants. La loi interdit l'utilisation à une fin de communication politique des données persos détenues par une administration. L'équipe de Macron assure que le fichier a été obtenu via un prestataire (donc il ne s'agit pas de données d'une administration) avec recueil préalable du consentement (et je vois bien une masse de profs mal-habiles avec la technologie avoir donné, par le passé, leur consentement à ce prestataire).
• Inflation dans la zone euro : 7,5 %. Inflation en France : 4,5 %. On est trop fort ? Faut voir. Méthode de calcul différente. Si l'on utilise la même, l'inflation française passe à 5,1 %. Le bouclier tarifaire permet de reporter 1,5 point de hausse. Notre production d'énergie nucléaire nous évite 1 point de hausse. Peut mieux faire ? Et, là encore, cela nous coûtera plus tard (endettement d'EDF et de l'État) ;
  
  
• Le 11 avril 2022, une trentaine de militaires français a été envoyée en Ukraine pour documenter les crimes de guerre de Vladi ;
  
  
• Les ricains seraient sur le point d'autoriser un consortium européen à enrichir les équipements électroniques des F-35 (vendus à l'Allemagne, et à nombre de pays européens). En voie d'éjection du projet Scaf (avion européen du futur sur lequel boches et français ne parviennent pas à se mettre d'accord), le boche Hensoldt pourrait donc travailler à un système électronique commun à tous les avions de l'OTAN (à base de F-35, donc ?). L'italien Leonardo, qui détient 25 % des actions de Hensoldt, a été choisi par les rosbifs et les suédois pour l'électronique du Tempest, le concurrent du Scaf ;
  
  
• Fin mars 2022, des soldats maliens encadrés par des paramilitaires russes débarquent à Moura. Accrochage meurtrier avec des combattants islamistes (Al-Qaida). Puis ratissage du bled pour débusquer des djihadistes supposés et des collabos présumés (au motif de porter la barbe et un pantalon court, signes du respect de la charia…). 300 civils assassinés, la plupart étaient des musulmans de l'ethnie peule. Le peu de témoins attestent que les morts détestaient les djihadistes… Le 8 avril, la Russie et la Chine ont bloqué la volonté d'enquêtes indépendantes du Conseil de sécurité des Nations-unies au motif qu'un procureur militaire local a déjà ouvert une enquête. La Minusma, la mission onusienne au Mali sollicite en vain l'accès au site du carnage ;
  
  
• Rasff : système européen d'alerte sanitaire sur les denrées alimentaires ;
  
  
• Il y aurait 320-360 k abris anti-atomiques en Suisse. 9 millions de places (8,6 millions d'habitants en 2019). Obligation légale depuis 1963 : chaque habitant doit disposer d'une place en abris PC (protection civile). Depuis la fin de la guerre froide, beaucoup d'abris privés ont été transformés en salle de sport ou de répétition (fanfare, groupes de zik, etc.), en caves à vins, etc. par leur proprio (la loi l'autorise tant que réversible en 12 heures) ;
  
  
• Chaque année au Danemark, environ 19 000 hommes sont maltraités physiquement par leur partenaire. 38 000 danoises sont victimes de violences conjugales. Hum, est-ce que les deux termes (maltraitance physique et violence conjugale) recoupent les mêmes pratiques ? Pas sûr, mais le Canard n'explicite pas ;
  
  
• Haha, Pécresse qui, avec plus de 10 millions d'euros de patrimoine, et qui est membre d'un parti qui pourfend l'assistanat, fait un appel aux dons « comme une vulgaire Rom ». Cocasse, mais c'est dans la lignée sarkoziste de 2012 (appel au don de 10,6-11 millions d'euros suite à l'affaire Bygmalion). Et après ces gens-là sont jugés crédible…