Mon blog

I created a bot to answer BGP queries over the fediverse (decentralized social network, best known implementation being Mastodon). What for? Well, mostly for the fun, but also because I need from time to time to find out the origin AS for an IP address or prefix, and I don't have a direct access to a DFZ router. This article is to document this project.

The idea was originally suggested during my lightning talk at RIPE 76 meeting in Marseille.

First, how to use it. Once you have a Fediverse account (for Mastodon, see https://joinmastodon.org/), you write to @bgp@botsin.space. You just tell it the IP address (or IP prefix) you want to know about and it replies with the actually announced prefix and the origin AS. There are also links to the RIPE Stat service, for more details. Here is an example, with the answer:

The bot replies with the same level of confidentiality as the query. So, if you want the request to be private, use the "direct" mode. Note that the bot itself is very indiscreet: it logs everything, and I read it. So, your direct messages will be private only from third parties, not from the bot administrator.

If you are a command-line fan, you can use the madonctl tool to send the query to the bot:

% madonctl toot "@bgp@botsin.space 2a01:e34:ec2a:94a0::4"

You can even make a shell function:

# Definition (in a startup file)
whichasn() {
    madonctl toot --visibility direct "@bgp@botsin.space $1"
}

# Usage
% whichasn   

You can also, instead of an IP address, just send "info" and the bot will reply with details about the number of prefixes and AS it knows.

There is also a more classical (non-fediverse) Web interface, at https://bgp.bortzmeyer.org/IPADDRESS. For instance, with curl :

% curl  https://bgp.bortzmeyer.org/159.89.230.222
159.89.224.0/20 1406
      

Note that, unlike the fediverse interface, the Web interface is not really necessary, you could use other online services such as RIPE Stat. Here is an example with RIPE Stat (we use jq to parse the resulting JSON):

% curl -s https://stat.ripe.net/data/routing-status/data.json\?resource=185.49.140.0 | jq .data.resource            
"185.49.140.0/22"

Now, the implementation of the bot. (You can get all the files at https://framagit.org/bortzmeyer/fediverse-bgp-bot/.) The code is derived from my DNS bot so I won't repeat here most of the stuff, only the BGP-specific things.

The bot backend could call directly the RIPE stat API mentioned above. But there is a limit in the number of requests and, if the bot is popular, it could be blacklisted. Same thing for other online services. Hence my choice of getting the raw RIS dumps. Parsing them and serving them to the bot is done by the WhichASN daemon.

Other useful services and readings for the BGP fans:

• We rely on the excellent RIS (Routing Information Service), which collects and stores BGP information, before making them available to the public.
• There are other ways to access RIS data, such as RIPE Stat or RIS Live.
• The RouteViews project has several useful tools, such as a DNS interface. It would solve the rate-limiting issue but, unfortunately, it works only with IPv4.
• I also like the Qrator API (but you need to register).
• I could also have used BGPstream.
• There are also several whois servers distributing BGP information such as whois.cymru.com or whois.bgpmon.net.

Dans beaucoup d'organisations, les noms de domaine locaux sont attribués dans un TLD, un domaine de tête, non normalisé, comme .loc ou .lan. Pourquoi n'y a t-il pas de domaine de premier niveau normalisé pour ces usages « internes » ?

Un certain nombre de personnes, sans avoir vérifié, croient savoir qu'il y a un domaine de premier niveau prévu pour cela. On cite parfois à tort .local (qui est en fait affecté à autre chose par le RFC 6762). Parfois, le .loc, plus court, est utilisé. La plupart du temps, on ne se pose pas la question, et on utilise un TLD non affecté, sans réfléchir.

Alors, peut-on répondre aux administrateurs réseaux de ces organisations « vous auriez dû utiliser le TLD standard prévu pour cela » ? Après tout, il y a des TLD standards pour des usages spécifiques, comme .test pour les essais et le développement ou comme .example pour les exemples dans la documentation. Ils sont normalisés dans le RFC 2606 et, depuis, a été créé un registre IANA, peuplé selon des règles définies dans le RFC 6761, pour stocker tous ces noms « spéciaux ». (Le RFC 8244 peut être aussi une bonne lecture, mais à lire avec son sens critique allumé.)

Mais, parmi eux, il n'y a pas de TLD réservé comme « usage interne des organisations ». Ce n'est pas faute d'avoir essayé, plusieurs tentatives ont été faites pour normaliser un tel nom, mais sans résultat. Pour comprendre, il faut d'abord revenir sur la question « pourquoi ne pas prendre un nom un peu au hasard et l'utiliser ? » Imaginons une organisation nommée « Foobar » et qui nommerait ses ressources internes sous le TLD non-existant .foobar. (Il y a de nombreux exemples réels. Par exemple, la société Belkin livrait des produits pré-configurés avec le TLD .belkin.) Quel(s) problème(s) cela poserait ? Ils sont au nombre de trois :

• Pendant longtemps, il semblait que la liste des TLD ne changeait pas et qu'un nom libre le resterait longtemps. Les indépendances suite à la fin de la guerre froide, et la création par l'ICANN de centaines de nouveaux TLD à partir de 2013 ont mis fin à cette légende. Si demain, l'ICANN ouvre un nouveau cycle d'enregistrement de TLD, et que quelqu'un demande et obtient .foobar, notre entreprise sera bien embêtée, il y aura de nombreuses collisions entre ses noms internes et les noms externes. Le résultat de la résolution DNS dépendra de beaucoup de choses. Cela avait par exemple posé des problèmes pour .dev.
• Quand on utilise un nom assez répandu comme, aujourd'hui, .loc, .home ou .corp, un autre danger se présente, celui lié aux fusions/acquisitions. Si une organisation fusionne avec une autre, par exemple une entreprise se fait acheter, et que les deux organisations utilisaient le même TLD interne, on retombe dans le même problème de collisions. La DSI aura bien du mal à gérer ce choc entre les deux utilisations du même nom. Utiliser un nom aléatoire tel que .fa43h7hiowxa3lk9aio comme TLD interne rendrait ce risque peu vraisemblable, mais ça ne serait pas très pratique.
• Et enfin il y a le problème des fuites. Lorsqu'on crée un TLD interne, c'est pour qu'il reste interne, d'autant plus qu'il recense des ressources privées, mais, en pratique, il est très difficile de s'assurer qu'il n'y aura pas de fuites. Un employé oublie qu'il n'a pas lancé le VPN de l'entreprise, et cherche à accéder à des ressources internes. Ou bien il rapporte le portable chez lui et ses logiciels tentent automatiquement de résoudre ces noms internes. Dans tous ces cas, les noms internes vont fuiter vers les serveurs faisant autorité, et la racine du DNS voit une part significative de requêtes pour des TLD n'existant pas. (Vous pouvez regarder vous-même ces requêtes pour des TLD non existants, par exemple sur la page de statistiques du serveur C-root.) Les fuites ne se produisent d'ailleurs pas que vers la racine du DNS. Le ministère de l'intérieur utilise .mi en interne et a déjà publié des appels d'offres, des offres d'emploi ou des communiqués de presse en indiquant un URL en .mi.

Pour ces trois raisons, utiliser un TLD imaginaire n'est pas une bonne idée. Notez qu'un certain nombre d'administrateurs réseau s'en moquent : ils se disent que le problème n'arrivera que dans plusieurs années, qu'ils auront changé d'entreprise à ce moment et que ce sera leur successeur ou successeuse qui devra gérer les conséquences de leurs décisions erronnées.

Mais alors, puisque ce n'est pas une bonne idée de prendre un TLD au pifomètre, pourquoi est-ce que l'IETF, qui a déjà enregistré plusieurs TLD spéciaux, n'enregistre pas un .internal (ou un autre nom) en le marquant comme « Usage interne seulement » ? Ce serait en gros l'analogue pour le DNS de ce que sont les adresses IP privées du RFC 1918. L'opération a été tentée, et pas qu'une seule fois. Le dernier essai était l'Internet-Draft draft-wkumari-dnsop-internal, qui réservait .internal.

Le brouillon draft-wkumari-dnsop-internal examinait également les autres possibilités, alternatives au .internal :

• Le TLD .alt avait été proposé (Internet-Draft draft-ietf-dnsop-alt-tld) mais pas (encore ?) approuvé et, de toute façon, il est réservé aux cas où la résolution de noms ne se faisait pas via le DNS mais, par exemple, via GNUnet.
• L'IETF a déjà un TLD quasiment à sa disposition, .arpa. On aurait pu envisager un quelquechose.arpa. Mais le sigle ARPA n'est pas parlant à M. Toutlemonde, et un suffixe de nom de domaine à deux composants est jugé moins pratique qu'un suffixe à un seul composant, le TLD.
• Les noms déjà réservés comme spéciaux comme .local ou .invalid ont tous une sémantique bien précise, et restrictive. Bref, ils servent déjà à autre chose.

D'où le choix du .internal par l'auteur du document.

À noter qu'une question intéressante, lorsqu'on décide de réserver un pseudo-TLD pour les sites locaux, est celle de DNSSEC. Si le TLD n'est pas délégué par la racine, les résolveurs validants rejetteront ce nom, puisque la racine est signée. Ce n'est peut-être pas trop grave puisqu'ils auront de toute façon besoin d'une configuration spécifique pour l'utiliser. Un exemple ? Ici, avec Unbound, on délègue .internal à deux serveurs internes :

server:
     domain-insecure: "internal" # Only necessary if there is no
     # insecure delegation from the root.    
    
forward-zone:
     name:   "internal"
     forward-addr: 10.42.1.68
     forward-addr: fd9d:ebf3:dd41:6094::1:53
  

Et si on délègue le nom (par exemple au nouvel AS112 du RFC 7535) ? Pas moyen de signer cette délégation (puisqu'il faudrait distribuer publiquement la clé privée, pour que chacun signe sa zone locale). La seule solution est donc une délégation non signée (des enregistrements NS mais pas de DS). Notez que .alt, s'il avait été accepté, n'aurait pas eu ce problème, puisqu'il était réservé aux usages non-DNS.

Mais le brouillon draft-wkumari-dnsop-internal note que c'est bien joli de choisir un joli nom, encore faut-il, si on a décidé qu'il était mieux de le déléguer, convaincre l'ICANN de le faire. Et, là, on est partis pour dix ans de multistakeholder bottom-up decision process et d'innombrables réunions. C'est en partie ce qui explique le manque d'intérêt qui a finalement coulé le projet .internal. Le marécage de la gouvernance Internet est difficile à traverser.

De toute façon, .internal n'aurait résolu que le premier problème (risque de délégation d'un vrai TLD du même nom). Il aurait un peu aggravé le second (collision lors d'une fusion/acquisition) puisque tout le monde utiliserait le même nom. Et il aurait un peu aidé pour le troisième (les fuites) puisqu'il aurait été plus facile de prendre des mesures standard pour gérer les fuites d'un TLD standard. Bref, l'idée n'est pas forcément excellente, la motivation principale pour le .internal était « c'est une mauvaise idée mais il y a une demande donc on donne ce TLD aux administrateurs réseau pour qu'ils arrêtent de râler ». On a vu que cette motivation n'avait pas été suffisante et que, finalement, on n'a pas de TLD (ou de suffixe) standard pour les noms internes.

Que doit faire l'administrateur réseau, alors ? Le plus simple, étant donné que toute organisation a (ou devrait avoir) un nom de domaine à soi, est de prendre un sous-domaine de ce domaine. Si l'organisation Foobar citée plus haut a foobar.com, qu'elle nomme ses ressources internes en internal.foobar.com. Du fait de la nature arborescente des noms de domaine, aucun risque que ce nom soit attribué à un autre, aucun risque de collision en cas de fusion/acquisition, et aucun risque de fuites.

Le 16 octobre 2019, les APDEN (association de professeur·e·s documentalistes de l'éducation nationale) franciliennes tenaient une journée d'études au lycée Janson-de-Sailly. Le thème était l'enseignement de l'informatique au lycée, notamment suite à la nouvelle option SNT (Sciences Numériques et Technologie) au lycée. Je parlais quant à moi de l'enseignement de l'Internet.

Les professeur·e·s documentalistes ne sont pas une espèce très connue. Pas mal d'élèves, et de parents d'élèves, ignorent que la « dame du CDI » est une professeure comme les autres. Pour le nouvel enseignement SNT, comme une bonne partie du programme porte sur la recherche d'informations, les professeur·e·s documentalistes sont aussi bien équipés que les autres pour l'enseigner. Si vous souhaitez connaitre le programme, il est disponible en ligne (et le PDF est là.) Tout le monde dans cette journée était d'accord pour dire qu'il est ambitieux. Voici deux manuels de cet enseignement, consultables en ligne : celui de Nathan, et celui d'Hachette.

Commençons par un café :

Bon, je vais utiliser le féminin dans le reste de cet article, pour parler des professeures documentalistes car, en pratique, c'est un métier essentiellement féminin.

J'ai parlé de ma vision de ce qu'il fallait enseigner sur l'Internet. Voici les supports (et leur source).

Autrement, Véronique Bonnet, professeure de philosophie et militante de l'APRIL nous a parlé de philosophie du document (Montaigne disait qu'il fallait pilloter les livres comme les abeilles pillotaient les fleurs…). Elle nous a également fait réfléchir sur les représentations visuelles d'Ada Lovelace. Sur ses portraits, elle n'a pas l'air d'une nerd, est-ce une bonne ou une mauvaise chose ? Est-ce que ça encourage à l'imiter ? (On n'a que des portraits officiels d'elle. On ne sait pas à quoi elle ressemblait quand elle travaillait dans son bureau.)

Tristan Nitot a ensuite parlé de souveraineté numérique, notamment avec l'exemple de Qwant. Qwant ne mémorise pas ses visiteurs : « c'est un guichetier amnésique ». Il y a de la publicité, mais purement liée à la recherche en cours, pas aux recherches précédentes. Plusieurs enseignantes ont fait remarquer que leurs élèves ne semblaient pas sensibles au flicage fait par les GAFA, estimant que la publicité ciblée était même une bonne chose. D'autres ont fait remarquer que le sevrage n'était pas facile : « J'ai essayé d'abandonner Google, j'ai tenu 10 jours. » (Et je rajoute que c'est d'autant plus vrai que les résultats de Qwant sont bien plus mauvais que ceux de Google.) Quant aux objets connectés, notamment aux assistants vocaux, Tristan Nitot a noté que « nous sommes plus crétins que les Troyens, car nous payons les caméras et les micros connectés que nous introduisons dans nos salons. Au moins, les Troyens n'avait pas payé pour le cheval. »

Nous avons eu aussi une présentation par Thierry Bayoud de son documentaire « LOL ; le logiciel libre, une affaire sérieuse », qui cherche actuellement un distributeur. (Le documentaire n'est pas distribué librement. Certains festivals exigent, pour envisager la possible remise d'un prix, d'être en première. Si le film a été diffusé avant, même accidentellement, c'est fichu.).

La journée se terminait avec une table ronde sur l'enseignement SNT (Sciences Numériques et Technologie) : quelle perspective pour les professeurs documentalistes ? Il y avait deux excellents récits d'expériences concrètes, sur le terrain. Céline Caminade a raconté son expérience avec l'implémentation du programme de SNT en lycée. Parmi les difficultés pratiques : les profs sont censés enseigner la programmation en Python mais ne savent pas forcément programmer (et ça ne s'apprend pas en deux semaines). Mais j'ai bien aimé qu'il y ait eu une sortie au théâtre pour voir la pièce « La Machine de Turing », de Benoit Solès, avec la prof d'anglais et la prof de maths. Amélie Chaumette, elle, avait fait une expérience (en dehors de l'enseignement SNT, qui n'existait pas encore) d'enseignement de la cryptographie en classe de première. Histoire (de César à Enigma, en passant par Vigenère) puis protection des données personnelles puis travaux divers pour les élèves.

Merci à Habib pour m'avoir invité, et à toutes les intervenantes et participantes, c'était passionnant, et j'ai appris plein de choses.

Ah, et le plaisir de se retrouver dans un vieux lycée parisien pittoresque…

Sur le site Web du consortium Unicode, consortium qui pilote l'évolution de cette norme, on trouve une très intéressante page d'histoire, rassemblant un certain nombre de documents sur le passé d'Unicode. Parmi eux, « Unicode 88 » qui, en 1988, était le premier document à exposer les bases de ce qui allait devenir la norme Unicode. Il est amusant de voir aujourd'hui ce qui a été gardé de ce projet, et ce qui a été changé.

Ce document « Unicode 88 » était un projet : tout n'était pas encore défini. Mais on y trouve déjà quelques principes importants qui ont été conservés :

• Encodage de caractères abstraits, et pas de glyphes (la représentation graphique du caractère),
• Utilisation pour le texte brut, sans caractères de formatage (ce qui n'a pas été complètement respecté).

D'autres principes étaient absents, comme la séparation de l'affectation des points de code et leur encodage en bits. Il y a aussi des principes qui ont été gardés mais qu'on regrette aujourd'hui comme l'unification Han.

Le plus frappant, avec le recul, est l'insistance sur un principe qui n'a pas été conservé, l'encodage de taille fixe (proche du futur UCS-2), en 16 bits (dérivé de XCCS). On sait qu'en fait c'est un encodage de taille variable, UTF-8 (RFC 3629), qui s'est imposé (pour les protocoles Internet, ce choix en faveur d'UTF-8 est formalisé dans les RFC 2277 et RFC 5198.) L'article « Unicode 88 » accuse son âge lorsqu'il écrit que 16 bits seront suffisants dans tous les cas (16 bits permettent d'encoder 65 536 caractères, or il en existe aujourd'hui 137 994). « Unicode 88 » note que cela implique d'abandonner les écritures du passé, qui sont au contraire aujourd'hui une part importante d'Unicode.

À l'époque, un certain nombre de gens critiquaient Unicode en raison de l'augmentation de taille des textes (un caractère sur deux octets au lieu d'un). L'argument a toujours été faible, compte tenu de la rapide augmentation des capacités des processeurs et des disques durs mais, à cette époque où la disquette de trois pouces et demi était une invention récente, il avait du poids. D'ailleurs, encore aujourd'hui, à une époque de documents Word de plusieurs dizaines de mégaoctets, sans même parler des vidéos haute définition, on entend parfois des critiques d'UTF-32 (un autre encodage de taille fixe…) sur la base de la taille des fichiers de texte brut. Le document estime que le problème de la taille est mieux réglé par la compression.

Autre point où le document accuse son âge, le curieux tableau qui mesure l'importance des écritures en fonction du PNB des pays qui les utilisent. Cela rappele qu'Unicode a été conçu par des entreprises capitalistes qui cherchaient le profit, et donc les marchés rentables.

Le choix d'un encodage de taille fixe (qui n'a donc pas été retenu par la suite) était stratégique, et le document revient plusieurs fois sur l'importance de ce choix, en raison de la simplification des programmes qu'il permet. L'argument de la simplicité des programmes a finalement cédé face à l'argument choc d'UTF-8 : la compatibilité avec ASCII (tout document en ASCII est automatiquement un document en UTF-8).

Et l'unification Han ? Cette idée de considérer les caractères chinois et japonais comme équivalents, en raison de leur origine commune, et malgré leurs apparences différentes (mais rappelez-vous qu'Unicode encode des caractères, pas des glyphes), est à peine discutée dans l'article, alors qu'elle est certainement le concept Unicode le plus critiqué depuis.

En mars dernier est sortie la version 12 d'Unicode. Une description officielle des principaux changements est disponible mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 137994

Combien de caractères sont arrivés avec la version 12 ?

ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float;
...
 10.0    |  8518
 11.0    |   684
 12.0    |   554
 12.1    |     1

554 nouveaux, cette version 12 est très modérée. Quels sont ces nouveaux caractères ?

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='12.0';
 codepoint |                                    name                                    
-----------+----------------------------------------------------------------------------
...
 U+1FA70   | BALLET SHOES
 ...
 U+2E4F    | CORNISH VERSE DIVIDER
 ...
 U+A7C3    | LATIN SMALL LETTER ANGLICANA W
 ...
 U+10FE0   | ELYMAIC LETTER ALEPH
 U+10FE1   | ELYMAIC LETTER BETH
 U+10FE2   | ELYMAIC LETTER GIMEL
 ...
 U+1E100   | NYIAKENG PUACHUE HMONG LETTER MA
 U+1E101   | NYIAKENG PUACHUE HMONG LETTER TSA
 U+1E102   | NYIAKENG PUACHUE HMONG LETTER NTA
 ...
 U+1F6D5   | HINDU TEMPLE
 U+1F6FA   | AUTO RICKSHAW
 ...
 U+1F97B   | SARI
 ...
 U+1F9A7   | ORANGUTAN
 ...
 U+1F9BB   | EAR WITH HEARING AID
 U+1F9BC   | MOTORIZED WHEELCHAIR
 U+1F9BD   | MANUAL WHEELCHAIR
 ...
 U+1FA30   | WHITE CHESS KNIGHT ROTATED TWO HUNDRED TWENTY-FIVE DEGREES
 U+1FA31   | BLACK CHESS KNIGHT ROTATED TWO HUNDRED TWENTY-FIVE DEGREES

Parmi les emojis de cette version, beaucoup concernent l'Inde, comme le sari ou le rickshaw. Beaucoup de caractères liés au handicap ont été créés, ainsi, mais c'est plus anecdotique, que beaucoup de caractères pour le jeu d'échecs. On trouve aussi des caractères étonnants comme U+2E4F, qui ne sert apparemment qu'à la poésie cornouaillaise. Et il y a bien sûr de nouvelles écritures comme l'élymaïque ou le nyiakeng puachue hmong. Même l'alphabet latin voit arriver de nouveaux caractères comme le U+A7C3.

Au fait, l'unique caractère de la version 12.1, c'était quoi ?

ucd=> SELECT To_U(codepoint) AS Codepoint, name FROM Characters WHERE version='12.1';
 codepoint |         name          
-----------+-----------------------
 U+32FF    | SQUARE ERA NAME REIWA

Une version d'Unicode uniquement pour introduire un caractère japonais permettant de noter l'ère Reiwa… (Merci à John Shaft pour avoir repéré celui-là.)

Tiens, d'ailleurs, combien de caractères Unicode sont des symboles (il n'y a pas que les emojis parmi eux, mais Unicode n'a pas de catégorie « emoji ») :

 ucd=> SELECT count(*) FROM Characters  WHERE category IN ('Sm', 'Sc', 'Sk', 'So');
 count 
-------
  7564

Ou, en plus détaillé, et avec les noms longs des catégories :

ucd=> SELECT description,count(category) FROM Characters,Categories WHERE Categories.name = Characters.category AND category IN ('Sm', 'Sc', 'Sk', 'So') GROUP BY category, description;
   description   | count 
-----------------+-------
 Modifier_Symbol |   123
 Other_Symbol    |  6431
 Math_Symbol     |   948
 Currency_Symbol |    62

Si vous avez les bonnes polices de caractères, voici les caractères pris en exemple plus haut : 🩰, ⹏, ꟃ, 𐿠, 𐿡, 𐿢, 𞄀, 𞄁, 𞄂, 🛕, 🛺, 🥻, 🦧, 🦻, 🦼, 🦽, 🨰, 🨱, ㋿ … (Si vous n'avez pas les bonnes polices, chaque lettre est un lien vers Uniview.)

À Bordeaux, le 23 septembre 2019, se sont tenues les RSSIA, « Assises régionales de la cyber-sécurité », organisées par le CLUSIR Aquitaine. J'y ai parlé de choix politiques en matière de sécurité informatique.

Je suis parti de mon livre, « Cyberstructure », qui parle des relations entre l'infrastructure technique et la politique. Comme le sujet de cette réunion était la sécurité, je me suis focalisé sur les questions liées à la « cybersécurité ». Voici les supports de ma présentation : au format PDF et le source LaTeX/Beamer. Désolé pour celles et ceux qui n'étaient pas présents, il n'y a pas eu de captation vidéo.

Comme dans la plupart des événements du même genre, il y avait également une exposition avec de nombreux stands. Sur l'un d'eux, une boite annonçait sur ses kakemonos qu'elle fournissait un « cryptage renforcé » qui m'a laissé perplexe.

Lors du discours de bienvenue en séance plénière, le président du conseil régional, Alain Rousset, a plaisanté sur le futur « campus de cybersecurité » aquitain en proposant qu'il soit baptisé Lisbeth Salander.

Dans les conférences techniques, Renaud Lifchitz a parlé de calculateurs quantiques, résumant l'état de l'art et ses conséquences pour la cryptographie (voir à ce sujet mon exposé à Pas Sage En Seine). J'y ai appris que le nombre de vrais calculateurs quantiques accessibles gratuitement sur l'Internet augmentait. Il n'y a pas que celui d'IBM, même Alibaba en propose un. L'auteur a également rappelé que, trois jours plus tôt, Google avait annoncé (puis retiré l'article) avoir atteint la « suprématie quantique », ce moment où un calculateur quantique va plus vite qu'un ordinateur classique émulant le calculateur quantique.

Et Rayna Stamboliyska a fait le bilan de son livre « La face cachée d'Internet ». Depuis sa parution il y a deux ans, la cybersécurité a-t-elle progressé ? Pas tellement, par rapport à l'ampleur de la menace. Il y a eu des changements : la quasi-disparition de l'« hacktivisme » indépendant, le progrès des attaques menées par des groupes proches de l'État, comme en Russie (tel que CyberBerkut) ou en Chine, le développement de l'Internet des objets, catastrophique pour la sécurité. Mais on voit toujours des machines connectées à l'Internet avec un RabbitMQ grand ouvert, laissant lire tous les messages, voire permettant d'en injecter. L'auteure est également revenue sur le mythe journalistique du « darknet » en notant qu'il n'y a guère que 50 000 domaines en .onion, la plupart avec un niveau de fiabilité très bas (« vu l'uptime des .onion, heureusement qu'ils ne signent pas de SLAs »), alors que les opérations et ventes illégales se font plutôt sur Instagram, WhatsApp, etc.

Le 6 septembre dernier, Mozilla a annoncé l'activation du protocole DoH par défaut dans leur navigateur Firefox. (Et, même si ce n'est pas explicite, il est prévu que ce soit par défaut avec le résolveur de Cloudflare.) Cette annonce a suscité beaucoup de discussions, souvent confuses et mal informées. Cet article a pour but d'expliquer la question de DoH, et de clarifier le débat.

DoH veut dire « DNS sur HTTPS ». Ce protocole, normalisé dans le RFC 8484, permet l'encapsulation de requêtes et de réponses DNS dans un canal cryptographique HTTPS menant au résolveur. Le but est double : empêcher un tiers de lire les requêtes DNS, qui sont souvent révélatrices (cf. RFC 7626), et protéger les réponses DNS contre des modifications, faites par exemple à des fins de censure. Le statu quo (laisser le DNS être le seul protocole important qui ne soit pas protégé par la cryptographie) n'est pas tolérable, et il faut donc féliciter Mozilla d'avoir agi. Mais cela ne veut pas dire que tout soit parfait dans leur décision. Notamment, DoH, comme toutes les solutions reposant sur TLS, ne fait que sécuriser le canal de communication contre la surveillance et la manipulation par un tiers. Il ne garantit pas que le partenaire à l'autre bout du canal est gentil. Faire du DoH vers un méchant résolveur ne serait donc pas très utile, et le choix du résolveur est donc crucial.

Voyons maintenant les principales critiques qui ont été faites contre DoH et/ou contre la décision de Mozilla (si j'en ai oublié, écrivez-moi). Rappelez-vous bien que le débat est très confus, en partie par mauvaise foi de certains, en partie par ignorance (du DNS ou de la sécurité). Notamment, certaines des critiques formulées contre DoH n'ont rien à voir avec DoH mais, par exemple, avec un aspect spécifique de la décision de Mozilla. Et, parfois, d'autres protocoles, comme DoT (DNS sur TLS, RFC 7858), présentent exactement les mêmes propriétés.

• DoH empêche (en réalité : rend plus difficile) d'appliquer une politique, par exemple de censurer Sci-Hub. Aucun doute à ce sujet, c'est même le but explicite. Ceux qui le présentent comme un inconvénient avouent franchement que leur but est le contrôle des utilisateurs. L'IETF, qui a normalisé le protocole, travaille pour un Internet ouvert. Si vous voulez utiliser les technologies TCP/IP dans un réseau fermé, vous avez le droit, mais c'est à vous de trouver des solutions. Cette critique n'est pas spécifique à DoH, DoT offre exactement le même avantage (ou le même inconvénient, si on est du côté des censeurs).
• DoH empêche (en réalité : rend plus difficile) la surveillance des utilisateurs. L'examen des requêtes DNS peut être très révélateur (cf. RFC 7626) et être utilisé pour le bien (détection de l'activité de logiciels malveillants) ou pour le mal (repérer qui visite tel ou tel site Web). Là encore, c'est le but explicite de DoH (comme de TLS en général) de rendre plus difficile la surveillance (cf. RFC 7258). Cette critique n'est pas spécifique à DoH, DoT offre exactement le même avantage (ou le même inconvénient, si on est du côté des surveillants).
• On a souvent lu que DoH aggravait la centralisation (déjà bien trop importante) de l'Internet et notamment du Web. C'est une drôle de façon de poser le problème que de l'attribuer à DoH. Lorsque Gmail rassemble la majorité du courrier électronique (oui, même si vous n'êtes pas client de Gmail, et n'avez pas accepté leurs conditions d'utilisation, une bonne partie de votre courrier est chez Gmail), est-ce qu'on décrit ce problème comme étant de la faute de SMTP ? (Notez que la relation entre les protocoles et les résultats de leurs déploiements est une question complexe, cf. RFC 8280.) Je suis personnellement d'accord que ce n'est pas une bonne idée d'envoyer tout le trafic DNS à Cloudflare, mais la solution n'est pas de supprimer DoH, ou de le limiter à parler aux résolveurs des FAI, précisément ceux auxquels on ne fait pas forcément confiance. La solution est au contraire de multiplier les serveurs DoH, de même que la solution aux réseaux sociaux centralisés est d'avoir plein d'instances décentralisées. C'est ce que je fais avec mon résolveur DoH personnel, c'est ce que font, en plus sérieux, les CHATONS. Bref, la centralisation du Web autour d'une poignée de GAFA est un vrai problème, mais pas lié à DoH. Les résolveurs DNS publics, comme Google Public DNS posent le même problème.
• On a lu parfois que DoH diminuait la vie privée car HTTP est bavard, très bavard. Ainsi, une requête DNS contient très peu d'informations sur le client, alors que HTTP transmet plein d'informations inutiles et dangereuses comme Accept-Language: ou User-Agent:, qui peuvent servir à identifier un utilisateur. Sans compter bien sûr les très dangereux biscuits (RFC 6265). Il s'agit là d'un vrai problème. Des solutions ont été proposées (cf. l'Internet-Draft draft-dickinson-doh-dohpe) mais n'ont guère suscité d'intérêt. C'est probablement l'une des deux seules critiques de DoH qui soit réellement spécifique à DoH (DoT n'a pas ce problème), le reste étant confusion et mauvaise foi.
• Un reproche plus conceptuel et abstrait qui a été fait à DoH (par exemple par Paul Vixie) est d'ordre architectural : selon cette vision, le DNS fait partie du plan de contrôle et pas du plan de données, ce qui fait qu'il doit être contrôlé par l'opérateur réseau, pas par l'utilisateur. Le positionnement du DNS ne fait pas l'objet d'un consensus : protocole situé dans la couche Application, il fait pourtant partie de l'infrastructure de l'Internet. Disons que cette ambiguïté est consubstantielle à l'Internet : plusieurs protocoles d'infrastructure (c'est aussi le cas de BGP) tournent dans la couche 7. Dans tous les cas, le DNS ne peut pas être vu comme purement technique (comme, par exemple, ARP), son utilisation massive pour la censure montre bien qu'il est aussi un protocole de contenu, et devrait donc être protégé contre la censure. Si les gens qui clament que le DNS fait partie de l'infrastructure et que l'utilisateur ne devrait pas pouvoir bricoler sa résolution DNS étaient cohérents, ils réclameraient également que les FAI s'engagent à ne jamais interférer (ce que suggérait l'IAB dans une récente déclaration). Mais cela semble peu réaliste à court terme.
• Un autre reproche de nature architecturale a été fait à DoH : tout faire passer sur HTTPS n'est pas « propre ». Ce reproche est justifié du point de vue technique (l'Internet n'a pas été conçu pour fonctionner comme cela, normalement, les applications doivent tourner sur SCTP, TCP, UDP, pas sur HTTPS). Mais, en pratique, « le bateau a déjà quitté le port », comme disent les anglophones. De plus en plus de réseaux bloquent tous les ports sauf 80 et 443 et, si on veut faire un protocole qui passe partout, il doit utiliser HTTPS. Si cela vous déplait, plaignez-vous aux gérants des points d'accès WiFi, pas à DoH. Notez que cette remarque est une des rares à être effectivement spécifique à DoH.
• Tel qu'il est mis en œuvre dans Firefox, DoH est fait par l'application, pas par le système d'exploitation (ce qu'on nomme parfois ADD, pour Applications Doing DNS). Ce n'est pas du tout une propriété de DoH, juste un choix de Firefox. Les nombreux schémas où on voit « avec DoH, c'est l'application qui fait les requêtes DNS » révèlent qu'ils ont été faits par des gens qui ne comprennent pas ce qu'est un protocole. DoH peut parfaitement être utilisé par les couches basses du système d'exploitation (par exemple, sur les systèmes qui ont le malheur d'utiliser systemd, par systemd-resolve ou, plus sérieusement, par un démon comme Stubby). Le choix de Mozilla est à mon avis erroné, mais n'a rien à voir avec DoH. Là encore, rien de spécifique à DoH, une application a toujours pu faire des requêtes DNS directement avec UDP, ou utiliser DoT, ou avoir son propre protocole privé de résolution de noms (ce que font souvent les logiciels malveillants).
• Enfin, on lit parfois que DoH poserait des problèmes lorsque la réponse DNS dépend de la localisation du client (ce qui est courant avec les CDN). C'est un effet déplorable de la centralisation du Web : comme l'essentiel du trafic est concentré sur un petit nombre de sites, ces sites doivent se disperser sur la planète et utiliser des bricolages dans le DNS pour diriger le client vers « le plus proche », estimé en fonction de l'adresse IP du client. Si le résolveur est loin de l'utilisateur, on sera renvoyé vers un endroit sous-optimal. Il existe une solution technique (RFC 7871) mais elle est très dangereuse pour la vie privée, et c'est pour cela que Cloudflare, contrairement à Google, ne l'utilise actuellement pas. Ceci dit, cela n'a rien de spécifique à DoH, tout résolveur DNS public (notez que ce terme est défini dans le RFC 8499) soulève les mêmes questions (c'est également le cas si vous avez des noms de domaine privés, spécifiques à une organisation).

Articles intéressants sur le sujet :

• Wired a fait un article correct et exposant bien les différents points de vue.

Et pour finir, une petite image (prise sur Wikimedia Commons) du détroit de Messine où, selon les légendes, les marins qui tentaient d'éviter Scylla tombaient sur Charybde. Bref, ce n'est pas parce qu'on n'aime pas Cloudflare qu'il faut maintenir le statu-quo et continuer à envoyer ses requêtes DNS au résolveur fourni par le réseau d'accès

Ce texte est la politique suivie par le résolveur DoH doh.bortzmeyer.fr et par le résolveur DoT dot.bortzmeyer.fr. Il explique ce qui est garanti (ou pas), ce qui est journalisé (ou pas), etc. (Vous pouvez également accéder à ce texte par l'URL https://doh.bortzmeyer.fr/policy .)

[If you don't read French, sorry, no translation is planned. But there are many other DoH resolvers available (or DoT), sometimes with policies in English.]

Les protocoles DoH (DNS sur HTTPS), normalisé dans le RFC 8484, et DoT (DNS sur TLS), normalisé dans le RFC 7858, permettent d'avoir un canal sécurisé (confidentialité et intégrité) avec un résolveur DNS qu'on choisit. DoH est mis en œuvre dans plusieurs clients comme Mozilla Firefox. Ce texte n'est pas un mode d'emploi (qui dépend du client) mais une description de la politique suivie. La sécurisation du canal (par la cryptographie) vous protège contre un tiers mais évidemment pas contre le gérant du résolveur DoH ou DoT. C'est pour cela qu'il faut évaluer le résolveur DoH qu'on utilise, juger de la confiance à lui accorder, à la fois sur la base de ses déclarations, et sur la base d'une évaluation du respect effectif de ces déclarations.

Le résolveur DoH doh.bortzmeyer.fr et le résolveur DoT dot.bortzmeyer.fr sont gérés par moi. C'est un projet individuel, avec ce que cela implique en bien ou en mal.

Ce résolveur :

• Est public (au sens du RFC 8499), ce qui veut dire que tout le monde peut l'utiliser,
• Est authentifiable par le nom dans le certificat, ou bien par DANE (RFC 6698) ou encore par l'épinglage de la clé qui vaut, pour le serveur DoT, eHAFsxc9HJW8QlJB6kDlR0tkTwD97X/TXYc1AzFkTFY= (en SHA-256/Base64, comme spécifié par le RFC 7858),
• N'offre aucune garantie de bon fonctionnement. Il est supervisé mais les ressources humaines et financières disponibles ne permettent pas de s'engager sur sa stabilité. (Mais vous êtes bien sûr encouragé·e·s à signaler tous les problèmes ou limites que vous rencontreriez.)
• Accepte tous les clients gentils, mais avec une limitation de trafic (actuellement cent requêtes par seconde mais cela peut changer sans préavis). Les clients méchants pourraient se retrouver bloqués.
• N'enregistre pas du tout les requêtes DNS reçues. Elles ne sont jamais mises en mémoire stable. Notez que la liste des adresses IP des clients, et celle des noms de domaines demandés est gardée en mémoire temporaire, et ne survit donc pas à un redémarrage du logiciel serveur (ou a fortiori de la machine). Les deux listes sont stockées séparément donc je peux voir que 2001:db8:99:fa4::1 a fait une requête, ou que quelqu'un a demandé toto.example, mais je ne sais pas si c'est la même requête.
• Et les requêtes complètes ne sont pas copiées vers un autre serveur. (Certaines politiques de serveurs disent « nous ne gardons rien » mais sont muettes sur l'envoi de copies à un tiers.) Notez que, pour faire son travail, le résolveur DoH doit bien transmettre une partie de la requête aux serveurs faisant autorité, mais cette partie est aussi minimisée que possible (RFC 7816).
• Le résolveur ne ment pas, il transmet telles quelles les réponses reçues des serveurs faisant autorité. Même des domaines dangereux pour la vie privée comme google-analytics.com sont traités de manière neutre.
• Je suis sincère (si, si, faites-moi confiance) mais ce serveur dépend d'autres acteurs. C'est une simple machine virtuelle et l'hébergeur peut techniquement interférer avec son fonctionnement. C'est d'autant plus vrai que la machine est en France et donc soumise à diverses lois liberticides comme la loi Renseignement.

Comme indiqué plus haut, il s'agit d'un projet individuel, donc sa gouvernance est simple : c'est moi qui décide (mais, en cas de changement des règles, je modifierai cet article, et en changeant la date pour que les utilisateurices de la syndication aient la nouvelle version). Si cela ne vous convient pas, je vous suggère de regarder les autres serveurs DoH disponibles (plus il y en a, mieux c'est). Voyez aussi les serveurs DoT.

Among the people who use the CowBoy HTTP server, some do it from an Erlang program, and some from an Elixir program. The official documentation only cares about Erlang. You can find some hints online about how to use CowBoy from Elixir but they are often outdated (CowBoy changed a lot), or assume that you use CowBoy with a library like Plug or a framework like Phoenix. Therefore, I document here how I use plain CowBoy, from Elixir programs, because it may help. This is with Elixir 1.9.1 and CowBoy 2.6.3.

I do not find a way to run CowBoy without the mix tool. So, I start with mix:

% mix new myserver 
...
Your Mix project was created successfully.
    

I then add CowBoy dependencies to the mix.exs file:

 defp deps do                                                                                                                      
    [                                                                                                                               
      {:cowboy, "~> 2.6.0"}                                                                                                         
    ]                                                                                                                               
 end        
    

(Remember that CowBoy changes a lot, and a lot of CowBoy examples you find online are for old versions. Version number is important. I used 2.6.3 for the examples here.) Then, get the dependencies:

% mix deps.get
...
  cowboy 2.6.3
  cowlib 2.7.3
  ranch 1.7.1
...
    

We can now fill lib/myserver.ex with the main code:

 defmodule Myserver do                                                                                                               
                                                                                                                                    
  def start() do                                                                                                                    
    dispatch_config = build_dispatch_config()                                                                                       
    { :ok, _ } = :cowboy.start_clear(:http,                                                                                         
      [{:port, 8080}],                                                                                                              
      %{ env: %{dispatch: dispatch_config}}                                                                                         
    )                                                                                                                               
  end                                                                                                                               
                                                                                                                                    
  def build_dispatch_config do                                                                                                      
    :cowboy_router.compile([                                                                                                        
      { :_,                                                                                                                         
        [                                                                                                                           
          {"/", :cowboy_static, {:file, "/tmp/index.html"}}
        ]}                                                                                                                          
    ])                                                                                                                              
  end                                                                                                                               
                                                                                                                                    
end                
    

And that's all. Let's test it:

      
% iex -S mix
Erlang/OTP 22 [erts-10.4.4] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1]

Compiling 1 file (.ex)
Interactive Elixir (1.9.1) - press Ctrl+C to exit (type h() ENTER for help)

iex(1)> Myserver.start()
{:ok, #PID<0.197.0>}

iex(2)> 
      
    

If you have HTML code in /tmp/index.html, you can now use any HTTP client such as curl, lynx or another browser, to visit http://localhost:8080/.

The start_clear routine (which was start_http in former versions) starts HTTP (see its documentation.) If you want explanation about the behaviour :cowboy_static and its parameters like :file, see the CowBoy documentation. If you are interested in routes (the argument of :cowboy_router.compile, directives for CowBoy telling it "if the request is for /this, then do that"), see also the documentation. There are many other possibilities, for instance, we could serve an entire directory:

 def build_dispatch_config do                                                                                                      
    :cowboy_router.compile([                                                                                                        
                                                                                                                                    
      { :_,                                                                                                                         
        [                                                                                                                           
          # Serve a single static file on the route "/".                                                                            
          {"/", :cowboy_static, {:file, "/tmp/index.html"}},                                                                        

          # Serve all static files in a directory.                                                                                  
          # PathMatch is "/static/[...]" -- string at [...] will be used to look up the file                                        
          # Directory static_files is relative to the directory where you run the server                                            
          {"/static/[...]", :cowboy_static, {:dir, "static_files"}}                                                                 
        ]}                                                                                                                          
    ])                                                                                                                              
  end     
    

You can now start from this and improve:

• Use start_tls instead of start_clear, to provide security through HTTPS,
• Replace def start() do by def start(_type, _args) do (or def start(type, args) do if you want to use the parameters) to follow OTP conventions, in order for instance to run the HTTP server under a supervisor (see this example - untested), or simply to create a standalone application,
• Serve dynamic content by using Elixir (or Erlang) modules to produce content on the fly.

L'hébergeur OVH a une offre nommée « VPS » (pour Virtual Private Server ») qui permet de disposer d'une machine virtuelle connectée à l'Internet, par exemple pour y héberger ses serveurs. Par défaut, on n'a que de l'IPv4 mais IPv6 est possible. Comme je n'ai pas trouvé de documentation qui marche pour le cas où la machine virtuelle tourne sous Arch Linux, je documente ici ma solution, pour que les utilisateurs des moteurs de recherche la trouvent.

Donc, le problème est le suivant. Soit un VPS OVH utilisant le système d'exploitation Arch Linux. Configuré et démarré, il n'a qu'une adresse IPv4 ce qui, en 2019, est inacceptable. OVH permet de l'IPv6, mais ce n'est pas configuré automatiquement par leur système « Cloud Init ». Il faut donc le faire soi-même. OVH documente la façon de faire mais Arch Linux n'y est pas mentionné. Du côté de ce système d'exploitation, IPv6 est documenté (il faut utiliser NetCtl). A priori, c'est simple, en utilisant les deux documentations, on devrait y arriver. Sauf que cela n'a pas marché, la machine, après redémarrage, n'a toujours pas d'adresse IPv6, et qu'il n'y a pas d'information de déboguage disponible. Pas moyen de savoir où je me suis trompé.

Après une heure d'essais infructueux, je suis donc passé à une méthode simple et qui marche immédiatement : écrire un script shell de deux lignes et le faire exécuter au démarrage de la machine. Le script était simplement :

ip -6 addr add 2001:41d0:302:2200::180/128 dev eth0
ip -6 route add 2001:41d0:302:2200::1 dev eth0
ip -6 route add default via 2001:41d0:302:2200::1
    

Cette façon de faire est un peu bizarre, avec ce préfixe de longueur 128 (normalement, cela devrait être 64), qui oblige à mettre une route vers… le routeur, mais c'est cohérent avec ce qui est fait par défaut pour IPv4. Une solution plus propre aurait été :

ip -6 addr add 2001:41d0:5fa1:b49::180/64 dev eth0
ip -6 route add default via 2001:41d0:5fa1:b49::1
    

Et cela marche mais je ne suis pas sûr que cela permette de joindre les machines du même réseau.

Les adresses IP à utiliser (votre machine, et le routeur par défaut) sont obtenues via l'espace client (manager) de votre compte OVH, rubrique Serveur → VPS → IP.

Une fois ce script écrit, stocké en /usr/local/sbin/start-ipv6, et rendu exécutable, il reste à le lancer au démarrage. Pour cela, je me sers de systemd. Je crée un fichier /etc/systemd/system/ipv6.service. Il contient :

[Unit]
Description=Starts IPv6
After=systemd-networkd.service
Before=network.target 

[Service]
ExecStart=/bin/true
ExecStartPost=/usr/local/sbin/start-ipv6

[Install]
WantedBy=multi-user.target
    

J'active ce service avec systemctl enable ipv6 et, au redémarrage de la machine, tout va bien et on a IPv6.

Du 27 au 29 août, à Quimper, s'est tenu l'évènement libriste « Entrée Libre ».

À cette occasion, j'avais préparé un exposé sur « Qu'est-ce qu'Internet ? ». Bien sûr, tout le monde connait l'Internet, mais sans savoir en général ce qui se passe derrière l'écran. Or, ce système pas directement visible peut avoir de sérieuses conséquences sur ce que l·e·a citoyen·ne peut faire sur l'Internet. Voici les supports de cet exposé, et leur source (en LaTeX). La vidéo, quant à elle, se trouve sur PennarWeb et sur Vimeo. (Oui, je sais, il faudrait aussi les mettre sur PeerTube.)

Il y avait également plein d'activités intéressantes, notamment des ateliers interactifs, et d'autres exposés passionnants (les vidéos sont sur Vimeo). Citons, entre autres, celle sur les données de santé, celle sur les logiciels libres pour les professionnels de la santé, celle sur Exodus Privacy.

Merci mille fois à Brigitte et à tous les bénévoles et salariés du Centre Social des Abeilles. (Et j'avais déjà eu le plaisir de venir à ce Centre des Abeilles.)

Le 12 août dernier, les médias ont annoncé en fanfare le lancement de Salto, le « Netflix français », lancement déjà annoncé en juin 2018. En réalité, une étape (purement bureaucratique) a été franchie. Mais quel avenir attend Salto ?

Les réseaux sociaux ont déjà fait d'innombrables blagues sur ce projet caricatural : décisions d'en haut, ignorance abyssale de ce qui existe, mépris pour les problèmes concrets, Salto cumule en effet de quoi faire ricaner. Mais de quoi s'agit-il et quelles sont les chances de réussite de Salto ?

Autrefois, il y a bien longtemps, la télévision était diffusée par ondes hertziennes, captées par tous. Il n'y avait qu'une seule chaîne de télévision, dirigée par l'État. Le ministre de l'information officielle et gaulliste y dictait les sujets (« la télévision est la voix de la France »), et tout le monde obéissait. Paradoxalement, dans cet environnement si contrôlé, des échappées étaient possibles et quelques émissions créatives (comme les Shadoks) ont quand même pu éclore. Pas d'enregistrement possible, ni de télévision à la demande des anciennes émissions, la France s'asseyait donc aux heures imposées devant l'unique écran de la maison, et regardait. Puis le magnétoscope est arrivé, d'autres chaînes sont apparues, puis les entreprises privées en ont créé ou bien ont mis la main sur d'ex-chaînes publiques, et il y a eu beaucoup de choix, enfin au moins en apparence.

Après l'Internet s'est répandu et, logiquement, on s'est mis à diffuser de la télévision via l'Internet, même si tous les experts français de l'expertise étaient d'accord au début des années 1990 pour dire que cela ne serait jamais possible, qu'il fallait plutôt utiliser les technologies françaises. Le nombre d'écrans par foyer a explosé, comme le choix, plus réel cette fois, puisque, avec l'Internet, M. Michu peut non seulement « accéder à du contenu » mais en produire.

Comme d'habitude, les élites dirigeantes françaises ont mis du temps à comprendre et, plutôt que de se féliciter de ces nouvelles possibilités, ont tout fait pour les contrôler et les limiter. La création de la HADOPI est sans doute le plus bel exemple de cet aveuglement, partagé par tous les partis politiques officiels, et par les médias dominants. Entre autres, on a diabolisé le pair-à-pair, c'est-à-dire les techniques qui exploitaient le mieux les caractéristiques techniques de l'Internet. En voulant ainsi défendre les intérêts de l'industrie du divertissement nationale, on a donc laissé se développer des GAFA centralisés comme YouTube et, plus tard, Netflix. Aujourd'hui, les gens qui regardent « la télévision », le font en général via ces plate-formes Internet, sur un écran d'ordinateur ou d'ordiphone, et plus en s'asseyant devant « la télévision ». (Notez qu'il existe un gros fossé générationnel : TF1 reste très regardé, chez la frange la plus âgée de la population, ce qui fait du monde. Les chaînes de télévision traditionnelles déclinent, mais il faudra de nombreuses années pour qu'elles disparaissent complètement.)

Ajoutons aussi que, déconnecté des demandes des utilisateurs, on a également ajouté de plus en plus de publicité à la télé, comme si on cherchait à encourager la migration vers Netflix…

Là, des gens dans les sphères d'en haut ont fini par se dire qu'il y avait un problème. Netflix, qui repose sur un système d'abonnement, croît continuellement, et se fait « un pognon de dingue », et les jeunes ne savent même plus ce que c'est que de lire Télé 7 jours pour savoir à quelle heure commence le film. C'est là qu'est né le projet Salto, baptisé « le Netflix français ».

Bien sûr, la comparaison avec Netflix est absurde. Salto n'aura jamais un budget comparable, et même les plus optimistes ne le voient pas prendre une part non-microscopique de la part de marché de Netflix. Mais l'enflure verbale est souvent appréciée des politiques et des journalistes, transformant un projet peu enthousiasmant (les télévisions du passé s'unissent pour mourir un peu moins vite…) en une croisade tricolore contre la sous-culture yankee.

Une grande partie des critiques contre Salto ont porté sur le catalogue : c'est la grande force de Netflix, la disponibilité d'une étonnante quantité de contenus, très souvent d'origine étrangère aux États-Unis. (Quelle chaîne de télévision française aurait diffusé une série comme « 3 % » ?) Face à cette offre surabondante, les catalogues des créateurs de Salto, TF1, France Télévisions et M6 paraissent en effet bien pâles… (D'autant plus qu'il semble bien qu'on n'aura sur Salto qu'une petite partie du catalogue des membres du projet.) Je ne vais donc pas insister sur cette question du catalogue, bien qu'elle soit en effet cruciale. Et je vais plutôt parler de l'opérationnel, et de la gouvernance.

Il me semble qu'il y a un sérieux problème pratique : une plate-forme comme celle de Netflix est un défi permanent pour l'ingéniérie. Il faut distribuer la vidéo, qui est très gourmande et prend énormément de capacité, il va falloir d'innombrables serveurs pour héberger ces vidéos, du devops pour lier le tout et une interface humaine adaptée à des millions d'utilisateurs qui veulent juste que ça marche, et se détourneront vite de Salto s'il y a des problèmes techniques. C'est d'autant plus sérieux que Netflix a de nombreuses années d'avance, et a déjà beaucoup innové en ce domaine (comme avec leur célèbre - à juste titre - singe du chaos.) Jusqu'à présent, les responsables de Salto ont fait preuve d'une légèreté inquiétante dans ce domaine. Ils ne communiquent que sur des succès bureaucratiques (la signature de l'accord initial, l'approbation de l'Autorité de la concurrence…) et jamais sur le travail concret qui sera colossal. Affirmer que le projet avance alors que pas une seule ligne de code n'a été écrite est révélateur d'une certaine vision : celle qui ne connait que les réunions au sommet, et jamais les considérations opérationnelles. Le Monde parlait de l'« accouchement » du projet. Mais l'accouchement de quoi, puisque rien n'a encore été produit, il n'y a eu que réunions et paperasses. Le plus dur, avoir une plateforme technique qui fonctionne, reste à faire.

On peut être d'autant plus inquiet pour Salto que la France a vécu plusieurs mauvaises expériences de projets informatique comparables. On fait des réunions, on signe des papiers, et on oublie complètement la réalisation concrète. Des années après, le projet est une catastrophe et il faut fermer boutique. On se souvient de l'escroquerie qu'avait été le « cloud souverain », définitivement clos en juillet 2019 après des années de gaspillage. Ou bien le « Google européen » lancé par Chirac, Quaero. Citons aussi le ridicule projet « OS souverain » qui, lui, a heureusement sombré vite, avant de coûter trop cher. Et concernant la distribution de vidéos, la liste des échecs est longue. A priori, un des scénarios les plus probables pour Salto était que des millions de lignes de Java seraient écrites par une grosse ESN habituée des contrats, et que rien ne marcherait jamais vraiment techniquement. Un gros projet informatique est quelque chose de complexe, qui ne se fait pas juste en signant des papiers et en sous-traitant à une entreprise importante. Souvent, il vaut mieux faire appel à une petite équipe, ayant une vision claire et ne dépendant pas de cahiers des charges de milliers de pages.

Selon certaines sources (non officielles, on ne trouve rien sur https://www.salto.fr/), le développement serait finalement fait par M6, un des membres du projet. (Ou peut-être en utilisant la technologie de SteamRoot, qui a l'avantage d'inclure du pair-à-pair.) J'ai donc voulu tester https://www.6play.fr/, le service de ce même M6, pour voir, et j'ai :

(Ce n'est pas un problème avec cette vidéo particulière, ça le fait pour toutes.)

Mais à part ces considérations pratiques, Salto a deux autres gros défauts, qui mettent sérieusement en danger le projet. L'un est son côté peu disruptif : il s'agit uniquement de copier Netflix, en plus petit et en moins bien. Battre un mastodonte comme Netflix, sans parler des autres entreprises qui vont tenter de faire la même chose comme Disney ou Warner, qui ont des projets similaires (Disney+ et HBO Max), est impossible si on se place sur le même terrain. Quand on n'a pas les moyens de Netflix (moyens financiers et humains), on n'essaie pas de lutter dans la même catégorie : on change de terrain. La distribution de vidéo depuis un service centralisé, comme Netflix ou Salto, est de toute façon une mauvaise façon d'utiliser l'Internet. Elle mène à des déséquilibres dans la répartition du trafic qui, à leur tour, mènent à des attaques contre la neutralité de l'Internet. La bonne solution, pour distribuer un contenu lourd en nombre de gigaoctets, est au contraire le pair-à-pair. Au lieu de laisser les ayant-trop-de-droits diaboliser ce mécanisme, il faudrait au contraire décentraliser au maximum la distribution, utilisant des petits services un peu partout au lieu de chercher à se faire aussi gros que le bœuf Netflix. Et ça tombe bien, il existe des solutions techniques pour cela, notamment le logiciel libre PeerTube, qui permet l'installation de plein de petits services partout, eux-même distribuant en pair-à-pair (grâce à WebTorrent) les vidéos. C'est ce genre de services, fondés sur le logiciel libre et le pair-à-pair que les pouvoirs publics devraient encourager et aider !

Certaines personnes qui défendent Salto estiment que toutes les critiques sont du « french bashing », de la critique systématique et masochiste de ce qui vient de France. Cet argument aurait plus de poids si Salto n'utilisait pas, pour son propre hébergement, un étranger (AWS) plutôt qu'un hébergeur français. Et PeerTube, que j'ai cité, est développé en France donc, si on veut vraiment faire du nationalisme, Salto n'est pas la bonne voie.

Outre ce problème technique, et ce manque d'intérêt pour les questions concrètes, Salto souffre d'un autre problème : il est entièrement conçu d'en haut, dans un entre-soi complet. Les gens qui connaissent vraiment Netflix, et/ou qui connaissent vraiment l'Internet, n'ont pas été consultés. (Tous et toutes auraient pu dire que le projet n'avait aucun sens.) Au lieu de discuter avec les personnes qui ont une expérience de l'Internet, Salto a été conçu dans des bureaux fermés, entre des dirigeants qui ne connaissent que la télé d'autrefois. Cela n'augure pas bien de son avenir.

En conclusion, mon pronostic est clair : Salto est fichu. Dans le meilleur des cas, il coulera vite. Dans le pire, cela durera des années, en engloutissant diverses aides et subventions pour « soutenir la création française » ou bien parce que « on ne peut pas laisser Netflix en numéro un ». Déjà, le gouvernement en est à menacer d'utiliser la contrainte (« S'ils ne le font pas, ils ne pourront plus être disponibles en France »), en annonçant que Netflix pourrait être censuré en France, ce qui montre bien que je ne suis pas le seul à être sceptique quant aux capacités de Salto.

Je ne changerai pas cet article dans le futur, vous pourrez donc voir en 2020 ou 2021 si j'avais raison…

Notez toutefois qu'une autre possibilité existe : derrière les rodomontades ridicules reprises en boucle par les médias (« faire un Netflix français »), il y a peut-être de tout autres projets, moins ambitieux. Par exemple, il est parfaitement possible que le vrai but de Salto soit de concurrencer Molotov plutôt que Netflix. Ou bien tout bêtement de remplacer l'accès aux émissions précédentes (replay) gratuit par un accès payant via Salto. Ce serait un objectif moins glorieux mais plus réaliste. Dans ce cas, le discours sur Netflix serait juste un écran de fumée.

Bon, j'ai fini cet article, je retourne regarder Arte.