Category Archives: Geek stuff

fr, Geek stuff, vie privée

Le blocage de site sans juge et le projet PJLSREN du gouvernement

3 Comments

Si vous avez suivi l’actualité Internet de ce week-end, ou bien si vous utilisez l’application de messagerie Telegram, vous êtes peut-être tombé samedi (13 mai 2023) sur la page d’erreur suivante en tentant de lire une page que l’on vous avait envoyée :

Que s’est-il passé ? Cet article du Monde revient sur l’incident ; cet article chez Stéphane Bortzmeyer de l’AFNIC explique les éléments techniques ; ce fil de Cécile d’AtaxyaNetwork sur Twitter est une rapide introduction aux notions de base du DNS. Ajout du 15 mai 2023 : article chez Nextinpact.

La liste de blocage DNS française

Ce système a été instauré en 2014 par Bernard Cazeneuve (cet article parle également des premières bavures en surblocage) pendant le mandat Hollande (avant de voter ce procédé, le PS l’avait lui-même combattu lorsqu’il était proposé lors du mandat Sarkozy). Il s’agissait alors, officiellement, de permettre à la police de bloquer en urgence — c’est à dire sans perdre de temps avec une procédure judiciaire, longue — les faits les plus graves : apologie du terrorisme et images de pédopornographie.

"Control of Internet Speech. How would you like this wrapped ? Anti-terrorism, protect kids..."
Image classique des années 90 sur les prétextes à la censure d’Internet

Les critiques n’ont pas manqué sur les dangers d’un tel procédé :

  1. érosion des garanties démocratiques en supprimant le juge
  2. risques de surblocage en raison du procédé utilisé
  3. risques d’erreurs de manipulation, réduisant la résilience de l’Internet français
  4. opacité, la liste n’étant pas publique
  5. risques d’extension sans fin du système à de nombreux cas d’application bénins

On peut citer cet amendement, rejeté, de Laure de la Raudière et Lionel Tardy (historique plus détaillé ici et ici chez Nextinpact), qui tentait de limiter les dégâts :

Et également cet avis de la CNIL, cité par Alexandre Archambault.

La plupart de ces craintes, balayées à l’époque du revers de la main par le ministre et le législateur, se sont aujourd’hui concrétisées.

Le blocage DNS, comment ça marche ?

L’adresse d’un site web, par exemple https://signal.eu.org/blog/, est appelée une URL. Pour diverses raisons, l’une étant le secret des correspondances au sens du Code des postes et des communications électroniques, une autre étant le déploiement massif du chiffrement suite à l’affaire Snowden pour protéger les utilisateurs contre la surveillance de masse, il n’est possible ni juridiquement ni techniquement de bloquer par le réseau un morceau de site web.

Un autre procédé a donc été mis en place par l’État : bloquer le nom de domaine qui sert à indiquer le serveur de l’URL, ici signal.eu.org.

Pour cela, ses services distribuent à quelques fournisseurs d’accès triés sur le volet une liste secrète des blocages à effectuer au niveau de leurs propres serveurs de noms (serveurs DNS), ceux dont la plupart de leurs clients se servent pour accéder au web ou au courriel.

Cette liste fait donc de ces serveurs des “DNS menteurs”, car ils peuvent donner une information exigée par une administration au lieu de l’information correcte.

Le blocage d’un site bloque le site complet. Il est impossible de bloquer une page seule ou un ensemble de pages. L’administration peut décider de bloquer, à sa convenance, un site complet même si celui-ci ne contient qu’une seule page tombant sous le coup de la loi. Cela pose un premier problème d’appréciation subjective de proportionnalité.

Comment est mis en œuvre le blocage DNS en France par l’État

L’opacité règne, malheureusement, sur les détails de procédure, mais on peut dire sans risque d’erreur que :

  • l’administration édicte une ou plusieurs listes de blocage, suivant les mandats qui lui sont confiés par le législateur
  • les fournisseurs dûment choisis par la puissance publique récupèrent périodiquement (au moins plusieurs fois par jour, voire en continu) et appliquent ces listes pour bloquer les domaines concernés

En mai 2023, les administrations en mesure d’édicter des blocages DNS sans juge sont, sauf erreur ou oubli :

  • l’OCLCTIC (office central de lutte contre la criminalité liée aux technologies de l’information et de la communication), qui édite la page d’avertissement en début de cet article. 2 autres pages d’avertissement sont : une page sur le blocage de sites faisant l’apologie du terrorisme, une page générique sur les sites illégaux. Cette liste est soumise légalement à un contrôle par la CNIL, et bientôt l’ARCOM à sa place, mais ce contrôle semble s’effectuer a posteriori, après blocage. Ce contrôle n’évite donc pas les bavures. [Mise à jour 19 mai 2023 : les rapports d’activité 2019 2020 2021 de la personnalité qualifiée de la CNIL avant transfert à l’Arcom, rapport 2022 après transfert]
Schéma de procédure extrait du rapport 2021 de la personnalité qualifiée CNIL
  • l’ANJ (autorité nationale des jeux), qui jusqu’en mars 2022 devait passer par le juge, mais cette protection a été supprimée. Désormais, l’ANJ peut de son propre chef faire ajouter un site aux blocages DNS nationaux. La liste ANJ est publique et disponible ici sous forme de fichier CSV, ce qui permet d’avoir une idée de son contenu. On peut l’imaginer proche de celui du fichier OCLCTIC, pour simplifier la vie des fournisseurs devant l’appliquer. À ce jour, elle contient 725 noms.
La page de blocage de l’ANJ

Techniquement, le fonctionnement du blocage est en partie laissé à l’appréciation des fournisseurs, mais les sites bloqués par l’OCLCTIC doivent renvoyer vers les pages explicatives de l’OCLCTIC. Au passage, ces pages incluent des trackers (gardant donc une trace du passage de l’utilisateur), ce qui pose des problèmes de respect du RGPD. Par ailleurs, la généralisation du chiffrement rend ces messages d’erreur largement inopérants, mais il serait trop long de développer le sujet ici.

Un rare épisode de désaccord persistant entre l’OCLCTIC et la personnalité qualifiée de la CNIL, en raison d’appréciations très différentes sur la caractérisation d’un contenu, a eu lieu en 2018-2019 au sujet du site Indymedia, poussant cette dernière à un recours devant le tribunal administratif de Cergy-Pontoise, qui lui a donné raison (jugement complet). 3 articles de Nextinpact à l’époque reviennent en détail sur l’affaire : Blocage administratif : bras de fer entre la personnalité qualifiée de la CNIL et l’Intérieur, Blocage administratif : le ministère de l’Intérieur attaqué par le représentant de la CNIL, Blocage administratif : la personnalité qualifiée de la CNIL fait plier la police devant la justice. Assez curieusement, seules les URL (pages web) sont évoquées, or, comme expliqué ici, les blocages ne peuvent concerner que le nom de domaine en entier, qui ne semble pas avoir été mis en œuvre en réalité.

Extension du domaine de la liste

Ce procédé sans juge de blocage instantané, mis en place en 2014 sur des cas extrêmes, a été progressivement étendu malgré les promesses initiales :

  • à des cas bien plus bénins comme les sites de jeux
  • à un nombre croissant de fournisseurs d’accès, dans des conditions également opaques. La police s’est initialement attaquée aux 4 plus grands fournisseurs français fixe et mobile (Free, Orange, Bouygues, SFR) ; en 2023, de nombreux autres fournisseurs de plus petite taille sont également tenus de mettre en œuvre les blocages. Il est difficile de savoir qui et suivant quels critères ; on peut supposer qu’il s’agit d’initiatives de la police, au cas par cas. L’opacité des blocages OCLCTIC limite fortement la possibilité de disséminer largement la liste chez tous les fournisseurs d’accès : la liste serait rapidement fuitée.

Surtout, un nouveau projet de loi du gouvernement, PJLSREN (projet de loi visant à sécuriser et réguler l’espace numérique), va étendre à nouveau très sensiblement le processus sans juge :

  • extension aux ajouts par la DGCCRF (répression des fraudes : sites commerciaux d’arnaques)
  • extension aux ajouts par l’ARCOM (sites ne procédant pas à une vérification forte d’âge pour l’accès à la pornographie ; sites de propagande étrangère ; possiblement sites de piratage de streams de contenus sportifs)
  • extension aux services DNS ouverts (résolveurs), souvent utilisés comme moyen de contournement des mesures de blocage
  • extension aux éditeurs de navigateurs web, pour afficher une page d’avertissement néanmoins contournable
  • [Mise à jour] et potentiellement, si on en croit l’étude d’impact, d’autres administrations encore, avec un inventaire à la Prévert : l’ANSSI (agence nationale de la sécurité des systèmes d’information), l’ACPR (autorité de contrôle prudentiel et de résolution), l’AMF (autorité des marchés financiers), CyberGend (commandement de la gendarmerie dans le cyberespace), le GIP ACYMA, la mission d’appui au patrimoine immatériel de l’État (APIE), Signal Spam.
Page 95 de l’étude d’impact

L’étude d’impact du PJLSREN ne s’encombre pas d’obstacles techniques, écartant la plupart de ceux-ci d’un rapide revers de main, ce qui ne fait que renforcer le sentiment de flottement (j’en ai parlé sur Twitter ici).

On passe donc graduellement, sous l’égide du gouvernement Macron, d’un système de blocage d’urgence et limité, réservé aux cas les plus graves, à un système administratif de censure instantanée d’Internet, en masse, sans juge. Il est non seulement probable, mais certain, que les mesures ci-dessus seront resserrées et étendues au fil du temps pour criminaliser ou interdire techniquement les contournements, et l’accès élargi à d’autres administrations.

Et les bavures ?

Il est également à craindre que l’extension de l’ampleur du système provoque une multiplication des bavures comme celle concernant Telegram ce samedi, rendant Internet de moins en moins fiable. Il est donc nécessaire de demander de limiter le nombre des catégories de sites concernés, et d’obtenir de la part de l’administration une plus grande transparence sur la procédure actuelle, sur les gardes-fous qu’elle inclut, et sur ceux à y ajouter.

En 2016, le député Lionel Tardy avait posé quelques questions au ministre, hélas restées sans réponse.

Quelques autres questions légitimes à poser, à l’administration comme au législateur, sur le système actuel comme sur ses extensions :

  • par quelle chaîne de décision a-t-on abouti à ce que le domaine t.me soit dans la liste de blocage sans que quelqu’un détecte et élimine l’erreur ?
  • quel est le fonctionnement actuel du système de blocage OCLCTIC ?
  • quelle catégorie d’agent est ou sera habilitée à demander un blocage, sous quelle forme (URL ou nom de domaine) ?
  • où, comment et à quel moment intervient la CNIL — que le PJLSREN compte remplacer par l’ARCOM — ?
  • quelles vérifications et validations, manuelles ou automatiques, sont faites sur la demande ?
  • [ajout le 15 mai 2023] t.me est un usage assez particulier (raccourcisseur avec redirection), quelles dispositions de la procédure permettent ou pourraient permettre de détecter et traiter spécifiquement ce type de nom afin d’éviter un surblocage ?
  • quelles sont les voies de recours rapides pour les sites bloqués à tort ?
  • quelle est la procédure corrective actuelle en cas d’erreur de blocage à corriger en urgence ?
  • comment peut-on éviter de nouvelles bavures similaires à celles de t.me, dans le mesure où le procédé risque d’être substantiellement étendu si la nouvelle loi est votée ?
  • comment une demande de blocage d’URL est-elle convertie en demande de blocage DNS afin de la faire figurer dans la liste envoyée aux fournisseurs d’accès ; quelles précautions sont prises pour éviter un surblocage ?
  • quels critères subjectifs sont et seront appliqués, par exemple pour estimer si un site est, ou non, de nature pornographique ? Un site d’apologie du terrorisme ? Un site d’arnaque ?
  • même question pour déterminer si un site est, ou non, un site de propagande étrangère ?

Le ministre Jean-Noël Barrot a indiqué en effet être prêt à faire bloquer totalement le réseau social Twitter, qui n’est pas un site pornographique, ou d’autres réseaux sociaux qui ne vérifieraient pas l’âge des utilisateurs et n’interdiraient pas la pornographie. La loi souhaite en outre faciliter le blocage de sites d’information sous influence de gouvernements étrangers. On est là au cœur de la problématique de la liberté de communication et d’influence politique de l’État sur son application par des acteurs privés.

Est-ce un incident ponctuel et isolé ?

L’arbre du DNS ne doit pas cacher la forêt : il existe une tendance de fond de l’État et du politique, en France et au delà, à vouloir régenter, censurer et surveiller, non seulement Internet, mais l’ensemble de notre vie privée, à l’aide de nos usages grandissants de la technologie, qui présentent des coffres aux trésors très tentants.

Ainsi, en articulation directe avec le PJLSREN cité ci-dessus et qui est le sujet principal de ce billet, on peut rappeler, entre autres, la loi dite de “majorité numérique” visant à forcer l’ensemble des adultes en France à fournir une preuve d’âge pour se connecter aux réseaux sociaux. Le PJLSREN permet un blocage beaucoup plus radical et rapide des sites qui n’appliqueraient pas avec une diligence suffisante une vérification forte de l’âge des utilisateurs.

Il existe de nombreuses autres lois similaires, en France comme dans d’autres pays, cherchant à s’attaquer à la confidentialité de nos communications privées, etc.

Il ne s’agit pas simplement, comme cela est souvent prétendu, d’appliquer à Internet les mêmes interdictions que dans la vie réelle, mais d’aller beaucoup plus loin grâce à l’utilisation à notre détriment, et sous prétexte de notre sécurité, des moyens technologiques modernes.

fr, Geek stuff, Hacks

Faire tourner une intelligence artificielle sur un ordinateur personnel

2 Comments

Les intelligences artificielles (IA) conversationnelles étant à la mode depuis l’émergence de ChatGPT cet automne, j’ai voulu en avoir le cœur net et évaluer les ressources qu’elles requièrent.

En effet, les affirmations ne manquent pas sur les ressources énormes nécessaires : cartes graphiques haut de gamme comme l’A100 de Nvidia (20 000 dollars), nombre de serveurs, nombre de paramètres, etc. Ces ressources les réserveraient à des grosses sociétés aux poches profondes. Est-ce vrai ?

Ce week-end j’ai donc réalisé mon premier dialogue avec une IA tournant chez moi, en utilisant notamment des dérivés de LLaMa, le moteur diffusé partiellement en logiciel libre par l’équipe de l’IA de Facebook. Cette équipe est dirigée par le français Yann Le Cun, un des pères du domaine.

Pourquoi ?

ChatGPT à sa sortie publique a provoqué un choc dans le milieu de l’intelligence artificielle et des LLM (modèles de langage), et au delà. La technologie est récente et les spécialistes du domaine connaissaient son potentiel, mais personne n’avait réussi à en proposer une mise en œuvre pertinente pour le grand public. OpenAI a donc, d’une certaine manière, « vexé » la profession en recevant toute l’attention. OpenAI, qui initialement avait été fondé pour diffuser ce travail en logiciel libre, a changé brutalement son fusil d’épaule sous prétexte de la puissance du procédé qu’il ne faudrait “pas mettre entre toutes les mains”. Les avertissements (et les peurs, souvent exagérées) sur les conséquences du déploiement de ces technologies sont à l’avenant.

En réaction sont apparus des efforts de mise à disposition au plus grand nombre, pour au contraire profiter à tous et éviter un accaparement de la technologie par OpenAI. En effet, OpenAI est loin d’être le seul acteur dans ce domaine, ni le premier. Hors Facebook (Meta), on peut notamment citer Hugging Face (page Wikipedia) fondée par des français.

Qu’est ce que c’est ?

Il existe 2 éléments principaux pour faire fonctionner une intelligence artificielle à apprentissage profond, qui est la technologie utilisée pour ces agents conversationnels :

  • le moteur, dont bon nombre existent en logiciel libre, mais qui ne savent rien faire par eux-mêmes ;
  • le paramétrage du moteur, résultat d’un long apprentissage sur un ensemble de textes, images ou autres, et qui recèle l’essentiel de l’« intelligence » du système.

Je n’ai pas installé le moteur initial de LLaMa mais une réimplémentation optimisée pour fonctionner avec moins de ressources, llama.cpp, fournie avec toutes les instructions d’installation sous Linux.

llama.cpp est un moteur “générique” et permet de faire tourner plusieurs modèles, comme le décrit sa page d’accueil : le modèle LLaMa original, mais aussi Alpaca, GPT4all, vigogne (un modèle français), etc.

Quels modèles ?

Le modèle LLaMa, de même nom que le moteur, a été distribué par Facebook suite au buzz provoqué par le lancement de ChatGPT.

De nombreux modèles sont dérivés du modèle Facebook (qu’il faut donc récupérer en montrant patte blanche, comme expliqué ici). D’autres sont distribués de manière indépendante, certains avec un moteur dédié, mais tous peuvent tourner avec le moteur llama.cpp, éventuellement suite à conversion de leur format.

J’ai ainsi essayé :

  • LLaMa dans 3 de ses versions : 7B, 13B et 30B. La version 65B est un peu trop grosse pour ma machine ;
  • Alpaca, plus compact que LLaMa à performances comparables ;
  • vigogne, un modèle français dérivé du modèle LLaMa. Vigogne est “réglé finement” (fine-tuned) avec des instructions en français. Le “fine tuning” consiste à compléter un gros modèle déjà calculé (processus très long) avec des instructions de spécialisation particulières qui l’ajustent à la marge. On obtient alors un nouveau modèle. Vigogne a ainsi repris les modèles d’apprentissage d’Alpaca, en les traduisant en français, pour obtenir un modèle plus à l’aise en langue française ;
  • gpt4all , un autre modèle dérivé de LLaMa, mais qui a reçu en complément d’apprentissage 800 000 questions-réponses en partie traitées avec GPT-3.5, le modèle d’OpenAI.

Je n’ai pas encore essayé :

Le domaine avance très vite et de nouveaux modèles ou mises à jour apparaissent en permanence.

Quelles ressources ?

Bien entendu, plus un modèle est gros, plus il est censé être “pertinent” et s’exprimer de manière naturelle, et plus il va occuper de ressources (disque, mémoire et processeur). Cependant, d’autres facteurs interviennent :

  • la qualité de l’apprentissage : à taille égale, certains modèles sont plus efficaces que d’autres ;
  • la taille du modèle : plus il est gros, plus il a compilé de « connaissances » et sera pertinent ;
  • la taille unitaire des paramètres : certains modèles ont 16 bits par paramètre, ce qui est assez lourd. Il est possible de réduire cette taille à 4 bits par paramètre, au prix d’une légère dégradation de pertinence ;
  • l’architecture du réseau neuronal choisi : nombre et taille des couches de neurones, interconnexions entre couches.

Si le procédé des réseaux neuronaux est d’ordre général, en revanche les formats de fichiers stockant les modèles diffèrent et évoluent. Un même modèle peut donc fonctionner sur différents moteurs, mais il peut être nécessaire de convertir les fichiers.

Les procédés de conversion pour llama.cpp sont expliqués dans la documentation du logiciel et concernent plusieurs modèles. La conversion des modèles LLaMa nécessite la bibliothèque pytorch, que je n’ai pas réussi à faire fonctionner sous FreeBSD, le système d’exploitation que j’utilise. J’ai donc installé un Linux, distribution Debian 11, dédié à cet usage. Vigogne et GPT4All ont également besoin de conversion de fichiers.

Les tailles des modèles que j’ai récupérés sont les suivantes :

  • LLaMa 7B : environ 13 Go en version originale 16 bits, 4 Go en version 4 bits.
  • LLaMa 13B : environ 26 Go en 16 bits, 8 Go en 4 bits.
  • LLaMa 30B : 65 Go en 16 bits, 20 Go en 4 bits.
  • LLaMa 65B : 130 Go en 16 bits, conversion encore en cours chez moi après plusieurs jours…
  • Alpaca : 4 Go, modèle en 4 bits
  • vigogne 7B : 13 Go en 16 bits (dérivé de LLaMa), 4 Go en 4 bits.
  • gpt4all : 4 Go en 4 bits (plusieurs modèles, “filtrés” ou non)

L’ordinateur sur lequel j’ai réalisé ces traitements est un PC sous FreeBSD, 32 Go de mémoire, 8 To de disque, et un processeur AMD Ryzen 5-5600G avec circuit graphique (GPU) intégré, qui hébergeait une machine virtuelle Debian 11 à qui étaient alloués 8 à 28 Go de mémoire pour convertir et faire tourner les modèles.

La conversion des modèles a nécessité de 8 à 20 Go de RAM. Le processus de conversion utilisait au pire 16,5 Go de mémoire pour le modèle le plus gros, LLaMa 65B.

Il est ensuite possible de lancer le modèle, soit avec son logiciel d’origine, soit avec llama.cpp. J’ai commencé avec le modèle LLaMa 7B, qui se contente pour fonctionner de 6 Go de mémoire. Voici une démonstration dans une vidéo non accélérée :

J’ai ensuite essayé le modèle LLaMa avec 13 milliards de paramètres (13B), qui répond de manière plus pertinente mais mélange parfois tout, avec des morceaux inattendus en LaTeX (un langage de traitement de texte). J’ai aussi eu des extraits de réponses en langage Python.

Puis j’ai tenté la même chose avec Alpaca (modèle diffusé par l’université de Stanford, dérivé à la fois de LLaMa et de certains fichiers d’apprentissage de OpenAI). Alpaca, peut-être grâce à son modèle stocké en 4 bits, a besoin de beaucoup moins de mémoire pour des résultats plus pertinents. Ici j’ai utilisé directement le logiciel chat fourni avec le modèle, qui chez moi tourne beaucoup plus rapidement qu’avec llama.cpp :

Verdict sur les ressources

Je voulais voir s’il était possible de faire tourner ce type de logiciel sur un PC relativement basique. La réponse est donc positive. Il est inutile d’avoir une carte graphique (GPU) surgonflée ou des quantités astronomiques de RAM, grâce au travail d’optimisation incroyable fait par les développeurs et publié en source.

Ça marche aussi sous FreeBSD

Je n’ai pas réussi à me passer de Linux pour la conversion des modèles, mais les utiliser est plus facile. Alpaca se compile et tourne très facilement sous FreeBSD :

$ git clone https://github.com/antimatter15/alpaca.cpp
$ cd alpaca.cpp
$ gmake
$ ./chat

Il faut aussi télécharger le fichier .bin du modèle (cf instructions d’Alpaca). Ce qui permet de se faire bullshiter ensuite comme par tout bon LLM :

llama.cpp tourne également sans problème sous FreeBSD, mais bien plus lentement car les extensions AVX/AVX2/F16C/SSE3 ne sont pas activées. Il s’agit d’un problème mineur probablement puisque alpaca.cpp les utilise. On note que, comme tout bon modèle de langage, LLaMa n’hésite pas à broder en m’affirmant des choses totalement hors de sa portée :

Quels résultats avec ces modèles ?

Tous les modèles présentés ici dérivent plus ou moins directement de LLaMa. Le but est de s’approcher au plus près de GPT-3.5, le modèle phare vendu par OpenAI, et avec le moins de ressources possibles.

Le résultat est subjectif et dépend des usages, mais GPT-3.5 semble détenir encore une avance assez nette en pertinence, longueur des réponses et qualité des textes générés, grâce à sa grande taille et à celle du corpus qui a servi à l’entraîner.

Cependant, les modèles existants peuvent déjà être très utiles en analyse de texte en langue naturelle, en aide à la rédaction de texte ou de code, créativité, etc.

Les progrès sont également très rapides : il y a quelques semaines à peine, les faire fonctionner sur un simple PC était beaucoup plus difficile. Il ne fait aucun doute que d’ici la fin 2023, d’autres avancées notables seront réalisées.

Annexes

Copie d’écran du processus de conversion d’un des modèles LLaMa :

Processus (beaucoup plus rapide) de transformation du modèle 16 bits en modèle 4 bits :

environnement, fr, Geek stuff

Énergie solaire personnelle pour le numérique, retour d’expérience

5 Comments

En mars 2022, j’ai voulu tenter une petite expérimentation : est-il possible en ville d’assurer 100 % de sa consommation énergétique numérique mobile (ordinateur portable + ordiphone) par énergie solaire renouvelable ?

L’idée de fond n’était pas de décarboner ni de faire une économie sur la facture d’électricité : malgré le pilonnage médiatique anti-numérique sur le poids colossal supposé de celui-ci, les quantités en jeu sont insignifiantes : tout au plus 50 à 100 Wh par jour, soit moins de 0,02 € sur la facture.

Le but était surtout de voir si on peut s’assurer une autonomie minimale en cas de coupure prolongée du réseau électrique.

L’habitat en ville, en immeuble, introduit quelques contraintes :

  • impossible d’utiliser un groupe électrogène classique : solution de toute façon exclue car polluante, bruyante, et non autonome puisqu’il faut de l’essence ;
  • difficile de déployer des panneaux solaires fixes sans accès à la toiture.

J’ai donc opté pour cette batterie de camping, d’une capacité de 500 Wh avec sortie 220 V et USB :

… et ce panneau solaire d’un peu moins de 1 m² , pour une puissance crête théorique de 120 W :

Le coût des 2 équipements est de presque 700 €, ce qui exclut toute rentabilité de l’investissement en terme de production d’électricité.

Avec une telle capacité de batterie, on peut en gros espérer alimenter un ordinateur portable pendant 20 à 30 heures, ou faire 30 recharges complètes de téléphone mobile.

La batterie pourrait se recharger théoriquement en 4-5 heures si le panneau produisait au maximum (120 W), mais la batterie possède un limiteur qui n’accepte pas plus de 65 W en charge. Cependant, il est possible de dépasser cette valeur par grand soleil en branchant des charges directement en sortie : elles seront alors alimentées directement par l’électricité reçue du panneau. L’électronique se charge alors de gérer les excédents en chargeant la batterie, ou les déficits en la déchargeant.

Par un beau jour et par éclairage direct, il est possible de récupérer 65 W, donc recharger la batterie théoriquement en 8-9 heures. En pratique, même au solstice d’été, en ville avec les ombres portées par les immeubles, il est difficile de dépasser 3-4 heures de charge maximale.

On peut bien sûr optimiser la production en déplaçant le panneau manuellement pour suivre au mieux le soleil, mais c’est peu pratique et très chronophage.

En novembre, ça se corse : le soleil est plus bas — ce qui, en ville, augmente très sensiblement les périodes d’ombre portée –, le temps est plus couvert, il est difficile de récupérer plus de 5-10 W. Ici, par temps couvert, on atteint péniblement 3 W, soit environ 2 heures pour gagner 1 % de charge batterie seulement. Depuis que j’ai pris cette photo, la puissance de charge est tombée à 1 W en plein midi…

La batterie était tombée à 10 % en début de mois, mais j’ai pu récupérer 30 % de charge en 2 journées relativement ensoleillées et avec un suivi serré du soleil.

En conclusion, si par une belle journée d’été ou de printemps il est assez facile de produire 100 à 200 Wh avec un tel matériel, on doit plutôt tabler sur 10 à 20 Wh par jour en moyenne en automne en région parisienne sur une journée couverte, et elles sont nombreuses.

Je considère donc que fonctionner en autonomie complète sur mon matériel mobile, malgré une utilisation très sobre (30 mn d’ordinateur portable par jour), est un quasi-échec.

fr, Geek stuff, vie privée

Boites noires, URLs et poudre de perlimpinpin

4 Comments

En raison de l’actualité — révision de la loi renseignement de 2015 –, on parle à nouveau des boites noires, dispositifs que les services de renseignement ont souhaité installer dès 2015 sur Internet dans l’espoir d’opérer un équivalent des écoutes téléphoniques.

Ce billet se veut une réflexion purement théorique sur les aspects juridiques et possibilités techniques des boites noires [pour les aspects techniques réels voire a-légaux, on peut se référer à cet article de Reflets sur IOL et j’y reviendrai peut-être ; pour le juridique, à cet article très détaillé de Félix Tréguer].

Les boites noires ont été créées, au titre de la loi renseignement votée en juillet 2015, par l’article L851-3 du code de la sécurité intérieure. Extrait :

il peut être imposé aux opérateurs et aux personnes mentionnés à l’article L. 851-1 la mise en œuvre sur leurs réseaux de traitements automatisés destinés, en fonction de paramètres précisés dans l’autorisation, à détecter des connexions susceptibles de révéler une menace terroriste.

Le législateur ne dit rien ici des moyens à mettre en œuvre. En théorie, il peut s’agir de traitements purement logiciels — utilisant donc les moyens existants de l’opérateur –, ou de matériel dédié à cet usage — ce que l’on entend en général par “boites boires” –.

C’est la CNCTR (Commission nationale de contrôle des techniques de renseignement) qui se charge de la mise en œuvre administrative des boites noires : procédures d’autorisation, etc.

La CNCTR et l’« algorithme »

Dans le rapport d’activité 2019 de la CNCTR, les « boites noires » sont plaisamment baptisées « technique de l’algorithme ». On peut lire page 51 :

“S’agissant enfin de l’algorithme52 sur des données de connexion en vue de détecter des menaces terroristes, aucune nouvelle autorisation de mise en œuvre n’a été sollicitée en 2019. À la fin de l’année 2019 trois algorithmes avaient été autorisés depuis l’entrée en vigueur du cadre légal et continuaient à être en fonctionnement.”

52 – Il s’agit de la technique prévue par les dispositions de l’article L. 851-3 du code de la sécurité intérieure.

À ce stade, avec 3 mises en œuvre en 2019, le déploiement des boites noires semble assez limité. Dans son rapport 2020 qui vient tout juste d’être publié, la CNCTR affirme que rien n’a changé cette année-là : ces mêmes 3 boites noires sont toujours en place.

Malgré de nombreux débats et questions au parlement lors de leur vote, on ne sait rien sur leurs capacités physiques, ni sur les données et algorithmes utilisés, ni sur les emplacements choisis. La raison invoquée est le secret défense.

Sous le capot : les données de connexion

Un rapide détour technique s’impose. Si cela vous ennuie, vous pouvez passer directement à la section suivante.

C’est un document technique, la RFC 791, qui a défini le format des informations échangées sur Internet, autrement le paquet IPv4 (je ne parlerai pas ici du paquet IPv6, mais les principes sont les mêmes). C’est son entête qui contient l’intégralité des données de connexion réellement utilisées par le fournisseur d’accès. On parle aussi de métadonnées. Surlignées en vert, les données indispensables à l’acheminement du paquet : l’adresse source et l’adresse destination. En orange, d’autres données également utiles à l’acheminement. En jaune, on commence à entrer dans les détails des données transmises : il ne s’agit plus vraiment de données de connexion au sens strict.

La RFC 793, quant à elle, définit les informations de l’entête TCP, qui est utilisé notamment pour les connexions http (web), et vient s’ajouter aux données IP précédentes.

TCP définit le port source et le port destination (ici en jaune) : ils permettent en particulier de distinguer une connexion web (port 80 ou 443) d’une connexion de courrier électronique (25, 143, 993, 587, etc, suivant le cas). TCP transporte également les données utiles — l’intérieur de l’enveloppe –, c’est le “data” en rouge en bas du paquet.

L’inspection profonde, ou DPI

On appelle Deep Packet Inspection (DPI), en français « inspection de paquets », l’accès aux données au delà des données de connexion. C’est un procédé beaucoup plus intrusif, et qui sort du cadre de ce qui est permis par la loi même au titre des boites noires.

En matière postale, cela reviendrait à ouvrir une enveloppe pour en lire le contenu, ce qui est formellement prohibé (secret des correspondances).

Le terme de DPI éveille donc l’attention lorsqu’il est utilisé.

Que sont les boites noires et où les met-on ?

Ce point à lui seul mériterait un billet complet. Les questions à se poser sont, notamment :

  • les boites noires contiennent-elles des moyens de stockage ?
  • où sont-elles placées : sur les dorsales de réseaux, aux points d’échange, aux points de raccordement des abonnés, chez les hébergeurs, sur des liens internationaux… liste non exhaustive et non exclusive ?
  • quelles informations pré-triées remontent-elles aux services de police ?
  • quels traitements sont réalisés, dans la boite noire et après celle-ci, sur les informations ?

La nouvelle loi et l’accès aux URL…

D’après Gérald Darmanin reçu par France Inter le 28 avril 2021, la nouveauté sera l’accès aux URL : « La difficulté que nous avions, c’est que nous n’utilisions pas les URL. Là vous utilisez les URL, c’est à dire les données de connexion qui vous permettent de voir quelle recherche exacte vous faites. » (émission ici).

[Mise à jour : Il invoque ensuite — et c’est un sujet légèrement différent, mais connexe et plus inquiétant — la collaboration des plateformes pour accéder à nos messages chiffrés et possiblement aux journaux de connexion, qui permettent de savoir les URL consultées.]

… et pourquoi ce n’est pas si simple qu’à la radio ou au parlement

Cela pose deux problèmes : un de principe, et un technique.

Le problème de principe est simple : l’URL est transportée uniquement dans la partie data des paquets. Si on se limite aux données de connexion, comme l’exige actuellement la loi, il est impossible d’y accéder. En fait, la loi interdit même, en théorie, à la police de distinguer une connexion web d’une connexion de courrier électronique ou d’une requête DNS, puisqu’il faut regarder les numéros de ports, et que ceux-ci ne relèvent pas à strictement parler des données de connexion au sens du fournisseur d’accès.

Pour accéder aux URL, il faut donc exploiter du DPI, mentionné plus haut.

Admettons donc qu’une analyse complète du paquet par DPI soit permise juridiquement.

Aujourd’hui, 80 % des communications de données sur Internet sont chiffrées. C’est ce qu’indique le cadenas dans votre navigateur, désormais présent sur presque tous les sites. [Correction : @cryptopartyrns sur twitter m’indique qu’en 2021 on est plutôt autour des 90-95 %]

Or, il est impossible d’accéder à ces données de manière instantanée. Au mieux, il faut dépenser des semaines ou mois de calcul intensif pour casser le chiffrement (décrypter). C’est évidemment impossible à réaliser sur une proportion significative du trafic Internet : ce type de décryptage, coûteux et lent, n’est effectué que dans des cas rares et limités.

La CNIL dans sa délibération du 8 avril 2021 confirme d’ailleurs que seule l’écoute des URL “en clair” est envisagée à ce stade :

Le chiffrement ne protège pas toutes nos communications

Sans casser le chiffrement, il existe encore plusieurs failles à la confidentialité de notre trafic :

  • les adresses IP source et destination, nécessaires pour acheminer le trafic.
  • les numéros de ports utilisés, qui donnent des indices sur l’activité (web, mail, etc).
  • le DNS, qui circule encore largement en clair aujourd’hui, même si DoH et DoT visent à mettre fin à cette faille. En écoutant le DNS, il est possible de savoir le nom du site auquel quelqu’un accède. Si le site est youtube.com ou facebook.com, cela ne va pas nous en apprendre autant sur le contenu que s’il s’agit de openrailwaymap.org.
  • le chiffrement web, appelé TLS, ne chiffre pas encore le nom du site demandé. On peut donc le connaître également par ce biais. C’est en cours de résolution avec une extension appelée ESNI, dont le déploiement est balbutiant.
  • il existe aussi des failles occasionnelles de sécurité permettant de casser plus rapidement du trafic chiffré. Ces failles sont évidemment corrigées après leur découverte, et tout est fait pour les éviter. Leur exploitation ne peut être qu’aléatoire et temporaire, il n’est pas possible de fonder une stratégie d’écoutes sur elles.
  • il y a enfin la possibilité d’émettre des faux certificats pour écouter le trafic. Ce type d’intervention n’est cependant pas discret, il ne peut donc pas être utilisé à grande échelle sous peine d’être rapidement découvert.

L’existence de très grandes plateformes rend la connaissance du nom de serveur de moins en moins utile : personne ne peut savoir par ce simple nom si la vidéo Youtube ou la page Facebook que je consulte sont celles d’un groupe faisant l’apologie du terrorisme ou d’un club de fondamentalistes des chatons.

Il existe un dernier moyen, plus aléatoire mais plus rapide, de découvrir quel contenu chiffré a été accédé : la connaissance de la quantité de données transférées. Si j’accède sur nextinpact.com ou partipirate.org à une page de 367813 octets, il est relativement facile à partir de cette simple information de retrouver de quelle page il s’agit à partir d’un index du site, tel que les moteurs de recherche peuvent en posséder. Là aussi, des contre-mesures sont envisageables dans le futur proche (bourrage de paquets, ou padding).

Déterminer quelle vidéo a été consultée à partir de la taille transmise est plus difficile, les retours en arrière ou visionnages partiels étant fréquents. En revanche, on peut tenter d’estimer le débit de la vidéo, voire le passage visionné, à partir des intervalles temporels et des tailles de paquets.

L’intelligence artificielle peut-elle aider Gérald Darmanin ?

Probablement : non.

Je suppose que l’on parle ici de la technique particulière de l’apprentissage profond (réseaux neuronaux). L’effet de mode étant patent, le terme d’IA utilisé en tant que poudre de perlimpinpin, comme le secret défense, permet de se dispenser d’argumentation.

Or l’intelligence artificielle — comme l’informatique — a besoin, pour fonctionner, de données concrètes et ne peut pas deviner des données non accessibles, par exemple chiffrées, qui sont majoritaires dans l’Internet d’aujourd’hui.

Supposons malgré cela qu’on ait des données suffisamment « en clair ».

L’intelligence artificielle a en outre besoin d’une quantité suffisante de données : un jeu de données initial, de préférence aussi étendu que possible, fourni avec les « réponses ». Dans le cas de l’apprentissage lié aux boites noires, puisque nous voulons déclencher, ou ne pas déclencher, des alarmes appelant à une investigation plus poussée, il faudrait donc les données suivantes :

  1. des données de connexion anodines ne devant pas déclencher d’alarme
  2. des données de connexion de présumés terroristes déclenchant l’alarme

Si l’ensemble 1 ne pose pas de problème technique pour être obtenu en volume, l’ensemble 2 est moins simple : il existe heureusement peu de terroristes, on ne dispose donc pas a priori de beaucoup de données de connexion en rapport, et les signaux à repérer vont varier dans le temps : nouveaux sites, nouveaux contenus, nouvelles applications.

L’usage de l’intelligence artificielle pour détecter des terroristes ne semble pouvoir mener qu’à une impasse également : les données d’apprentissage ont toutes les chances d’êtres insuffisantes, la cible est rare, et la combinaison de ces deux facteurs va donc produire une quantité élevée de faux positifs. Tous les systèmes de « détection automatique de terroristes » ont ce même problème statistique.

Comment réagir ?

Il est établi que l’accès aux URL n’est pas possible avec le degré et l’utilité que laissent entendre les déclarations de Gérald Darmanin.

Concernant l’usage de l’intelligence artificielle, le ministre cherche manifestement à développer l’industrie des technologies de surveillance par de la subvention déguisée. Autrement dit : chacun sait que cela ne peut pas marcher, mais cela permet d’attribuer de la commande publique à des sociétés bien choisies. Cette intention de soutenir l’industrie de la surveillance a déjà été explicitée par le gouvernement, notamment lors des discussions sur la reconnaissance faciale.

Il est probable que la loi ne va pas changer grand chose à l’efficacité des boites noires. Si la disposition permettant l’accès aux URL est adoptée, elles vont devenir plus intrusives : l’accès au delà des données de connexion est un précédent et supprime une protection notable. Il faut donc nécessairement le refuser, en tant que position de principe.

Mais l’impact de ce renoncement est fortement atténué par le déploiement du chiffrement suite aux révélations d’Edward Snowden concernant la surveillance de masse.

Nous devons donc continuer à privilégier les outils chiffrés de bout en bout, et les informaticiens à les déployer et les développer (je pense à la protection des noms de domaine). Fondés sur les mathématiques plutôt que sur les intentions de nos gouvernants et de nos polices, ils restent le meilleur moyen à ce stade de nous protéger des intrusions à grande échelle dans nos communications personnelles et notre vie privée.

Quant aux intentions exprimées par Gérald Darmanin sur la collaboration des plateformes pour accéder à nos contenus chiffrés en passant par la petite porte, elles sont à suivre avec une grande attention, car elles constituent une autre forme notable d’extension de la surveillance, d’autant plus inquiétante qu’il n’y a jamais de retour en arrière (effet cliquet).

divers, environnement, fr, Geek stuff, Hacks

Pourquoi j’ai piraté ma propre imprimante et ses cartouches officielles

24 Comments

Tout a commencé en septembre 2017 par un banal achat d’imprimante laser couleur. Il nous fallait une imprimante utilisable facilement ailleurs que sous Windows, idéalement en réseau pour éviter des allées et venues entre ordinateurs, et recto-verso. De préférence, connaissant les formats Postscript ou PDF pour éviter d’avoir à réaliser des conversions. La plupart de ces fonctions sont réalisables par logiciel pour compenser leur absence, mais c’est toujours plus compliqué à mettre en œuvre.

Par ailleurs, nous souhaitions une imprimante laser au lieu d’une jet d’encre. Ces dernières ne sont pas particulièrement moins chères, et sont moins fiables (l’encre sèche avec le temps), alors que nous imprimons assez peu. Je pensais aussi échapper aux restrictions d’usage qui touchent les cartouches jet d’encre et permettent de les vendre à prix fort, pensant naïvement que les cartouches de toner en étaient exemptes.

Bref, nous trouvons rapidement un modèle qui coche toutes les cases à un prix intéressant, un peu moins de 110 €. Appelons-la modèle 310.

C’est une imprimante très ressemblante mais d’un modèle différent que nous recevons. Appelons-la 317. La 317 est identique à la 310, à un petit détail près : elle a l’option wifi, qui ne nous intéresse pas du tout. Mais ça ne semble pas gênant de l’avoir.

L’imprimante est munie de 4 cartouches d’encre d’origine : noir, magenta, cyan, jaune. Elles sont censées permettre l’impression d’environ 1500 pages, contrairement aux cartouches vendues ensuite, prévues pour 3000 pages. Leur format étant identique, les cartouches d’origine ne sont donc pas remplies complètement. Le coût par page de l’imprimante neuve avec cartouches est ainsi relativement comparable au coût par page des 4 cartouches de remplacement. Le constructeur souhaite probablement s’assurer qu’on ne commandera pas une imprimante neuve complète lorsque vient le moment de changer les cartouches d’origine.

Passent alors quelques mois d’utilisation sans histoire, jusqu’à la fin 2018, principalement en noir et blanc. Nous approchons de l’épuisement de la cartouche magenta, gentiment signalé à l’avance par l’imprimante.

Nous commandons donc des cartouches de remplacement du constructeur, profitant d’une offre groupée à prix « d’ami » incluant les 4 couleurs. Nous les stockons en attente d’utilisation, le temps que la cartouche magenta d’origine arrive effectivement à bout, ce qui prendra 4 ou 5 mois.

« Et là, c’est le drame. »

L’imprimante ne reconnaît pas la cartouche magenta de remplacement, produisant une erreur cryptique et refusant catégoriquement d’imprimer, même en noir et blanc.

Tout naturellement nous appelons donc l’assistance de la marque en France, qui investigue pour m’expliquer, en substance, que tout cela est de ma faute : mon modèle est le 317, or j’ai commandé des cartouches pour le modèle 310. Il est donc tout à fait « normal » que cela ne fonctionne pas. J’aurais dû faire attention. Je peux m’adresser au vendeur des cartouches pour demander un échange.

De son côté, le vendeur des cartouches — nous avions, autre erreur, privilégié un commerçant du sud de la France pour éviter d’engraisser une grande plateforme de vente en ligne — explique qu’au titre de ses conditions de vente il ne peut réaliser d’échange, même de cartouches neuves non déballées, car notre commande date de plus de 3 mois (puisque nous nous y étions pris à l’avance).

Nous voilà donc avec une imprimante totalement inutilisable à moins de payer à nouveau au moins une cartouche magenta (environ 150-170 €), et 450 € de cartouches inutilisables, potentiellement revendables sur e-bay avec les complications associées, une perte de valeur pour nous, et un risque pour l’acheteur.

Pour la petite histoire, la présence d’une cartouche vide empêche également toute mise à jour logicielle de l’imprimante.

En faisant quelques recherches en ligne, je découvre que des commerçants chinois revendent des circuits (chips) de remplacement pour les cartouches, classés par couleur d’encre, modèle d’imprimante, nombre de pages le cas échéant, et zone géographique.

Ici un petit aparté sur la notion de zone géographique pour imprimante. D’après l’assistance du fabricant, il s’agit de fournir du toner optimisé pour la région où il est utilisé, afin d’être adapté aux conditions climatiques locales (hygrométrie, température).

On pourra juger de cette promesse en constatant sur cette image que la Russie et toute l’Afrique sont dans la même zone, ainsi que l’Espagne et le Groenland, ou encore le sud des États-Unis et le grand nord du Canada. En revanche, cette politique commerciale permet d’appliquer des tarifs et circuits de distribution différenciés par continent.

J’ai donc commandé sur Aliexpress, en Chine, les circuits de remplacement “zone Europe”, pour chacune des 4 couleurs, pour le modèle d’imprimante 317.

Ces circuits sont normalement prévus pour recharger des cartouches avec du toner “compatible” (bien moins cher). Je dois être l’un des rares à m’en être servi sur des cartouches constructeur neuves. La somme est modique (15 € par circuit), le risque financier est donc minime même si l’opération échoue, et la manipulation est simple : 2 vis à ôter, le chip à remplacer, on revisse et c’est reparti.

Cet hiver j’avais remplacé le chip de la cartouche magenta, ce qui m’a permis d’utiliser à nouveau l’imprimante après presque 1 an de panne sans trop savoir comment s’en sortir. Je viens de remplacer le chip et la cartouche noire. On note sur l’emballage (photo ci-dessous) la mention du nombre de pages (3K), de la couleur (BK = black, noir), et de la zone géographique (EUR).

Addendum technique : les circuits ci-dessus sont interfacés avec l’imprimante par le protocole I2C, très courant dans le petit matériel électronique. Il est possible, dans une certaine mesure, de les reprogrammer par ce protocole pour changer les paramètres (autre couleur, autre imprimante, autre zone géographique, remise à zéro du compteur), et on trouve sur le web des instructions d’électroniciens à cet effet. C’est de ce type d’instructions que se servent les vendeurs de chips “pirates”. Dans certains cas, il est impossible de reprogrammer un circuit qui est arrivé au bout du nombre de pages. J’ai essayé ces procédés avec un Raspberry — car celui-ci comporte une interface I2C — sur les circuits “constructeur”, mais sans succès. J’aurai peut-être plus de résultats avec les circuits commandés en Chine.

Les imprimantes considérées ici sont les Lexmark CS310dn (sans wifi) et CS317dn (avec wifi), mais il existe énormément d’autres marques connues qui pratiquent le même genre de procédé : HP, Epson, Ricoh, Samsung, etc. L’objet de ce texte était surtout de montrer les complications que cela implique pour des usages légitimes, ces restrictions n’étant bien entendu jamais explicitées lors de l’acquisition.

fr, Geek stuff, Hacks

La mesure automatisée de consommation électrique

Suite à mon billet précédent sur la question, et quelques retours de Stéphane Bortzmeyer, Philippe Bourcier et Laurent Penou, que je remercie ; suite aussi à un article tout récent de Pour la Science, j’ai décidé de commander un peu de matériel électronique pour pouvoir mieux mesurer la consommation des équipements réseau domestiques.

Voici le graphique extrait de Pour la Science titré « le vrai coût énergétique du numérique » (réservé abonnés) [ bizarrement, le graphique semble avoir disparu de l’article depuis que je l’ai consulté initialement ], par Anne-Cécile Orgerie.

C’est ce style de graphe que je souhaiterais réaliser.

Pour cela, il faut un système permettant un relevé automatique périodique des consommations.

J’ai donc commandé :

  • une prise DELOCK 11827, essayée par Jan-Piet Mens ici.

Ces prises permettent une commande de l’appareil branché, mais aussi une consultation de sa consommation relevable par navigateur web ou programmation, à travers une connexion wifi.

  • un boîtier PZEM-004T. Le PZEM-004T est un circuit wattmètre intégré qui se branche entre le secteur et l’équipement à mesurer. Il se vend parfois nu, parfois dans un boîtier plastique. Il peut être relevé par port série (sur niveaux TTL), ou avec un câble USB réalisant l’adaptation. Le modèle représenté ici est limité à 10 ampères, mais il existe également une version 100 ampères que je n’ai pas commandée pour l’instant, et qui dispose d’une pince de courant pratique pour mesurer de fortes intensités sans couper le câble.
  • un relais 1PM « Shelly Plug ». Ce boîtier, normalement conçu pour être intégré dans un interrupteur mural ou une prise pour les rendre commandables à distance par navigateur web ou téléphone mobile, à travers votre wifi, inclut également un wattmètre relevable. Il y a en ce moment des promotions chez Shelly, petite société bulgare, et le paquet de 2 Shelly 1PM est à un prix particulièrement intéressant.
  • une « Shelly Plug S », à peu près la même chose que le Shelly 1PM ci-dessus, mais sous forme de prise électrique, prête à utiliser, et similaire à la DELOCK 11827 présentée en haut. Il existe un autre modèle de puissance supérieure, et toute une gamme pour commander vos appareils électriques à distance.
  • un module wattmètre I2C pour basse tension, courant continu, relevable par I2C. Il est donc plus compliqué à utiliser, il faut lui adjoindre un équipement supplémentaire disposant de l’I2C : un Raspberry, par exemple, ou un processeur destiné à l’électronique embarquée comme un STM32 ou un ESP32 qui disposent des interfaces nécessaires. Il doit être calibré avant usage, mais il dispose d’une bonne résolution (20 mW). En le complétant avec quelques prises adaptées, on peut par exemple lui faire mesurer la consommation d’un appareil USB, d’un appareil sur batterie, ou peut-être sur adaptateur secteur — si la tension mesurée est suffisamment lissée, ce qui n’est pas forcément gagné dans ce dernier cas –.

Voilà. Restera à installer tout ça et à en tirer des informations pertinentes.

PS : Stéphane Bortzmeyer a lui aussi parlé des mesures qu’il a faites sur son réseau (électrique) domestique, des appareils utilisés, et des résultats obtenus. https://www.bortzmeyer.org/mesure-conso-energie.html

en, Geek stuff, ipv6

Converting a FreeBSD ezjail configuration to VNET

I have recently converted my self-hosted FreeBSD jails (including this very blog) to the VNET architecture.

A few words about VNET

The purpose of this post is not to explain jails, or VNET, but to provide examples for migration from the traditional jail networking environment (in my case, using ezjail), to the VNET architecture. There are numerous documents online for jail environments based on iocage, but not that much about ezjail-based ones.

Up to VNET, networking in jails had severe limitations on addressing, in particular limitations on the loopback interfaces (::1 and 127.0.1) and usage of IP aliases, which caused numerous configuration headaches. This was due to the jails sharing network interfaces and the full networking stack with the host. It was possible to alleviate some of this with multiple routing tables (setfib & al), but it was still limited.

VNET allows the jails to run networking stacks totally separated from the host’s, like it would in a fully virtualized guest. As a consequence, it allows running virtual routers with specific firewalls filters to better organize and isolate jail networking.

VNET basically works by moving network interfaces to the guest jails, in a separate instance of the network stack, hiding them from the host environment. This is done at jail startup, but it can also be done dynamically to a running jail with:

ifconfig <interface> vnet <jail_id>

VNET works on any kind of interface: physical or virtual. It is thus perfectly possible to assign a physical interface, or a VLAN tagged interface, etc, to a jail.

Enabling VNET

First, we need to enable VNET in the kernel. From FreeBSD 12, the default kernel has VNET already, so there is nothing to do, unless you have a custom kernel. On FreeBSD 11, you need to recompile a kernel after adding the following line:

options VIMAGE # Subsystem virtualization, e.g. VNET

VNET and ezjail

What to do next with ezjail?

ezjail‘s configuration files are stored in /usr/local/etc/ezjail, one file per jail, named after the jail’s name. ezjail uses environment variables based on the former jail configuration variables stored in /etc/rc.conf. Under the hood, the system converts these lines to the new jail syntax, .conf files stored in /var/run.

The line that configures networking looks like the following (may be wrapped on your screen):

export jail_jailname_ip="re0|192.168.0.17,re0|2a01:e34:ec2a:94a0::11,lo0|127.0.0.17"

To convert this configuration to VNET, we have to:

  • disable the traditional jail networking system: this done by providing an empty value for the above line
  • enable VNET for the jail
  • specify the VNET interface(s) the jail is going to use

Which is done using the following lines:

export jail_jailname_ip=""
export jail_jailname_vnet_enable="YES"
export jail_jailname_vnet_interface="epair17b"

Note that we don’t specify IP addresses or the loopback interface anymore. Configuration will be done by the jail itself, possibly in the regular /etc/rc.conf way:

ifconfig_epair17b="192.168.0.17/24"
ifconfig_epair17b_ipv6="2a01:e34:ec2a:94a0::11/64"

We still have to create the interface the jail is going to use, here epair17b. I chose the epair/if_bridge architecture as it seemed the most flexible and easier to get a grip of, but it is also possible to use netgraph-based interfaces, or anything other the system supports.

epair interfaces are 2 virtual network interfaces linked with a virtual crossover cable. if_bridge is a bridge interface which switches traffic between the interfaces you attach to it. By combining both and adding routers, you can create any virtual network architecture.

To prepare the interfaces,

ifconfig epair17

creates two interfaces, epair17a and epair17b.

epair17b will be given to the jail; epair17a will stay on the host, and will have to get connectivity somehow. This is typically done by making it a bridge member.

epair17a may or may not have an IP address assigned to it (it does not need one if it is only used for bridging), but it needs to be up:

ifconfig epair17a up

We also need to add one of the interfaces to a bridge, so it gets connectivity to the rest of the network:

ifconfig bridge0 create up
ifconfig bridge0 addm epair17a

To make it easier to understand, I made a view images showing possible architectures.

First, example of a basic configuration where all the jails are configured on the same local network as the host through bridge0, mimicking the traditional jail networking.

Figure 1

Here, the jails are organized on two separate subnetworks, with Host possibly providing IP routing and firewalling.

Figure 2

Lastly, on Figure 3, another architecture where the first group of guests, Guest 1 and Guest 2, is directly configured on the local network, whereas Guest 4 and Guest 5 are connected through virtual router Guest 3. For example, this can be used in a setting where Guest 1 and Guest 2 provide the front-end to a service, and Guest 3 and Guest 4 provide the backend (databases, etc). Guest 4 and Guest 5 don’t even need full connectivity to the Internet, this can be enforced with firewall rules on Host or Guest 3.

Figure 3

Making the configuration persistent

The above commands were meant to explain the workings of the setup, but they are ephemeral. The configurations need to be made persistent in the boot configuration of Host, for example in /etc/rc.conf:

cloned_interfaces="bridge0 bridge1 epair1 epair2 ... ifconfig_bridge0="up addm re0 addm epair1a addm epair2a ..."
ifconfig_epair1a="up"

Note that the epair interfaces on the guests don’t need to be up from the host configuration. The guest startup code will manage this.

Using jib to create/destroy interfaces dynamically

The above static configuration has a small issue: VNET takes quite some time (dozens of seconds) to reassign an interface of a deleted jail to the host, making it invisible in the meantime. This means that a jail restart will fail for lack of the adequate interface.

To avoid this, and create persistent MAC addresses for the interface, which comes-in handy, there are scripts provided in /usr/share/examples/jails, jib (for epair/bridge-based interfaces) and jng (for netgraph-based interfaces).

We just need to install these scripts in /usr/local/sbin and make them executable.

cp /usr/share/examples/jails/jib /usr/local/sbin
chmod a+rx /usr/local/sbin/jib
cp /usr/share/examples/jails/jng /usr/local/sbin
chmod a+rx /usr/local/sbin/jng

jib creates epair interfaces and adds one interface of the pair to a bridge connected to an output interface, ie:

jib addm TEST re0

will create interfaces e0a_TEST and e0b_TEST and add e0a_TEST to a bridge named re0bridge if it exists, or failing that, create such a bridge and connect it to re0. The jail will be configured to use nterface e0b_TEST.

The cherry on the cake with jib/jng : they try and keep MAC addresses persistent.

To create and destroy interfaces dynamically with ezjail, instead of tweaking /etc/rc.conf, we only need to add the following lines to the ezjail configuration file for the jail:

export jail_jailname_vnet_enable="YES"
export jail_jailname_vnet_interface="e0b_jailname"
export jail_jailname_exec_prestart0="/usr/local/sbin/jib addm jailname re0"
export jail_jailname_exec_poststop0="/usr/local/sbin/jib destroy jailname"

Notes

Note that it is possible to directly set-up IP addresses on bridge0 bridge1 etc, which may save a couple of epair interfaces in the second and third examples. This is left as an exercise for the reader.

Also, it seems currently difficult or impossible to use VLAN interfaces (if_vlan) in a bridge configuration. I’m still digging on this subject.

References

I have found the following pages useful when preparing my setup and this post:

https://www.reddit.com/r/freebsd/comments/je9oxv/can_i_add_vnet_to_an_ezjail/

https://yom.iaelu.net/2019/03/freebsd-12-vnet-jail-using-bridge-epair-and-pf.html

https://www.cyberciti.biz/faq/how-to-configure-a-freebsd-jail-with-vnet-and-zfs/

Thanks to Jacques Foucry for his work on the nice graphics, Mat Arnold for pointing me to /usr/share/examples/jails and Éric Walter for the idea of the SVG WordPress plugin, avoiding the use of pixelated graphics 🙂

en, Geek stuff

Post-mortem of a DNSSEC incident at eu.org

1 Comment

(or: the good, the bad and the ugly)

Abstract

Due a bug in zone generation, all updates for the EU.ORG zone were stuck from 2020-08-29 02:19 UTC to 2020-09-04 14:40 UTC. Then an incorrect fix was made, resulting in the publication of incorrect DNSSEC signatures for the zone from 2020-09-04 14:40 UTC to 2020-09-04 19:37:00 UTC. Then the final, correct fix was implemented.

This episode, unoriginal albeit humbling, nevertheless yielded interesting returns of experience.

All times in the rest of this document are UTC times.

The software setup at eu.org

The primary DNS server for EU.ORG runs ISC‘s BIND. The zone is currently generated by Python and shell scripts from a Postgresql database. This does not include DNSSEC records for the zone (except DS records for delegations). DNSSEC records are generated and refreshed by dnssec-signzone, one of the tools provided with bind. Once the zone file has been updated, it is reloaded using rndc reload, another command-line tool provided with bind.

Zone key rotation is handled by custom scripts which periodically check for key age and schedule key generation, pre-publication, activation and de-activation as needed, calling dnssec-keygen to manage the key files.

Setup for the failure: blocked updates

2020-08-29 02:19: due to a race condition in the zone generation process (issue #1), the EU.ORG zone file disappeared.

The last good and published version of the EU.ORG zone file, still loaded in the primary server, had serial number 2020082907, generated at 2020-08-29 01:12. In the case of a missing file, the reload obviously fails but bind behaves nicely and keeps serving its older in-memory version of the file.

However, the disappearance of the zone file caused all subsequent zone file generation processes to fail (issue #2), as they were accessing the current version of the file to fetch the currently published serial number.

The problem remained unnoticed (issue #3: incomplete monitoring) until 4 September 2020, when a user notified us that his new domain was still undelegated.

The ugly

Around 2020-09-04 14:40, a first fix was attempted: a known good version of the zone file was reinstalled to allow the zone generation process to succeed, then a new zone was generated, freshly DNSSEC-signed, and loaded.

However, the above timeline conflicted with a scheduled key rotation of the zone-signing keys. The theoretical key rotation schedule was as follows:

Theoretical key rotation schedule

The new key (14716) was due to be published from 2020-08-29 05:37, a few hours after the zone update process failed. It should have been present in concerned resolver caches about 24 hours later, alongside the previous key (22810), ready to be used to check signatures (RRSIG records) of the zone which were supposed to be published from 2020-09-03 05:37.

However, due the zone update suspension, this happened instead. The skipped steps are shown in gray.

Actual key rotation schedule (before fix)

The zone was directly updated from the 2020-08-14/2020-08-29 key configuration to 2020-09-04 14:40.

A few minutes after 2020-09-04 14:40, it was apparent that something was amiss: the resolution of EU.ORG domains failed for people using resolvers with DNSSEC validation.

The cause was quickly identified: since pre-publication for DNSKEY 14716 was missed, most resolvers only had the unexpired DNSKEY 22810 in their cache, while the only RRSIG records available in the zone servers required key 14716.

The bad

The obvious fix was to reactivate key 22810 and regenerate the zone signatures (RRSIG records) with dnssec-signzone. This also leaves in place the signatures with key 14716 (keeping the latter was needed for resolvers which had begun to cache key 14176).

As a side note, it helped that the EU.ORG switched a few months ago to NSEC3 “opt-out” mode. This saves a lot of space (especially in nameserver memory) for zones with many delegations, which is especially useful if you temporarily need double signatures such as in this episode.

A first implementation attempt was made at 2020-09-04 14:52 by updating the dates in the public key file (.key) for key 22810, pushing the inactivation date to 2020-09-07 05:37:00 and the deletion date to 2020-09-09 05:37:00.

Before update:

; Created: 20200808100738 (Sat Aug  8 12:07:38 202)
; Publish: 20200809053700 (Sun Aug  9 07:37:00 202)
; Activate: 20200814053700 (Fri Aug 14 07:37:00 202)
; Inactive: 20200903053700 (Thu Sep  3 07:37:00 202)
; Delete: 20200905053700 (Sat Sep  5 07:37:00 202)
EU.ORG. 172800 IN DNSKEY 256 3 8 AwEAAcHAqfeFzQqo9vFq8ZziaQs2...

Side remarks:

  • the TTL value above is ignored by dnssec-signzone, which by default reuses the TTL in the zone file. The actual TTL is 86400.
  • note the weird year 202 instead of 2020

After update:

; Created: 20200808100738 (Sat Aug  8 12:07:38 202)
; Publish: 20200809053700 (Sun Aug  9 07:37:00 202)
; Activate: 20200814053700 (Fri Aug 14 07:37:00 202)
; Inactive: 20200907053700
; Delete: 20200909053700
EU.ORG. 172800 IN DNSKEY 256 3 8 AwEAAcHAqfeFzQqo9vFq8ZziaQs2...

However… (issue #4: when working in a hurry, expect stupid mistakes), this fix was wrong, albeit harmless. As should have been obvious from the “;” prefix, the above lines are informational. The change above was without any effect, but this was initially unnoticed for lack of adequate testing. (issue #5: don’t reset resolver caches too early, it may hamper testing; if you are expecting specific RRSIG records, test this explicitly).

The good

The actual dates are in the adjoining .private file, which was finally updated as follows:

Private-key-format: v1.3
Algorithm: 8 (RSASHA256)
...
Successor: 14716
Created: 20200808100738
Publish: 20200809053700
Activate: 20200814053700
Inactive: 20200907053700
Delete: 20200909053700

This resulted in the following key rotation schedule, implemented from 2020-09-05 19:37, which finally fixed the issue and probably reduced the zone downtime by almost 19 hours.

It was tested on an untouched resolver which failed EU.ORG requests and recovered from the update (hypothesis: is this because of heuristics on RRSIG records when no cached DNSKEY matches the cached RRSIG records?).

Fixed key rotation schedule

Lessons learned

The above incident will result in several procedural changes on the EU.ORG servers. Some of these are marked as issue #n; others are being considered, like using bind‘s automated signature mode, coupled with dynamic zone updates, which would have made the whole episode moot (but would introduce a strong dependency on bind). Writing this post-mortem text helped make the most of the incident.

Thanks to Stéphane Bortzmeyer, always vigilant when it comes to DNS and DNSSEC bugs, who noticed and notified us that the zone was still broken after the initial incorrect fix, and who read and commented an initial version of this text.

divers, fr, Geek stuff, neutralité

La sobriété numérique, oui mais pour quoi faire ?

49 Comments

Avertissement ajouté le 17/7/2020 : l’objet de ce billet n’est pas de nier l’impact environnemental du numérique, mais d’étudier la pertinence des injonctions à la limitation de notre volume de données.

La facturation au volume, ou la limitation des abonnements Internet, vieux serpent de mer des réseaux numériques depuis des décennies et rêve de certains opérateurs, fait aujourd’hui sa réapparition sous la motivation de la défense de l’environnement, notamment via un rapport récent du sénat, suivi d’un rapport similaire du Conseil national du numérique. Ces rapports s’appuient notamment sur ceux du Shift Project de 2018 et 2019 sur la sobriété numérique ; ces derniers ont vu certains de leurs éléments critiqués en raisons d’erreurs manifestes (surévaluations des empreintes).

Suite à de nombreuses discussions notamment sur les réseaux sociaux, lectures de rapports et études, etc, depuis 2 ans, je voulais poser ici quelques arguments mis en forme pour éviter d’avoir à les réécrire ici et là.

L’affirmation principale qui sous-tend l’idée de limiter notre consommation de données est que l’explosion des volumes provoquerait une explosion de la consommation électrique. Cet argument est également cité pour mettre en doute la pertinence du déploiement de la 5e génération (5G) de téléphonie mobile.

Nous allons voir qu’en fait, l’essentiel de la consommation électrique des réseaux est constitué par le fonctionnement de l’infrastructure, indépendamment de la quantité de données.

Si vous n’avez pas envie de lire les détails de ce billet, vous pouvez vous contenter de “Et le réseau mobile” et “Faut-il vraiment réduire notre consommation de données ?”, en complétant si nécessaire par “La puissance et l’énergie” pour les notions d’électricité.

La puissance et l’énergie

Pour commencer, quelques rappels de notions électriques fondamentales pour mieux comprendre les chiffres que l’on voit circuler ici et là, et leurs ordres de grandeur.

Le Watt est l’unité de puissance électrique. C’est une valeur “instantanée”. Pour éclairer correctement vos toilettes, vous aurez besoin de moins de puissance que pour illuminer un monument comme la tour Eiffel. Un four électrique, un grille pain ou un radiateur engloutissent aux alentours de 1500 à 2500 watts. Un téléphone mobile, moins de 5 watts. Comme la quasi totalité de la consommation électrique passe en effet Joule, tout objet usuel qui consomme de manière significative émet de la chaleur. C’est un moyen très simple de s’assurer qu’un objet ne consomme pas beaucoup d’électricité : il ne chauffe pas de manière sensible (c’est un peu différent pour des moteurs électriques, mais cela reste vrai pour des ampoules).

Le Watt.heure, Wh (ou son multiple le kilowatt.heure, kWh) est une unité d’énergie. Si vous vous éclairez pendant 2 heures au lieu d’une heure, la consommation d’énergie sera doublée. Et en mettant deux ampoules, vous consommerez en une heure ce qui aurait pris deux heures avec une simple ampoule.

Le fournisseur d’électricité compte donc les kWh pour la facturation. Il calibre également le compteur pour une limite (en Watts) à la puissance appelable à un moment donné. C’est une limitation de débit. Cela peut vous empêcher de faire tourner à la fois le four électrique et le chauffe-eau, gros consommateurs d’électricité, mais ça ne vous interdit pas de les utiliser l’un après l’autre.

Une batterie, que ce soit de téléphone ou de voiture (électrique ou non) stocke de l’énergie et voit donc sa capacité exprimée en watts.heure. On peut aussi l’indiquer en ampères.heure. Dans ce cas, il faut multiplier cette dernière valeur par la tension nominale (volts) pour obtenir la capacité équivalente en watts.heure.

On voit passer parfois, au fil des articles, des “kilowatts par an” ou “mégawatts par heure”. Ces unités n’ont pas de sens physique directement utile. Elles indiquent en général une erreur.

Comment vérifier des consommations d’appareils électriques

Il est facile de vérifier soi-même la consommation des appareils électriques usuels avec un “consomètre”. Ainsi, vous n’aurez pas à prendre pour argent comptant ce qu’on affirme ici ou là. On en trouve pour moins de 15 €. Les modèles auto-alimentés (sans pile) sont en général préférables, évitent la corvée de piles et sont donc plus respectueux de l’environnement, mais peuvent perdre la mémoire en cas de coupure. Ces appareils permettent aussi bien de mesurer la consommation instantanée (la puissance, en W) que l’énergie utilisée sur une certaine durée (en kWh donc), pour les appareils qui ont une consommation fluctuante (par exemple, un frigo ne se déclenche que pour refaire un peu de froid quand c’est nécessaire).

Commençons par un objet courant, le point d’accès wifi.

TP-Link Routeur WiFi N450 Vitesse sans fil jusqu’à 300 Mbps，Dual-band, 5 ports (Ethernet 4 ports ), 2 antennes externes, Support contrôle parental, TL-WR940N

Un point d’accès wifi de ce type, allumé, consomme environ 4 watts, tout le temps, indépendamment de son utilisation. Côté antenne wifi, la législation en France interdit une émission d’une puissance supérieure à 100 mW. Autrement dit, la consommation due à la transmission par l’antenne est au grossièrement (pour simplifier, car l’électronique interne sera également un peu plus sollicitée) 2,5 % de la consommation totale de la borne. L’interface ethernet (filaire) consomme un peu d’électricité elle aussi, mais celle-ci dépend de la longueur du câble plus que du volume de données transmis. Certaines bornes disposent ainsi d’un mode “vert” pour réduire la consommation électrique dans un environnement personnel, où les câbles mesurent quelques dizaines de mètres au maximum, plutôt que 100 mètres.

La différence de consommation entre une borne qui émet au maximum de sa capacité et une borne allumée sans aucun trafic sera donc au maximum de 2,5 %. En tout cas, il faut être conscient que diviser par 2 sa propre consommation de données ne divisera pas par 2 la consommation électrique associée, ni chez soi, ni ailleurs. Il est très facile avec un consomètre de le vérifier par soi-même pour la partie à domicile.

La box Internet

Les mêmes remarques s’appliquent à votre box d’accès Internet. Celle-ci va avoir, comme un point d’accès wifi, une ou plusieurs prises ethernet, et un accès au réseau de l’opérateur : aujourd’hui ADSL, VDSL ou fibre.

L’ARCEP a publié en 2019 un rapport sur l’impact carbone des accès à Internet. D’après un des acteur interrogés, “la fibre consomme en moyenne un peu plus de 0,5 Watt par ligne, soit trois fois moins que l’ADSL (1,8W) et quatre fois moins que le RTC [réseau téléphonique classique] (2,1W) sur le réseau d’accès”. Ces estimation de consommation ne varient pas du tout en fonction du volume transmis. En effet l’ADSL comme la fibre ont besoin d’émettre en permanence, que beaucoup ou peu de données soient transmises.

On voit aussi les progrès sensibles accomplis au fil des générations technologiques, puisque la consommation fixe décroît alors que le débit disponible augmente.

Par ailleurs, comme avec la borne wifi, la partie concernant la transmission longue distance présente une consommation marginale par rapport à celle de la box qui représente aux alentours de 10 à 30 watts suivant les générations. Les opérateurs travaillent d’ailleurs à la réduction de cette consommation, car elle devient un argument commercial.

Le téléphone mobile

Bon, la box Internet ou le point wifi ne consomment donc pas tant que ça. Qu’en est-il du téléphone mobile, présenté comme extrêmement gourmand ?

L’avantage du téléphone mobile est qu’il est alimenté par une batterie. Il est donc très facile d’estimer sa consommation maximale en fonctionnement : c’est celle d’une charge batterie complète, moins les pertes de celle-ci (faibles).

Une batterie de téléphone mobile d’aujourd’hui possède une capacité de 10 à 15 Wh. Elle peut donc fournir 10 à 15 W pendant une heure, ou la moitié pendant 2 h, etc.

L’éclairage d’écran d’un téléphone consomme à lui seul aux alentours de 2 W (facile à vérifier avec un consomètre assez sensible sur lequel on branche le chargeur). Cela représente le coût majeur lorsque vous visionnez une vidéo. La consommation est nettement plus élevée si vous préférez le faire sur un grand écran type téléviseur, et cela s’applique également à la télévision hertzienne classique.

Par comparaison, une ampoule LED consomme environ 8 watts pour remplacer à luminosité équivalente une ampoule à incandescence de 60 watts. Autrement dit, une charge de téléphone mobile n’a l’énergie pour éclairer une ampoule “basique” que pendant 1 à 2h. Il est évidemment important d’éteindre les pièces inoccupées, mais on en parle peu. Nous avons été convaincus que le téléphone mobile consommait bien plus, ce qui est faux.

Et le réseau mobile ?

Comme votre installation personnelle, la consommation du réseau de téléphonie mobile est essentiellement un coût fixe. L’équipement actif d’une antenne allumée va consommer quelques kilowatts ou dizaines de kilowatts, l’émission hertzienne proprement dite se contente de quelques dizaines de Watts, soit 100 fois moins. Autrement dit, la variable principale qui sous-tend la consommation électrique d’un réseau mobile est l’étendue de la couverture géographique, directement corrélée au nombre d’antennes.

Une étude finlandaise citée par le document Arcep a tenté d’estimer, pour la téléphonie mobile, la consommation électrique du réseau par rapport au volume de données, autrement dit le nombre de kWh par gigaoctet transféré (kWh/Go).

Pour effectuer de telles estimations d’impact environnemental, les méthodes dites d'”analyse du cycle de vie” (ACV) évaluent l’ensemble des coûts imputés par une activité. Ainsi, l’évaluation de l’empreinte de la téléphonie mobile intègre la fabrication des terminaux, la consommation personnelle (recharge quotidienne du téléphone), etc. Pour évaluer l’empreinte d’un opérateur mobile, on prend en compte la consommation des antennes, mais également la climatisation et chauffage des bureaux, etc. En divisant ce chiffre de consommation électrique totale par le volume échangé total, on peut obtenir une estimation de l’empreinte électrique du volume de données échangées.

Ce chiffre est intéressant pour évaluer l’empreinte totale des opérateurs, mais trompeur : il laisse entendre que la consommation électrique d’un opérateur mobile est totalement dépendante du volume échangé, ce qui est faux. Si du jour au lendemain tous les abonnés mobiles de France divisent leur consommation de données par 2, la consommation électrique des opérateurs ne va pas se réduire du même facteur : leurs antennes resteront allumées, leurs bureaux continueront à être climatisés et éclairés, etc.

L’étude finlandaise citée ci-dessus est intéressante à cet égard : on voit que la consommation électrique des opérateurs finlandais est restée à peu près stable pendant la décennie 2010, malgré une légère croissance tendancielle.

En revanche, les volumes échangés ont considérablement augmenté sur la même période :

L’étude finlandaise utilise les deux graphes précédents pour en déduire un graphe d’efficacité énergétique en kWh/Go :

Si on ne prenait en compte que ce dernier graphe, ou même simplement une estimation ponctuelle en kWh/Go, on serait tenté de croire que doubler le volume de données va doubler la consommation énergétique associée, mais c’est totalement faux. Pour simplifier un peu, on ne ferait qu’introduire un nouveau point de données avec une efficacité énergétique multipliée par deux.

Bien sûr, les choses sont un peu plus complexes que ci-dessus. Augmenter la consommation en volume va provoquer l’installation de nouvelles antennes, de routeurs plus puissants, de liaisons fibre de plus grande capacité, peut-être de nouveaux liens terrestres pour développer le réseau. Inversement, comme on l’a vu ci-dessus, les générations technologiques permettent d’échanger des volumes de données toujours plus élevés avec une consommation électrique qui se réduit. Ces progrès, réels, ne sont que peu visibles dans les chiffres agrégés de kWh/Go, puisque ces derniers sont essentiellement constitués de coûts fixes sans rapport avec les technologies de transmission.

Le rapport ARCEP cité ci-dessus propose également une évaluation en termes de gaz à effet de serre (indicateur plus important que la consommation électrique), qui montre une baisse progressive de l’empreinte des opérateurs français.

La section à laquelle ce graphique figure est d’ailleurs titrée “Une amélioration de l’efficacité énergétique qui compense, à ce stade, l’effet de l’explosion de trafic” pour résumer la situation.

Et les centres serveurs (datacenters) ?

Si tous les éléments cités ci-dessus ont une consommation faible, rien ne prouve que la consommation des datacenters n’est pas en train d’exploser pour répondre à la demande croissante ?

Une étude de l’agence internationale de l’énergie (IEA) montre, là encore, que la consommation électrique de ces centres n’explose pas, car les coûts principaux sont également des coûts fixes, et l’amélioration des équipements et de leur taux d’utilisation permet de traiter une quantité toujours croissante de services à consommation électrique égale.

De 2010 à 2019, le volume réseau a ainsi été multiplié par 12 alors que la consommation électrique est restée remarquablement stable.

Faut-il vraiment réduire notre consommation de données ?

On voit d’abord qu’aucun des éléments de la chaîne, du serveur de données à notre installation personnelle, n’éprouve une sensibilité particulière aux volumes de données échangés. Il n’y a donc pas de raison écologique de se forcer à réduire notre consommation de celles-ci.

Il n’y a pas de raison non plus de forcer les opérateurs à le faire à notre place, en appelant à l’interdiction des forfaits illimités, ou à une obligation de facturation au volume. On notera d’ailleurs que ces envies de facturation proviennent historiquement des opérateurs eux-mêmes, et ont pu être liées à des initiatives pour remettre en cause la neutralité du réseau.

On peut légitimement arguer que l’électricité française est l’une des moins carbonées du monde (nos efforts en matière de consommation électrique ont donc beaucoup moins d’impact CO2 qu’ailleurs, à énergie économisée équivalente).

Mais puisque rien ne prouve qu’être sobre sur notre consommation de données aura le moindre impact significatif sur la consommation électrique, à quoi bon s’épuiser en efforts inutiles ?

Ce tweet résume d’ailleurs bien la question, pour montrer que le refus “par principe” de l’illimité n’a pas de sens :

En conclusion, la sobriété pour la sobriété, qu’elle soit volontaire ou forcée, n’est guère justifiable, et risque même de nous empêcher de profiter des externalités positives significatives, et reconnues, du numérique. Préférons donc la sobriété dûment justifiée.

Il est bien entendu utile d’éteindre sa box Internet, son accès wifi ou son ordinateur lorsqu’on ne s’en sert pas, comme on éteint la lumière ou le chauffage dans une pièce inoccupée. Il semble également établi, jusqu’à preuve du contraire — les données fiables sur la question sont rares en Europe –, que la fabrication des terminaux mobiles reste une activité consommatrice de ressources, il est donc utile d’utiliser les nôtres le plus longtemps possible pour mieux en amortir ce coût fixe.

Ce billet est resté succinct pour ne pas noyer le lecteur sous des tonnes de chiffres, mais n’hésitez pas à laisser un commentaire ici si vous avez des données pertinentes et sourcées qui pourront peut-être faire l’objet d’une deuxième couche 🙂

copyrightdirective, Geek stuff, neutralité, vie privée

Copyright Directive Article 13 Flowchart

1 Comment

To get a better idea of how Article 13 of the Copyright Directive (to be voted very soon at the European Parliament) operates, and evaluate how complicated and dangerous it is, I have made the following flowchart. Feel free to share. Comments welcome.

Source text, current article 13 draft: https://juliareda.eu/wp-content/uploads/2019/02/Art_13_unofficial.pdf

See also my analysis about content filtering for article 13.

Article13 Flowchart

Other references with graphs:

https://www.nextinpact.com/news/107705-directive-droit-dauteur-notre-schema-pour-comprendre-larticle-13.htm

https://boingboing.net/2019/03/11/legislative-analysis.html