Daily - GuiGui's Show

GuiGui's Show - Monday 25 August 2025

Mon, 25 Aug 2025 00:00:00 +0200

Steve Jobs: Stay Hungry, Stay Foolish! - Stanford Commencement | ENGLISH SPEECH with BIG Subtitles - YouTube

Mon Aug 25 15:28:03 2025 -
https://www.youtube.com/watch?v=EfAtsfOoh_M

Un prof d'anglais d'un [IUT](https://fr.wikipedia.org/wiki/Institut_universitaire_de_technologie) nous avait fait travailler sur ce topo de Jobs.

J'ignore pour quoi je ne l'ai pas partagé ici plus tôt… D'autant que je l'ai revisionné de temps à autre depuis. (Je n'ai aucun problème avec Jobs, j'ai toujours ouvertement affirmé que j'admire le commercial, le styliste, son attachement à l'[expérience utilisateur](https://fr.wikipedia.org/wiki/Exp%C3%A9rience_utilisateur), mais que je déteste l'[enfermement des utilisateurs / personnes](https://fr.wikipedia.org/wiki/Steve_Jobs#Style_de_management_et_personnalit%C3%A9) qu'il a contribué à impulser ‒ ça n'allait pas de soi à l'époque dans le milieu de la tech ‒ et à façonner, ainsi que le sous-développement de ses qualités humaines ‒ pour rester poli.)

Il s'agit donc d'une causerie de Steve Jobs lors de la remise des diplômes à l'université de Stanford en juin 2005.

Elle est axée autour de trois thématiques.

1) **Connecting the dots**. Je suis d'accord avec le principe sous-jacent, mais en désaccord avec l'aspect mystique (les tripes, le karma, la destinée, la vie relierait automagiquement les points). Je préfère penser qu'il faut élargir ses expériences et compétences *tout* en restant fidèle à ses valeurs, et les combiner entre elles d'une nouvelle manière (c'est la définition de l'intelligence). La fidélité à des valeurs choisies permet de garder le cap, de ne pas se disperser. Sous cette condition, tout apprentissage peut être utile même s'il semble inutile au premier abord, comme la calligraphie pour Jobs. Un peu comme Hermione Granger dans *Harry Potter* qui, parce qu'elle a étudié un maximum de sujets, est en capacité d'influer sensiblement sur les événements, notamment dans le tome 7. On peut donc relier les points en amont, préparer son itinéraire. Relier les points en aval, c'est souvent sélectionner les seuls faits qui vont dans le sens de ce que l'on cherche à asséner. Exemple : dans une biographie, une vie devient un destin hors du commun *par* un choix soigneux des faits qui font du sujet une grande personne. Je ne partage pas l'idée selon laquelle les ordis n'auraient peut-être pas eu de jolies polices de caractères sans Jobs : de toujours, plusieurs personnes travaillent simultanément sur les mêmes inventions ([exemples](/?_WEGgA), pénultième point).

2) **Love and loss**. Persévérer dans ce qu'on aime faire, réessayer, ne pas se résigner. **L'accomplissement découle du boulot bien fait et à fond, qui n'est possible que si l'on aime ce que l'on fait**. J'en suis convaincu. À juste titre, Jobs nuance en invoquant l'intuition et le cœur : ne faire que ce que l'on aime. Je nuance en rappelant que Jobs a dû faire des détours et qu'il a connu des traversées du désert (ex. : période [NeXT](https://fr.wikipedia.org/wiki/NeXT) ou partager le dortoir d'amis et ne pas manger à sa faim durant son étude de la calligraphie). Ce n'est qu'après coup qu'il peut parader sur le thème « c'est fou ce que ça m'a été utile », mais, à l'instant T, il ne devait pas aimer sa situation. Bref, il ne suffit pas d'insister, il faut s'adapter.

3) **Death**. Je n'ai jamais accroché au slogan « Vivre chaque jour comme si c'était le dernier ». Simplement parce que si j'avais la certitude de ma mort imminente, je ne lancerais pas de projets, puisque je ne les verrais pas aboutir, et je ferais des choses exceptionnelles (mettre mes affaires en ordre) et/ou déraisonnables (sexe de folie, vengeance, etc.). Jobs pose un critère : s'il n'aimait pas ce qu'il faisait durant trop de jours consécutifs, il savait qu'il fallait changer des choses dans sa vie. Après combien de jours ? Au final, qu'a-t-il changé de significatif (après tout, il a passé sa vie chez Apple) ? Je suis d'accord que la mort permet le changement (c'est un classique), que nous n'avons rien à perdre, que nous avons déjà tout perdu, que la vie est courte, qu'il faut vivre *sa* vie en suivant son intuition, son courage et son cœur et en étant imperméable aux dogmes et opinions d'autrui. La phrase finale, tirée du *[Whole Earth Catalog](https://fr.wikipedia.org/wiki/Whole_Earth_Catalog)*, m'a toujours marqué : « **Stay hungry, stay foolish** ». On pourrait discuter la signification : insatiable d'écraser autrui ou insatiable de connaissances et/ou d'augmenter sa capacité d'influer sur sa vie (c'est aussi ça le pouvoir, être en capacité de faire) ? Au regard de l'orientation du *Catalog*, je ne pense pas me tromper en retenant la deuxième. Phrase rigolote : « même ceux qui veulent aller au paradis ne veulent pas mourir ». :D

GuiGui's Show - Sunday 24 August 2025

Sun, 24 Aug 2025 00:00:00 +0200

15 ans…

Sun Aug 24 17:00:06 2025 -
http://shaarli.guiguishow.info/?ZoxaHg

J'ai enregistré ce nom de domaine en juin 2010. J'ai commencé à publier du contenu en juillet 2010.

Hé bah.

Réviser nftables et fail2ban face à un flot massif de requêtes web pourries

Sun Aug 24 16:07:34 2025 -
http://shaarli.guiguishow.info/?w8g1KQ

Le dimanche 17 août 2025, [mon blog](http://www.guiguishow.info/) a fait l'objet d'un incident informatique.

Tellement c'était naïf et dénué de finalité, j'hésite à parler d'attaque informatique, de [DDoS](https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service), et autres termes galvaudés.

Ce fut l'occasion de réviser les commandes du pare-feu de Linux ainsi que `fail2ban`.

### Caractéristiques de l'incident

2025-08-17T08:09:15 - - "GET http://www.guiguishow.info/page-sitemap.xml HTTP/1.1" 200 921 "-" "python-requests/2.32.3"

* Entre 7 h 04 (UTC+2) et 20 h 50 (idem), soit une durée d'environ 14 h. À nouveau quelques requêtes le 19/08/2025 entre 9 h 43 et 10 h 17 (UTC+2) ;

* Environ 179 000 requêtes web. Soit environ 3 requêtes/seconde pendant 14 h. Évidemment, il y a une forte disparité. Environ 90 000 requêtes la première heure, avant mon intervention, soit 25 requêtes/seconde en moyenne. 1 680, soit 0,46 r/s, la dernière heure ;

* Requêtes web portant sur trois ressources (= pages) : page-sitemap.xml, post-sitemap.xml, et sitemap-misc.xml. Ressources discriminantes ;

* Toujours le même entête HTTP [User-Agent](https://fr.wikipedia.org/wiki/User_agent) discriminant ;

* Adresse de la ressource au format absolu (http://…), pas relatif (/page-sitemap.xml). C'est autorisé par les normes techniques, mais c'est très souvent les robots qui l'utilise ;

* Uniquement en HTTP, pas HTTPS ;

* Supra, j'ai qualifié ce procédé de « naïf et dénué de finalité » à cause de ces discriminations faciles à opérer ;

* Environ 168 000 adresses IP uniques. Environ 147 000 IPv4. Environ 21 000 IPv6. Attention : les blocages que j'ai mis en œuvre ont pu réduire ce chiffre ;

* IP réparties dans environ 22 000 réseaux de taille /20 (paquet de 4096 IPv4) ou /56 (2⁷² IPv6). Mes blocages ont eu une incidence sur ce chiffre durant 3 heures a minima ;

* IP réparties dans au moins plus de la moitié de l'espace d'adressage IPv4 : environ 116 réseaux /8 alors qu'il y a en 256 possibles (0.0.0.0/8, 1.0.0.0/8, …, 254.0.0.0/8, 255.0.0.0/8) et que nombre d'entre eux [ne sont pas utilisés sur Internet](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xml) (224-255/8, 0/8, 127/8, 10/8, etc.) et/ou sont [alloués à de grandes multinationales](https://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks). Ce calcul provient d'une unique mesure durant 30 minutes le matin ;

* En IPv6, la répartition est moins bonne. Essentiellement deux /32 d'un opérateur vietnamien. Le reste venait d'une centaine de /32 (Pérou, République dominicaine, etc.) ;

* Cette répartition m'a étonné au regard de l'objectif (demander en boucle uniquement le [plan de mon site](https://fr.wikipedia.org/wiki/Plan_de_site)…), étant donné que l'usurpation d'IP est compliquée en IPv4 puisqu'il faut accomplir la [poignée de main TCP](https://fr.wikipedia.org/wiki/Acquittement_(informatique)#Dans_le_cas_de_TCP) avant d'effectuer une requête web. Une telle répartition dans tout IPv4 pour faire si peu…

### Actions

Ce site web est hébergé sur une machine virtuelle (VPS) louée à OVH. L'anti-DDoS de ce dernier ne s'est pas activé. Je sais qu'on peut le déclencher soi-même, mais moins un prestataire, quel qu'il soit, se mêle de mes affaires selon des critères obscurs, mieux je me porte.

**Dans le feu de l'action, il est recommandé d'utiliser uniquement ce que l'on connaît**. C'est une des raisons pour lesquelles je n'ai pas utilisé le fameux [Anubis](https://en.wikipedia.org/wiki/Anubis_(software)) que tout le monde s'arrache (les autres raisons : disproportionné par rapport à l'incident ; pas envie d'avoir un logiciel de plus à administrer).

#### Phase 1 : soulager le serveur

J'ai commencé à intervenir un peu moins d'une heure après le début de l'incident.

Mon shaarli était un poil plus lent que d'habitude mais sans plus. La charge du système était d'environ 10. Pour une machine dotée d'un seul processeur virtuel. Le système était donc surchargé.

Les ressources web demandées, page-sitemap.xml, post-sitemap.xml, et sitemap-misc.xml, sont générées à la volée à chaque requête. Donc PHP et MariaDB sont mis en branle.

Il faut agir sur ce fait, soit en transformant ces ressources en pages web statiques (c'est-à-dire les `wget` puis les mettre dans le DocumentRoot), soit en en interdisant l'accès.

Vu l'absence de criticité, j'ai choisi la deuxième option. Dans la configuration d'Apache httpd (je n'utilise pas les htaccess) :

Require all denied

La charge système tombe en dessous de 1.

Le [code HTTP](https://fr.wikipedia.org/wiki/Liste_des_codes_HTTP) 403, qui signifie accès refusé, n'arrête pas le robot.

Je constaterai plus tard que, de toute façon, le robot s'en fiche d'avoir une réponse, y compris la 2^e étape de la poignée de main TCP (SYN+ACK), il continue.

J'aurais pu m'arrêter ici : mon service fonctionnait et mon serveur n'était pas débordé. Mais les journaux se remplissaient.

#### Phase 2 : des carences dans nftables

La première idée qui m'est venue, c'est d'utiliser le module `string` du pare-feu Linux pour dégager toutes les requêtes HTTP pour les ressources et l'user-agent impliqués. [Je l'ai déjà utilisé](http://www.guiguishow.info/2014/08/23/comment-mettre-en-place-un-serveur-dns-recursif-cache-ouvert-dans-de-bonnes-conditions/#toc-5206-limitation-de-trafic-portant-sur-le-qtype-any-avec-netfilter) par le passé.

Mais [nftables](https://fr.wikipedia.org/wiki/Nftables), la nouvelle interface de commande de Netfilter (et plus), [ne prend pas en charge le module string](https://wiki.nftables.org/wiki-nftables/index.php/Supported_features_compared_to_xtables). Ni u32 d'ailleurs (même si ça n'aurait pas convenu ici à cause des entêtes de taille variable). Hors de question que j'écrive un programme eBPF.

#### Phase 3 : fail2ban en détresse

J'ai un `fail2ban` (f2b) configuré pour bannir des IPs qui accèdent à certains fichiers (wp-config.php, par exemple) ou qui tentent des [injections SQL](https://fr.wikipedia.org/wiki/Injection_SQL). J'ai dupliqué l'action nftables pour bannir par /24 en IPv4 et en /64 par IPv6, c'est-à-dire par réseau contenant une IP qui a tenté un truc malveillant.

J'ai ajouté un filtre sur les URL et le User-Agent. J'ai réutilisé mon action nftables modifiée. J'ai créé une jail pour bannir 12 h.

f2b a galéré. Dans son journal, essentiellement des lignes « Found », très peu de « Ban », comme s'il ne tenait pas la cadence. Le nombre de requêtes par seconde ne diminuait pas vraiment. Même après 15-30 minutes.

Rétrospectivement, **j'ai commis plusieurs erreurs**.

D'une part, puisqu'il était nouveau dans sa configuration, fail2ban a lu l'ensemble du journal Apache httpd. Il contenait plus d'une heure de requêtes (environ 100 k). J'aurais dû stopper httpd, créer un journal vierge, etc.

D'autre part, j'ai rechargé et redémarré f2b à plusieurs reprises (au lieu de tester mon nouveau filtre avec `fail2ban-regex`, pour tenter de lui faire lire le journal depuis l'instant T, etc.). Forcément, f2b perd du temps à ré-appliquer les bannissements depuis sa base de données. Il ne faut pas faire ça en plein incident, il faut utiliser le client (`fail2ban-client`).

À ma décharge, `fail2ban-client` a refusé certaines instructions parfaitement valides, comme `unban --all` ou changer la durée de bannissement afin de purger les anciennes IPs (celles de la première heure de l'incident). J'ai fini par stopper f2b et supprimer sa base de données (/var/lib/fail2ban/fail2ban.sqlite3).

#### Phase 4 : fail2ban plus agressif

Puisque fail2ban ne semblait pas tenir la cadence, je l'ai configuré pour bannir par /8 en IPv4 ou /32 en IPv6.

Évidemment, en moins de 15 minutes, ce fut très efficace.

Évidemment, les dommages collatéraux sont très nombreux puisque pour une adresse IPv4 coupable, j'en bannis 16,7 millions d'autres… C'est les chiffres que j'ai exposés supra : j'ai banni plus de la moitié de l'espace d'adressage IPv4.

Je suis donc passé à /16 en IPv4 et /48 en IPv6. f2b tenait toujours la cadence.

#### Phase 5 : limitation de trafic et fail2ban

Je voulais limiter le nombre de requêtes par seconde. Je [savais le faire avec iptables](http://www.guiguishow.info/2014/08/23/comment-mettre-en-place-un-serveur-dns-recursif-cache-ouvert-dans-de-bonnes-conditions/#toc-5206-limitation-de-trafic-global-en-utilisant-netfilter), mais pas avec nftables.

**`iptables` fournit les programmes `iptables-translate` et `ip6tables-translate`** :

$ iptables-translate -A INPUT -p tcp --dport 80 --tcp-flags SYN,ACK,FIN,RST SYN -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-HTTP-v4 --hashlimit-srcmask 8 -j DROP
nft 'add rule ip filter INPUT tcp dport 80 tcp flags syn / fin,syn,rst,ack meter RL-HTTP-v4 { ip saddr and 255.0.0.0 limit rate over 1/second burst 2 packets } counter drop'

$ ip6tables-translate -A INPUT -p tcp --dport 80 --tcp-flags SYN,ACK,FIN,RST SYN -m hashlimit --hashlimit-above 1/sec --hashlimit-burst 2 --hashlimit-mode srcip --hashlimit-name RL-HTTP-v6 --hashlimit-srcmask 32 -j DROP
nft 'add rule ip6 filter INPUT tcp dport 80 tcp flags syn / fin,syn,rst,ack meter RL-HTTP-v6 { ip6 saddr and ffff:ffff:0000:0000:0000:0000:0000:0000 limit rate over 1/second burst 2 packets } counter drop'

Je limite uniquement les paquets TCP SYN (initialisation d'une connexion). 1 nouvelle connexion par seconde par /8 (IPv4) ou /32 (IPv6), pic à 2/s. (J'aurais pu utiliser `ct state new`, nouvelle syntaxe de `-m state --state NEW`, mais l'analyse des drapeaux me semble moins coûteuse en temps CPU que le suivi des connexions.)

J'utilise une seule table de type inet. Je me demandais si chaque meter allait travailler sur son type d'IP (v4 ou v6) malgré tout. Dans le doute, j'avais ajouté le critère `ip version 4` dans la première règle et `ip6 version 6` dans la seconde. J'ai testé à froid : oui, **meter se débrouille tout seul, pas besoin de filtrer le type d'IP en amont**.

Je configure f2b pour bannir par /20 (IPv4) ou /56 (IPv6). L'idée c'est de bannir l'environnement immédiat d'un réseau contenant une IP qui me prend pour cible, car, ces quinze dernières années, les opérateurs ont souvent obtenu des réseaux d'une taille entre entre /16 et /22 au fil de la [pénurie d'IPv4](https://fr.wikipedia.org/wiki/%C3%89puisement_des_adresses_IPv4). Bannir l'environnement d'un réseau sans bannir tout un opérateur, en somme.

Malgré tout ça, mon Apache httpd journalise encore 8 requêtes/seconde en moyenne. Pollution inutile de mes journaux.

#### Phase 6 : blocage par pays

Plus pour tester que par nécessité, j'ai décidé de bloquer toutes les IPs qui ne sont pas attribuées à un opérateur français et qui causent au port 80 (HTTP) de ma machine.

Tout est dans le [wiki officiel de nftables](https://wiki.nftables.org/wiki-nftables/index.php/GeoIP_matching).

Seule adaptation : `meta mark != $FR counter drop` (note la négation, qui ne se fait pas avec `not`, dont la traduction n'est que `!`).

Cette technique est redoutablement efficace : aucune requête web ne passe, rien.

Je n'aurais pas mis en œuvre cette technique si j'étais un site web international et/ou marchand, mais, dans mon cas, l'inaccessibilité de mon site web n'a aucune conséquence.

Ironie tout de même : la première IP française qui s'est présentée, ce fût pour chercher une faille de sécurité sur mon blog…

J'ai laissé ainsi pendant 3 h et j'ai fait autre chose de ma vie.

#### Phase 7 : blocage par pays, limitation de trafic, et fail2ban

Si IP française, elle passe. Sinon, limitation de trafic (1 requête/s, pic à 10/s par /8 ou /32). Dans les deux cas, fail2ban veille (bannissement par /20 ou /56).

Apache httpd continue de recevoir 2 requêtes/seconde en moyenne.

Les heures avançant, j'ai été plus coulant sur la limitation de trafic : 10 connexions/minute, pic à 30, etc.

#### Phase 8 : préparer le retour

Je n'ai pas cru à la fin de l'incident, je m'attendais à ce que ça recommence le lendemain.

Cela aurait été intelligent car avec une durée de bannissement de 12 h, f2b allait gracier toutes les IPs avant l'aube.

J'ai donc **exporté la configuration de nftables, y compris les ensembles d'IP** avec `nft list ruleset > sauvegarde.nft`. Ainsi, dans l'urgence, je pourrais re-bannir toutes les IPs qui ont participé. On charge ce fichier avec `nft -f`.

#### Phase 9 : nettoyage

Ce genre d'incident fait grossir les journaux (d'Apache httpd, de fail2ban, etc.).

Avant que tout cela finisse dans mes sauvegardes et les fasse grossir inutilement, j'ai fait le ménage.

J'ai viré l'incident des journaux `access.log` et `error.log` d'Apache httpd et de `fail2ban.log`.

J'ai forcé SQLite à supprimer sur disque les données supprimées dans la base de données interne de f2b (`VACUUM`).

### Commandes utiles

`nft -t list ruleset` : **« -t » permet de ne pas afficher le contenu des ensembles (set)** et des tableaux associatifs (map).

`nft -f ` : charger un jeu de règles. Se souvenir que, désormais, il peut y avoir plusieurs tables et chaînes d'un même type (filter, nat, etc.). Toutes ont [une priorité](https://wiki.nftables.org/wiki-nftables/index.php/Netfilter_hooks#Priority_within_hook) qui indique leur ordre dans le traitement des paquets. Un verdict « drop » est définitif, les paquets rejetés ne passeront pas dans une éventuelle chaîne de même type moins prioritaire. Un verdict « accept » n'est définitif que lorsqu'il se trouve dans la dernière chaîne, sinon les paquets passeront dans les chaînes de même type moins prioritaires. [Source](https://wiki.nftables.org/wiki-nftables/index.php/Configuring_chains#Base_chain_priority).

**Compter les éléments d'un ensemble nommé** : je n'ai pas trouvé. Il faut bricoler : `nft list set | tail -n +5 | head -n -2 | wc -l`. En IPv4, il y a deux IP / réseaux par ligne. Une en IPv6. Sinon, en passant par JSON : `nft -j list set | jq ".nftables[1].set.elem | length"`…

`nft monitor` : écouter les événements (ajout/suppression d'une table, d'une règle, d'un élément dans un ensemble, etc. et tracer les paquets qui tapent une règle (lui ajouter « meta nftrace set 1 » et utiliser `nft monitor trace`).

GuiGui's Show - Friday 22 August 2025

Fri, 22 Aug 2025 00:00:00 +0200

Paramétrer yt-dlp

Fri Aug 22 11:40:37 2025 -
http://shaarli.guiguishow.info/?lRluew

Depuis un peu plus d'un an, l'interface web de Google YouTube ne m'affiche plus les vidéos au motif que je devrais me connecter pour prouver que je ne suis pas un robot.

Il s'agit d'un blocage fondé sur une notation arbitraire et opaque des adresses IP. À ce stade et vu le peu d'infos dont je dispose, la responsabilité semble être partagée entre les géants du Net (car il n'y a pas que Google) et mon [Fournisseur d'accès à Internet associatif](https://ffdn.org/).

Au début, j'utilisais [yt-dlp](https://github.com/yt-dlp/yt-dlp) avec un tmpfs (= un [ramdisk](https://fr.wikipedia.org/wiki/Disque_virtuel)) comme destination.

Un tmpfs se vide à chaque redémarrage de l'ordinateur. Comme le consigne [sa doc](https://github.com/yt-dlp/yt-dlp?tab=readme-ov-file#output-template), le paramètre `-o` de `yt-dlp` crée les dossiers qui n'existent pas, donc j'utilisais `yt-dlp -o /tmp/ytd/%(title)s.%(ext)s` via un fichier de configuration (j'vais y revenir).

Puis Google YouTube a aussi appliqué le blocage par IP aux flux vidéo eux-mêmes.

J'utilisais donc `yt-dlp` et la fonctionnalité [mandataire SOCKS de SSH](http://www.guiguishow.info/2010/12/28/ssh-du-port-forwarding-au-vpn-bon-marche/) via un alias dans mon terminal (`alias ytd='yt-dlp --proxy socks5://127.0.0.1:6666'`).

Bien souvent, le son est séparé de l'image, donc avant de regarder une vidéo, il faut attendre le téléchargement entier des deux pistes et leur fusion par `yt-dlp` (via `ffmpeg`).

Du coup, pour accélérer les choses, je me suis mis à restreindre la définition des vidéos à 720p max via le paramètre `-f` de `yt-dlp` : `ytd -f 247+ba` (piste vidéo dont l'identifiant est 247 et piste audio de la meilleure qualité disponible). L'identifiant 247 était stable, à part quelques exceptions, de vieilles vidéos, par ex.

Depuis quelques jours, l'identifiant de piste vidéo a changé, et il n'est plus identique entre les chaînes.

`yt-dlp` ne pourrait-il pas identifier automatiquement la « bonne » piste vidéo ? Bien sûr que si : `-f 'bv[height<=720]+ba'`. [Plusieurs autres filtres (critères) sont disponibles](https://github.com/yt-dlp/yt-dlp). C'est via un [article de Lord](https://lord.re/posts/233-exit-kodi-enter-mpv/) que j'ai découvert cette syntaxe.

Certaines chaînes doublent la bande son de leurs vidéos. Pour avoir la meilleure piste vidéo tant que la définition est inférieure ou égale à 720p et la meilleure piste audio tant qu'elle est en français ou la meilleure piste audio sans étiquette de langue : `-f 'bv[height<=720]+(ba[language=fr]/ba)'`.

`yt-dlp` accepte d'être configuré via un fichier.

Ce fichier de configuration est cherché dans [plusieurs emplacements](https://github.com/yt-dlp/yt-dlp?tab=readme-ov-file#configuration).

Le plus pratique, car il peut être caché tout en étant à côté des autres fichiers de conf personnels, me semble être `~/.yt-dlp/config`. C'est celui que j'utilise.

La syntaxe du fichier est donnée dans la doc précitée. Dans mon cas :

-f 'bv[height<=720]+(ba[language=fr]/ba)'

-o /tmp/ytd/%(title)s.%(ext)s

(Je ne mets pas le proxy, car je ne l'utilise pas en dehors de Google YouTube, donc un alias dans mon terminal est plus adapté).

GuiGui's Show - Thursday 21 August 2025

Thu, 21 Aug 2025 00:00:00 +0200

Achat en ligne avec une carte bancaire : choisir le réseau (CB, Visa, Mastercard, etc.)

Thu Aug 21 10:57:33 2025 -
http://shaarli.guiguishow.info/?uLDjFA

En France, les cartes de débit / crédit comportent systématiquement deux schémas : CB et Visa ou CB et Mastercard.

Chaque transaction passe sur l'un ou l'autre des réseaux.

CB = Groupement d'Intérêt Économique Cartes Bancaires (GIE CB), une entité française. Visa et Mastercard sont des entités états-unienne.

[Visa et Mastercard proposent ou revendent des stats sur les transactions](/?ROopdg). Plus ou moins agrégées. Prétendument sans [ré-identification](/?0w0d2w) possible.

Lors d'un achat sur le web avec une carte bancaire, il est souvent possible de choisir le réseau (Visa ou CB, par ex.). En effet, dans le champ collectant le numéro de carte du formulaire de paiement, il y a souvent une icône carte de paiement. Parfois elle affiche qu'elle est une liste déroulante, mais parfois non et il faut alors cliquer dessus.

À chaque fois que je le peux, je choisis CB.

GuiGui's Show - Friday 15 August 2025

Fri, 15 Aug 2025 00:00:00 +0200

Rapports sur la conservation et l'accès aux données de connexion

Fri Aug 15 15:11:06 2025 -
http://shaarli.guiguishow.info/?m0qUGA

J'ai déjà beaucoup [écrit sur les données de connexion](/?LxxJsA). J'ai actualisé cet article.

Pas de nouveauté, pas de changement en pratique, toujours au stade du blablabla.

Tous ces rapports portent sur l'utilisation des données de connexion dans les enquêtes pénales.

### Rapport d'information du Sénat « *[Surveiller pour punir ? Pour une réforme de l'accès aux données de connexion dans l'enquête pénale](https://www.senat.fr/notice-rapport/2023/r23-110-notice.html)* »

* Novembre 2023

* **En 2022, environ 3 millions de données de connexion ont fait l'objet d'une réquisition** (page 11) ;

* Environ moitié données d'identification, comme l'identité civile de toutes les personnes présentes dans une zone ou l'identité civile derrière un numéro d'appel (page 17). L'autre moitié, c'est les fadettes et la localisation (page 39). **Internet semble insignifiant**, ce qui explique en partie l'orientation du rapport sur la téléphonie, les 4 grands opérateurs, les [OTT](https://fr.wikipedia.org/wiki/Service_par_contournement) (opérateurs sans numérotation = VoIP sans accord commercial avec FAI : Discord, Signal, WhatsApp, etc.), etc. ;

* **Hausse tendancielle de 10 % par an jusqu'en 2022** (page 11). Graphique page 38. + 0,36 % entre 2021 et 2022 (refonte du cadre législatif FR), page 99. Attention : le rapport tente de faire croire que c'est l'arrêt de la Cour de cassation de 2022 qui aurait mis un frein alors que cela n'est pas flagrant sur le graphique proposé ;

* Attention aux chiffres : une demande de bornage pour le même point d'une même enquête = 4 gros opérateurs pour trois antennes (couvrant à 360 degrés une zone) = 12 réquisitions (page 39).

* Le **rapport reconnaît un « accès massif aux données de connexion »**. Causes :

* « La facilité d’un tel accès » en ce, qu'avant 2022 (loi sur le harcèlement scolaire, [voir ici](/?LxxJsA#lldji-histo)), cet accès était régi par le droit commun des réquisitions, sans garde-fou, qui permettait de recueillir toute information intéressant l'enquête (page 39) ;

* Les enquêteurs ont pris l'habitude de demander, en premier lieu, par **réflexe**, les facture détaillées, qui contiennent des éléments au-delà de l'infraction, sans rapport avec celle-ci (page 109). Seul l'argent (compensation des opérateurs, cf. infra) a limité le jeu (page 40) ;

* Pages 34-37 : premier tri avant de solliciter des mesures plus intrusives comme la géolocalisation en temps réel ou les écoutes (plus pour des questions de thune que d'amour des libertés, à mon avis). Les avocats à tout stade de la procédure. Le droit au silence. Les citoyens ne veulent plus témoigner. Les criminels, sauf les primo, maîtriseraient les techniques de la police scientifique et ne laisseraient plus de traces d'ADN & co (mais des données de connexion si ? J'y crois moyen). Essor des messageries chiffrées (pourquoi, alors, la moitié des réquisitions portent sur des fadettes ?). Gain de temps et d'effectifs RH. Les magistrats voudraient des données de connexion dans les dossiers, même pour du vol à la tire, sinon ils considérent qu'il y a doute qui doit profiter à l'accusé (étonnant, non ?). Les citoyens voudraient l'efficacité de la répression des infractions. Les données de connexion seraient essentielles aux enquêtes liées à la délinquance du quotidien (page 55).

* **L'impact des [arrêts de la Cour de justice de l'union européenne](/?LxxJsA#lldji-histo) (CJUE) a été limité** :

* À mon avis, à la lecture du rapport, ils ont calmé le jeu sur l'accès (par une entité indépendante, etc.). Reste la conservation ;

* Réactions très diverses des États-Membres. Page 58 : en sus de la France, 12 États-Membres auraient toujours une conservation généralisée. D'autres États-membres ont toujours un accès trop ouvert. D'autres n'ont pas adapté leur législation. Aucune action en manquement de la Commission européenne. Seule l'Allemagne le vivrait bien (elle n'a jamais voulu la rétention des données de connexion). **Étude comparative** à partir de la page 137 ;

* La **conservation rapide** (injonction faite à un intermédiaire technique de garder ce qu'il détient à l'instant T) implique l'**absence d'historique** / de rétrospective, ce qui serait insuffisant pour lutter contre la criminalité grave (cf. Slovaquie). Page 61 ;

* la **conservation ciblée est compliquée à mettre en œuvre, juridiquement et techniquement** : quels critères non-discriminatoires utiliser ? Les zones particulièrement exposées à la menace (aéroports, gare, infrastructures, institutions, etc.) ou celles présentant le taux de criminalité le plus important sont-elles pertinentes ? Comment le calcule-t-on (nombre d'infractions uniquement => pouf, toutes les grandes villes sont surveillées) ? Fiabilité (comme en France, la [criminalité déclarée par les flics contient de nombreuses erreurs](/?YR6ztA), cf. page 141) ? En Belgique et au Danemark, 67 % de la population est concernée par de la conservation dite ciblée… Quid du déplacement de la criminalité (les quartiers criminels des trois dernières années ne seront pas forcément ceux de demain) ? Et si je prépare mon crime hors des zones ciblées ? Au Danemark, la conservation vise des catégories de personnes : automatique, pour 3 à 10 ans, pour les condamnées (quid de la rédemption ?) et pour ceux qui ont fait l'objet d'une interception téléphonique (en quoi ça prouve quoi que ce soit ?) ;

* **Dissensions** au sein de la Commission européenne (les directions générales s'écharpent, mais, au global, sont plutôt pro-flicage) et entre la Commission, le Conseil européen (pro-flicage) et le Parlement européen (anti-flicage) sur l'équilibre à tenir entre poursuite des infractions et protection de la vie privée. Page 69 ;

* Les rapporteurs évoquent un possible glissement vers d'autres techniques en France : [LAPI](https://www.cnil.fr/fr/les-dispositifs-de-lecture-automatisee-de-plaque-dimmatriculation-lapi), vidéo-surveillance, interceptions des communications, enquêtes administratives (plus intrusives mais ciblées donc moins nombreuses, à mon avis), porosité entre les services de renseignement et la justice (ce dont l'Allemagne est soupçonnée, cf. page 123) ou autres preuves numériques (réquisition d'un smartphone, [IMSI catcher](https://fr.wikipedia.org/wiki/IMSI-catcher), perquisition numérique, etc.) ;

* À mon avis, pour LAPI et la vidéo-surveillance, il faudra décider si tout cela est ciblé au motif que "peu" d'endroits sont couverts, ou si ça ne l'est pas car, si c'est positionné aux endroits clés, alors c'est « susceptible de tirer des conclusions précises sur la vie privée d'une personne » (mantra de la CJUE pour invalider la rétention généralisée). À mes yeux, une plaque d'immatriculation a le même statut qu'une adresse IP (identification) ;

* Page 114 : **certains demandent toujours des autorisations prospectives** : accès aux fadettes d'un suspect puis identification des contacts voire accès aux fadettes et aux autres données de connexion d'un contact, tout ça à partir d'une seule autorisation initiale. Les rapporteurs doutent de la conformité à la jurisprudence de la CJUE qui veut un contrôle préalable de chaque accès. Bref, la leçon n'a pas encore été apprise.

* À partir de la page 137, étude comparative de la conservation des données de connexion dans l'UE. Quelques éléments hallucinants : l'Irlande conservait 2 ans. Aucune mise en conformité après l'arrêt Digital Right Ireland, seulement après Garda Síochána ; Italie : conservation toujours généralisée, pour 6 ans (!) ; Lettonie : 18 mois ; Pologne a ignoré les arrêts CJUE alors que certains pensent que la motivation de la CJUE vient des démocraties illibérales ; Pays-Bas et Slovaquie : seules les données utiles aux besoins techniques ou commerciaux des opérateurs sont disponibles ;

* Page 85 : la conservation rapide vient de la Convention de Budapest de 2001 sur la cybercriminalité. Celle-ci ne précise pas si cela porte sur l'historique (données conservées). La CJUE n'a rien dit que la conservation rapide, sauf qu'il ne peut y avoir accès pour autre finalité que celle qui a justifié la collecte (criminalité grave != sécurité nationale). Mais une injonction de conservation rapide n'ajouterait-elle pas, après-coup, une finalité, se demandent les rapporteurs. Pour moi, c'est non, mais, au final, on retrouve cette idée de réutilisation pour une finalité compatible dans l'article 5(1)b du RGPD, et, au final, que la conservation ait lieu pour l'obligation légale X ou Y ne change environ rien… ;

* Pages 72 à 74 : **[règlement européen e-evidence](https://eur-lex.europa.eu/FR/legal-content/summary/electronic-evidence-in-criminal-proceedings.html) (preuves électroniques dans les procédures pénales)**, adopté en 2023, entrée en vigueur en 2026 :
* Rénove le cadre issu de la Convention de Budapest de 2001 sur la cybercriminalité ;

* Forcer les grands acteurs du numérique à coopérer avec les autorités judiciaires de manière fluide, y compris pour des enquêtes nationales ;

* Comme [DMA / DSA](/?26d_bg) : représentant légal dans l'UE dès que service proposé dans l'UE ;

* Injonction à produire les preuves sous dix jours (8 h en cas d'urgence) ;

* Injonction de conserver les preuves (conservation rapide, quick freeze) pour 60 jours, renouvelable pour 90 jours de plus ;

* Les magistrats pourront émettre les deux types d'injonction pour toute infraction pénale en ce qui concerne les données d'identification. Seuls un juge du siège, un juge d'instruction ou une juridiction pourront requérir les données de trafic ou de localisation (que la nomenclature UE inclut dans les données de trafic), et le contenu, si l'infraction présumée est passible d'au moins 3 ans de taule ou pour certaines infractions entièrement ou partiellement commises en ligne (pédoporn, attaque d'un système d'information, terrorisme, etc.). En cas d'urgence, les enquêteurs pourront enjoindre, contrôle a posteriori sous 48 h ;

* 2 % du chiffre d'affaires si manquement ;

* Quelques gardes fous : si l'État d'émission d'une injonction n'est pas celui où a eu lieu l'infraction ni celui où réside l'auteur présumé, alors ledit État doit notifier sa demande aux autorités du pays d'établissement de l'intermédiaire technique, qui peut bloquer (mais bien sûûûûr). La notification pourra ( ;) ) être automatique pour les États émetteurs qui violent systématiquement l'état de droit ; protections spécifiques pour les avocats, journalistes, secret médical, etc. ;

* Bien entendu, s'il n'y a pas de conservation généralisée, les injonctions ne retourneront que les données conservées par les intermédiaires techniques pour leurs besoins techniques ou commerciaux ;

* Au final, **ça respecte la jurisprudence de la CJUE** en matière de données de connexion, d'où il est probable que ça serve de modèle / de fondation ;

* Les rapporteurs voient, dans le quantum de peine et dans les infractions spécifiques, l'émergence d'une approche européenne de ce qu'est la criminalité grave (même si elle est déjà définie dans les procédures de coopérations, pour ces seules procédures). Elle ouvrerait la voie à une définition européenne des règles de procédures pénales (ce qui serait contraire à la répartition des compétences prévue par les traités).

* Les **officiers de police judiciaire (OPJ) formulent leur demande aux magistrats par téléphone**. Les OPJ demandaient aux opérateurs par fax, courrier, email. Faible traçabilité. Depuis 2016, Plateforme nationale des interceptions judiciaires (PNIJ) gérée par l'Agence nationale des techniques d’enquêtes numériques judiciaires (ANTENJ) ;

* Il faudrait **harmoniser** le périmètre des autorisations d'accès aux données de connexion car certains parquets les octroient par dossier pour 6 mois, d'autres pour chaque nouvelle ligne identifiée. Une autorisation par ligne semble au-delà des exigences de la CJUE, mais une par dossier ne semble pas acquise (page 113). De même, différences entre parquet et juge d'instruction du même ressort. Différences en fonction des individus mis en cause, du lieu, de l'environnement perso, etc. (page 18) ;

* De même, il faudrait préciser ce qu'il convient de conserver et combien de temps car l'**appréciation varie chez les 4 grands opérateurs**. Exemple : la localisation en l'absence de communication serait conservée 1 ans pour 2 d'entre eux, 90 jours pour un 3^e, pas conservé pour le dernier ;

* Normalement, le droit à la preuve catégorise les moyens de preuve en fonction de leur degré d'atteinte à la vie privée. Or, en matière de preuve numérique (au-delà des données de connexion donc, réquisition smartphone, perquisition numérique, etc.), il n'y a pas eu de réflexion globale, **la législation a été complétée au fil de l'eau, au gré des techniques, ce qui induit une disparité des régimes**. Un même quantum de peine autorise des techniques plus ou moins intrusives. Une URL est à la fois une métadonnée et un contenu (en ce qu'elle le révèle). Pourtant, les L851-3 (boîtes noires) et L851-2 (accès temps réel) du Code de la sécurité intérieure les chopent (le Conseil constitutionnel a dit non pour les boîtes noires dans sa [décision 2025-885 DC sur la loi narcotrafic](https://www.conseil-constitutionnel.fr/decision/2025/2025885DC.htm). Je pense que le rapport confond accès en temps réel aux données de connexion et interception. De même, la liste des applis d'un smartphone en dit long sans être du contenu (pages 31-33). Bref, le **clivage contenant (métadonnées) / contenu** n'est pas pertinent, il faudrait revoir la classification des différentes données de connexion (identité civile, trafic/localisation, identification c'est-à-dire donnée pivot, comme une adresse IP) ;

* Plateforme nationale des interceptions judiciaires, PNIJ (pages 44-47) :
* Dernier audit par la CNIL : 2022-2023. Dernier audit par l'ANSSI : 2016 (!) ;

* En parallèle du Commissariat aux communications électroniques de défense qui intervient pour la supervision technique (définition des spécifications techniques des équipements déployés par les opérateurs pour mettre en œuvre leurs obligations légales, la mise en place des liaisons entre les opérateurs et les plateformes, la vérification de leur bon fonctionnement et du respect des normes de sécurité informatique, etc.). Le Commissariat est complémentaire à l'Agence nationale des techniques d’enquêtes numériques judiciaires (ANTENJ) qui assure la maintenance correctrice de la PNIJ, le développement de nouvelles fonctionnalités, et l'assistance aux utilisateurs ;

* 20 à 30 opérateurs sont branchés sur la PNIJ (sur environ 1800), mais la collecte portant sur les clients des NVMO (opérateurs sans réseau physique) se ferait via les opérateurs disposant d'un réseau physique (hum… pourquoi avoir raccordé 20 à 30 opérateurs si ça sert à rien ?) ;

* Traçabilité 3 ans des actions sur la PNIJ ;

* La PNIJ ne contrôle pas l'authenticité de la demande : c'est l'OPJ qui saisi sa demande, pas le magistrat qui l'autorise ; la PNIJ ne vérifie pas si l'OPJ est dans le même ressort que le magistrat qui l'aurait autorisé ;

* **La PNIJ ne couvrirait** pas les FAI (je pense que le rapport parle ici uniquement des interceptions, car, il consigne par ailleurs que les données de connexion passent par la PNIJ, et la [grille de compensation financière](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000041553495) prévoit des actions sur des adresses IP via la PNIJ, mais peut-être uniquement pour les 4 opérateurs…), les Over The Top (surtout ceux extra-UE comme Google ou Meta), ni les opérateurs satellites, ni l'interception en Outre-Mer.

* **20 à 25 % de « hors PNIJ »**, notamment par des logiciels d'interception tiers (pages 48-49). Le hors PNIJ, qui n'offre pas les mêmes garanties (traçabilité, sécurité, etc.) est anormalement élevé dans certains services (page 49). Attention au chiffre : la PNIJ ne couvre pas toutes les technos ni tous les opérateurs donc est-ce 20-25 % des requêtes que la PNIJ pourrait servir ou 20-25 % de toutes les réquisitions, ce qui a moins de sens ? ;

* Confirmation que Google et Meta refusent de répondre en direct aux enquêteurs, hors PNIJ, ce [à quoi ils ne sont pas tenus](https://www.courdecassation.fr/decision/613fe26074b8ceec7653852e), et qu'ils contrôlent l'opportunité (la légitimité) de la demande (page 47) ;

* « Para-PNIJ » : **réutilisation des données obtenues via la PNIJ** (ou hors PNIJ) dans des logiciels de rapprochement judiciaire (MERCURE, ANACRIM, DeveryAnalytics, etc.) qui n'offrent pas les mêmes garanties (traçabilité, etc.), au titre que la PNIJ manque de fonctionnalités, genre, exemple périmé, la visualisation graphique de la géolocalisation (page 48) ;

* Logiciels de rapprochement judiciaires :

* Autorisés par la LOPPSI 2 de 2011, cf. les articles 230-20 à 230-27 et R40-39 à R40-41 du Code de procédure pénale (page 50). Le Conseil constitutionnel a posé une réserve d'interprétation dans sa décision [2011-625 DC](https://www.conseil-constitutionnel.fr/decision/2011/2011625DC.htm) : pas de traitement général, c'est par enquête. ;

* Autorisés par décret après avis de la CNIL.

* Chapsvision rachète tout le monde (MERCURE, Elektron, Deveryware, etc.) ;

* Les rapporteurs s'inquiètent (pages 51-52) : l'usage de ces logiciels requiert une masse conséquente de données, l'usage constitue un rapprochement automatisé, de la découverte fortuite (donc comment adapter le contrôle, basé sur la gravité de l'atteinte aux droits, quand on ignore à l'avance ce qu'on va découvrir ?), et une absence de traçabilité.

* Avant août 2006, la compensation d'un accès aux données de connexion était librement facturée par les opérateurs (page 42). Depuis, forfait pour investir en matériel + facturation à l'acte, cf. [A43-9 du Code de procédure pénal](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000041553495) (note 2 en bas de page 41). 69 M€ en 2005, 38 M€ en 2006, 122,5 M€ en 2015 (page 42) ;

* Page 111 : l'ANSSI n'a pas de compétence pour superviser les équipements utilisés par les opérateurs pour collecter et conserver les données de connexion. La vulnérabilité aux attaques extérieures des systèmes d'information des 4 opérateurs est auditée par l'ANSSI au titre qu'ils sont [OIV](https://fr.wikipedia.org/wiki/Op%C3%A9rateur_d%27importance_vitale) (c'est pour ça les fuites de données chez 3 d'en eux en 2024-2025 ? :)))) Sources : [1](https://bonjourlafuite.eu.org/img/free.png), [2](https://next.ink/brief_article/red-by-sfr-informe-ses-clients-dune-nouvelle-fuite-avec-une-ribambelle-de-donnees/), [3](https://bonjourlafuite.eu.org/img/bouygues.png)). Le R226-1 du Code pénal donne compétence à l'ANSSI sur l'emploi de dispositifs permettant les interceptions et la géolocalisation en temps réel. Les rapporteurs proposent l'homologation du matériel utilisé par les opérateurs pour collecter et conserver les données de connexion (lol) ;

* **Recherche géographique inversée** (qui était dans telle zone géographique à telle heure au lieu de vérifier si tel suspect était dans telle zone). Page 34 : « la liste des utilisateurs présents dans une même zone à un instant déterminé via le recueil des flux ayant transité par une ou plusieurs bornes » ; « Elles permettent également, par recoupement des numéros de téléphone ayant « borné » dans certains lieux au moment de la commission de plusieurs infractions ». Page 38 : « […] soit pour identifier l’ensemble des utilisateurs présents sur une zone par « bornage » […] ». Page 39. Page 122 : « Il va essayer de voir qui pouvait se trouver dans le secteur à l’heure concernée. ». On retrouve cela dans la [grille tarifaire de compensation des opérateurs](https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000041553495) (MT 40 / MT 41). Ainsi, il n'y aurait pas que les [mézants ricains](/?3Q0AMg) qui pratique cela ? :)))) ;

* L'accès en temps réels aux données de connexion serait plus intrusif que l'accès différé (à ce qui est conservé), car ça recouvrerait aussi les données traitées par les opérateurs pour leurs besoins techniques, comme la localisation GPS (comment un opérateur a-t-il ça ?), les données d'acheminement qui permettent de détecter anonymisation ou VPN, les certificats électroniques ou encore les identifiants et les mots de passe (page 28). Gné ? Ça ressemble à de l'interception des communications, quel rapport avec les données de connexion ? ;

* La directive e-privacy, qui précise l'application du RGPD dans le domaine des communications électroniques et les dérogations, n'est pas entièrement compatible avec le RGPD, sans plus de précision. Page 70 ;

* Page 48 : « analyse des flux interne chiffrés » : kézako ? ;

* On reconnaît un rapport sénatorial à ce qu'à plusieurs reprises, les rapporteurs râlent que la CJUE contraint l'État alors que les grands acteurs du numérique font ce qu'ils veulent, y compris du profilage qui « est susceptible de permettre de tirer des conclusions très précises concernant la vie privée d'une personne » (qui est ce que la CJUE radote dans ses arrêts sur la rétention des données de connexion). Pages 24, 58, 69, 126. Pourtant, il y a le RGPD. Qui les laisse faire ? Pourquoi la CNIL et ses homologues européennes ne font jamais rien ?! Il faut combattre le privé comme le public.

### [Groupe européen de haut-niveau pour l'accès aux données pour une application efficace de la loi](https://home-affairs.ec.europa.eu/networks/high-level-group-hlg-access-data-effective-law-enforcement_en)

* Aussi nommé groupe de réflexion « Going Dark » (:O) ou groupe d'experts ADELE (access to data for effective law enforcement) ;

* Sous l'autorité de la direction générale des affaires intérieures (Home) de la Commission européenne et de la Présidence du Conseil européen, qui sont tous deux pro-flicage, d'après le rapport de la section précédente, page 69 ;

* **Recommandations en juin 2024**, rapport final en novembre 2024 ;

* Ça va bien plus loin que les données de connexion : interception, déchiffrement, coopération, investigation numérique, preuve numérique. Je n'ai lu que les introductions, synthèses / résumés, et sections concernant la rétention des données de connexion ;

* Les données conservées par les intermédiaires techniques pour leurs besoins techniques ou commerciaux doivent être accessibles aux autorités, y compris si le fournisseur chiffre les métadonnées ou les données d'identité civile ;

* **Forcer l'enregistrement des utilisateurs d'un service** (création d'un compte), sans quoi, les fournisseurs de service qui n'ont pas de besoin commercial n'auront rien à communiquer en cas d'injonction (quid de l'adresse IP ?) ;

* **Obligation minimale de conserver les données de connexion permettant d'identifier un utilisateur**, comme l'adresse IP source et le numéro de port ;

* Le reste est basique : harmonisation du cadre juridique sur la rétention des données de connexion et sur l'accès à celles-ci (en se basant sur le règlement e-evidence, cf. supra), cadre indépendant des technos, standardisation des échanges entre acteurs, coopération, le chiffrement pose des difficultés, etc.

#### [Déclaration du Comité européen de la protection des données (CEPD) sur les recommandations du groupe de haut-niveau](https://www.edpb.europa.eu/system/files/2024-11/edpb_statement_20241104_ontherecommendationsofthehlg_en.pdf)

* **Novembre 2024** ;

* Le groupe d'experts propose un régime de conservation harmonisé pour tous les fournisseurs de services qui peuvent octroyer un accès à des preuves numériques, peu importe leur type. Le CEPD y voit une **extension au-delà des services de communication électroniques accessibles au public** qui sont les seuls concernés à ce jour par la rétention des données de connexion, ce qui conduirait à une surveillance généralisée. Et, en effet, à la page 36 de son rapport, le groupe évoque les LLM, les constructeurs automobiles, etc. ;

* Sur la conservation minimale des éléments permettant d'identifier une personne, le CEPD rappelle qu'il s'agit de conserver l'identité civile et les adresses IP de manière indiscriminée. Dans son arrêt C-470/21 (LQDN / HADOPI), la CJUE a jugé qu'une telle conservation généralisée et indifférenciée est possible pour tout type d'infraction *tant* qu'elle ne permet pas de tirer des conclusions précises sur la vie privée d'une personne. Ainsi, le CEPD rappelle que **toute combinaison des adresses IP avec d'autres données est impossible** et que le raisonnement de la CJUE sur la conservation des IP ne s'applique **pas forcément à d'autres types de données de trafic ou de localisation** dès lors qu'elles permettent de tirer des conclusions précises sur la vie privée d'une personne.

### [Rapport d'Eurojust sur l'effet de la jurisprudence de la CJUE sur les régimes nationaux de rétention des données de connexion et la coopération judiciaire](https://www.eurojust.europa.eu/sites/default/files/assets/files/data-retention-report-cjeu-eurojust-13-11-2024.pdf)

* Novembre 2024 ;

* Je ne l'ai pas lu, je l'ai survolé. On retrouve ce qui a déjà été dit : **diversité** des durées, des données conservées, des garanties, des procédures, de ce que sont les infractions graves, etc. **La plupart des États-Membres continuent de travailler sur le sujet**. L'absence de données de connexion perturberait les enquêtes et la coopération judiciaire européenne (comme d'hab', ce point n'est pas vraiment étayé).

### [Étude sur la conservation des metadonnées des communications électroniques à des fins répressives](https://op.europa.eu/o/opportal-service/download-handler?identifier=081c7f15-39d3-11eb-b27b-01aa75ed71a1&format=pdf&language=en)

* 2020 ;

* Par un cabinet de conseil belge, pour la direction générale des affaires intérieures de la Commission européenne (pro-flicage, cf. supra) ;

* Je ne l'ai pas lu, je l'ai survolé ;

* Page 49 : appréciable diagramme de Venn sur les différents ensemble de données de connexion (identité civile, trafic, identification) ;

* Page 162 et suivantes : excellente annexe III sur les **types de données de connexion conservées par chaque État-Membre de l'UE**.

GuiGui's Show - Saturday 9 August 2025

Sat, 09 Aug 2025 00:00:00 +0200

Gagner de l'argent en purgeant /var/lib/mysql

Sat Aug 9 15:14:02 2025 -
http://shaarli.guiguishow.info/?GzvgQQ

J'ai un [SGBD](https://fr.wikipedia.org/wiki/Syst%C3%A8me_de_gestion_de_base_de_donn%C3%A9es) MariaDB. Deux bases de données : Wordpress et Tiny-Tiny RSS. /var/lib/mysql occupe 4,6 Go. Les sauvegardes de ces bases par `mysqldump` occupent moins de 100 Mo. Facteur 47. :O

La raison est évidente : les SGBD ne libèrent pas réellement, sur le stockage, l'espace occupé par des données supprimées. Or, mes bases ont quinze ans (!), j'ai eu jusqu'à trois ans de RSS dans une base, et mon Wordpress recevait plusieurs centaines de commentaires indésirables par semaine, ce qui a fait grossir mes bases de données.

Avec SQLite ou PostgreSQL, un `VACUUM` libère l'espace. Avec MariaDB, il faut un `OPTIMIZE TABLE` sur chaque table, et je n'ai pas obtenu de gain. Aucune idée de la raison. J'attribue ça à un paramètre obsolète dans la configuration.

Sur le web, ça dit de détruire /var/lib/mysql. C'est ce que j'ai fait. Après avoir stoppé MariaDB et m'être assuré d'avoir des sauvegardes, au format archive du système de fichiers et au format extraction des bases au format SQL. J'ai également réinstallé MariaDB afin de tout remettre à plat, d'avoir les paramètres au goût du jour et d'avoir, sans effort, la connexion au SGBD sans mot de passe depuis l'utilisateur système root.

Plus précisément :

Mettre mon blog en maintenance dans la config Apache httpd (« Require all denied »)
systemctl stop mariadb.service
mv /var/lib/mysql /var/lib/mysql.BAK
mkdir /var/lib/mysql
chown mysql:mysql /var/lib/mysql
chmod 700 /var/lib/mysql
apt install --reinstall mariadb-server
systemctl status mariadb.service
mysql # recréer les utilisateurs
mysql -u -p < /chemin/vers/sauvegarde.sql

Résultat : /var/lib/mysql occupe 648 Mo. 672 Mo deux mois plus tard. Soit un gain d'environ 4 Go d'espace de stockage.

Avant cette manipulation, tout mon système occupait 21 Go sur les 40 Go dont dispose ma machine virtuelle. Stable depuis des années.

Du coup, je loue désormais une machine virtuelle dotée de 20 Go d'espace de stockage (au lieu de 40 Go). 2,76 € TTC d'économie par mois. J'ose même pas imaginer le gain d'une telle opération chez les grands fournisseurs ricains d'hébergement qui facturent au temps passé. :O

GuiGui's Show - Friday 8 August 2025

Fri, 08 Aug 2025 00:00:00 +0200

Utiliser Sieve pour ajouter une information à un courriel lors de sa réception

Fri Aug 8 17:13:29 2025 -
http://shaarli.guiguishow.info/?MDrpBg

### Problème

Une administration met à disposition un téléservice pour effectuer des démarches qui se déroulent sur un temps long (plusieurs années).

Elle notifie par courriel l'avancement d'un dossier. Cette notification ne contient aucune information autre que le numéro de dossier et elle renvoie au téléservice.

Quand on a plusieurs dossiers (en dizaines), il faut donc aller sur le téléservice ou consulter son inventaire (tableur) maison pour savoir de quel dossier il s'agit.

Il m'est donc impossible de prioriser ma réaction en fonction du dossier sans accomplir ces formalités au préalable.

C'est fastidieux. N'y a-t-il pas moins pénible ?

### Pistes

J'ai deux idées reposant sur Sieve, un langage de script pour manipuler des emails côté serveur, cf. [mon article sur le sujet](/?pXtpPg).

Soit ajouter un drapeau IMAP (flag) contenant le nom du dossier administratif. Usuellement, ces drapeaux sont utilisés pour marquer un état (vu, répondu, etc., cf. [RFC 9051](https://www.rfc-editor.org/rfc/rfc9051.html#section-2.3.2)), signaler une priorité (urgent, important, etc.) ou trier (perso, pro, etc.).

Soit ajouter le nom du dossier administratif dans le sujet du courriel.

### Réalisation

Pour rappel, j'utilise [PigeonHole, l'implémentation de Sieve de Dovecot](https://doc.dovecot.org/2.3/configuration_manual/sieve/) (qui, en sus d'être un serveur IMAP / POP peut aussi être un [MDA](https://fr.wikipedia.org/wiki/Mail_Delivery_Agent), un agent local de livraison des emails, qui s'occupe des derniers kilomètres, comme un facteur humain, nommé dovecot-lda).

#### Drapeau IMAP

D'abord, il faut utiliser l'action `addflag ` de l'extension `imap4flags`, cf. [RFC 5232](https://datatracker.ietf.org/doc/html/rfc5232) :

require ["body", "imap4flags"];

if body :contains "" {
addflag "";

stop;
}

Ensuite, il faut configurer ton logiciel de messagerie (MUA) pour qu'il affiche un libellé en fonction du drapeau. Avec Thunderbird, cela se passe dans Édition > Paramètres > onglet Général > rubrique Étiquettes.

#### Modification du sujet

Dans un courriel, comme dans un courrier, le sujet (objet) est un entête, comme la date, l'expéditeur, etc.

Il existe l'extension Sieve « Editheader » ([RFC 5293](https://www.rfc-editor.org/rfc/rfc5293.html)).

Néanmoins, elle ne permet pas de modifier un entête, uniquement d'en ajouter et d'en supprimer. Dès lors, il me faudra stocker le contenu initial de l'entête entre les deux opérations.

L'extension Sieve « Variables » ([RFC 5229](https://www.rfc-editor.org/rfc/rfc5229.html)) est là pour ça.

Comment affecter le contenu d'un entête existant à une variable ? Le RFC sur l'extension Variables donne la réponse : expression régulière (regex), capture, groupe de correspondance, etc. Tout cela est pris en charge par le comparateur `:matches`.

Il n'y a plus qu'à assembler ces différentes briques pour composer la solution.

Sur le web, je trouve un [exemple tout prêt](https://superuser.com/questions/1502588/how-to-change-a-messages-subject-in-a-sieve-rule). Je le recopie :

require ["body", "variables", "editheader"];

if body :contains "" {
# On affecte le sujet existant à une variable nommée « varSubject »
if header :matches "Subject" "*" {
set "varSubject" "${1}";
}

deleteheader "Subject";

# « last » est pour le confort : insertion de l'entête à la fin des autres entêtes, juste avant le corps
addheader :last "Subject" "${varSubject} ";

stop;
}

Attention : avec Dovecot, il faut activer l'extension Editheader dans la configuration et la recharger avant de pouvoir l'utiliser dans un script, cf. la [documentation](https://doc.dovecot.org/2.3/configuration_manual/sieve/extensions/editheader/) (sinon : « error: require command: unknown Sieve capability `editheader' ») :

plugin {
sieve_extensions = +editheader
}

On peut également restreindre les entêtes manipulables par un script Sieve via une liste des entêtes autorisés ou une liste des entêtes interdit. Je préconise d'activer ce paramètre.

#### Avantages et inconvénients

L'inconvénient principal du drapeau, c'est qu'il faut le définir dans le script Sieve et dans le client de courriels. La duplication d'une information doit toujours être évitée pour simplifier la maintenance. De plus, l'automatisation de l'ajout des drapeaux côté Thunderbird ne va pas être facile et, vu mes dizaines de dossiers administratifs, il est hors de question que je fasse le boulot à la main.

L'autre inconvénient, c'est qu'il faut cliquer sur un email dans Thunderbird pour voir son drapeau. Oui, un drapeau peut être associé à une couleur, mais vu le nombre de mes dossiers administratifs, c'est impossible à mémoriser.

L'inconvénient principal de la modification d'entête, c'est la sécurité et l'intégrité. Ce n'est pas pour rien que Dovecot n'active pas cette extension par défaut et permet de restreindre la manipulation à certains entêtes. Je ne l'aurais pas activée si je n'étais pas le seul utilisateur de mon serveur de courriel. De plus, que se passe-t-il en cas d'incident (plantage, panne d'électricité, etc.) entre la suppression de l'entête et son ajout ?

L'autre inconvénient est que c'est inutilisable sur des courriels que l'on compte utiliser comme preuves. Ce n'est pas mon cas, mais il faut y penser.

#### Précaution

Pour des raisons de performance, d'intégrité et d'évitement des faux positifs, je préconise de délimiter les emails susceptibles de faire l'objet d'une recherche dans leur corps ou de voir l'un de leur entête être modifié.

### Rigolo

Je ne suis pas parvenu à utiliser les drapeaux prédéfinis dans Thunderbird (« Important », « Travail », « Personnel », etc.). Dans mon script Sieve, je les ai écrits en français, en anglais, en respectant la case ou non, rien à faire, Thunderbird les ignore.

GuiGui's Show - Monday 21 July 2025

Mon, 21 Jul 2025 00:00:00 +0200

Association P·U·R·R — Réponses à consultation public : pixels traçants et consentement cross-device

Mon Jul 21 11:08:20 2025 -
https://asso-purr.eu.org/2025/07/20/reponses-consultations.html

[Réponse de l'association Pour un RGPD respecté (PURR)](https://asso-purr.eu.org/assets/media/20250720-consultation_publique_pixel_tracant.pdf) à la [consultation publique de la CNIL sur les images de traçage dans les courriels](https://www.cnil.fr/fr/consultation-publique-projet-recommandation-pixels-de-suivi).

Il reste **jusqu'à jeudi (24/07) pour participer à la [consultation de la CNIL](https://www.cnil.fr/fr/consultation-publique-projet-recommandation-pixels-de-suivi)**.

Tu n'es pas obligé de répondre aux questions (en réponse à la première question, tu peux dire que t'es contre le flicage de ta correspondance privée quel qu'en soit l'objectif, ça suffit), tu peux faire référence à la contribution de PURR (« Je partage le positionnement de l'association PURR »), tu peux copier-coller des bouts entiers, tu peux t'en inspirer, etc. **L'important, c'est de participer**, de signifier une large opposition aux pixels de traçage dans les emails, au-delà des pénibles de service habituels.

[Résumé du projet soumis à consultation et des enjeux](/?kzU9Yg).