Loading...
An error has occurred

An error has occurred in Orbeon Forms. You may want to try one of the following:

  • Close this dialog and continue to use this page.
  • Reload this page. Note that you will lose any unsaved changes.
  • If the above does not work, try reloading the page yourself. Note that you will lose any unsaved changes:

    • With Firefox and Safari: hold down the shift key and click the Reload button in your browser toolbar.
    • With Internet Explorer: hold down the control key and click the Reload button in your browser toolbar.
  • Return home.
Help

PLANÈTE XMLFR

Agrégation de carnets web.

2019-10-22

☕︎ Privilèges

Une nuit en forêt avec pour challenge de ne pas faire de feu. S’adapter petit à petit au manque de luminosité, décider de dormir à la belle étoile même avec des températures négatives. Se sentir chanceux.

Mes privilèges sont nombreux et me permettent d’apprécier ma vie, de mieux comprendre ce que peut être la vie des autres, et de relativiser les quelques épreuves qui j’ai pu rencontrer jusqu’ici ainsi que le mérite que je pourrais penser avoir en les ayant dépassées.

Mes privilèges (cache)

Merci Boris de partager cette liste, je ne me sens pas suffisamment stable émotionnellement pour assumer une telle liste pour l’instant. J’aime prendre connaissance des sommets que je pourrais gravir ultérieurement. J’apprécie les personnes qui me montrent l’un des chemins possibles pour y accéder.

Les montagnes techniques ne m’intéressent plus.

I prefer coding everything by hand, because I don’t like the huge piles of garbage that the automated generators create. These programs that generate a website, app, or file for you spit out thousands of lines of unnecessary junk when really only 10 lines are needed. Then people wonder why their site is so slow, and they think it’s their phone or connection’s fault.

Digital pollution (cache)

Je réfléchis beaucoup à ce que signifie l’auto-suffisance en matière de développement (web). La différence entre aller cueillir des poires dans le verger du voisin et en acheter une caisse chez Monsanto.

Une excellente façon de prendre conscience du coût caché de l’open-source.

Wendat jette un regard tout aussi critique sur les habitudes de conversation des Français. Sagard a été surpris et impressionné par l’éloquence et la capacité de raisonnement de ses hôtes, des compétences affinées par des discussions quasi quotidiennes sur les affaires communes ; ses hôtes, en revanche, lorsqu’ils ont pu voir un groupe de Français réunis, ont souvent remarqué la façon dont ils semblaient constamment se bousculer les uns les autres et s’entretuer dans la conversation, utilisant des arguments faibles, et surtout (le sous-texte semblait être), ne se montrant pas très intelligents. Ceux qui essayaient de s’emparer de la scène, refusant aux autres les moyens de présenter leurs arguments, agissaient à peu près de la même manière que ceux qui s’emparaient des moyens matériels de subsistance et refusaient de les partager ; on a l’impression que les Américains considéraient les Français comme vivant dans une sorte de guerre hobbésienne de tous contre tous.

La sagesse de Kandiaronk : la critique indigène, le mythe du progrès et la naissance de la Gauche (cache)

Peut-être que les européens ont décimé une vérité qui leur était trop insupportable à admettre ?

Cet article est incroyable.

Citation de la semaine :

Ton écran peut être selon ton vouloir ou bien ta fenêtre ou bien ton miroir !

L’apprenti sage, Gilles Vigneault

L’un de mes nombreux privilèges est de pouvoir échanger avec des personnes qui alimentent ma façon de pousser. Merci à vous.

Journée de l'APDEN (professeur·e·s documentalistes) sur l'enseignement de l'informatique

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 a 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 chose.

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

2019-10-20

Unicode à ses débuts

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.

2019-10-15

☕︎ Discrétion

Une semaine très chaotique. Je me demande souvent si je devrais pas me faire plus discret lorsque mon attention se trouve être sollicitée de manière non soutenable. Ou au moins ne pas avoir d’opinions trop tranchées. Et en même temps, c’est ce qui me permet de vider un trop plein.

La discrétion, que Benoît appelait la « mère des vertus », est le discernement mesuré des situations uniques, qui fait de notre obéissance le contraire même de l’enrégimentement. La réflexion que je souhaite encourager requiert de la discrétion de la part du lecteur, sans qu’elle en devienne privée pour autant. L’intimité est une construction sociale toute moderne. Elle relève de l’individualisme possessif qui forme les opinions semeuses de discorde. Ce que je souhaite vous voir partager avec moi, ce n’est pas une opinion, mais une angoisse presque insupportable face à […].

La perte des sens, Ivan Illich

J’avais déjà lu que pour d’autres cultures/civilisations, l’intimité n’existait pas forcément. Est-ce que l’intimité est nécessaire à la création de rareté, de capital personnel ? Peut-il y avoir capitalisme sans intimité ?

Vous avez une semaine.

“What if we were to take advantage of all these incredible solutions that have been developed and driven by people who have nothing to do with the federal government?” he asked during his speech to the packed ballroom. “What if we were to unlock those capabilities to do the mission of national defense? What if we were to take advantage of the long-tail marketplaces that have developed in the commercial cloud industries? That’s what JEDI is.”

Meet America’s newest military giant: Amazon (cache)

Vous pourriez être tenté de participer à une bibliothèque comme boto à un moment dans votre vie. Puis apprendre bien plus tard qu’elle pourrait être utilisée par le Pentagon pour des objectifs qui vous semblent en désaccord avec ce qui est bien ou mal. Ce n’est pas forcément une question de valeurs mais de temporalité.

Les développeurs sont les forgerons des temps modernes et ils sont en train de se rendre compte qu’une hache ne sert pas qu’à fendre du bois.

The Open Source movement has always been focused on code. The result is a system that sadly neglects people. Many maintainers find themselves in a curious place. On one hand, we have people who regret seeing their code used for unethical purposes, but, because of the Open Source values they previously embraced, are unable to do anything except watch their code become weaponized.

Open Source is Broken (cache)

This project is only relevant if the collapse is of a specific magnitude. A weak-enough collapse and it’s useless (just a few fabs that close down, a few wars here and there, hunger, disease, but people are nevertheless able to maintain current technology levels). A big enough collapse and it’s even more useless (who needs microcontrollers when you’re running away from cannibals).

But if the collapse magnitude is right, then this project will change the course of our history, which makes it worth trying.

Collapse OS - Why? (cache)

C’est la beauté de tout ce qui est entrepris relativement à un effondrement prochain : l’inconnu. On ne peut se préparer qu’à un certain ordre de magnitude pour un certain contexte. Pour les autres cas, il vaut mieux en rire.

Je salue l’initiative cela dit.

  1. Connaître l’impact de nos trajets en avion
  2. Comparer plus justement les différentes options
  3. Penser le trajet comme un voyage
  4. Profiter au mieux du spectacle par la fenêtre
  5. Rester connecté pendant le voyage
  6. Explorer de nouvelles villes pendant les correspondances
  7. Profiter et se laisser inspirer par le voyage

Et si demain on ne prenait plus l’avion ? (cache)

En ce moment, je me sens surtout responsable de faire prendre l’avion aux autres pour venir me voir. Ce qui est à double tranchant.

Les dissonances de l’expatriation trans-atlantique.

Tout va dans le même sens : Les héri­tages béné­fi­cient prin­ci­pa­le­ment aux plus favo­ri­sés. On ne parle pas de soli­da­rité inter­gé­né­ra­tion­nelle mais de perpé­tua­tion de la richesse par droit de nais­sance.

Quelques chiffres sur l’héritage (cache)

Merci Éric de faire ce travail, chiffres à l’appui. Et concernant les taxes appliquées :

Alors 16 % pour quelqu’un qui reçoit magiquement de quoi être dans les plus riches sans rien avoir fait pour, comparé à la taxation du travail… moi je dis que c’est insignifiant.

Si ça avait du sens, je proposerais même d’inverser (plus taxer l’héritage, moins taxer le travail)

Commentaire sur « Quelques chiffres sur l’héritage » (cache)

Si seulement tout cela avait un sens. L’héritage financier est une vaste blague.

Citation de la semaine :

Quand le passé est pris pour un gouvernail, le navire marche à reculons.

L’apprenti sage, Gilles Vigneault

Je me rends compte que je n’écris plus en anglais ici et ça a changé ma façon de penser. Ou plutôt ma faculté à pouvoir communiquer mes pensées en anglais plus rapidement. Peut-être quelque chose à prendre en considération pour la suite.

2019-10-10

Twitter & les gaz lacrymogènes

Beaucoup de textes ont été écrits sur le rôle de l'Internet, et des réseaux sociaux centralisés, comme Facebook ou Twitter, dans des évènements politiques. Ce fut le cas, par exemple, du printemps arabe. L'auteure explore, dans ce livre très riche et très rigoureux, tous les aspects de cette relation entre les militants et les techniques d'information et de communication. Twitter peut-il battre les gaz lacrymogènes ?

(Le livre a été écrit en anglais, Zeynep Tufekci étant étatsunienne - d'origine turque. Il a été publié dans sa langue originale en 2017. Je l'ai lu dans la traduction française, tout à fait correcte, à part une certaine tendance à utiliser le mot anglais en français, comme traduire activist par activiste ou devastated par dévasté.)

Une grande partie des articles et messages écrits au sujet de l'utilisation de l'Internet par les militants des quatre coins du globe sont assez excessifs dans un sens ou dans l'autre. Soit on estime que l'Internet change tellement de choses qu'il ouvre une façon toute nouvelle de faire de la politique, et rend donc dépassées les méthodes traditionnelles, soit on se moque des « révolutions Twitter » et on affirme que le pouvoir se prend dans la rue, comme avant. La vérité est évidemment plus complexe : l'arrivée de l'Internet n'a pas supprimé les lois de la politique, les questions posées aux militants et aux révolutionnaires restent les mêmes, ainsi que les problèmes auxquels ils et elles font face. Mais l'Internet n'est pas non plus un épiphénomène : comme d'autres techniques avant lui (l'imprimerie est l'exemple canonique, d'ailleurs analysé de façon originale par l'auteure), l'Internet a changé les moyens dont les gens disposent, a créé de nouvelles affordances (là, je ne critiquerai pas la traduction : il n'y a pas de bon terme en français), c'est-à-dire de nouvelles potentialités, des encouragements à aller dans de nouvelles directions. Sur la question récurrente de la neutralité de la technique, Zeynep Tufekci cite à juste titre la citation classique de Melvin Kranzberg : « La technologie n'est ni bonne, ni mauvaise ; et n'est pas neutre non plus. »

Une des raisons pour lesquelles bien des discours sur les mouvements politiques utilisant l'Internet sont très unilatéraux est que beaucoup de leurs auteurs sont des férus de technique qui ne connaissent pas grand'chose à la politique, et qui découvrent comme s'ils étaient les premiers à militer, ou bien ils sont des connaisseurs de la politique, mais complètement ignorants de la technique, dont il font un tout, animé d'une volonté propre (les fameux « algorithmes »), et pas des outils que les gens vont utiliser. L'auteure, au contraire, informaticienne, puis chercheuse en sciences politiques, connait bien les deux aspects. Elle a étudié en profondeur de nombreux mouvements, les zapatistes au Mexique, Occupy Wall Street, l'occupation du parc Gezi, Black Lives Matter, les révolutions tunisienne et égyptienne, en étant souvent sur le terrain, à respirer les gaz lacrymogènes. (Les gilets jaunes n'y sont pas, bien que ce mouvement mériterait certainement d'être étudié dans son rapport à Facebook, mais le livre a été publié avant.) Et elle analyse le rôle de l'Internet, en chercheuse qui le connait bien, en voit les forces et les limites.

En contraste, elle étudie également le mouvement des droits civiques aux États-Unis. Voici un mouvement de très grande importance, qui a tout fait sans disposer de l'Internet. Alors qu'aujourd'hui, deux ou trois messages sur Facebook peuvent être le point de départ d'une manifestation très importante, et très rapidement prête, le mouvement des droits civiques a dû ramer pendant de nombreux mois pour, par exemple, organiser sa grande manifestation à Washington. L'auteure ne dit pas que c'était mieux à l'époque ou mieux aujourd'hui : elle insiste plutôt sur les permanences de l'action politique. Mais elle note aussi les différences : si l'organisation était bien plus laborieuse à l'époque (pas question de coordonner les aspects matériels avec une feuille de calcul mise en ligne et partagée), cela avait également des avantages. Les militants apprenaient à se connaitre, à se faire confiance, même des activités a priori sans intérêt politique, comme l'organisation pratique des voyages pour aller sur le lieu de la manifestation, avaient l'avantage de créer des liens, qui allaient permettre au mouvement de rester solide dans les tempêtes, face à la répression, et surtout face aux choix tactiques et stratégiques nécessaires lorsque la situation évolue.

Au contraire, l'Internet permet de se passer de cette organisation, au moins au début. Un individu seul peut se créer son blog et s'exprimer là où, auparavant, il aurait dû mendier un espace d'expression aux médias officiels, ou bien rejoindre un parti ou un mouvement critique, pour pouvoir faire relayer ses idées. C'est un énorme avantage et un des grands succès de l'Internet. Mais cela entraine de nouveaux risques, comme le fait qu'on n'a plus besoin de supporter les difficultés du travail collectif, ce qui peut rendre plus compliquée la traduction des idées en actions qui changent les choses.

Parmi les affordances de l'Internet, il y a le fait que beaucoup de choses sont possibles sans organisation formelle. Des mouvements très forts (comme celui du parc Gezi) ont été possibles sans qu'un parti traditionnel ne les structure et ne les dirige. Mais, bien sûr, cet avantage a aussi une face négative : puisque la nécessité d'une organisation n'est pas évidente, on peut se dire qu'on peut s'en passer. Au début, ça se passe effectivement bien, sans les lourdeurs bureaucratiques exaspérantes. Mais, ensuite, les problèmes surgissent : le pouvoir en place fait des ouvertures. Comment y répondre ? Ou bien il change de tactique, et le mouvement doit s'adapter. Et, là, l'absence d'un mécanisme de prise de décision commun se fait sentir, et beaucoup de mouvements s'affaiblissent alors, permettant à la répression de disperser ce qui reste. J'avais été frappé, sur les rond-points, par la fréquence du discours « ah non, surtout pas de partis, surtout pas de syndicats, surtout pas d'organisations et de porte-paroles », chez des gilets jaunes qui n'avaient sans doute pas étudié les théoriciens de l'anarchisme. Mais c'est que le débat est aussi ancien que la politique. L'Internet le met en évidence, en rendant possible des fonctionnements moins centralisés, mais il ne l'a pas créé.

Léger reproche à l'auteure : elle ne discute pas ce qui pourrait arriver avec d'autres outils que les gros réseaux centralisés étatsuniens comme Facebook ou Twitter. Il est vrai qu'on manque encore d'exemples détaillés à utiliser, il n'y a pas encore eu de révolution déclenchée sur le fédivers ou via Matrix.

Je n'ai donné qu'une idée très limitée de ce livre. Il est très riche, très nuancé, l'auteure a vraiment tenu à étudier tout en détail, et aucun résumé ne peut donc suffire. En conclusion, un livre que je recommande à toutes celles et tous ceux qui veulent changer le monde et se demandent comment faire. Il n'est ni optimiste, ni pessimiste sur le rôle de l'Internet dans les révolutions : « ni rire, ni pleurer, mais comprendre » (Spinoza, il semble).

Petit avertissement : j'ai reçu un exemplaire gratuit de ce livre.

2019-10-08

☕︎ Désespérance

J’aime le rythme des saisons, je me demande ce que cela fait de vivre proche de l’équateur. L’impression que chaque jour se répète inlassablement. Dans quelle mesure la saisonnalité encourage la prise de recul ?

Ernst Bloch avait identifié le « principe espérance » comme cette force dynamique qui fait avancer l’humanité en quête de progrès. Ce n’est alors pas sans raison, peut-être, que Bakhtine indiquait que les carnavals permettent l’expression des « espérances populaires ». Mais y a-t-il aussi, du côté des rebelles d’aujourd’hui, un « principe désespérance » qui pousse à agir même lorsque l’action paraît vaine, lorsque le rapport de force est si défavorablement asymétrique que la révolution est plus que jamais nécessaire, mais parait plus que jamais improbable, pour reprendre les mots du pamphlet L’insurrection qui vient, du Comité Invisible ?

[…]

Aujourd’hui, l’humanité est totalement étatisée, pour reprendre l’expression de Thomas Bernard. Résultat : une bonne partie des forces progressistes est incapable de penser l’« efficacité » politique autrement qu’en des termes étatiques : nombres de sièges au parlement, nouvelles politiques publiques, etc. Quant au capitalisme mondialisé, il s’insinue partout et ne se limite plus à l’exploitation du salariat, à la production de faux besoins et à l’intoxication de la vie intime. Il menace la vie sur terre, avec la complicité des gouvernements qui feignent de s’en émouvoir.

Devant pareille catastrophe, l’espérance n’est plus de mise, mais la désespérance n’est pas nécessairement synonyme d’apathie. D’où l’expression : la rage du désespoir. D’où l’expression, également, de « pessimisme combatif » […]

Les nouveaux anarchistes, Francis Dupuis-Déri

Pessimisme combatif. J’ai l’impression d’avoir le choix d’un peu trop de combats ces jours-ci.

Niveau pessimisme ça devrait aller.

Although I was intellectually quite well prepared for the birth of my first child, I was stunned by the degree of randomness that this event created in my life. It took me a while to understand that it was pointless to plan my days the way I used to. This did not mean that I didn’t plan or prearrange, but that I needed different schemes to deal with the unplannable.

Women in particular have developed such schemes over the centuries—arrangements that are not a surrender to randomness, but an allotment of time and resources based on situational judgements. … What makes them so different is that holistic strategies are, more often than not, intended to minimize disaster rather than to maximize gain. (80)

A crucial distinction here is the place of context. Attempts to minimize disaster require recognition and a profound understanding of context. Context is not considered as stable and invariant; on the contrary, every response induces a counter-response which changes the situation so that the next steps and decisions are taken within an altered context. Traditional planning, on the other hand, assumes a stable context and predictable responses. (81)

Production and growth (cache)

Je ne connaissais Ursula Franklin que de nom et elle a l’avantage d’avoir une page wikipedia bien détaillée. Merci Lucas ! (cache)

Limiter les dégâts plutôt que de gagner davantage que son prochain. Il y aurait un parallèle à faire autour de l’agilité et de ma génération de développeurs et développeuses qui est devenue parent.

Coïncidence ?

Ensuite que le travail de ces réseaux que l’on dit sociaux est avant tout de produire de la norme et de faire en sorte que ladite norme satisfasse au modèle économique de régie publicitaire qui est le leur. Et que tout le reste n’est que littérature.

Or, à l’échelle d’une société, il existe plein de manières différentes de produire de la norme, de fabriquer des référents légitimes et d’en rendre d’autres illégitimes. La manière dont les réseaux sociaux fonctionnent aujourd’hui dès lors qu’ils ont à traiter de questions liées aux corps et à leur représentation dans l’espace public qu’ils circonscrivent au sein de leurs audiences plus ou moins captives, cette manière repose sur des effets de stigmatisation et de désignation (body shaming) qui hystérisent la visibilité de certains traits. Mais elle repose également de manière bien plus insidieuse, sournoise et, hélas efficace, sur notre besoin d’identification et d’appartenance sociale qui nous rend dociles à des effets d’invisibilisation toujours plus prégnants.

Cheveux longs et algos courts. (cache)

Produire de la norme, c’était l’objectif de la religion avant d’être celui de l’État. Seule une homogénéité est contrôlable (aujourd’hui on dit « influençable »).

Fausses nouvelles, vraies vieilleries.

The above quote yields a glimpse into my position on the entire matter: stop focusing on the solution, and start focusing on the problem. You probably know more about your specific problem than the people behind your “found” solutions do. It’s a reasonable approach to give this knowledge precedence over the unknown data that influenced the design decisions of others.

Thinking vs Choosing (cache)

Devenir la nouvelle mode sans être radicalement différent. Prendre le risque de perdre l’utilisateur·ice ou de guider une nouvelle tendance. L’arête est escarpée.

Designer c’est douter.

Some years ago I contacted them because a flaw had been found in TLS encryption that might be dangerous for them, and to my surprise no one there cared. They had been assuming their Internet traffic was being spied upon anyhow, and it turns they were right.

Later they told me “we all use VPNs” and was impressed how privacy conscious they were. But no they told me, everyone does that, because without a VPN the internet here is too slow, they suspected the spying machinery was generally overloaded. The VPN was for speed. It was not assumed to deliver privacy, on which point they were also proven right (most VPN providers are pretty shady).

I mention these two stories to show that our assumptions on oppressive regimes may be wildly off, and not represent the reality on the ground in China, Russia, Iran, Indonesia and Turkey. It is a lot of fun being an armchair imaginary political activist, but things are remarkably different if you actually live there.

Centralised DoH is bad for privacy, in 2019 and beyond (cache)

Lorsque la réalité est fantasmée.

L’engagement c’est comme le thé : quand il est trop fort, le veilleur perd sommeil ; et quand il est trop faible, il s’endort.

L’apprenti sage II, Gilles Vigneault

J’aimerais parfois pouvoir m’arrêter de veiller. Est-ce qu’il suffit d’arrêter de boire du thé ?

La Nature n’est ni un allié, ni un ennemi… Je me protégerai du vent, de la pluie et de la neige et j’allumerai un feu pour me réchauffer. Je ne laisserai ni la peur, ni la panique conquérir mon esprit car là se trouve le véritable ennemi. — Mors Kochanski

Survie 101: Initiation au bushcraft et à la survie (cache)

J’ai participé à un atelier de (sur)vie en forêt. Avec des personnes qui ont une approche qui m’intéresse. Cela m’a permis de prendre conscience des connaissances/expériences accumulées dans le domaine. Peut-être qu’il serait temps que je tente de transmettre cela ? Je ne sais pas encore quelle forme est-ce que cela pourrait prendre. J’ai l’impression qu’il y a un intérêt croissant pour le domaine, un peu comme l’auto-défense fut un temps.

Emblématique des peurs d’une époque donnée.

If you have some power, then your job is to empower somebody else.

Toni Morrison cité dans « The Weight of the WWWorld is Up to Us by Patty Toland » (cache)

In June 2014, Apple announced that development of Aperture has been discontinued. Since then, Apple has released six major macOS upgrades. For technical reasons, macOS Mojave is the last version of macOS to run Aperture. Starting with macOS Catalina, Aperture is no longer compatible with macOS.

Migrate Aperture libraries to the Photos app or Adobe Lightroom Classic (cache)

Apple m’indique qu’Aperture ne se lancera même plus à la prochaine version de macOS. Je procrastine depuis cinq ans sur le sujet sans trouver d’alternative valable (et je voulais bien sûr faire un tri avant…). Quand je vois les bugs de iCloud + Photos.app par ailleurs je ne peux considérer cette option comme étant (v|f)iable. J’hésite à tout exporter en jpeg dans un coin en attendant mieux, c’est peut-être le format qui sera le plus longtemps supporté.

Il y a déjà deux autres outils que j’utilise qui mentionnent une migration potentiellement difficile. Plus grande sera la friction, plus motivé je serai à aller voir ailleurs.

Ravi.

Version 12 d'Unicode

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.)

2019-10-07

Une histoire populaire de la France

Excellent (vraiment excellent) livre d'histoire de la France, vu sous un angle différent de l'habituel : moins de rois et de princes, et d'avantage de gens du peuple.

Le titre fait référence à un livre très connu d'histoire des États-Unis. L'idée de départ est la même : les livres d'histoire traditionnels privilégient les gens importants, les « premiers de cordée », comme dirait Macron, et oublient les « 99 % ». On voit ainsi des historiens écrire sans sourciller que « Louis XIV a construit le château de Versailles », sans tenir compte des ouvriers.

Si les historiens tendent à privilégier ces « gens d'en haut », ça n'est pas forcément par conviction politique aristocratique, ou par mépris du peuple. C'est aussi parce que c'est plus facile. On dispose de tas de textes sur Louis XIV, de sa main, de celle de ses courtisans, de celle de ses ennemis, tout est bien documenté. Les nobles et les bourgeois de l'époque ont aussi parlé de leur classe sociale respective. Mais que sait-on des travailleurs de base ? Ils ne savaient en général pas écrire et, même quand c'était le cas, leurs textes ont rarement été gardés. On a des traces matérielles, mais peu de choses sur ce qu'ils ressentaient, leurs opinions, la vie quotidienne.

Et l'auteur ne résout pas complètement ce problème : il reconnait dès le début que l'historien manque de matériaux sur lesquels s'appuyer pour une histoire des classes populaires. Son livre est donc plutôt une histoire de France, en gardant sans cesse comme perspective que la France ne se limitait pas au roi et à la cour.

Le plan est classique, chronologique, de la guerre de Cent Ans à nos jours, soit 800 pages bien tassées. La question des débuts de la France est étudiée en détail ; à partir de quand les gens se disaient-ils français ? L'histoire traditionnelle est souvent anachronique, en qualifiant par exemple Jeanne d'Arc de patriote française, notion qui lui était bien étrangère. Les questions religieuses occupent ensuite beaucoup de place : au Moyen-Âge, tout conflit interne était présenté comme religieux, même quand ses causes profondes étaient politiques. L'auteur explique d'ailleurs que les guerres de religion ne méritaient que partiellement leur nom, et qu'elles avaient des racines qui n'étaient pas toujours religieuses.

L'esclavage et le colonialisme sont largement traités. Ils sont parfois absents des « histoires de la France », soit parce que ce n'était pas très glorieux, soit parce que les pays qui en furent victimes n'étaient pas la France. Ici, au contraire, ces questions sont vues en détail. Ces peuples n'avaient pas voulu faire partie de l'histoire de France, mais ils en sont devenus une composante importante. Comme l'accent du livre est mis sur le peuple, pas seulement comme sujet mais aussi comme acteur, les révoltes d'esclaves et les luttes anti-colonialistes jouent un rôle important.

Comme le peuple s'obstine à ne pas comprendre que les dirigeants veulent son bien, et qu'il se révolte de temps en temps, et de diverses manières, l'État développe ses moyens de contrôle. Noiriel explique ainsi le développement successif de la notion d'identité (comme dans « carte d'identité »), et le contrôle qu'elle permet.

La révolution industrielle fait franchir une nouvelle étape à ces processus, avec la création du prolétariat de masse, et la prise de conscience qui a suivi, permettant les nombreuses révoltes du 19e siècle. Mais l'articulation entre l'appartenance de classe et les opinions politiques est restée compliquée. Le parti communiste, par exemple, n'a jamais hésité à jouer la carte de la culpabilisation, écartant toutes les critiques de sa politique d'un « nous sommes un parti ouvrier, donc nous avons forcément raison ». Lorsque l'opposant était en effet né dans une famille bourgeoise, l'argument avait du poids. Comme le note Noiriel, « la culpabilité est mauvaise conseillère ». (Et elle continue à l'être.)

Par la suite, les changements dans l'organisation de la société, et une offensive idéologique importante, ont remis en cause cette conscience de classe. Aujourd'hui, l'idéologie dominante est identitaire et racialiste, faisant croire au prolétaire que sa nationalité, sa couleur de peau ou sa religion sont les choses importantes, niant les classes sociales. Cette méthode est efficace pour limiter le risque de révolte contre les dominants. Mais l'histoire n'est jamais terminée et les choses vont continuer à changer, peut-être en mieux, peut-être pas.

Je recommande fortement la lecture de ce livre, si vous voulez une histoire de France très complète, très documentée, et qui ne cherche pas à faire des raccourcis au milieu des chemins souvent complexes que cette histoire a empruntés.

2019-10-01

☕︎ Présent

Être moins soucieux pour l’avenir en ayant des actions au présent. S’occuper, se résigner, suivre le flux présent en croyant à une certaine conscience collective. Fermer les yeux.

Il y a une grosse insistance dans le livre sur l’anarchisme que je lis à vivre cette révolte au présent à travers le « socialisme utopique » (en opposition au « socialisme scientifique » issu du marxisme qui aspire à de meilleurs lendemains). Je n’avais pas envisagé cela sous cet angle auparavant.

Or les expériences temporaires nous encouragent aussi à (re)penser notre rapport au politique et au temps.

E. Armand (Milieux de vie en commun et colonies) minimisait au début du XXe siècle l’importance de s’inscrire dans la longue durée. Selon l’expérience des colonies libertaires, la durée est en fait « un signe infaillible d’amollissement et de relâchement ». Il faut d’ailleurs se demander ce que signifierait une expérience anarchiste se coagulant dans la durée : quelle liberté resterait à ceux et celles y participant, qui ne feraient que répéter et mimer des pratiques définies par d’autres et depuis longtemps stabilisées ?

[…]

Ces expériences temporaires temporaires restent significatives pour qui y participent. Pourquoi évaluer uniquement la pertinence politique d’une action à sa capacité à faire advenir plus rapidement une Révolution ? Pourquoi tout de suite se demander comment gérer l’avenir ? L’autogestion se vit au quotidien, et se conjugue donc toujours au présent.

Les nouveaux anarchistes, Francis Dupuis-Déri

Je suis finalement allé faire acte de présence auprès de 500 000 autres personnes à Montréal. Une collection d’individus anxieux qui s’extériorisent (littéralement). Je n’ai jamais aussi peu vu de policiers à une manifestation. C’est peut-être ce qui m’a le plus impressionné.

Cela représente un·e montréalais·e sur quatre.

Les tribus de la Zomia, incroyablement hétérogènes, ont multiplié les stratégies pour contourner l’État et échapper à son pouvoir. Tout ce qui, de manière classique, est mis sur le compte de la barbarie, d’une incapacité à rejoindre la civilisation – définie par la sédentarité, l’écriture, la distinction entre État et société, la fixité des identités, etc. –, découle pour Scott de choix conscients et délibérés des peuples des collines pour éviter l’État, à défaut de pouvoir le défier ou le renverser. […]

La première de ces stratégies repose sur l’adoption d’un mode de vie itinérant. Pour Scott, la culture sur brûlis et la cueillette n’ont rien d’archaïques mais procèdent d’une volonté d’opposer la mobilité à tous les efforts que l’État déploie pour borner les propriétés, les privatiser et les consigner dans les registres du cadastre. Que peut prélever le fisc si l’agriculture n’est pas concentrée ? […]

Plus fondamentalement, Scott considère que l’absence d’écriture, traditionnellement associée à une incapacité à entrer dans l’histoire, est en fait un choix volontaire des tribus, qui privilégient la culture orale par opposition aux logiques scripturales de l’État. […] Sans écriture, les montagnards sont aussi sans histoire, ce qui les préserverait du fléau de l’identité et de la fixité.

Zomia, là où l’État n’est pas (cache)

J’aime beaucoup le parallèle avec les riches actuels qui font transiter leur argent de paradis fiscaux en paradis fiscaux en tentant d’effacer des lignes d’écriture comptable.

Pendant des siècles, les faibles si bien étudiés par Scott ont résisté par les vertus du nomadisme, de la fluidité et du jeu avec les identités. Ne sont-ce pas là les armes modernes qu’utilisent les plus puissants pour échapper aujourd’hui aux contraintes de la souveraineté ou aux exigences de la solidarité ?

Ibid.

Là où seule la distance géographique (temporelle) permettait d’échapper à l’État, c’est dorénavant une distance pécuniaire qui autorise à s’y soustraire.

Les riches sont-ils les nouveaux rebelles ? ©LePoint

notre communauté ne veut pas la révolution ; elle est la révolution. Mais elle a surmonté le vieux sens négatif de la révolution ; pour nous la révolution, ce n’est pas renverser de vieilles choses, c’est vivre de nouvelles choses. Ce n’est pas l’esprit de destruction qui nous anime, mais un enthousiasme créateur. Ce qui fait le caractère de notre révolution, c’est que, en petit groupe, dans une pure communauté, nous faisons naître une vie nouvelle.

Communauté, Martin Buber

Peut-être que je me sens prêt à aller vers un regroupement plus communautaire malgré mon aversion pour certaines relations sociales. Tenter de créer de nouvelles choses, un peu à la marge et enthousiasmantes.

Et accepter mon prochain ?

L’obéissance, au sens biblique, est l’épitomé d’audire, « entendre ». Il s’agit d’une écoute que rien ne contrarie, d’une disposition inconditionnelle à entendre, d’une inclination sans mélange à se laisser surprendre. Elle n’a rien à voir avec ce que l’on appelle l’obéissance aujourd’hui, quelque chose qui implique toujours la soumission et connote vaguement notre rapport avec nos chiens. Quand je me soumets, mon cœur, mon esprit et mon corps passent au-dessous de l’autre.

Quand mon écoute est inconditionnelle, respectueuse, courageuse, quand je suis disposé à recevoir autrui comme une surprise radicale, je fais autre chose. Je m’incline, je me penche vers l’altérité radicale de quelqu’un. Je renonce à chercher des ponts entre l’autre et moi-même, reconnaissant le gouffre qui nous sépare. Paradoxalement, pourtant, renonçant à un lien, j’amorce entre nous une relation libre pour laquelle nous ne disposons que d’un mot malmené, le « prochain ».

Me penchant au-dessus de cette béance, je prends conscience de la profondeur de ma solitude ; mais je puis la supporter à la lumière de la ressemblance substantielle entre l’autre et moi. La seule chose qui m’atteigne, c’est l’autre dans sa parole, que j’accepte en confiance. Par la force de cette parole, je puis être maintenant assez confiant pour marcher en surface sans être englouti par la puissance institutionnelle. […]

Cette espèce de confiance docile est la substance de l’Évangile ; le pouvoir institutionnel d’enseigner en est l’antipode. La docilité est une réponse aimante à l’incarnation d’une parole aimante. Ce que nous appelons aujourd’hui les systèmes éducatifs, c’est la matérialisation de l’ennemi, du pouvoir. Son rejet du pouvoir — en Grec, son an-archie — trouble le monde du pouvoir parce que Jésus se soumet totalement à lui sans jamais y prendre part. Sa soumission même est d’amour. C’est une relation d’un nouveau genre […]

La perte des sens, Ivan Illich

La lecture d’Ivan Illich me donne à nouveau envie de m’intéresser à la religion. Je repense à nos échanges sur le sujet avec Aurélien. J’aimerais prendre le temps d’en discuter avec Stéphane.

Un bon moment pour remettre un peu de sel dans ma vie.

Thomas rebondit (cache).

Sans compter que… ce n’est pas sain ! On le sait, c’est hyper pratique de pouvoir dire « tu veux une alternative, va voir les Framachins ! ». C’est rassurant d’avoir tout dans un même endroit, sous un même nom… On le sait, et c’est même pour cela qu’on a utilisé cette technique de la marque « frama », qui pourtant, n’est vraiment pas notre tasse de thé.

Mais centraliser des trucs sur Internet, ce n’est pas une bonne idée : non seulement ce réseau n’a pas été pensé pour créer des points de centralisation, mais surtout c’est en mettant toutes nos données dans le même panier que l’on concentre les pouvoirs entre les mains des personnes qui gèrent les serveurs, et c’est sur cette pente glissante que se sont créés des géants du web tels que Google ou Facebook.

Il faut donc nous déframasoftiser.

Déframasoftisons Internet ! (cache)

Saine décision. Framasoft nous a montré que ces services étaient utiles et utilisables. À nous de prendre le relais en ajoutant de la diversité et de la décentralisation.

J’utilise Framagit et Framaboard au quotidien. Merci de m’avoir prêté vos machines.

To decarbonize, we need to decomputerize.

This proposal will no doubt be met with charges of Luddism. Good: Luddism is a label to embrace. The Luddites were heroic figures and acute technological thinkers. They smashed textile machinery in 19th-century England because they had the capacity to perceive technology “in the present tense”, in the words of the historian David F Noble. They didn’t wait patiently for the glorious future promised by the gospel of progress. They saw what certain machines were doing to them in the present tense – endangering their livelihoods – and dismantled them.

To decarbonize we must decomputerize: why we need a Luddite revolution (cache)

Ce n’est pas la première fois que je vois passer une ode au Luddites. Ou du moins que cette approche m’attire, celle de prendre conscience de ce que la technique quotidienne implique.

Il faudrait que je creuse un peu ce sujet.

Citation de la semaine :

Respecter, c’est regarder une deuxième fois. Avec plus d’intérêt que la première.

L’apprenti sage II, Gilles Vigneault

Pas mal de lectures hors écrans cette semaine. Les effets à moyen terme d’un arrêt de lecture de timelines commencent à se faire ressentir. Pas pire.

2019-09-30

IPv6 sur un VPS Arch Linux chez OVH

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.

Documentation technique de mon résolveur DoH

Cet article documente le fonctionnement interne du résolveur DoH https://doh.bortzmeyer.fr/ et du résolveur DoT dot.bortzmeyer.fr. Il concerne donc essentiellement les technicien·ne·s. Si vous vous intéressez plutôt aux conditions d'utilisation de ce service, voyez l'article décrivant la politique.

Pour comprendre les protocoles DoH et DoT, il faut relire les normes qui les décrivent, respectivement les RFC 8484 et RFC 7858.

C'est le même résolveur qui gère les deux protocoles. Si une version initiale de ce résolveur DoH utilisait une mise en œuvre en Python que j'avais écrite lors d'un hackathon de l'IETF, la version « de production » se sert de l'excellent logiciel dnsdist. dnsdist est un frontal pour serveurs DNS, assurant des fonctions telles que la répartition de charge et, ce qui nous intéresse surtout ici, le relais entre différents protocoles. Ici, dnsdist a été configuré pour accepter des connexions DoH et DoT (mais pas le traditionnel DNS sur UDP, ni sur TCP en clair, d'ailleurs) et pour relayer les requêtes DNS vers le « vrai » résolveur.

La machine est une Arch Linux tournant chez OVH, sur l'offre nommée « VPS ».

La configuration de dnsdist se trouve dans un fichier de configuration, dnsdist.conf. N'hésitez pas à consulter la documentation très complète de dnsdist. Voyons les points essentiels.

On fait du DoH donc on lance un service DoH, en IPv4 et en IPv6 :

    
addDOHLocal("0.0.0.0:443", "/etc/dnsdist/server-doh.pem", "/etc/dnsdist/server-doh.key", "/", {minTLSVersion="tls1.2", customResponseHeaders={["link"]="<https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html> rel=\"service-meta\"; type=\"text/html\""}}) 
addDOHLocal("[::]:443", "/etc/dnsdist/server-doh.pem", "/etc/dnsdist/server-doh.key", "/", {minTLSVersion="tls1.2", customResponseHeaders={["link"]="<https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html> rel=\"service-meta\"; type=\"text/html\""}})

  
Pour améliorer un peu la sécurité, on exige du TLS 1.2 au minimum. Notez qu'il y aurait plein d'autres paramètres à configurer (refuser des algorithmes trop faibles), pour avoir une meilleure note sur SSLlabs. Et les trucs bizarres qui commencent par customResponseHeaders ? Il s'agit d'utiliser la technique du RFC 8631 pour indiquer des méta-informations sur le service, ici, la politique suivie. Cela donne :

% curl -v https://doh.bortzmeyer.fr/help
...
< HTTP/2 200 
< server: h2o/dnsdist
< link: <https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html> rel="service-meta"; type="text/html"
< content-length: 86
< 

  
Pour avoir des URL « spéciaux » ne faisant pas du DoH, on ajoute aussi :

supportpagemap = { newDOHResponseMapEntry("^/rfc$", 307, "https://www.rfc-editor.org/info/rfc8484"),
                   newDOHResponseMapEntry("^/about$", 307, "https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html"),
                   newDOHResponseMapEntry("^/policy$", 307, "https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html"),
		   newDOHResponseMapEntry("^/help$", 200, "For the server policy, see <https://www.bortzmeyer.org/doh-bortzmeyer-fr-policy.html>.") }
dohFE = getDOHFrontend(0)
dohFE:setResponsesMap(supportpagemap)
dohFE6 = getDOHFrontend(1)
dohFE6:setResponsesMap(supportpagemap)

Ces instructions disent à dnsdist de rediriger /policy vers l'article décrivant la politique, et d'afficher un court message pour /help.

Et on veut faire du DoT, pas seulement du DoH, donc on met aussi :

addTLSLocal("0.0.0.0:853", "/etc/dnsdist/server-dot.pem", "/etc/dnsdist/server-dot.key", {minTLSVersion="tls1.2"})
addTLSLocal("[::]:853", "/etc/dnsdist/server-dot.pem", "/etc/dnsdist/server-dot.key", {minTLSVersion="tls1.2"})

Le résolveur est public, donc les ACL autorisent tout le monde :

addACL('0.0.0.0/0')
addACL('[::]/0')
  
Mais on se méfie quand même des clients trop enthousiastes donc on les limite à cent requêtes par seconde :
addAction(MaxQPSIPRule(100), DropAction()) 
  
Au passage, il faut dire un mot de addAction car il sert souvent. dnsdist permet de définir des politiques à appliquer lors du traitement d'une requête DNS (la documentation dit « paquet », mais, apparemment, il s'agit bien d'une requête). La syntaxe générale (cf. la documentation) est addAction(critère, action) avec de nombreux critères possibles (ici, « a fait plus de 100 r/s ») et plein d'actions disponibles (ici, ignorer la requête).

dnsdist est un répartiteur de charge, il n'est pas un résolveur DNS. Il faut donc un ou plusieurs « vrais » résolveurs derrière. Le principal résolveur, pour le service https://doh.bortzmeyer.fr, est un Unbound qui tourne sur la même machine. Au cas où quelque chose irait mal, un second résolveur, complètement indépendant, est fourni par OVH. dnsdist permet de choisir quel résolveur utiliser et j'ai mis :

  
setServerPolicy(firstAvailable)
newServer({address="127.0.0.1:53", name="Local-Unbound"})	
newServer({address="213.186.33.99:53", name="OVH"})
Pourquoi firstAvailable ? Parce que je voulais éviter autant que possible d'envoyer des requêtes à ce second résolveur que je ne contrôle pas et dont je ne connais pas la politique en matière de vie privée. Comme voulu, la quasi-totalité des requêtes arrivent donc au premier résolveur :
> showServers()
#   Name                 Address                       State     Qps    Qlim Ord Wt    Queries   Drops Drate   Lat Outstanding Pools
0   Local-Unbound        127.0.0.1:53                     up     0.0       0   1  1       2509       0   0.0  70.4           0 
1   OVH                  213.186.33.99:53                 up     0.0       0   1  1          0       0   0.0   0.0           0 
All                                                              0.0                      2509       0                         
  

Pour pouvoir utiliser la console de dnsdist, comme ci-dessus, il faut l'activer dans le fichier de configuration :

controlSocket('[::1]:5199')
setKey("kg...=")
  
(La documentation explique quelle valeur indiquer à setKey().) L'accès à la console se fait ensuite avec dnsdist -c :
%  dnsdist -c
> dumpStats()
acl-drops              	          0    latency0-1             	       5058
cache-hits             	       4429    latency1-10            	        351
cache-misses           	       2571    latency10-50           	        785
cpu-sys-msec           	      12929    latency100-1000        	        388
cpu-user-msec          	      47305    latency50-100          	        280
...
 

dnsdist dispose également d'un serveur Web minimal, permettant de regarder l'état du service (ce n'est pas un site Web d'administration, c'est juste pour jeter un coup d'œil). Voici une configuration typique :

webserver("[::1]:8082", "2e...", "a5..")
 
Les deux derniers paramètres indiquent le mot de passe à utiliser pour les accès au site Web et la clé pour l'API. Ici, le serveur n'écoute que sur une adresse locale. Si vous voulez le rendre accessible de l'extérieur, comme il ne gère pas HTTPS, il vaut mieux le mettre derrière un relais. J'ai utilisé stunnel, avec cette configuration :
[dnsdist]
accept  = 8083
connect = localhost-ipv6:8082
cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.key
 
Cela me permet de regarder de l'extérieur :

Et pour l'API de ce serveur interne, qui renvoie des résultats en JSON :

% curl -s --header "X-API-Key: XXXX" https://doh.bortzmeyer.fr:8083/api/v1/servers/localhost/statistics | jq .
[
  {
    "name": "responses",
    "type": "StatisticItem",
    "value": 2643
  },
  {
    "name": "queries",
    "type": "StatisticItem",
    "value": 3698
  },
...
   

Il y a aussi quelques paramètres liés aux performances du serveur. Celui-ci active la mémoire de dnsdist, qui gardera au maximum 100 000 enregistrements DNS :

  
pc = newPacketCache(100000)
getPool(""):setCache(pc)			
Pour l'instant, cette valeur est énorme pour ce modeste serveur. Dans la console :
> getPool(""):getCache():printStats()
Entries: 84/100000
Hits: 1127
Misses: 2943
...
Cette mémoire explique pourquoi, plus haut, le serveur indiquait davantage de requêtes que de réponses (il ne compte comme réponse que ce qui a été traité par les vrais résolveurs). Autres réglages, portant sur le réseau, qu'il me reste à ajuster dès que le serveur recevra du trafic abondant :
setMaxUDPOutstanding(65535)     -- Nombre maximum de requêtes en attente pour un résolveur
setMaxTCPClientThreads(30) 	-- Nombre maximum de fils d'exécution TCP (chacun pouvant traiter plusieurs clients)
setMaxTCPConnectionDuration(1800) -- Après trente minutes, on raccroche
setMaxTCPQueriesPerConnection(300) -- Après trois cents requêtes, on raccroche 
setMaxTCPConnectionsPerClient(10) -- Dix connexions pour un seul client, c'est déjà beaucoup, mais il faut penser à des choses comme le CG-NAT
  

dnsdist permet d'enregistrer chaque requête DNS, par exemple dans un fichier. Cette fonction n'est pas activée sur https://doh.bortzmeyer.fr car elle serait contraire aux promesses faites quant au respect de la vie privée. Mais c'est un bon exemple d'utilisation de addAction pour toutes les requêtes (AllRule) :

-- addAction(AllRule(), LogAction("/tmp/dnsdist.log", false, true, false))
(Attention si vous utilisez systemd, avec l'option PrivateTmp=true, le fichier journal sera mis quelque part sous /tmp/systemd-private-XXXXXXX-dnsdist.service-Ijy8yw, pour être plus difficile à trouver.) Les lignes journalisées sont du genre :
Packet from [2001:db8::a36b::64]:44364 for www.ietf.org. AAAA with id 8283
Pour la même raison de vie privée, je n'utilise pas la TeeAction (qui permet de copier les requêtes ailleurs) ou dnstap.

De même qu'on ne journalise pas, on ne ment pas. dnsdist peut le faire via SpoofAction() ou bien avec un script Lua spécifique, pour faire des choses horribles comme bloquer un type de données particulier :

luarule(dq) if (dq.qtype==dnsdist.NAPTR) then return DNSAction.Nxdomain, "" else return DNSAction.Allow, "" end end
addLuaAction(AllRule(), luarule)
  

DoH et DoT fonctionnent tous les deux sur TLS (RFC 8446) et utilisent donc son mécanisme d'authentification via des certificats PKIX (RFC 5280). Il faut donc obtenir des certificats raisonnablement reconnus par les clients donc, comme tout le monde, j'ai utilisé Let's Encrypt. dnsdist n'inclut pas de client ACME (RFC 8555), j'ai donc utilisé certbot que je fais tourner en mode autonome (standalone). Cela marche car dnsdist n'écoute que sur le port 443 alors qu'ACME n'utilise que le 80. Pour créer le certificat initial :

certbot certonly -n --standalone --domain doh.bortzmeyer.fr
  
Et pour le renouveler :
certbot renew --standalone --reuse-key --deploy-hook /usr/local/sbin/restart-dnsdist
  
(restart-dnsdist contient dnsdist -e 'reloadAllCertificates()'.) Et voici les liens symboliques configurés pour pointer vers les répertoires utilisés par Let's Encrypt :
% ls -lt                                                                        
total 28
lrwxrwxrwx  1 root root   51 Sep 24 15:50 server-dot.key -> /etc/letsencrypt/live/dot.bortzmeyer.fr/privkey.pem
lrwxrwxrwx  1 root root   53 Sep 24 15:50 server-dot.pem -> /etc/letsencrypt/live/dot.bortzmeyer.fr/fullchain.pem
lrwxrwxrwx  1 root root   51 Sep 15 16:31 server-doh.key -> /etc/letsencrypt/live/doh.bortzmeyer.fr/privkey.pem
lrwxrwxrwx  1 root root   53 Sep 15 16:31 server-doh.pem -> /etc/letsencrypt/live/doh.bortzmeyer.fr/fullchain.pem
...
  
Avec gnutls-cli, on peut voir le certificat utilisé :
% gnutls-cli dot.bortzmeyer.fr:853
...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=dot.bortzmeyer.fr', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x047aa99cbff8ac180c4c3b14935d9599b1f5, RSA key 2048 bits, signed using RSA-SHA256, activated `2019-09-24 12:46:32 UTC', expires `2019-12-23 12:46:32 UTC', key-ID `sha256:787005b3173d1c95bc425241ea40e5474b644f00fded7fd35d87350331644c56'
	Public Key ID:
		sha1:696c94f0f093a3b1037ffcb2fcd9d23859d539bc
		sha256:787005b3173d1c95bc425241ea40e5474b644f00fded7fd35d87350331644c56
	Public key's random art:
		+--[ RSA 2048]----+
		|      o          |
		|       = o       |
		|    . . O     ...|
		|     o B +    .+.|
		|      = S    .  o|
		|       = .  .  E |
		|        . .=     |
		|       . o=o.    |
		|        o.oo.    |
		+-----------------+

- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', key-ID `sha256:60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18'
- Status: The certificate is trusted. 
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-GCM)
...
  
Pour pouvoir authentifier le serveur par d'autres moyens que la chaîne de confiance PKIX (par exemple par épinglage de la clé, ou par DANE), je demande à certbot de ne pas changer la clé lors des renouvellements de certificats, avec l'option --reuse-key (cf. mon précédent article sur la question).

À propos de DANE (RFC 6698), j'ai créé les enregistrements nécessaires avec hash-slinger :

% tlsa --create --selector 1  --port 853 dot.bortzmeyer.fr
Got a certificate with Subject: /CN=dot.bortzmeyer.fr
_853._tcp.dot.bortzmeyer.fr. IN TLSA 3 1 1 787005b3173d1c95bc425241ea40e5474b644f00fded7fd35d87350331644c56
  
Puis je les mets dans le fichier de zone DNS, et on peut voir les enregistrements avec dig :
    
% dig TLSA _853._tcp.dot.bortzmeyer.fr
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15141
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 11
...
;; ANSWER SECTION:
_853._tcp.dot.bortzmeyer.fr. 86400 IN TLSA 3 1 1 (
				787005B3173D1C95BC425241EA40E5474B644F00FDED

  
Et on peut les vérifier :
  
% tlsa --verify --resolvconf="" doh.bortzmeyer.fr
SUCCESS (Usage 3 [DANE-EE]): Certificate offered by the server matches the TLSA record (193.70.85.11)
SUCCESS (Usage 3 [DANE-EE]): Certificate offered by the server matches the TLSA record (2001:41d0:302:2200::180)
Et superviser le tout depuis Icinga.

On a vu qu'il y avait deux résolveurs DNS derrière dnsdist, le principal, géré par moi, et un résolveur de secours. Le résolveur principal utilise Unbound. Pour mieux protéger la vie privée, il utilise la QNAME minimisation du RFC 7816. Dans le unbound.conf, on a  :

server:
  qname-minimisation: yes
  
Vous pouvez vérifier que c'est bien activé avec le domaine de test qnamemintest.internet.nl et l'outil test-doh présenté plus loin :
% test-doh https://doh.bortzmeyer.fr qnamemintest.internet.nl TXT
...
a.b.qnamemin-test.internet.nl. 10 IN TXT "HOORAY - QNAME minimisation is enabled on your resolver :)!"
  
Alors qu'avec un autre résolveur DoH, moins soucieux de vie privée :
% test-doh https://dns.google/dns-query qnamemintest.internet.nl TXT   
...
a.b.qnamemin-test.internet.nl. 9 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :("
  
J'ai aussi mis quelques autres paramètres Unbound, typiquement pour durcir la résolution face à diverses menaces :
  harden-glue: yes
  harden-below-nxdomain: yes
  harden-dnssec-stripped: yes
  harden-referral-path: yes
  aggressive-nsec: yes
  

Avec tout ça, je crois ne pas avoir dit comment j'avais installé dnsdist. Comme il n'existe pas de paquetage dnsdist dans Arch Linux (mais il existe dans AUR), j'ai téléchargé le source et compilé moi-même, selon les instructions. D'abord, j'ai téléchargé et installé la bibliothèque libh2o, qui permet à dnsdist de parler HTTP/2 (RFC 7540) :

cmake .
make
make install
  
Puis on peut installer dnsdist :
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig  ./configure --enable-dns-over-tls --enable-dns-over-https
make
make install
  

Testons maintenant, d'abord avec kdig (qui fait partie de Knot, et notez la première ligne de la réponse) :

    
% kdig  +tls @dot.bortzmeyer.fr nextinpact.com
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 56403
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; nextinpact.com.     		IN	A

;; ANSWER SECTION:
nextinpact.com.     	118	IN	A	45.60.122.203
nextinpact.com.     	118	IN	A	45.60.132.203

;; Received 75 B
;; Time 2019-10-03 17:34:29 CEST
;; From 2001:41d0:302:2200::180@853(TCP) in 14.1 ms
  
Puis grâce aux sondes RIPE Atlas, le service. Les Atlas savent faire du DoT. Voyons d'abord en IPv6 (le choix par défaut) :
%  blaeu-resolve --dnssec --displayvalidation --displayrtt --tls --nameserver=dot.bortzmeyer.fr --nsid --sort --requested=1000   cyberstructure.fr  
Nameserver dot.bortzmeyer.fr
[ (Authentic Data flag)  2001:4b98:dc0:41:216:3eff:fe27:3d3f] : 956 occurrences Average RTT 1572 ms
[TIMEOUT] : 17 occurrences Average RTT 0 ms
[TUCONNECT (may be a TLS negotiation error)] : 14 occurrences Average RTT 0 ms
Test #22928943 done at 2019-09-30T09:37:15Z
  
Il y a quand même trop d'échecs. Ceci dit, il s'agit parfois de problèmes réseau et pas de problèmes DoT. Essayons ICMP Echo avec les mêmes sondes :
  
% blaeu-reach --old_measurement=22928943 --by_probe 2001:41d0:302:2200::180

493 probes reported
Test #22929082 done at 2019-09-30T09:48:25Z
Tests: 487 successful probes (98.8 %), 6 failed (1.2 %), average RTT: 72 ms
Donc, au moins une partie des problèmes n'est pas spécifique à DoT. Pour les autres cas d'échec, on peut aussi imaginer que certains réseaux ne laissent pas sortir les communications vers le port 853, qu'utilise DoT (c'est d'ailleurs une des principales raisons qui a motivé le développement de DoH qui, utilisant HTTPS, est plus difficile à bloquer). En attendant, essayons en IPv4 :
%  blaeu-resolve --dnssec --displayvalidation --displayrtt --tls --nameserver=dot.bortzmeyer.fr --nsid --sort --requested=1000  -4 cyberstructure.fr  
Nameserver dot.bortzmeyer.fr
[ (Authentic Data flag)  2001:4b98:dc0:41:216:3eff:fe27:3d3f] : 971 occurrences Average RTT 975 ms
[TIMEOUT] : 9 occurrences Average RTT 0 ms
[TUCONNECT (may be a TLS negotiation error)] : 6 occurrences Average RTT 0 ms
Test #22929087 done at 2019-09-30T09:51:59Z

% blaeu-reach --old_measurement=22929087  --by_probe  193.70.85.11
494 probes reported
Test #22929254 done at 2019-09-30T11:35:16Z
Tests: 494 successful probes (100.0 %), 0 failed (0.0 %), average RTT: 78 ms
  
C'est clair, on a moins d'erreurs. L'Internet est hélas moins fiable en IPv6 (surtout vu les difficultés de configuration d'IPv6 chez OVH).

J'ai utilisé plus haut le script test-doh pour tester le serveur. Ce script est écrit en Python et disponible en test-doh.py. Exemple d'utilisation :

% test-doh https://doh.bortzmeyer.fr netflix.com AAAA
id 0
opcode QUERY
rcode NOERROR
flags QR RD RA
;QUESTION
netflix.com. IN AAAA
;ANSWER
netflix.com. 60 IN AAAA 2a01:578:3::3431:7806
netflix.com. 60 IN AAAA 2a01:578:3::22fd:6807
netflix.com. 60 IN AAAA 2a01:578:3::36e5:444d
...
;AUTHORITY
;ADDITIONAL
  
On peut aussi utiliser doh-client.sh, qui appelle curl, et utilise deux programmes Python, dns-t2b.py et dns-b2t.py pour créer les messages DNS en entrée et les lire à la sortie (DoH n'utilise pas JSON ou XML, mais le format binaire du DNS.)

Le service est supervisé par Icinga. Pour DoT, je me sers d'un programme développé lors d'un hackathon IETF. (Il y a depuis une version plus propre dans getdns, le programme dans le paquetage Debian getdns-utils se nomme getdns_server_mon.) Lancé à la main, il donne :

 % /usr/local/lib/nagios/plugins/check_dns_with_getdns -H 2001:41d0:302:2200::180 -n nextinpact.com
GETDNS OK - 16 ms, expiration date 2019-12-23, auth. None:  Address 45.60.132.203 Address 45.60.122.203
  
Pour DoH, certains des tests sont les tests génériques des monitoring plugins, par exemple le test de l'expiration du certificat (pour ne pas être surpris si les renouvellements Let's Encrypt se sont mal passés). Cela se configure avec :
vars.http_vhosts["doh-http"] = {
    http_uri = "/"
    http_vhost = "doh.bortzmeyer.fr"
    http_ssl = true
    http_sni = true
    http_timeout = 15
    http_certificate = "4,2"
    }
  
Ainsi, je suis prévenu s'il reste moins de quatre jours au certificat (et une alarme est levée s'il ne reste que deux jours). Autre test générique, que le serveur renvoie bien un échec si on ne lui parle pas en DoH correctement :
vars.http_vhosts["doh-raw-http"] = {
    http_uri = "/"
    http_vhost = "doh.bortzmeyer.fr"
    http_ssl = true
    http_sni = true
    http_timeout = 15
    http_expect = 400
    http_string = "Unable to parse the request"
    }
  
Mais il faut évidemment tester que le serveur répond bien aux requêtes DoH. On utilise pour cela un script dérivé du test-doh cité plus haut, check_doh.py. Utilisé à la main, ça donne :
% /usr/local/lib/nagios/plugins/check_doh -H doh.bortzmeyer.fr -n nextinpact.com
https://doh.bortzmeyer.fr/ OK - No error for nextinpact.com/AAAA, 107 bytes received
   
Et pour l'intégrer dans Icinga, on déclare une commande dans commands.conf :
object CheckCommand "doh_monitor" {                                               
  command = [ PluginContribDir + "/check_doh" ]                                          
                                                                 
  arguments = {                                                                
          "-H" = "$address6$",
          "-n" = "$doh_lookup$",                                    
          "-p" = "$doh_path$",                                   
          "-V" = "$doh_vhost$",                                         
          "-t" = "$doh_type$",                                        
          "-p" = "$doh_post$",                                                   
          "-i" = "$doh_insecure$",                                       
          "-h" = "$doh_head$"                                                  
          }                                                        
}                                                                                     
  
Puis un service dans services.conf :
Apply Service "doh" {                                                                   
  import "generic-service"                                                     
                                                                                 
  check_command = "doh_monitor"                                                                   
    assign where (host.address || host.address6) && host.vars.doh                                        
}                                                                                          
  
On peut alors configurer la machine à superviser :
     vars.doh = true
     vars.doh_vhost = "doh.bortzmeyer.fr"
     vars.doh_lookup = "fr.wikipedia.org"
     vars.doh_post = true
   
On supervise également le serveur Web internet :
vars.http_vhosts["doh-admin"] = {
    http_uri = "/api/v1/servers/localhost"
    http_port =	8083
    http_vhost = "doh.bortzmeyer.fr"
    http_ssl = true
    http_sni = true
    http_timeout = 15
    http_header = "X-API-Key: 23b..."
    http_string = "dohFrontends"
    }
}
   

Il existe d'autres résolveurs DoH gérés par des associations ou des individus, comme celui du .cz, https://www.nic.cz/odvr/ ou comme celui de l'association 42l. Mais je n'en trouve pas (pour l'instant) qui ait documenté en détail leur configuration technique.

Sinon, si vous aimez lire, il y a les très bons supports de l'exposé de Shaft à Pas Sage En Seine (plein de DoT et un peu de DoH.)

2019-09-29

Permanent record

Tout le monde connait bien sûr Edward Snowden, le héros grâce à qui les citoyens ordinaires ont des informations précises et étayées sur la surveillance de masse qu'exercent les États sur les citoyens. S'il a fait plusieurs interventions à distance, depuis son exil, il n'avait pas encore raconté de manière détaillée son parcours. C'est ce qu'il fait dans ce livre.

(J'ai lu ce livre en anglais car le titre de la traduction française m'avait semblé bizarre. Permanent record, c'est « Dossier qui vous suivra toute la vie » ou « Fiché pour toujours », certainement pas « Mémoires vives ».)

Je n'étais pas sûr de l'intérêt de ce livre : on peut être un héros sans savoir écrire, un informaticien compétent sans capacités pédagogiques, un lanceur d'alerte sans avoir guère de connaissances politiques. Mais j'ai été agréablement surpris : le livre est très bien écrit (Snowden remercie à la fin ceux qui ont lui ont appris à faire un livre intéressant), souvent drôle, malgré la gravité des faits, et Snowden explique très bien les questions informatiques comme le fonctionnement des services de surveillance étatiques.

Une partie du livre, surtout au début, est plutôt personnelle : enfance, jeunesse, débuts dans l'informatique. L'auteur décrit très bien la passion qu'est l'informatique, comment le hacker veut savoir comment ça marche, comment les erreurs aident à progresser. Tout informaticien se reconnaitra sans peine. (Si vous croisez quelqu'un qui dit « je ne comprends pas comment on peut être passionné par l'informatique », faites-lui lire ce livre.) Après commence la vie professionnelle, et Snowden démonte très bien le mécanisme pervers de recrutement des agences gouvernementales étatsuniennes : plutôt que d'avoir des fonctionnaires, on fait appel à des sous-traitants, qui facturent cher et font vivre un certain nombre de boites parasites, qui se contentent de mettre en rapport les informaticiens et l'État. Toute personne qui a travaillé dans une SSII reconnaitra ce monde, où on n'est jamais dans l'entreprise qui vous a embauché, et où on est parfois sous-traitant du sous-traitant. La majorité des gens qui conçoivent et font fonctionner le système de surveillance de masse sont des employés du privé…

Les amateurs de récits d'espionnage, même s'il n'y a évidemment aucun secret militaire dans ce livre, seront ravis des explications sur le fonctionnement interne des services de sécurité étatsuniens, monde très opaque et très complexe, qui est ici bien décortiqué.

La divergence entre Snowden et ses collègues a lieu après : la plupart des passionnés d'informatique accepteront sans problème de travailler pour Palantir, pour Facebook, pour Criteo ou pour la NSA. Ils ne se poseront pas de questions, se disant « de toute façon, c'est comme ça, on ne peut rien y faire » ou bien « la technique est neutre, je ne suis pas responsable de ce que les chefs font de mes programmes ». C'est là que Snowden suit une autre voie : il s'interroge, il se pose des questions, il lit, au grand étonnement de ses collègues de la CIA ou de la NSA, le texte de la constitution, et il finit par décider d'alerter le public sur le système d'espionnage qui avait été mis en place de manière complètement illégale (et qui l'est toujours).

Les amateurs de sécurité informatique pratique liront avec intérêt les réflexions d'Edward Snowden qui, sans pouvoir en parler avec personne, a dû concevoir un mécanisme pour sortir des locaux de la NSA, les innombrables documents qui ont fait les « révélations Snowden ». Je vous divulgue tout de suite un truc : les cartes SD (surtout microSD) sont bien plus discrètes que les clés USB, ne font pas sonner les détecteurs de métaux, et peuvent être avalées plus rapidement en cas d'urgence. Pendant qu'on en est aux conseils techniques, Snowden insiste sur l'importance du chiffrement, la principale protection technique sérieuse (mais pas à 100 %) contre la surveillance. Un des intérêts de ce livre est de revenir sur des points sur lesquels les discussions suite aux révélations de Snowden avaient parfois été brouillées par du FUD, où des gens plus ou moins bien intentionnés avaient essayé de brouiller le message en disant « mais, le chiffrement, ça ne protège pas vraiment », ou bien « mais non, PRISM, ce n'est pas une récolte directement auprès des GAFA ». Snowden explique clairement les programmes de la NSA, aux noms pittoresques, et les mécanismes de protection existants, au lieu de pinailler pour le plaisir de pinailler comme cela se fait parfois en matière de sécurité informatique.

Puis, une fois les documents sortis, c'est le départ pour Hong Kong et l'attente dans la chambre d'hôtel avant la rencontre avec Glen Greenwald et Laura Poitras, qui a filmé ces journées pour son remarquable documentaire « Citizenfour » (si vous ne l'avez pas vu, arrêtez de lire ce blog et allez voir ce documentaire).

Le livre n'a pas vraiment de conclusion : c'est à nous désormais de l'écrire.

2019-09-24

☕︎ Manifester

Je me rends compte que je raconte souvent mes balades en forêt mais rarement lorsque c’est en famille. Comme si ces sorties étaient plus intimes, ou moins portées sur la réflexion. L’expérience acquise seul me permet d’être en confiance une fois à plusieurs.

Je vais manifester pour dire que ce sujet est important. Comme le dit Alex Steffen, une personne qui n’a pas démérité depuis 15 ans pour faire avancer les choses, “The climate emergency is not an issue, it’s an era.” C’est notre ère, c’est notre vie. Nous devons être là pour demander des gestes dont nous savons qu’ils seront désagréables, dans un premier temps. J’irai manifester pour dire que je suis prêt aux changements nécessaires pour être en phase avec notre ère; que certes, il y aura des conséquences à ces changements, mais que les conséquences de l’inaction seront de loin plus lourdes. Il est temps d’agir.

Pourquoi je vais manifester vendredi (cache)

Y aller ou ne pas y aller. Avec violence ou pas. Déguisé en clown ?

Les clowns rebelles adoptent une position en rupture avec cette attitude jugée inutilement sérieuse, voire puriste : « Nous sommes des clowns, car que peut-on être d’autre dans un tel monde stupide. Parce qu’à l’intérieur de toute personne se trouve un clown sans loi qui essaie de s’évader. Parce que rien ne mine l’autorité comme de révéler son ridicule. »

[…]

L’approche des clowns permettrait de « rester imprévisible. À la confrontation et à la négociation, les clowns choisissent d’opposer la confusion. »

Les nouveaux anarchistes, Francis Dupuis-Déri

Toujours empli de doutes quant à la radicalisation.

Alors nous ne ferons pas barrage. L’histoire jugera. « Antifasciste pour antifasciste, un jour on comptera les points », disait François Bégaudeau, sommé sur France Culture de se prononcer sur le fameux barrage. L’histoire nous jugera, oui, et surtout l’histoire vous jugera. Elle jugera quelles étaient les puissances à l’œuvre, quels étaient les rapports de force de l’époque, qui avait le pouvoir d’agir dessus, qui ne l’a pas fait et, surtout, qui l’a fait pour favoriser le désastre. Nous ne transpirons pas à cette idée. Et vous ?

Nous ne ferons pas barrage (cache)

Les cartes locales sont constellées d’initiales B.C. pour Barrage Castor. Manifestement rien à voir, sauf qu’il s’agit d’une piste : troquer un gros barrage quinquennal contre une multitude de barrages au quotidien.

Il manque un emoji de castor.

However, it is clear that checks and balances have not provided relief to the fundamental issues of the policies in question. Chef, as well as other companies, can take stronger positions against these policies that violate basic human rights. Over the past year, many of our employees have constructively advocated for a change in our position, and I want to thank them.

After deep introspection and dialog within Chef, we will not renew our current contracts with ICE and CBP when they expire over the next year. Chef will fulfill our full obligations under the current contracts.

An Important Update from Chef (cache)

Que faire lorsqu’on collabore avec un exécutif qui semble très éloigné de ses valeurs ? Je me suis beaucoup posé cette question ces dernières années.

Je lisais aussi par ailleurs :

The software may not be used by individuals, corporations, governments, or other groups for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of underprivileged individuals or groups.

The Hippocratic License (cache)

Non seulement son application me semble impossible à tenir mais je suppose qu’il y a beaucoup de produits où la limite est bien plus grise que ça.

À rapprocher de :

The canonical horrible, no good, very bad example of this is the JSON license, an MIT-family license plus “The Software shall be used for Good, not Evil.”. This kind of thing might be “very Crockford”. It is definitely a pain in the ass. Maybe the joke was supposed to be on the lawyers. But they laughed all the way to the bank.

The MIT License, Line by Line (cache)

La lecture en arpentage consiste à partager les pages d’un livre et à les distribuer à un collectif. Il s’agit d’une pratique issue de l’éducation populaire et ouvrière qui offre la possibilité de mettre en mouvement l’intelligence d’un groupe. À l’origine, elle a été pratiquée par les ouvriers pour s’approprier des textes législatifs ou politiques. En ce sens, elle représente une forme d’autogestion et d’autodidactie collective qui permet de se passer de la glose de l’expert, quel qu’il soit. C’est une pratique qui vise à l’autonomie du collectif concerné. Dans les maquis du Vercors, les résistants, conscients de la nécessité de lutter aussi par la pensée, ont repris cette pratique de lecture. Elle permet un partage de la culture, « légitime » autant qu’ouvrière. Ce partage prend la forme d’un échange de points de vue et permet aux membres du groupe d’affermir leur pratique argumentative mais aussi de questionner le sens, la structure ou encore la portée de l’œuvre. En somme, c’est un outil d’accès à la culture par le partage et par la réflexion critique.

La culture en partage (cache)

Arpenter des programmes politiques plutôt que de battre le pavé ? Arpenter des publications scientifiques plutôt que de rafraîchir des timelines ?

“The past keeps changing,” the historian Margaret MacMillan has said, “because we keep asking different questions of it.”

post-modern late-capitalism or late-capitalist post-modernism? (cache)

Quelles questions pourra-t-on poser à notre époque ? Quelle est la légitimité des injonctions à avoir des actions historiques en (ne) sachant (pas) cela ?

Assises régionales de la cyber-sécurité à Bordeaux

À 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 protocole DoH et pourquoi il y a tant de discussions

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 :

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

La politique du serveur DoH doh.bortzmeyer.fr et ce qu'il faut savoir

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.

2019-09-17

☕︎ Arpenter

Vingt-quatre heures dans la forêt. Un marathon de marche afin d’épuiser le corps et l’esprit. Pour penser, dé-penser, repenser. Panser des blessures profondes, faire le vide, faire le plein. Habiter la forêt comme un lieu accueillant, un refuge aux bruits de ce monde.

La particularité de l’anarchisme réside plutôt dans sa conception radicale des principes de liberté et d’égalité, qui favorise un processus de prise de décision autonome, horizontal, participatif, délibératif et consensuel. L’anarchisme offre ou se présente alors comme une « boussole éthique », comme l’ont suggéré plusieurs anarchistes, puisqu’il offre quelques critères pour évaluer la meilleure direction à prendre, en terme d’organisation collective, de processus de prise de décision, d’action individuelle et collective.

[…]

Or, la dynamique des groupes d’affinité est influencée de façon particulière par l’amitié entre ses membres. En formant ou en joignant un groupe d’affinité, les individus deviennent ce qu’il convient de nommer des amilitantes et amilitants. Ce nouveau concept évoque à la fois un amalgame entre le rôle d’ami et de militant, ainsi qu’une certaine négation du militantisme traditionnel (le préfixe a- pouvant indiquer une négation). C’est ici l’amitié qui influence avant tout le comportement politique, plutôt qu’une doctrine idéologique ou un patriotisme organisationnel, comme dans le cas du militantisme traditionnel ; et cette politique de l’amitié favorise une diffusion — conscience ou non — des principes anarchistes au sein du mouvement altermondialiste. Amilitantes et amilitants sentent que la primauté du lien affinitaire et amical au sein de leur groupe implique presque naturellement un désir et une volonté de rechercher le consensus.

Les nouveaux anarchistes, Francis Dupuis-Déri

Yannick évoquait l’anarchisme il y a quelques temps au sein de scopyleft, je creuse un peu.

Ne faites pas non plus des restrictions personnelles pour sauver la planète : c’est inutile. Pour chaque lumière que vous éteignez, y a un gratte-ciel de bureaux qui laisse sa lumière, son chauffage/sa clim et ses PC, téléphones et photocopieurs allumés toute la nuit et chaque week-end (et pour chaque robinet que vous fermez, il y a une commune qui arrose ses routes pour laver la poussière — riez pas, c’est arrivé pas loin d’ici durant la canicule).

Faites ça pour votre porte-monnaie, et uniquement pour ça. Car au final, c’est vous qui consommez, c’est vous qui payez. Et tout ce que vous ne payez pas en électricité, vous pourrez le dépenser dans ce que vous voulez réellement : un bon restau, une sortie, un cadeau, ou n’importe quoi.

L’électricité verte, c’est quoi ? (cache)

Et si ce que l’on veut réellement c’est justement ne pas dépenser ? Comment rendre montrable — et donc enviable — le fait de ne pas faire quelque chose ? Non pas une vie d’ascète mais une vie décente, en accord avec l’énergie disponible pour tous et pour longtemps.

Au passage, je consultais les données climatiques pour Montréal et il n’y pas grand chose qui ne serait pas relativement enviable pour un autochtone si ce n’est la montée des eaux. Bon soit, l’approvisionnement en nourriture aussi…

Il faut rendre la propriété temporaire : les mêmes personnes ne doivent pas concentrer le capital éternellement. Je propose qu’au-delà d’un certain seuil, chacun redonne à la collectivité une partie de ce qu’il détient. J’imagine un impôt très progressif sur la propriété : il serait très faible (mettons 0,1 %) pour les personnes qui possèdent 100 000 ou 200 000 euros (trois fois moins que l’actuelle taxe foncière), mais pourrait monter jusqu’à 90 % pour ceux ayant au-delà de 10 000 fois le patrimoine moyen, c’est-à-dire plus de 2 milliards d’euros. Dans un tel système, les milliardaires disparaîtraient, de fait. Mais la petite propriété privée, elle, aurait toute sa place, tout comme l’entreprenariat. Car l’idée qu’il est tout à fait naturel que les entrepreneurs soient milliardaires est un mythe absurde, sur lequel repose en partie notre culte de la propriété privée : en réalité, les entrepreneurs qui ont des idées ne gagnent bien souvent pas des fortunes, et le dynamisme économique se nourrit justement de ces petits succès, de ces petites entreprises. L’hyperconcentration du capital entre les mains de quelques personnes n’est pas un modèle efficace ni indépassable.

Thomas Piketty : « Chaque société invente un récit idéologique pour justifier ses inégalités » (cache)

Si vous avez lu mon programme politique, vous savez à quel point j’aime l’héritage (surtout immobilier). Aussi quand je lis une personne, qui me semble être médiatique (en tout cas j’ai déjà entendu son nom), s’exprimer en ces termes je me dis que les propositions finiront bien par germer ici et là. Que proposer comme transition ? Quel est le premier pas acceptable ?

This year I wanted to reduce the volume of races (less traveling and resting) to be able to train more / better and try to give the best in the races I was competing, changing quantity to quality.

Training and Racing Summer 2019 (cache)

Kilian partage ses capacités, entrainements, etc. C’est assez impressionnant. Je lisais par ailleurs qu’il disait récupérer un peu moins bien. Jajaja.

When a society helps people through its shared democratic institutions, it does on behalf of all, and in a context of equality. Those institutions, representing those free and equal citizens, are making a collective choice of whom to help and how. Those who receive help are not only objects of the transaction, but also subjects of it — citizens with agency. When help is moved into a private sphere, no matter how efficient we are told it is, the context of the helping is a relationship of inequality: the giver and the taker, the helper and the helped, the donor and the recipient.

Winners take all, Anand Giridharadas

À rapprocher de :

In this respect, any movement toward a more just and civil society can now be considered a meaningful climate action. Securing fair elections is a climate action. Combatting extreme wealth inequality is a climate action. Shutting down the hate machines on social media is a climate action. Instituting humane immigration policy, advocating for racial and gender equality, promoting respect for laws and their enforcement, supporting a free and independent press, ridding the country of assault weapons—these are all meaningful climate actions. To survive rising temperatures, every system, whether of the natural world or of the human world, will need to be as strong and healthy as we can make it.

What if We Stopped Pretending the Climate Apocalypse Can Be Stopped? (cache)

Lorsque je chemine sur l’arbre des possibles, je vois un retour à l’État et à la religion. Mutualiser d’un côté, faire groupe de l’autre. Comment réussir à morceler cela en minimisant la violence ? Se redéfinir sans avoir besoin d’un bouc-émissaire. Partager sans passer par un système pyramidal.

La protection de la nature, de la variété et de la liberté humaines ne sera assurée que si l’on dissocie l’économie nationale ou multinationale en petites unités autarciques et autogérées

Bernard Charbonneau cité dans « Greta Thunberg, Extinction Rebellion et le mouvement pour le développement durable (cache) »

The pollution caused by an event is part of the hidden costs and we want to ensure that we take responsibility for it.

2019:Carbon offsetting (cache)

Combien de tonnes de carbone économisées pour une annulation de ParisWeb (cache) ?

Note : ce n’est plus le cas, ce billet mériterait d’être édité.

The amount of time and knowledge that you need to have to setup such tools and services and to keep them up and running is insane.

Yes, they save a lot of time once they are working. If you don’t touch them they are probably stable for a while. But I never learned to love them in all those years. It’s more like a love-hate relationship, slightly tilted to hate.

Simplicity (II) (cache)

Je verse une larme de réalité à chaque paragraphe de cet article. L’intégration continue c’est bien, l’intégration soutenue c’est mieux. Il faudrait que j’écrive un billet là-dessus.

Citation de la semaine :

as a programmer and as a parent, I’m always cleaning up shit created by a younger version of myself

Zach Leatherman (qui prend possession de ses archives Twitter (cache))

J’ai ri.

Using the CowBoy HTTP server from an Elixir program

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.

2019-09-12

« Entrée libre » à Quimper

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.)

2019-09-10

☕︎ Nostalgie

Un brin de nostalgie cette semaine lorsque j’ai essayé de retrouver des informations sur mon site au sujet du Canada. Il faudra que je propose une recherche par ici, un jour.

Tout d’abord cette petite pépite d’il y a 12 ans :

Québecois, canadiens, vous avez un merveilleux pays. Ne laissez pas le profit saccager tout ça avec des hordes de français tous plus incorrects les uns que les autres et conservez ce patrimoine. L’eau est la richesse de demain et ce pays va donc devenir une puissance mondiale importante au cours des prochaines décennies, vous n’avez pas besoin d’exploiter au maximum la filière du tourisme comme certains pays.

Le pire, et c’est là où j’ai vraiment eu honte, c’est que vous adorez les français ! Il serait peut-être temps que je déménage moi...

Recette du français en vacances à l’étranger

Lorsque je parle de pépite, il ne s’agit pas forcément d’un contenu que je ne cautionne plus totalement aujourd’hui mais de cette allusion au déménagement. Cela m’a aussi renvoyé à une histoire d’ex-patriation où je me rends compte à quel point les commentaires c’était un autre temps. Et c’était pas mal.

Au passage, je relis Intégrer une équipe qui résonne avec Faire équipe, puis Diète de tweets il y a six ans déjà…

Ce site aura 15 ans dans quelques semaines, ça correspond à la création de Facebook et à la sortie de Firefox 1.0 (cache). Pour la peine j’ai relu le billet des 10 ans mais aussi un web omni-présent. J’aurais du mal à être optimiste sur l’évolution du Web au cours de ces cinq dernières années. Vraiment.

Être humain veut dire connaître le chemin, le pont et la porte.

La perte des sens, Ivan Illich

Il va me falloir du temps pour rééquilibrer cela ayant privilégié le chemin à la porte depuis très longtemps. Ouvrir son esprit à beaucoup plus de choses. Explorer de nouveaux ponts, emprunter ceux proposés par d’autres. Avoir la main sur la poignée sans savoir s’il faut tirer ou pousser. Accueillir ou s’inviter.

non pas comme un antiquaire concerné par son caractère de passé, mais en tant qu’historien qui essaie de faire ressortir ce qui du passé est part de nous-mêmes.

Citation de Paolo Prodi dans la Préface de La perte des sens, Ivan Illich

Panneau dans un parc avec l’interdiction d’avoir un chien, un vélo, des boissons (alcoolisées), de faire du hockey (?), un seul pictogramme autoriser : jeter à la poubelle. Que peut-on faire dans un parc pour enfants ? Jeter uniquement.

Où l’on peut observer une profondeur de champ numérique qui a du mal avec les grillages. Ça donne un certain charme. Et un charme certain lorsque ça deviendra rétro, d’ici quelques années. Les bugs d’aujourd’hui sont les points d’intérêt de demain.

L’envie de (re)faire des photos.

Étudier un jour les similitudes entre le geste de semer et celui d’écrire. Entre le compost et les archives.

L’apprenti sage, Gilles Vigneault

Arrivé·e ici, vous devez en avoir marre de lire des liens auto-centrés. Et ça tombe bien, j’ai commencé à rassembler des articles que je trouve intemporels en date de la dernière semaine de cette année. Contrôler son espace de publication, c’est avoir la liberté de faire des choix sans être limité par les choix qui ont conduit à l’outil d’un·e autre.

Planter des liens et voir pousser un Web.

L'avenir de Salto

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.

2019-09-06

RFC 8620: The JSON Meta Application Protocol (JMAP)

Le protocole JMAP, JSON Meta Application Protocol, permet de bâtir des mécanismes d'accès à des objets distants (par exemple des boîtes aux lettres, ou des agendas), en envoyant et recevant du JSON au dessus de HTTPS. Son principal « client » est le protocole « JMAP for mail », un concurrent d'IMAP normalisé dans le RFC 8621.

Au début, JMAP était même conçu uniquement pour l'accès au courrier, comme l'indique son nom, qui évoque IMAP. Mais, dans le cadre de la normalisation de JMAP, est apparu le désir de séparer le protocole générique, adapté à toutes sortes d'objets distants, du protocole spécifique du courrier. D'où les deux RFC : ce RFC 8620 normalise le protocole générique, alors que le RFC 8621 normalise « JMAP for mail ». Dans le futur, d'autres protocoles fondés sur JMAP apparaitront peut-être, par exemple pour l'accès et la synchronisation d'un agenda (en concurrence avec le CalDAV du RFC 4791, donc).

Parmi les concepts techniques importants de JMAP, notons :

  • Utilisation de JSON (RFC 8259) pour encoder les données, parce que tout le monde utilise JSON aujourd'hui,
  • Transport sur HTTPS (RFC 2818 et RFC 7230), là encore comme tout le monde aujourd'hui, avec toutes les propriétés de sécurité de HTTPS (notamment, le client JMAP doit authentifier le serveur, typiquement via un certificat),
  • Possibilité de regrouper (batching) les requêtes en un seul envoi, pour les cas où la latence est élevée,
  • Possibilité de notification par le serveur (push), pour éviter l'interrogation répétée par le client (polling),
  • Un mécanisme de transfert incrémental des objets, pour limiter le débit sur le réseau.
Du fait de l'utilisation de JSON, il est bon de réviser le vocabulaire JSON, notamment le fait qu'un objet (object) JSON est en fait un dictionnaire.

Outre les types de données de base de JSON, comme les booléens, les chaînes de caractères et les entiers, JMAP définit quelques types à lui, notamment le type Id, qui stocke l'identificateur d'un objet. Syntaxiquement, c'est une chaîne de caractères LDH (Letter-Digit-Hyphen, lettres ASCII, chiffres et trait d'union). Par exemple, dans le RFC 8621, la première boîte aux lettres mentionnée a comme identificateur MB23cfa8094c0f41e6. Notre RFC crée aussi le type Date, puisque JSON ne normalise pas les dates. Ce type utilise le format du RFC 3339.

À ce stade, je peux avouer que j'ai fait un abus de langage. J'ai parlé de JSON mais en fait JMAP utilise un sous-ensemble de JSON, nommé I-JSON, et décrit dans le RFC 7493, afin d'éviter certaines ambiguités de JSON (section 8.4 de notre RFC). Tout le contenu échangé en JMAP doit être du I-JSON. D'ailleurs, si vous connaissez un logiciel libre qui vérifie qu'un texte JSON est du I-JSON, je suis preneur.

JMAP nécessite que le client se connecte au serveur (section 2 du RFC, sur la session). Pour cela, il lui faut l'URL du serveur (rappelez-vous que JMAP tourne sur HTTPS), qui peut être obtenu manuellement, ou par un processus de découverte décrit plus loin. Et il faut évidemment les moyens d'authentification (par exemple nom et phrase de passe), ceux-ci n'étant pas précisés dans notre RFC. Un mécanisme unique avait été prévu mais avait suscité trop de controverses à l'IETF. Finalement, les mécanismes utilisables sont ceux habituels de HTTPS (enregistrés à l'IANA). Lors de la connexion, le serveur va envoyer un objet JSON décrivant entre autres ses capacités, comme la taille maximale des objets téléversés, ou comme les extensions gérées (comme le « JMAP for mail » du RFC 8621). Voici un exemple (tiré du RFC, car je n'ai pas trouvé de serveur JMAP où je pouvais avoir facilement un compte pour tester, si vous en avez un, n'hésitez pas à m'écrire) :


   {
     "capabilities": {
       "urn:ietf:params:jmap:core": {
         "maxSizeUpload": 50000000,
         "maxSizeRequest": 10000000,
...
         "collationAlgorithms": [
           "i;ascii-numeric",
           "i;ascii-casemap",
           "i;unicode-casemap"
         ]
       },
       "urn:ietf:params:jmap:mail": {}
       "urn:ietf:params:jmap:contacts": {},
       "https://example.com/apis/foobar": {
         "maxFoosFinangled": 42
       }
     },
     "accounts": {
       "A13824": {
         "name": "john@example.com",
         "isPersonal": true,
         "isReadOnly": false,
         "accountCapabilities": {
           "urn:ietf:params:jmap:mail": {
             "maxMailboxesPerEmail": null,
             "maxMailboxDepth": 10,
             ...
           },
           "urn:ietf:params:jmap:contacts": {
             ...
           }
...
      "apiUrl": "https://jmap.example.com/api/",
...

    
Notez que ce serveur annonce qu'il sait faire du JMAP pour le courrier (RFC 8621, cf. la ligne urn:ietf:params:jmap:mail) et qu'il a également une extension privée, https://example.com/apis/foobar. Les capacités publiques sont dans un registre IANA. On peut ajouter des capacités par la procédure (cf. RFC 8126) « Spécification nécessaire » pour les capacités marquées « fréquentes » (common), et par la procédure « Examen par un expert » pour les autres.

La méthode standard pour découvrir le serveur JMAP, si on n'en connait pas l'URL, est d'utiliser un enregistrement SRV (RFC 2782, mais voir aussi le RFC 6186) puis un URL bien connu. Imaginons que le domaine soit example.net. On cherche le SRV pour _jmap._tcp.example.net. (jmap a donc été ajouté au registre des services.) On récupère alors le nom du serveur et le port (a priori, ce sera 443, le port standard de HTTPS). Et on n'a plus qu'à se connecter à l'URL bien connu (RFC 8615), à https://${hostname}[:${port}]/.well-known/jmap. jmap figure à cet effet dans le registre des URL bien connus. (Notez que l'étape SRV est facultative, certains clients iront directement au /.well-known/jmap.) Ainsi, si vous utilisez JMAP pour le courrier, et que votre adresse est gerard@example.net, vous partez du domaine example.net et vous suivez l'algorithme ci-dessus. (Je ne sais pas pourquoi JMAP n'utilise pas plutôt le WebFinger du RFC 7033.)

Puisqu'on utilise le DNS pour récupérer ces enregistrements SRV, il est évidemment recommandé de déployer DNSSEC.

Une fois qu'on a récupéré le premier objet JSON décrit plus haut, on utilise la propriété (le membre, pour parler JSON) apiUrl de cet objet pour faire les requêtes suivantes (section 3 du RFC). On utilise la méthode HTTP POST, le type MIME application/json, et on envoie des requêtes en JSON, qui seront suivies de réponses du serveur, également en JSON. Les méthodes JMAP (à ne pas confondre avec les méthodes HTTP comme GET ou POST) sont écrites sous la forme Catégorie/Méthode. Il existe une catégorie Core pour les méthodes génériques de JMAP et chaque protocole utilisant JMAP définit sa (ou ses) propre(s) catégorie(s). Ainsi, le RFC 8621 définit les catégories Mailbox, Email (un message), etc. Comme Core définit une méthode echo (section 4, le ping de JMAP), qui ne fait que renvoyer les données, sans les comprendre, un exemple de requête/réponse peut être :

      
[[ "Core/echo", {
      "hello": true,
      "high": 5
}, "b3ff" ]]

[[ "Core/echo", {
      "hello": true,
      "high": 5
}, "b3ff" ]]

    
(Oui, la réponse - le second paragraphe - est identique à la question.)

En cas d'erreur, le serveur devrait renvoyer un objet décrivant le problème, en utilisant la syntaxe du RFC 7807. Une liste des erreurs connues figure dans un registre IANA.

Il existe des noms de méthodes standard qu'on retrouve dans toutes les catégories, comme get. Si on a une catégorie Foo décrivant un certain type d'objets, le client sait qu'il pourra récupérer les objets de ce type avec la méthode Foo/get, les modifier avec Foo/set et récupérer uniquement les modifications incrémentales avec Foo/changes. La section 5 du RFC décrit ces méthodes standard.

Une méthode particulièrement utile est query (section 5.5). Elle permet au client de demander au serveur de faire une recherche et/ou un tri des objets. Au lieu de tout télécharger et de faire recherche et tri soi-même, le client peut donc sous-traiter cette opération potentiellement coûteuse. Cette méthode est une de celles qui permet de dire que JMAP est bien adapté aux machines clientes disposant de faibles ressources matérielles, et pas très bien connectées. Le RFC cite (section 5.7) un type (imaginaire) Todo décrivant des tâches à accomplir, et l'exemple avec query permet d'illustrer le membre filter de la méthode, pour indiquer les critères de sélection :


[[ "Todo/query", {
       "accountId": "x",
       "filter": {
              "operator": "OR",
              "conditions": [
                         { "hasKeyword": "music" },
                         { "hasKeyword": "video" }
	      ]
       }
    }			 
]]                     

    
Comme beaucoup de méthodes JMAP, query peut imposer un travail important au serveur. Un client maladroit, ou cherchant déliberement à créer une attaque par déni de service pourrait planter un serveur trop léger. Les serveurs JMAP doivent donc avoir des mécanismes de protection, comme une limite de temps passé sur chaque requête.

On l'a dit, un des intérêts de JMAP est la possibilité d'obtenir des notifications du serveur, sans obliger le client à vider sa batterie en interrogeant périodiquement le serveur. La section 7 du RFC détaille ce mécanisme. Deux alternatives pour le client : garder la connexion HTTPS ouverte en permanence, pour y recevoir ces notifications, ou bien utiliser un service tiers comme celui de Google. Notons que ces notifications, par leur seule existence, même si le canal est chiffré, peuvent révéler des informations. Comme noté dans la revue du protocole par la direction Sécurité à l'IETF "I.e., if someone can see that wikileaks smtp server sends email to corporate smtp server, but the smtp traffic is encrypted so they do not know the recipient of the email, but then few seconds later see push event notification stream going to the Joe's laptop indicating something has happened in his mail box, they can find out the who the recipient was.".

Il existe une page « officielle » présentant le protocole et plusieurs mises en oeuvre (actuellement, la plupart sont, expérimentales et/ou en cours de développement). C'est une des raisons pour lesquelles je ne présente pas ici d'essais réels. Notez toutefois que Fastmail a du JMAP en production.

2019-09-04

RFC 8618: Compacted-DNS (C-DNS): A Format for DNS Packet Capture

Lorsque l'opérateur d'un service DNS veut conserver les données de trafic, il peut demander au serveur d'enregistrer requêtes et réponses (mais, la plupart du temps, le serveur n'écrit qu'une petite partie des informations) ou bien écouter le trafic réseau et enregistrer le pcap. Le problème est que le format pcap prend trop de place, est de trop bas niveau (une connexion TCP, par exemple, va être éclatée en plusieurs paquets), et qu'il est difficile de retrouver les informations spécifiquement DNS à partir d'un pcap. D'où la conception de ce format de stockage, spécifique au DNS, et qui permet d'enregistrer la totalité de l'information, dans un format optimisé en taille et de plus haut niveau. C-DNS s'appuie sur CBOR pour cela.

Le DNS est un service d'infrastructure absolument critique. Il est donc nécessaire de bien le connaitre et de bien l'étudier. Cela passe par une récolte de données, en l'occurrence le trafic entrant et sortant des serveurs DNS, qu'ils soient des résolveurs ou bien des serveurs faisant autorité. Ce genre de récolte peut être coordonnée par l'OARC pour des projets comme DITL (« un jour dans la vie de l'Internet »). Un exemple d'une telle récolte, faite avec le classique tcpdump (qui, en dépit de son nom, ne fait pas que du TCP) :

% tcpdump -w /tmp/dns.pcap port 53
    
Le fichier produit (ici, sur un serveur faisant autorité pour eu.org), au format pcap, contient les requêtes DNS et les réponses, et peut être analysé avec des outils comme tcpdump lui-même, ou comme Wireshark. Il y a aussi des outils spécifiques au DNS comme PacketQ ou comme dnscap. Ici, avec tcpdump :
% tcpdump -n -r /tmp/dns.pcap      
15:35:22.432746 IP6 2001:db8:aa:101::.40098 > 2400:8902::f03c:91ff:fe69:60d3.53: 41209% [1au] A? tracker.torrent.eu.org. (51)
15:35:22.432824 IP6 2400:8902::f03c:91ff:fe69:60d3.53 > 2001:db8:aa:101::.40098: 41209- 0/4/5 (428)
    
Au lieu des outils tous faits, on peut aussi développer ses propres programmes en utilisant les nombreuses bibliothèques qui permettent de traiter du pcap (attention si vous analysez du trafic Internet : beaucoup de paquets sont mal formés, par accident ou bien délibérément, et votre analyseur doit donc être robuste). C'est ce que font en général les chercheurs qui analysent les données DITL.

Le problème du format pcap (ou pcapng) est qu'il y a à la fois trop de données et pas assez. Il y a trop de données car il inclut des informations probablement rarement utiles, comme les adresses MAC et car il ne minimise pas les données. Et il n'y en a pas assez car il ne stocke pas les informations qui n'étaient pas visibles sur le réseau mais qui l'étaient uniquement dans la mémoire du serveur DNS. Ainsi, on ne sait pas si la réponse d'un résolveur avait été trouvée dans le cache ou pas. Ou bien si les données étaient dans le bailliage ou pas (cf. RFC 8499, section 7). Les captures DNS peuvent être de très grande taille (10 000 requêtes par seconde est banal, 100 000, ça arrive parfois) et on désire les optimiser autant que possible, pour permettre leur rapatriement depuis les serveurs éloignés, puis leur stockage parfois sur de longues périodes. (Les formats « texte » comme celui du RFC 8427 ne conviennent que pour un message isolé, ou un tout petit nombre de messages.)

Le cahier des charges du format C-DNS (Compacted DNS) est donc :

  • Minimiser la taille des données,
  • Minimiser le temps de traitement pour compacter et décompacter.

La section du RFC détaille les scénarios d'usage de C-DNS. En effet, la capture de données DNS peut être faite dans des circonstances très différentes. Le serveur peut être une machine physique, une virtuelle, voire un simple conteneur. La personne qui gère le capture peut avoir le contrôle des équipements réseau (un commutateur, par exemple, pour faire du port mirroring), le serveur peut être surdimensionné ou, au contraire, soumis à une attaque par déni de service qui lui laisse peu de ressources. Le réseau de collecte des données capturées peut être le même que le réseau de service ou bien un réseau différent, parfois avec une capacité plus faible. Bref, il y a beaucoup de cas. C-DNS est optimisé pour les cas où :

  • La capture des données se fait sur le serveur lui-même, pas sur un équipement réseau,
  • Les données seront stockées localement, au moins temporairement, puis analysées sur une autre machine.
Donc, il est crucial de minimiser la taille des données récoltées. Mais il faut aussi faire attention à la charge que représente la collecte : le serveur de noms a pour rôle de répondre aux requêtes DNS, la collecte est secondaire, et ne doit donc pas consommer trop de ressources CPU.

Compte-tenu de ces contraintes, C-DNS a été conçu ainsi (section 4 du RFC) :

  • L'unité de base d'un fichier C-DNS est le couple R/R, {requête DNS, réponse DNS} (Q/R data item), ce qui reflète le fonctionnement du protocole DNS, et permet d'optimiser le stockage, puisque bien des champs ont des valeurs communes entre une requête et une réponse (par exemple le nom de domaine demandé). Notez qu'un couple R/R peut ne comporter que la requête, ou que la réponse, si l'autre n'a pas pu être capturée, ou bien si on a décidé délibérément de ne pas le faire.
  • C-DNS est optimisé pour les messages DNS syntaxiquement corrects. Quand on écrit un analyseur de paquets DNS, on est frappés du nombre de messages incorrects qui circulent sur le réseau. C-DNS permet de les stocker sous forme d'un « blob » binaire, mais ce n'est pas son but principal, il ne sera donc efficace que pour les messages corrects.
  • Pratiquement toute les données sont optionnelles dans C-DNS. C'est à la fois pour gagner de la place, pour tenir compte du fait que certains mécanismes de capture ne gardent pas toute l'information, et pour permettre de minimiser les données afin de préserver la vie privée.
  • Les couples R/R sont regroupés en blocs, sur la base d'élements communs (par exemple l'adresse IP source, ou bien la réponse, notamment les NXDOMAIN), qui permettent d'optimiser le stockage, en ne gardant cet élément commun qu'une fois par bloc. (Par contre, cela complexifie les programmes. On n'a rien sans rien.)

C-DNS repose sur CBOR (RFC 7049). La section 5 du RFC explique pourquoi :

  • Format binaire, donc prenant moins d'octets que les formats texte comme JSON (l'annexe C discute des autres formats binaires),
  • CBOR est un format normalisé et répandu,
  • CBOR est simple et écrire un analyseur peut se faire facilement, si on ne veut pas dépendre d'une bibliothèque extérieure,
  • CBOR a désormais un langage de schéma, CDDL (RFC 8610), qu'utilise notre RFC.

Avec la section 6 du RFC commence la description du format. Classiquement, un fichier C-DNS commence par un en-tête, puis une série de blocs. Chaque bloc comprend un certain nombre de tables (par exemple une table d'adresses IP pour les adresses apparaissant dans le bloc), suivies des éléments R/R. Ceux-ci référencent les tables. Ainsi, une requête de 2001:db8:1::cafe à 2001:db8:ffff::beef pour le nom www.example.org contiendra des pointeurs vers les entrées 2001:db8:1::cafe et 2001:db8:ffff::beef de la table des adresses IP, et un pointeur vers l'entrée www.example.org de la table des noms de domaine. S'il n'y a qu'un seul élément R/R dans le bloc, ce serait évidemment une complication inutile, mais l'idée est de factoriser les données qui sont souvent répétées.

On l'a vu, dans C-DNS, plein de choses sont optionnelles, car deux dispositifs de capture différents ne récoltent pas forcément les mêmes données. Ainsi, par exemple, un système de capture situé dans le logiciel serveur n'a pas forcément accès à la couche IP et ne peut donc pas enregistrer le nombre maximal de sauts (hop limit). Cela veut dire que, quand on lit un fichier C-DNS :

  • Il faut déterminer si une donnée est présente ou pas, et ne pas supposer qu'elle l'est forcément,
  • Il peut être utile de déterminer si une donnée manquante était absente dès le début, ou bien si elle a été délibérément ignorée par le système de capture. Si un message ne contient pas d'option EDNS (RFC 6891), était-ce parce que le message n'avait pas cette option, ou simplement parce qu'on ne s'y intéressait pas et qu'on ne l'a pas enregistrée ?
C-DNS permet donc d'indiquer quels éléments des données initiales ont été délibérément ignorés. Cela permet, par exemple, à un programme de lecture de fichiers C-DNS de savoir tout de suite si le fichier contient les informations qu'il veut.

Ces indications contiennent aussi des informations sur un éventuel échantillonnage (on n'a gardé que X % des messages), sur une éventuelle normalisation (par exemple tous les noms de domaine passés en caractères minuscules) ou sur l'application de techniques de minimisation, qui permettent de diminuer les risques pour la vie privée. Par exemple, au lieu de stocker les adresses IP complètes, on peut ne stocker qu'un préfixe (par exemple un /32 au lieu de l'adresse complète), et il faut alors l'indiquer dans le fichier C-DNS produit, pour que le lecteur comprenne bien que 2001:db8:: est un préfixe, pas une adresse.

La section 7 du RFC contient ensuite le format détaillé. Quelques points sont à noter (mais, si vous écrivez un lecteur C-DNS, lisez bien tout le RFC, pas juste mon article !) Ainsi, toutes les clés des objets (maps) CBOR sont des entiers, jamais des chaînes de caractère, pour gagner de la place. Et ces entiers sont toujours inférieurs à 24, pour tenir sur un seul octet en CBOR (lisez le RFC 7049 si vous voulez savoir pourquoi 24). On peut aussi avoir des clés négatives, pour les extensions au format de base, et elles sont comprises entre -24 et -1.

La syntaxe complète, rédigée dans le format CDDL du RFC 8610, figure dans l'annexe A de notre RFC.

On peut reconstruire un fichier pcap à partir de C-DNS. Une des difficultés est qu'on n'a pas forcément toutes les informations, et il va donc falloir être créatif (section 9). Une autre raison fait qu'on ne pourra pas reconstruire au bit près le fichier pcap qui aurait été capturé par un outil comme tcpdump : les noms de domaines dans les messages DNS étaient peut-être comprimés (RFC 1035, section 4.1.4) et C-DNS n'a pas gardé d'information sur cette compression. (Voir l'annexe B pour une discussion détaillée sur la compression.) Pareil pour les informations de couche 3 : C-DNS ne mémorise pas si le paquet UDP était fragmenté, s'il était dans un ou plusieurs segments TCP, s'il y avait des messages ICMP liés au trafic DNS, etc.

Si vous voulez écrire un lecteur ou un producteur de C-DNS, la section 11 du RFC contient des informations utiles pour la programmeuse ou le programmeur. D'abord, lisez bien le RFC 7049 sur CBOR. C-DNS utilise CBOR, et il faut donc connaitre ce format. Notamment, la section 3.9 du RFC 7049 donne des conseils aux implémenteurs CBOR pour produire un CBOR « canonique ». Notre RFC en retient deux, représenter les entiers, et les types CBOR, par la forme la plus courte possible (CBOR en permet plusieurs), mais il en déconseille deux autres. En effet, la section 3.9 du RFC 7049 suggérait de trier les objets selon la valeur des clés, et d'utiliser les tableaux de taille définie (taille indiquée explicitement au début, plutôt que d'avoir un marqueur de fin). Ces deux conseils ne sont pas réalistes pour le cas de C-DNS. Par exemple, pour utiliser un tableau de taille définie, il faudrait tout garder en mémoire jusqu'au moment où on inscrit les valeurs, ce qui augmenterait la consommation mémoire du producteur de données C-DNS. (D'un autre côté, le problème des tableaux de taille indéfinie est qu'ils ont un marqueur de fin ; si le programme qui écrit du C-DNS plante et ne met pas le marqueur de fin, le fichier est du CBOR invalide.)

Le RFC a créé plusieurs registres IANA pour ce format, stockant notamment les valeurs possibles pour le transport utilisé, pour les options de stockage (anonymisé, échantillonné...), pour le type de réponse (issue de la mémoire du résolveur ou pas).

Bien sûr, récolter des données de trafic DNS soulève beaucoup de problèmes liés à la vie privée (cf. RFC 7626). Il est donc recommander de minimiser les données, comme imposé par des réglements comme le RGPD, ou comme demandé dans le rapport « Recommendations on Anonymization Processes for Source IP Addresses Submitted for Future Analysis ».

Les passionnés de questions liées aux formats regarderont l'annexe C, qui liste des formats alternatifs à CBOR, qui n'ont finalement pas été retenus :

  • Apache Avro, trop complexe car on ne peut lire les données qu'en traitant le schéma,
  • Protocol Buffers, qui a le même problème,
  • JSON (RFC 8259), qui n'est pas un format binaire, mais qui a été ajouté pour compléter l'étude.
Cette annexe décrit également le résultat de mesures sur la compression obtenue avec divers outils, sur les différents formats. C-DNS n'est pas toujours le meilleur, mais il est certainement, une fois comprimé, plus petit que pcap, et plus simple à mettre en œuvre qu'Avro ou Protocol Buffers.

Notez que j'ai travaillé sur ce format lors d'un hackathon de l'IETF, mais le format a pas mal changé depuis (entre autres en raison des problèmes identifiés lors du hackathon).

Voyons maintenant une mise en œuvre de ce format, avec l'outil DNS-STATS plus exactement son Compactor (source sur Github, et documentation). Je l'ai installé sur une machine Debian :

aptitude install libpcap-dev libboost1.67-all-dev liblzma-dev libtins-dev
git clone https://github.com/dns-stats/compactor.git
cd compactor
sh autogen.sh
autoconf
automake
./configure
make
    
Et après, on peut l'utiliser pour transformer du C-DNS en pcap et réciproquement. J'ai créé un fichier pcap d'un million de paquets avec tcpdump sur un serveur faisant autorité, avec tcpdump -w dns.pcap -c 1000000 port 53. Puis :
%   ./compactor -o /tmp/dns.cdns  /tmp/dns.pcap
    
Et en sens inverse (reconstituer le pcap) :
%  ./inspector /tmp/dns.cdns
    
Cela nous donne :
% ls -lth /tmp/dns*                        
-rw-r--r-- 1 stephane stephane  98M Jul 31 08:13 /tmp/dns.cdns.pcap
-rw-r--r-- 1 stephane stephane 3.2K Jul 31 08:13 /tmp/dns.cdns.pcap.info
-rw-r--r-- 1 stephane stephane  27M Jul 31 07:27 /tmp/dns.cdns
-rw-r--r-- 1 root     root     339M Jul 30 20:05 /tmp/dns.pcap
    
Notez que dns.cdns.pcap est le pcap reconstitué, on remarque qu'il est plus petit que le pcap original, certaines informations ont été perdues, comme les adresses MAC. Mais il reste bien plus gros que la même information stockée en C-DNS. Le /tmp/dns.cdns.pcap.info nous donne quelques informations :
% cat /tmp/dns.cdns.pcap.info
CONFIGURATION:
  Query timeout        : 5 seconds
  Skew timeout         : 10 microseconds
  Snap length          : 65535
  Max block items      : 5000
  File rotation period : 14583
  Promiscuous mode     : Off
  Capture interfaces   : 
  Server addresses     : 
  VLAN IDs             : 
  Filter               : 
  Query options        : 
  Response options     : 
  Accept RR types      : 
  Ignore RR types      : 

COLLECTOR:
  Collector ID         : dns-stats-compactor 0.12.3
  Collection host ID   : ns1.example

STATISTICS:
  Total Packets processed                  : 1000000
  Matched DNS query/response pairs (C-DNS) : 484407
  Unmatched DNS queries            (C-DNS) : 98
  Unmatched DNS responses          (C-DNS) : 69
  Malformed DNS packets                    : 68
  Non-DNS packets                          : 0
  Out-of-order DNS query/responses         : 1
  Dropped C-DNS items (overload)           : 0
  Dropped raw PCAP packets (overload)      : 0
  Dropped non-DNS packets (overload)       : 0

RFC 8605: vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)

Ce RFC décrit des extensions au format vCard afin d'ajouter dans les réponses RDAP deux informations exigées par l'ICANN. Il concerne donc surtout registres et utilisateurs des TLD ICANN.

Le protocole RDAP (RFC 7483) sert à récupérer des informations sur un objet enregistré, par exemple un nom de domaine. Une partie des informations, par exemple les adresses et numéros de téléphone, est au format vCard (RFC 6350). Mais l'ICANN a des exigences supplémentaires, décrites dans la Specification for gTLD Registration Data. Par exemple, l'ICANN exige (cf. leur politique) que, si les informations sur un contact ne sont pas publiées (afin de préserver sa vie privée), le registre fournisse au moins un URI indiquant un moyen de contact (section 2.7.5.2 de la politique ICANN), par exemple un formulaire Web (comme https://www.afnic.fr/fr/resoudre-un-litige/actions-et-procedures/joindre-le-contact-administratif-d-un-domaine/). Cette propriété CONTACT-URI est désormais dans le registre IANA. (Si vous voulez réviser les notions de propriété et de paramètre en vCard, plus exactement jCard, cf. RFC 7095.)

D'autre part, la norme vCard, le RFC 6350, précise dans sa section 6.3.1, que le nom du pays doit être spécifié en langue naturelle, alors que l'ICANN exige (section 1.4 de leur politique) un code à deux lettres tiré de la norme ISO 3166. (Notez qu'à l'heure actuelle, certains registres mettent le nom du pays, d'autres le code à deux lettres…) Le paramètre CC, qui va indiquer le code, est désormais dans le registre IANA.

Ainsi, une réponse vCard suivant notre RFC pourrait indiquer (je ne peux pas vous montrer d'exemples réels d'un registre, aucun n'a apparemment déployé ces extensions, mais, si vous êtes curieux, lisez jusqu'à la fin) :

      
%  curl -s https://rdap.nic.example/domain/foobar.example | jq . 
...
    [
            "contact-uri",  <<< Nouveauté
            {},
            "uri",
            "https://rds.nic.example/get-in-touch"
    ]
...
    [
            "adr",
            {"cc": "US"},  <<< Nouveauté
	    "text",
            ["", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A."]
   ]    
...

    

J'ai parlé jusqu'à présent des registres, mais l'ICANN impose également RDAP aux bureaux d'enregistrement. Cela a en effet un sens pour les registres minces, comme .com, où les données sociales sont chez les bureaux en question. La liste des bureaux d'enregistrement ICANN contient une colonne indiquant leur serveur RDAP. Testons avec Blacknight, qui est souvent à la pointe :

% curl https://rdap.blacknight.com/domain/blacknight.com | jq .  
...
          [
            "fn",
            {},
            "text",
            "Blacknight Internet Solutions Ltd."
          ],
          [
            "adr",
            {
              "cc": "IE"
            },
...
          [
            "contact-uri",
            {},
            "uri",
            "https://whois.blacknight.com/contact.php?fqdn=blacknight.com&contact_type=owner"
          ]
    
On a bien un usage de ces extensions dans le monde réel (merci à Patrick Mevzek pour ses remarques et ajouts).

2019-09-03

☕︎ Déconstruire

Cette semaine, tentative de reconstruction de mon dos. Trois jours en forêt pour méditer, faire voler des hameçons au-dessus du raft, analyser le poids que j’ai sur les épaules.

Déconstruire l’espoir de pouvoir aller à l’encontre de l’effondrement de cette civilisation. Accepter que les survivants feront au mieux avec ce qu’il leur restera. Accepter d’avoir sa part de responsabilité et d’impuissance. Au même titre que les nouveaux optimistes (cache), ces vieux milliardaires repentis.

Accompagner des enfants.

Déconstruire le fait que la première chose qu’apprenne les enfants en maternelle à l’école publique au Québec en 2019 c’est à se mettre en rang. Les filles d’un côté, les garçons de l’autre.

L’année va être longue.

Déconstruire l’imaginaire que les femmes ne peuvent pas arriver avant les hommes (cache). C’est à la fois triste et ironique. J’ai tout de même un peu de mal à en rire.

Laisser courir.

Déconstruire le fait qu’il ne puisse y avoir un respect de la nature dans nos sociétés actuelles. Que la piste de protection ne peut être économique (cache). Accepter que le Web soit un acteur majeur de cet irrespect (cache). Et que les concepteurs n’aient pas la moindre empathie (cache) alors que les solutions techniques existent (cache).

Construire une cabane. Loin…

Déconstruire les réflexes patriarcaux même et encore plus lorsqu’ils sont liés au capitalisme (cache). Continuer à douter (cache), à écouter, à évoluer, à admettre.

Déconstruire l’immonde pour (re)construire son monde.

RFC 8615: Well-Known Uniform Resource Identifiers (URIs)

Plusieurs normes du Web s'appuient sur l'existence d'un fichier à un endroit bien connu d'un site. Les deux exemples les plus connus sont robots.txt et favicon.ico. Autrefois, ces endroits « bien connus » étaient alloués sans schéma central. Depuis le RFC 5785, c'est mieux organisé, avec tous ces fichiers « sous » /.well-known/. Notre RFC remplace le RFC 5785 (et le RFC 8307), avec peu de changements significatifs.

Prenons l'exemple le plus connu, robots.txt, fichier stockant la politique d'autorisation des robots qui fouillent le Web. Si un robot examine le site Web http://www.example.org/, il va tenter de trouver ledit fichier en http://www.example.org/robots.txt. Même chose pour, par exemple, sitemap.xml ou P3P (section 1 du RFC). Ce système avait plusieurs inconvénients, notamment le risque de collision entre deux noms (puisqu'il n'y avait pas de registre de ces noms) et, pire, le risque de collision entre un de ces noms et une ressource normale du site. D'où l'importance d'un « rangement » de ces ressources bien connues. Elles doivent dorénavant être préfixées de /.well-known/. Ainsi, si le protocole d'autorisation des robots était normalisé aujourd'hui, on récupérerait la politique d'autorisation en http://www.example.org/.well-known/robots.txt.

À noter que le RFC spécifie uniquement un préfixe pour le chemin de la ressource, /.well-known/ n'est pas forcément un répertoire sur le disque du serveur (même si c'est une mise en œuvre possible).

Le RFC 8615 note aussi qu'il existe déjà des mécanismes de récupération de métadonnées par ressource (comme les en-têtes de HTTP ou les propriétés de WebDAV) mais que ces mécanismes sont perçus comme trop lourds pour remplacer la ressource unique située en un endroit bien connu.

Le nom .well-known avait été choisi (cf. annexe A de notre RFC) car il avait peu de chances de rentrer en conflit avec un nom existant (traditionnellement, sur Unix, système d'exploitation le plus utilisé sur les serveurs Web, les fichiers dont le nom commencent par un point ne sont pas affichés).

Bref, passons à la section 3 qui donne les détails syntaxiques. Le préfixe est donc /.well-known/, les noms en « dessous » doivent être enregistrés (cf. section 5.1), et ils doivent se conformer à la production segment-nz du RFC 3986 (en clair, cela veut dire qu'ils doivent être une suite de caractères ASCII imprimables, avec quelques exclusions comme la barre oblique). Du point de vue sémantique, ils doivent être précis, pour éviter l'appropriation de termes génériques (par exemple, l'application Toto qui veut stocker ses métadonnées devrait utiliser toto-metadata et pas juste metadata.) À noter que l'effet d'une requête GET /.well-known/ (tout court, sans nom de ressource après), est indéfini (sur mon blog, cela donne ça ; devrais-je le configurer pour renvoyer autre chose ? Sur Mastodon, ça donne 404.)

Quelques conseils de sécurité pour le webmestre (section 4) : ces ressources « bien connues » s'appliquent à une origine (un « site Web ») entière, donc attention à contrôler qui peut les créer ou les modifier, et d'autre part, dans le contexte d'un navigateur Web, elles peuvent être modifiées par du contenu, par exemple JavaScript.

La section 5 décrit les conditions d'enregistrement des noms bien connus à l'IANA. Le registre contient par exemple les métadonnées du RFC 6415. Y mettre des noms supplémentaires nécessite un examen par un expert et une description publiée (pas forcément un RFC). Dans les termes du RFC 8126, ce sera Spécification Nécessaire et Examen par un Expert. Il y a un mini-formulaire à remplir (section 3.1 du RFC) et hop, le nom bien connu sera enregistré. Plusieurs existent désormais.

Notez qu'il est très difficile de savoir combien de sites ont des ressources /.well-known. Bien sûr, Google le sait, mais ne donne pas accès à cette information (une requête inurl:/.well-known ou inurl:"/.well-known" ignore hélas le point initial et trouve donc surtout des faux positifs). Si on n'a pas accès à la base de Google, il faudrait donc faire soi-même une mesure active avec un client HTTP qui aille visiter de nombreux sites.

Les changements depuis le RFC 5785 sont résumés dans l'annexe B du RFC :

  • Les plans d'URI pour WebSocket, du RFC 8307, ont été intégrés,
  • D'ailleurs, le préfixe /.well-known/ n'est plus réservé au Web, il peut être utilisé pour d'autres plans d'URI, ce qui a modifié le registre des plans pour y ajouter une colonne indiquant s'ils permettent ce préfixe (section 5.2),
  • Les instructions pour l'enregistrement d'un nouveau nom ont été légèrement assouplies,
  • La section sur la sécurité est nettement plus détaillée.

2019-09-02

RFC 8624: Algorithm Implementation Requirements and Usage Guidance for DNSSEC

Quel algorithme de cryptographie choisir pour mes signatures DNSSEC, se demande l'ingénieur système. Lesquels doivent être reconnus par le logiciel que j'écris, s'interroge la programmeuse. Il y a bien un registre IANA des algorithmes normalisés mais c'est juste une liste non qualifiée, qui mêle des algorithmes de caractéristiques très différentes. Ce nouveau RFC vise à répondre à cette question en disant quels sont les algorithmes recommandés. Il remplace l'ancien RFC 6944, qui est modifié considérablement. Notamment, il marque l'avantage désormais donné aux courbes elliptiques par rapport à RSA.

La précédente liste d'algorithmes possibles datait donc du RFC 6944. D'autres algorithmes ont été ajoutés par la suite. Certains sont devenus populaires. Par exemple, ECDSA est maintenant suffisamment répandu pour qu'un résolveur validant ne puisse plus raisonnablement l'ignorer. D'autres algorithmes ont été peu à peu abandonnés, par exemple parce que les progrès de la cryptanalyse les menaçaient trop.

Aujourd'hui, le développeur qui écrit ou modifie un signeur (comme ldns, utilisé par OpenDNSSEC) ou un logiciel résolveur validant (comme Unbound ou Knot) doit donc se taper pas mal de RFC mais aussi pas mal de sagesse collective distillée dans plusieurs listes de diffusion pour se faire une bonne idée des algorithmes que son logiciel devrait gérer et de ceux qu'il peut laisser tomber sans trop gêner ses utilisateurs. Ce RFC vise à lui simplifier la tâche, en classant ces algorithmes selon plusieurs niveaux.

Notre RFC 8624 détermine pour chaque algorithme s'il est indispensable (MUST, nécessaire pour assurer l'interopérabilité), recommandé (RECOMMENDED, ce serait vraiment bien de l'avoir, sauf raison contraire impérieuse), facultatif (MAY, si vous n'avez rien d'autre à faire de vos soirées que de programmer) ou tout simplement déconseillé (NOT RECOMMENDED), voire à éviter (MUST NOT, pour le cas de faiblesses cryptographiques graves et avérées). Il y a deux catégorisations, une pour les signeurs (le cas de l'administratrice système cité au début), et une pour les résolveurs qui valideront. Par exemple, un signeur ne devrait plus utiliser RSA avec SHA-1, vu les faiblesses de SHA-1, mais un résolveur validant doit toujours le traiter, car des nombreux domaines sont ainsi signés. S'il ignorait cet algorithme, bien des zones seraient considérées comme non signées.

La liste qualifiée des algorithmes se trouve dans la section 3 : ECDSA avec la courbe P-256, et RSA avec SHA-256, sont les seuls indispensables pour les signeurs. ED25519 (RFC 8080) est recommandé (et sera probablement indispensable dans le prochain RFC). Plusieurs algorithmes sont à éviter, comme DSA, GOST R 34.10-2001 (RFC 5933) ou RSA avec MD5 (RFC 6151). Tous les autres sont facultatifs.

Pour les résolveurs validants, la liste des indispensables et des recommandés est un peu plus longue. Par exemple, ED448 (RFC 8080) est facultatif pour les signeurs mais recommandé pour les résolveurs.

La même section 3 justifie ces choix : RSA+SHA-1 est l'algorithme de référence, celui qui assure l'interopérabilité (tout logiciel compatible DNSSEC doit le mettre en œuvre) et c'est pour cela qu'il reste indispensable pour les résolveurs, malgré les faiblesses de SHA-1. RSA+SHA-256 est également indispensable car la racine et la plupart des TLD l'utilisent aujourd'hui. Un résolveur qui ne comprendrait pas ces algorithmes ne servirait pas à grand'chose. RSA+SHA-512 ne pose pas de problème de sécurité, mais a été peu utilisé, d'où son statut « non recommandé » pour les signeurs.

D'autre part, le RFC insiste sur le fait qu'on ne peut pas changer le statut d'un algorithme trop vite : il faut laisser aux ingénieurs système le temps de changer leurs zones DNS. Et les résolveurs sont forcément en retard sur les signeurs : même si les signeurs n'utilisent plus un algorithme dans leurs nouvelles versions, les résolveurs devront continuer à l'utiliser pour valider les zones pas encore migrées.

Depuis le RFC 6944, ECDSA a vu son utilisation augmenter nettement. Les courbes elliptiques sont clairement l'avenir, d'où leur statut mieux placé. Ainsi, une zone DNS qui n'était pas signée et qui va désormais l'être devrait choisir un algorithme à courbes elliptiques, comme ECDSA ou EdDSA (RFC 8032 et RFC 8080). Avec ECDSA, il est recommandé d'utiliser l'algorithme déterministe du RFC 6979 pour générer les signatures. Les zones actuellement signées avec RSA devraient migrer vers les courbes elliptiques. Une chose est sûre, la cryptographie évolue et ce RFC ne sera donc pas éternel.

Le RFC note d'ailleurs (section 5) que le remplacement d'un algorithme cryptographique par un autre (pas juste le remplacement d'une clé) est une opération complexe, à faire avec prudence et après avoir lu les RFC 6781 et RFC 7583.

Ah, et parmi les algorithmes à courbes elliptiques, GOST (RFC 5933) régresse car l'ancien algorithme R 34.10-2001 a été remplacé par un nouveau qui n'est pas, lui, normalisé pour DNSSEC. L'algorithme venant du GOST avait été normalisé pour DNSSEC car les gérants du .ru disaient qu'ils ne pouvaient pas signer avec un algorithme étranger mais, finalement, ils ont utilisé RSA, ce qui diminue sérieusement l'intérêt des algorithmes GOST.

Outre les signeurs et les résolveurs, le RFC prévoit le cas des registres, qui délèguent des zones signées, en mettant un enregistrement DS dans leur zone. Ces enregistrements DS sont des condensats de la clé publique de la zone fille, et, ici, SHA-1 est à éviter et SHA-256 est indispensable.

Aujourd'hui, les mises en œuvre courantes de DNSSEC sont en général compatibles avec ce que demande le RFC. Elles sont parfois trop « généreuses » (RSA+MD5 encore présent chez certains), parfois un peu trop en retard (ED448 pas encore présent partout).

2019-08-30

RFC 5933: Use of GOST signature algorithms in DNSKEY and RRSIG Resource Records for DNSSEC

L'algorithme de signature russe GOST R 34.10-2001 ayant été spécifié en anglais dans le RFC 5832, plus rien ne s'opposait à son utilisation dans DNSSEC. Ce RFC marque donc l'arrivée d'un nouvel algorithme dans les enregistrements DNSSEC, algorithme portant le numéro 12. (Depuis, le GOST R 34.10-2012 a été publié, mais pas normalisé pour DNSSEC.)

La liste originelle des algorithmes DNSSEC figurait dans le RFC 4034, annexe A.1. La liste actuelle est un registre à l'IANA, https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml#dns-sec-alg-numbers-1. Elle comprend désormais GOST. Notez que GOST désigne en fait une organisation de normalisation, le terme correcte serait plutôt « GOST R 34.10-2001 » pour l'algorithme de signature et « GOST R 34.11-94 » pour celui de condensation, décrit dans le RFC 5831 (voir la section 1 de notre RFC 5933).

La section 2 décrit le format des enregistrements DNSKEY avec GOST, dans lequel on publie les clés GOST R 34.10-2001. Le champ Algorithme vaut 12, le format de la clé sur le réseau suit le RFC 4491. GOST est un algorithme à courbes elliptiques, courbes décrites par Q = (x,y). Les 32 premiers octets de la clé sont x et les 32 suivants y (en petit-boutien, attention, contrairement à la majorité des protocoles Internet). Les autres paramètres de la clé figurent dans le RFC 4357.

Les bibliothèques cryptographiques existantes sont parfois capables de lire des clés GOST (section 2.1). Pour OpenSSL, il existe une distribution de GOST (par la même entreprise où travaille l'auteur des RFC GOST).

La section 2.2 donne un exemple de clé GOST publiée dans le DNS mais autant utiliser ici un exemple réel (ce domaine a des clés GOST et aussi des clés RSA de type 5) :


% dig +multi DNSKEY caint.su

; <<>> DiG 9.9.2 <<>> +multi DNSKEY caint.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61873
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;caint.su.              IN DNSKEY

;; ANSWER SECTION:
caint.su.               3600 IN DNSKEY 256 3 12 (
                                HQUwRfZDsGuso1XEVztO9nIt7S6MrC/XNYQ9Agup8oW0
                                FCfy0T52buB3czWe9YHa0kLgrcFP1pHpu19jdmO70A==
                                ) ; ZSK; alg = ECCGOST; key id = 35724
caint.su.               3600 IN DNSKEY 257 3 5 (
                                AwEAAdfmAyxcSu09Ik449sIGygbD78jxCKaBek3fhC1a
                                hO7363pdMGlXf8ZEzv7Kl+9yOokmMoTI0peVUqF57it3
                                hmqcIJQ+OsrKdsF1XBwa8VULaLh+TNb67dkdbj6iZ6Gd
                                WxkD6i2vbjvmVHtoQyKswgeR7lUn42XMRYRbYiIrI5r8
                                zT/xllwtCCxaC68V6azpk//7GrYpnwS9NGzr2cBignwj
                                Jj6VeAGfrBe5AM0XNplaFLf7NNU34qqGBKpYbogdAYzM
                                Il02dhPvruzDcadbm2a53OI2/fqchjOgZ8wSTfekuJQb
                                ReYWsNUasgqxjydMU5vweSiogGqkrUEzqn5PD/0=
                                ) ; KSK; alg = RSASHA1; key id = 697
caint.su.               3600 IN DNSKEY 257 3 12 (
                                qMxkfdx4fNxdLDU3z5KGAxrEiL1fm+dxw03js+ACY996
                                wc1wYiVbmqA1QVUmLg5bO3/IawdItM3jQcigFEi/3A==
                                ) ; KSK; alg = ECCGOST; key id = 33831
caint.su.               3600 IN DNSKEY 256 3 5 (
                                AwEAAawWrWjeYqJ+07pakuybnkLQz3xbe1rnG2g7ihfO
                                NpSLNYrNOyhcCTRbt3cgJLWR29Qh6uko9Zcd9uylHlY1
                                ru1HpBQxpzKffwUUki2e7SiTiGrj/DvJz9UH52VZyxi5
                                qf9neYBz0sxvlrLWC5JMqqGIBRUMx/clPjab72BV7exR
                                ) ; ZSK; alg = RSASHA1; key id = 15876

;; Query time: 326 msec
;; SERVER: 192.168.2.254#53(192.168.2.254)
;; WHEN: Tue Oct 23 15:59:57 2012
;; MSG SIZE  rcvd: 621


La section 3 décrit le format des enregistrements RRSIG, les signatures. On suit les RFC 4490 et RFC 4357. Voici un exemple actuellement présent dans le DNS (notez qu'il y a double signature, avec RSA et GOST, la clé GOST étant la 35724) :


dig +dnssec MX caint.su

; <<>> DiG 9.9.2 <<>> +dnssec MX caint.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61031
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 10

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;caint.su.                      IN      MX

;; ANSWER SECTION:
caint.su.               3600    IN      MX      10 mail.caint.su.
caint.su.               3600    IN      RRSIG   MX 5 2 3600 20121027063752 20120927063752 15876 caint.su. E5d1eZxLgYxNg1YiNXEyQ5UGJFOyd09bmpo9AtwnpJn0ezSX0wsAnvd1 ExBWf9ue0TnPSknZxofevtOHD3cBw09Lq/ZathhEOvNhHaK4kbMEXWm7 KzwLeNDDhqNbhAbY0duDLEPCA69ege00dJFjBMtqV17TTJ13BxrFXNzs Hmk=
caint.su.               3600    IN      RRSIG   MX 12 2 3600 20121027063752 20120927063752 35724 caint.su. 52NgPC9ZmFwIgL8CsK0C+wwoM+brh4uTfw70yRDJTjbkUVivkdCakDIS YVxPLWaQO6mDMzNwC53QYqwUyEYlEQ==

...

Attention, une particularité de GOST fait que deux signatures des mêmes données peuvent donner des résultats différents, car un élément aléatoire est présent dans la signature.

La section 4 décrit le format des enregistrements DS pour GOST. La clé publique de la zone fille est condensée par GOST R 34.11_94, algorithme de numéro 3. Voici un exemple dans la nature :

% dig DS caint.su
...
caint.su.               345330  IN      DS      33831 12 3 267B93EB54BF7707BF5500900722F3B0FBFCA04FF4F1BF22735F9ABB 607832E2
Notez que ce domaine a d'autres clés et aussi la même clé condensée par les algorithmes de la famille SHA, soit six DS en tout. Ou un autre exemple dans .fr ?
absolight.fr.		172724 IN DS 12545 8 3 (
				DDA74E5E94CEA6057072B073F60A5DD37D16DC8E896A
				EC57B055888DB84B4210 )

Les sections 5 et 6 couvrent des questions pratiques liées au développement et au déploiement de systèmes GOST, par exemple un rappel sur la taille de la clé (512 bits) et sur celle du condensat cryptographique (256 bits).

GOST peut se valider avec Unbound (au moins depuis la version 1.4.4, voir l'option de compilation --enable-gost) et avec BIND (depuis la version 9.8, si elle est compilée avec un OpenSSL qui a GOST). nsd a GOST depuis la version 3.2.11, pubiée en juillet 2012. Pour les programmeurs Java, DNSjava a GOST depuis la version 2.1.7. Pour le statut (recommandé ou non) de l'algorithme GOST pour DNSSEC, voir le RFC 8624. On peut trouver des conseils pratiques pour l'utilisation de GOST en anglais à http://www.cryptocom.ru/dns/dnssec-cryptocom-en.html.

2019-08-27

☕︎ Documenter

Une semaine à notamment s’interroger sur ce qui fait coopérative. Et peut-être qu’il s’agit d’avoir une histoire commune à raconter. Partager non pas ce que l’on a fait ensemble mais ce que l’on a été ensemble. Réflexion à poursuivre… à documenter ?

Ce document est une forme expérimentale de backlog, c’est ici que nous allons écrire, décrire ce que le service fait ou va faire. Peut-être pourrait-on l’appeler documentation vivante, mais n’ayant pas encore lu le livre de Cyrille Martraire Living Documentation, je me garderais bien d’utiliser ce terme.

Les phrases gras qui commence par En attendant correspondent à des choses qui ont été faite rapidement dans l’application en attendant mieux.

Les phrase en italique qui commence par En option et qui utilise le conditionnel, correspondent à des choses qui pourrait être faite plus tard, afin d’améliorer l’utilisation du service.

DaTrust (cache)

Yannick explore des choses et c’est un sujet qui m’intéresse beaucoup (notamment car je participe à des équipes distribuées). Introduire de l’écriture dans le processus de création, non pas a priori mais pendant pour savoir comment est-ce que l’on en est arrivé là a posteriori. Quelles étaient les intentions sous-jacentes ? Dans quel contexte ces choix ont été faits à l’époque ? Etc.

Tout en rendant cette histoire explicite et consultable et pouvant être enrichie par toutes les personnes du produit.

I didn’t know how to write a book. But I did know how to give a workshop. […] The workshop was a prototyping device. It was going to do three things:

  • Force me to come up with a full day’s worth of content that could eventually become a book.
  • Get instant feedback from an audience to learn what’s interesting, what resonates and what doesn’t.
  • Put something out into the world that people could buy, so I could interview them afterward using the jobs-to-be-done approach.

How I Wrote Shape Up (cache)

Ryan Singer explique le processus d’écriture de Shape Up (cache, PDF, 20 Mo), dont je n’ai pas encore pris le temps de parler. J’apprécie beaucoup le partage de ce processus car il m’offre des pistes de réflexion pour documenter ma propre façon de travailler.

Lean Writing?

June 1, 2020: users will not be able to use Mercurial features in Bitbucket or via its API and all Mercurial repositories will be removed.

Sunsetting Mercurial support in Bitbucket (cache)

Git a gagné. Cela me désole qu’il puisse y avoir un monopole de la décentralisation. Enfin encore faudrait-il voir ce que l’on entend par décentralisation lorsqu’il y a un oligopole d’acteurs mais passons.

En voyant le verre à moitié plein, cela va me permettre de faire du ménage dans l’historique de ce qui est publié (actuellement sous mercurial). Et peut-être le rendre public ? Je vois la valeur que cela pourrait avoir. Et en même temps pour moi l’écriture est une pratique relativement intime.

Peut-être que cela me permettrait d’en apprendre davantage sur mon propre processus ?

Many parents and pediatricians speculate about the role that screen time and social media might play in this social deficit. But it’s important to acknowledge that simply taking away or limiting screens is not enough. Children turn to screens because opportunities for real-life human interaction have vanished; the public places and spaces where kids used to learn to be people have been decimated or deemed too dangerous for those under 18.

We Have Ruined Childhood (cache)

No kidding.

Pun intended.

But the real tragedy of modern technology is that it’s turned us into consumers. Our voracious consumption of media parallels our consumption of fossil fuels, corn syrup, and plastic straws. And although we’re starting to worry about our consumption of those physical goods, we seem less concerned about our consumption of information.

We treat information as necessarily good, and comfort ourselves with the feeling that whatever article or newsletter we waste our time with is actually good for us. We equate reading with self improvement, even though we forget most of what we’ve read, and what we remember isn’t useful.

Consume less, create more (cache)

Est-ce que le ratio créateur·ice·s/consommateur·ice·s a évolué au cours du temps ? Est-ce qu’il peut même évoluer compte tenu de l’importance d’avoir des comsommateur·ice·s pour se motiver à créer ?

Le stylo/pinceau/clavier invisible de la création.

Le 18 décembre 2018, cailloux n°18, six minutes et trente-cinq secondes de grâce.

cailloux n°44 : premier anniversaire (cache)

Merci Alexia de ressortir des archives ce petit caillou/bijou que j’avais loupé. Sur un morceau que j’apprécie énormément.

Au passage, Alternate Tube Redirector sauve des ours blancs et réduit votre exposition aux algorithmes de Google.

Today, we are updating our advertising policies with respect to state media. Going forward, we will not accept advertising from state-controlled news media entities. […] We are exploring transparency approaches to keep the public updated on these types of actions going forward.

Updating our advertising policies on state media (cache)

Commencer par documenter pourquoi est-ce que l’on prend une telle décision serait la moindre des choses.

La base en fait.

Citation de la semaine :

Le froid, le silence et la solitude sont les trois produits de luxe du monde contemporain.

Une vie à coucher dehors, Sylvain Tesson

À méditer lors de ma prochaine balade dans les bois. Le froid s’en vient.

P.S. : toujours intéressant de voir à partir de quand est-ce que l’on a les pieds dans l’eau lorsqu’on habite sur une île.

2019-08-26

★ Faire équipe

Ceci n’est pas une recette, encore moins une méthode. Il s’agit d’un instantané, d’une histoire, d’un témoignage. Le récit d’une année à faire équipe. Faire car il s’agit d’une attention permanente pour réussir à grandir ensemble. Équipe car des liens suffisamment forts se sont formés pour avoir envie de continuer.

Est-ce que le fait qu’on soit une équipe distribuée et asynchrone change quelque chose ? Est-ce que le fait qu’il y ait une certaine diversité dans l’équipe influe sur nos relations ? Est-ce qu’il y aurait des choses à améliorer ? Je n’en ai aucune idée. Et cela ne m’intéresse pas dans ce contexte, car justement il est changeant. Aussi, je vais davantage me concentrer sur le comment… faute d’avoir trouvé un pourquoi.

L’équipe

Nous sommes cinq et aucun de nous n’est à plein temps sur le produit (cache) :

  • Mélodie a la connaissance métier
  • Ronan code avec moi
  • Maïtané rend le produit utilisable
  • Raphael est là en soutien

Les rôles ne sont pas pour autant figés, sur une petite équipe il est de toute façon nécessaire de pouvoir emprunter la casquette de l’autre, ne serait-ce que pendant des vacances.

Les rituels

Une journée type lorsqu’on a six heures de décalage horaire.

Je me lève et je regarde ce qui s’est dit dans la matinée française. Le niveau de stress est assez bas car je sais que Ronan peut être sur le pont avant moi. J’enchaîne en faisant un tour du côté du code pour voir s’il y a de nouvelles propositions et/ou commentaires.

Lorsque je me sens apte à parler (pas évident au réveil), je propose à Ronan ou Maïtané de travailler ensemble sur une fonctionnalité si le contexte et l’enthousiasme s’y prêtent. Sinon, je picore dans la liste des choses à faire.

En fin de matinée (pour moi), on papote avec Mélodie et les présent·e·s, en moyenne autour d’une heure par jour je dirais. C’est un temps important pour s’accorder et transmettre des informations sur la vie du produit, notamment lorsqu’on est à distance. C’est aussi le moment où je discute d’un plus gros morceaux à faire lorsque les autres ont décroché·e·s.

Mon après-midi ou ma soirée (ça dépend de la météo) est généralement consacrée à une tâche demandant une concentration plus profonde, ce qui est l’idéal car je suis moins sollicité. En parallèle, je garde un œil sur le serveur de production si c’est un moment législatif particulier.

Et on recommence le lendemain. Ou presque.

Tous les mois, il y a une démonstration qui nous permet d’échanger avec les utilisateurs et utilisatrices sur ce que nous développons. Ce qui vient ajuster la liste des choses à faire afin d’être plus proche de leurs besoins.

Quand on en ressent le besoin on se fait une rétrospective, à peu près tous les quatre/cinq mois. L’occasion de prendre un peu de recul et de se rappeler qu’on aime bien travailler ensemble.

Lorsqu’il y a un gros morceau qui nécessite d’en discuter de manière plus avancée, on n’hésite pas à prendre le temps de penser à distance. Lorsqu’il y a des petits tracas personnels, on n’hésite pas non plus à panser à distance.

Tous les ans, on se retrouve physiquement. Bon ok, ça n’est arrivé qu’une fois mais statistiquement ça se tient :-).

Les pratiques

Commençons par la technique car c’est plutôt mon domaine.

On passe du temps à coder ensemble avec Ronan. On ne se l’impose pas pour autant, ça dépend beaucoup de la motivation du moment. On écrit des tests, on fait des revues de code, rien d’extravagant.

Ce qui est moins courant, c’est que l’on passe du temps à designer ensemble avec Maïtané aussi. On se partage un écran et on passe en revue ce qui ne va pas afin de corriger cela en direct.

Autant le pair-programming me semble être une pratique relativement courante, autant le pair-designing (?) est moins documenté. Cela apporte pourtant une grande valeur au produit et à la cohérence de ce qui est développé. Sans compter le fait de s’accorder dans l’équipe sur la pertinence de certains éléments.

Mais en fait tout cela n’est rien sans des retours de nos utilisateur·ice·s.

Les démonstrations sont une excuse pour discuter avec les personnes qui utilisent notre outil et savoir comment est-ce qu’elles appréhendent certaines fonctionnalités ou les problèmes qu’elles ont rencontré dans leur cas particulier.

Comme cela ne suffit pas pour identifier tous les irritants, Mélodie et Maïtané vont régulièrement observer sur place comment travaillent en vrai les personnes. Quelles sont leurs habitudes avec les onglets, quels sont les chemins courants qui pourraient être simplifiés, qu’est-ce qui est complètement ignoré dans le feu de l’action, etc.

Les joies

For a long time I believed that a strong team is made of stars — extraordinary world-class individuals who can generate and execute ideas at a level no one else can. These days, I feel that a strong team is the one that feels more like a close family than a constellation of stars. A family where everybody has a sense of predictability, trust and respect for each other. A family which deeply embodies the values the company carries and reflects these values throughout their work. But also a family where everybody feels genuinely valued, happy and ignited to create.

Vitaly Friedman on LinkedIn (cache)

Les rituels, les pratiques, tout cela semble très analytique et pourtant c’est autre chose qui se produit au quotidien. On voit les autres évoluer et on se sent évoluer grâce aux différentes interactions que l’on peut avoir. On partage davantage que du code ou un produit, un bout de chemin que l’on fait ensemble et qui donne envie d’aller de l’avant. En trouvant un équilibre entre monotonie et apprentissage qui satisfasse chacun·e d’entre nous.

Peut-être est-ce cela faire équipe : partager l’enthousiasme de faire des choses ensemble qui permettent de mieux se connaître. Et si je me connais bien davantage aujourd’hui c’est après avoir eu l’occasion d’échanger avec ces personnes bienveillantes. C’est après avoir traversé des périodes anxiogènes en se serrant les coudes. C’est enfin avoir su s’adapter pour communiquer autant au sein de l’équipe qu’avec notre contexte de manière sereine.

L’arithmétique

J’ai déjà parlé du mythe des 10x engineers, je crois de plus en plus en la somme des individus qui forme un tout plus pertinent. Le fameux 1 + 1 = 3 appliqué à un périmètre plus large. Et par pertinent j’entends harmonieux et enthousiasmant plus que productif et efficace. Je vais donner quelques exemples pour préciser.

Je pourrais coder pendant une année complète tout seul sur un produit. Ça m’est arrivé par exemple quand j’étais au Japon. Et je sais que dans ces conditions, la qualité en pâtit. Pas seulement la qualité du code mais la qualité de mon apprentissage autour de celui-ci (qui est relativement lié à ma qualité de vie). Depuis, je fais mon possible pour ne pas me retrouver dans cette situation à nouveau et j’ai du plaisir à pouvoir échanger sur mes pratiques au quotidien. Parenthèse : c’est aussi pour cela que je ne suis plus à mon compte, ce que je (re)trouve dans scopyleft c’est cette capacité à apprendre et réfléchir par l’échange.

Autre exemple, on peut faire une interface peu avenante et fonctionnelle. On peut recruter quelqu’un·e pour faire des maquettes. Mais lorsque toute l’équipe s’y met on a une combinaison de contraintes techniques, de contraintes métiers, de retours utilisateur·ice·s et d’inspirations diverses pour arriver au compromis qui soit satisfaisant pour toutes et tous. Avoir quelqu’un qui tient la barre dans ce domaine est un plus indéniable et quand tout l’équipage est sur le pont pour réussir à garder le cap ça permet d’y aller de manière plus sereine.

Enfin, une personne peut porter un projet toute seule. Mais sans échanges réguliers avec l’équipe, la responsabilité qui lui incombe va finir par altérer son jugement et son humeur. C’est normal, c’est même sain. Il faut un moyen de décharger les frictions et rien ne vaut pour cela le soutien de celles et ceux embarqué·e·s dans la même aventure.

Les mystères

Est-ce que c’est pour autant double rainbow all the way tous les jours ? Non. Est-ce qu’on code tout parfaitement du premier coup ? Encore moins. Est-ce qu’on œuvre pour le bien commun ou pour le gouvernement ? ¡Porque no los dos! Est-ce qu’on s’envoie des gifs et des vidéos toute la journée ? Mème pas.

Plus sérieusement, est-ce que ça va durer et/ou est-ce que c’est reproductible ? Difficile de répondre à ces deux questions aussi je les assimile à des mystères. Et j’arrive plutôt bien à vivre avec ainsi :-).

Conclusion

Au-delà de la notion de faire équipe, il y a celle plus globale de savoir-agir qui vient mettre en pratique des savoir-être et des savoir-faire. Peut-être est-ce qu’il s’agit là de l’un des savoirs essentiels à notre temps et tellement négligé. Au moment où l’on encourage à devenir un consomm’acteur qui s’assimile pour moi à un avoir-agir, il me semblerait pertinent d’essayer d’apprendre à faire ensemble.

Si possible à plus de cinq.

Est-ce que ce témoignage a été utile ? Difficile à évaluer tout seul, on en discute pour essayer de le rendre plus pertinent ?

???

2019-08-22

La vie privée à l'ère du RGPD

Samedi 24 mars 2018, aux JDLL (Journées du Logiciel Libre) à Lyon, j'ai fait un exposé sur la question de La vie privée sur l’Internet à l’ère du RGPD.

Je sais, le RGPD est un sujet à la mode. Mais ce n'est pas une raison pour ne pas en parler. Les supports de l'exposé :

Et voici aussi des jolies photos de l'évènement.

RFC 8612: DDoS Open Threat Signaling (DOTS) Requirements

Les attaques par déni de service, et notamment les dDoS (distributed Denial of Service), sont une des principales plaies de l'Internet. Le projet DOTS (DDoS Open Threat Signaling) à l'IETF vise à développer un mécanisme de signalisation permettant à des acteurs de la lutte anti-dDoS d'échanger des informations et de se coordonner, même lorsque l'attaque fait rage. Par exemple, un mécanisme DOTS permettra à un client d'un service de traitement des attaques de demander à son fournisseur d'activer le filtrage anti-dDoS. Ce RFC est le premier du projet : il décrit le cahier des charges.

Ces attaques par déni de service (décrites dans le RFC 4732) peuvent être utilisées à des fins financières (racket), lors d'affrontements inter-étatiques (comme dans le cas estonien souvent cité), à des fins de censure contre des opposants politiques. Le risque est particulièrement élevé pour les « petits ». En effet, beaucoup d'attaques par déni de service reposent sur la taille : par exemple, l'attaquant envoie tellement d'octets qu'il sature la ou les connexions Internet de sa victime. La seule solution est alors de louer un tuyau plus gros, ce qui n'est pas toujours financièrement possible. Les attaques dDoS favorisent donc les plus riches. Aujourd'hui, par exemple, un petit hébergeur Web a le plus grand mal à faire face à d'éventuelles attaques, ce qui rend difficile l'hébergement associatif et/ou décentralisé. Les attaques par déni de service ont donc des conséquences bien au-delà des quelques heures d'indisponibilité du service : elles encouragent la centralisation des services, puisqu'il faut être gros pour encaisser le choc. C'est ainsi qu'aujourd'hui beaucoup d'organisations sont chez Cloudflare, dépendant de cette société privée étatsunienne pour leur « protection ». On est dans l'équivalent moderne de la relation féodale au Moyen-Âge : le paysan seul, ou même le village, est trop vulnérable, il doit chercher la protection d'un seigneur, en échange de sa soumission.

Il est très difficile de se protéger contre les attaques par déni de service. Et le projet DOTS ne va pas proposer de solution magique, uniquement des mécanismes de cooordination et d'échange en cas d'attaque. La réponse à une attaque dDoS consiste typiquement à examiner les paquets entrants, et à jeter ceux qui semblent faire partie de l'attaque. (Voir par exemple mon article sur le filtrage.) Il faut bien sûr le faire le plus tôt possible. Si vous êtes connecté à l'Internet par un lien de capacité 1 Gb/s, et que l'attaquant arrive à le saturer par les paquets qu'il envoie, trier les paquets de votre côté ne servira à rien, cela serait trop tard ; ils doivent être triés en amont, par exemple chez votre opérateur. Et, évidemment, trier n'est pas trivial, les paquets ne sont pas marqués comme participant à l'attaque (sauf si on utilise le RFC 3514, mais regardez sa date de publication). Il y aura donc toujours des faux positifs, des paquets innocents jetés. (Pour un exemple de solution anti-dDoS, voir le VAC d'OVH, et les nombreux articles qui lui ont été consacrés.) En 2019, beaucoup d'organisations ne font plus ce tri elles-mêmes (par manque de moyens financiers, et surtout humains) mais sous-traitent à un fournisseur spécialisé (comme Arbor, pour lequel travaille un des auteurs du RFC). On envoie le trafic vers ce fournisseur, par des astuces DNS ou BGP, il le trie, et vous renvoie ce qui lui semble inoffensif. Ce tri se nomme en anglais scrubbing. Ces fournisseurs sont donc un élement critique, par exemple parce qu'ils voient passer tout votre trafic. En général, on active ce service à la demande, et cette activation est un des scénarios d'utilisation de DOTS les plus cités dans le RFC.

Actuellement, l'activation du service de scrubbing se fait via des interfaces privatrices, fournies par le « protecteur », ce qui contribue à enfermer le client dans sa relation avec le fournisseur. Et puis, parfois, il faut que plusieurs acteurs participent à la réponse à attaque. D'où l'idée du projet DOTS (dDoS Open Threat Signaling) qui va développer une interface normalisée, au sein du groupe de travail du même nom à l'IETF.

La section 1.2 du RFC précise le terminologie employée : DOTS sera client/serveur, le client DOTS étant chez la victime, qui cherche une solution, et le serveur DOTS étant chez le protecteur (mitigator dans le RFC). Rappelez-vous que DOTS ne normalise pas les méthodes de protection (elles évoluent vite, même si le motif « tri puis poubellisation des paquets » reste dominant), mais uniquement la communication entre les acteurs impliqués. Les différents acteurs communiquent avec deux sortes de canaux, les canaux de signalisation et les canaux de données. Les premiers sont prévus pour des messages assez courts (« jette tous les paquets à destination du port NNN ») mais qui doivent arriver à tout prix, même en cas d'attaque intense ; ils sont le cœur du système DOTS, et privilégient la survivabilité. Les seconds, les canaux de données, sont prévus pour de grandes quantités de données, par exemple pour envoyer le trafic trié ou bien pour envoyer des informations de configuration, comme la liste des préfixes IP à protéger.

L'essentiel du RFC est la section 2, qui décrit les exigences auxquelles devra se soumettre le futur protocole DOTS. (Notez que le travail est déjà bien avancé, et qu'il y aura un RFC d'architecture générale du systéme.) Il s'agit d'exigences techniques : ce RFC ne spécifie pas d'exigences business ou de politique. Par exemple, il ne dit pas à partir de quand un client DOTS a le droit de demander une action au serveur, ni dans quels cas le client a le droit d'annuler une demande.

Le protocole DOTS a des exigences difficiles ; compte-tenu du caractère très sensible des échanges entre le client et le serveur, il faut absolument fournir authentification, intégrité, confidentialité et protection contre le rejeu par un tiers. Autrement, le protocole DOTS, comme la plupart des techniques de sécurité, pourrait en fait fournir un nouveau moyen d'attaque. Mais, d'un autre côté, le protocole doit être très robuste, puisqu'il est précisément conçu pour fonctionner face à un hostile, qui va essayer de perturber les communications. Combiner toutes ces demandes n'est pas trivial. DOTS fournira de la robustesse en utilisant des messages de petite taille (qui auront donc davantage de chances de passer), asynchrones, et qui pourront être répétés sans dommage (en cas de doute, les acteurs DOTS n'hésiteront pas à envoyer de nouveau un message).

Je ne vais pas répéter ici la longue liste des exigences, vous les trouverez dans la section 2. Elles sont réparties en plusieurs catégories. Il y a d'abord les exigences générales :

  • Le protocole doit être extensible, car les attaques par déni de service vont évoluer, ainsi que les solutions (la lutte de l'épée et de la cuirasse est éternelle),
  • Comme rappelé ci-dessus, le protocole doit être robuste, la survivabilité doit être sa principale qualité puisqu'il est prévu pour fonctionner en situation très perturbée,
  • Un message qui a du mal à passer ne ne doit pas bloquer le suivant (pas de head-of-line blocking),
  • Le client doit pouvoir donner des indications sur les actions souhaitées, puisqu'il dispose parfois d'informations, par exemple issues du renseignement sur les menaces.
Il y a ensuite les exigences sur le canal de signalisation :
  • Il doit utiliser des protocoles existants comme UDP (TCP est possible mais, en cas d'attaque, il peut être difficile, voir impossible, d'établir une connexion),
  • La taille des messages doit être faible, à la fois pour augmenter les chances de passer malgré l'attaque, et pour éviter la fragmentation,
  • Le canal doit être bidirectionnel, entre autres pour détecter une éventuelle coupure du lien (un serveur peut être configuré pour activer les solutions anti-dDoS précisément quand il ne peut plus parler au client, des messages de type battement de cœur sont donc nécessaires, mais pas évidents à faire correctement, cela avait été une des plus grosses discussions à l'IETF),
  • Le client doit pouvoir demander au serveur des actions (c'est le but principal du protocole), et doit pouvoir aussi solliciter des informations sur ce que voit et fait le serveur DOTS (« j'ai jeté 98 % des paquets » ou « je jette actuellement 3,5 Gb/s »),
  • Le client doit pouvoir tenir le serveur au courant de l'efficacité perçue des actions effectuées (« ça marche pas, je reçois toujours autant »),
  • Le client doit pouvoir indiquer une durée pour les actions du serveur, y compris une durée infinie (si le client préfère que tout son trafic soit examiné et filtré en permanence),
  • Le client doit pouvoir demander un filtrage fin, en indiquant une portée (« uniquement ce qui vient de 192.0.2.0/24 » ou « seulement les paquets à destination de 2001:db8:a:b::/64 », voire « seulement les paquets pour www.example.com », et le serveur DOTS doit alors faire la résolution de nom).
Il y a aussi des exigences pour l'autre canal, celui des données. Rappelons que, contrairement au canal de signalisation, il n'est pas indispensable qu'il puisse fonctionner pendant l'attaque. La principale exigence est la transmission fiable des données.

Vu le contexte de DOTS, il y a évidemment des exigences de sécurité :

  • Authentification mutuelle (du serveur par le client et du client par le serveur), un faux serveur ou un faux client pourraient faire des catastrophes, cf. section 4 du RFC,
  • Confidentialité et intégrité, vu le caractère critique des données (imaginez si un attaquant pouvait modifier les messages DOTS…)

La section 3 du RFC se penche sur le problème de la congestion. Le protocole DOTS ne doit pas ajouter à l'attaque en noyant tout le monde sous les données, alors qu'il utilisera sans doute un transport qui ne gère pas lui-même la congestion, UDP (au moins pour le canal de signalisation). Il faudra donc bien suivre les règles du RFC 8085.

À noter qu'Arbor a un brevet sur les mécanismes analogues à DOTS (brevet 20130055374, signalé à l'IETF ici.) Arbor promet des licences RF et RAND. Même les attaques créent du business…

2019-08-20

☕︎ Frustration

Une semaine avec l’intention de faire des choses en famille. On a cueilli des bleuets et dormi dans la forêt. Essayé la Rabaska et le kayak de mer. Pêché pas mal d’algues et de boutons de moustiques.

These kinds of violent, spectacular disasters are what the public has come to understand as a technological failure. But most technological failures, especially when dealing with the environment, are decidedly mundane. They often disproportionately affect the poor in ways that are spatially diffuse and take generations to unfold—a kind of “slow violence,” as the scholar Rob Nixon has memorably argued.

[…]

But it also has the outlines of a broader truth: in engineering, the “success” of a technology often has less to do with solving problems than rendering them opaque or distant from our imagination. Like an endless game of whack-a-mole, the problems never truly go away—they come back with a vengeance decades later and miles away in new forms, often made worse by the very infrastructure engineers created.

Engineers Don’t Solve Problems (cache)

J’aime cette idée de transformation du problème plus que de trouver une solution. En ayant conscience que la transformation n’est pas forcément celle que l’on croit (cache).

J’ai découvert une nouvelle technique de pêche appelée Tenkara qui est suffisamment minimaliste pour m’attirer. Quitte à faire tremper des hameçons dans l’eau, autant que ce soit avec style.

Et aussitôt de réaliser que cela requiert encore un équipement dédié. Comment explorer et itérer sans consommer ? Que faire du matériel devenu obsolète lorsque le savoir-faire remplace la technique ?

C’est une réflexion qui me taraude depuis que j’ai commencé à aller en forêt.

la culpabilité sert à maquiller une honte, tu penses que ça maquille la honte de quoi ?

☕️ Journal : En réponse à "Holisme" (cache)

Probablement celle d’un monde dont je fais partie.

Je me demande si les Deux cents familles sont le pendant de nos 1%. Et à quel point il s’agit d’un mythe lorsqu’on arrive à ce type de données relativement sourcées.

Capture d’écran d’un site dont  les contrastes sont mauvais par défaut. Ironie ? Si seulement…

Je ne compte plus le nombre de site de designers avec de bonnes intentions mais des lacunes techniques qui rendent leur message peu crédible à mes yeux. Parler d’effondrement sur un site avec un logo animé qui consomme un CPU à 100% en permanence, parler de low-techs avec plusieurs méga-octets d’images en carousel, publier du contenu inaccessible par défaut lorsqu’on ne veut pas accéder aux ressources distantes (ou lorsqu’elles vont disparaitre), etc.

Comment leur faire prendre conscience de cela sans amener la violence de ma frustration ?

These are powerful moments. You can feel a silence like that. It stretches out—listening, there’s only a sense of expanding space. Straining the ears, the expanding emptiness of the air strikes you. The outside wakes up the inside, and I realize I’m standing alone with my thoughts.

And then I or someone or something moves, intentionally or unintentionally sending out a ripple that disrupts this packet of silence, reconfiguring a quiet geography with some new wave.

A geography of intentional sound (cache)

Silence par défaut. Alors que je suis entouré de cônes oranges, de tondeuses, d’arrosage automatiques, de robots de piscines et autres sources de pollutions pas que sonores, j’aspire au silence.

La technologie et la richesse sont liées au bruit. Plus on en produit, plus on est riche d’énergie.

S’approprier l’espaces sonore afin de réduire les pauvres au silence.

J’ai peut-être enfin trouvé comment transformer la frustration de faire chauffer un four à haute température pour faire cuire un pain sans réutiliser la chaleur produite. Il s’agit de faire chauffer la théière en fonte d’une part et de faire cuire des Onsen tamago d’autre part. La pierre semble transférer l’énergie adéquate pour tenir une température de 70°C pendant la durée nécessaire.

Et quand j’ai du temps ? Pizza !

Une pizza, un pain et de l’huile d’olive. Une pizza, un pain et de l’huile d’olive. Pas pire.

Citation de la semaine :

Vous savez quoi ? J’ai envie d’être dur, mais réaliste, avec nous : si la planète (ou plutôt l’humanité) s’en va actuellement chez le diable, la responsabilité, voire la faute, nous incombe.

Ouais. Parce qu’on tolère ce genre de tricheries, de mensonges et d’indolences de nos gouvernements. Parce qu’on s’évite d’en faire un enjeu primordial, trop occupés à se vautrer dans un confort à la con, à s’acheter un climatiseur alors que la planète est en train de bouillir. Parce que c’est ben le fun, le compost, les bixis et la bouffe bio, mais rien ne suffira en l’absence de politiques macros. Parce qu’on regarde le doigt, comme des idiots, alors que les sages, soit les scientifiques, pointent la lune.

Dérèglements politiques, Frédéric Bérard

Mine de rien, je commence à m’intéresser à la politique québécoise.

Supprimer les réseaux sociaux me fait passer plus de temps sur Wikipedia. Je ne m’y attendais pas vraiment et je trouve ça chouette. Ça n’a pas l’air de me rendre moins aigri par contre.

2019-08-16

RFC 8576: Internet of Things (IoT) Security: State of the Art and Challenges

Une blague très courante dit que, dans IoT (Internet of Things, l'Internet des Objets), le S veut dire sécurité… C'est peu dire que la sécurité de l'Iot est mauvaise. Elle est en fait catastrophique, comme l'analyse bien Schneier dans son livre « Click here to kill everybody ». C'est en grande partie dû à des raisons politico-économiques (les fabriquants se moquent de la sécurité notamment, parce que les failles de sécurité n'ont aucune conséquence négative pour eux) et en petite partie aux réelles difficultés techniques qu'il y a à sécuriser des objets qui sont parfois contraints en ressources (énergie électrique limitée, par exemple.) Ce nouveau RFC du groupe de recherche T2T (Thing to Thing) de l'IRTF se penche sur la question et essaie d'identifier les questions à long terme. À lire absolument, si vous vous intéressez à la sécurité des objets connectés. Et à lire également si vous ne vous y intéressez pas car, que vous le vouliez ou non, la sécurité des objets connectés va vous toucher.

On ne part pas de zéro pourtant. Contrairement à ce que disent parfois les vendeurs d'objets connectés pour justifier l'insécurité abyssale de leurs produits, des solutions techniques ont été développées. (Voir par exemple cet article qui parle de la sécurité des sondes Atlas.) Il existe des protocoles adaptés aux objets, comme CoAP (RFC 7252), une alternative légère à HTTP, qu'on peut sécuriser avec DTLS (RFC 6347). Mais il reste à les déployer.

Notre RFC suit un plan classique : il étudie d'abord le cycle de vie des objets connectés (section 2 du RFC), examine ensuite les risques (section 3), l'état de l'art (section 4), puis les défis pour sécuriser les objets (section 5), et enfin les prochaines étapes du travail nécessaire (section 6).

Le terme d'Internet des Objets fait partie de ces termes pipeau qui ne veulent pas dire grand'chose. Les « objets » n'ont pas grand'chose à voir, allant d'un ordiphone plus puissant que certains ordinateurs, à des étiquettes RFID, en passant par des voitures connectées qui disposent d'électricité et de puissance de calcul considérables, et des capteurs industriels qui sont au contraire très contraints. Quant à leur connexion, elle se limite parfois au réseau local et, parfois, à envoyer toutes leurs données, aussi privées qu'elles soient, vers leur maitre dans le mythique cloud. C'est le consortium privé Auto-Id qui a popularisé ce terme à la fin des années 1990, pour de simples raisons marketing. À l'époque, c'était limité à des étiquettes RFID n'ayant qu'une connexion très limitée, sans rapport avec l'Internet. Certains ont suggéré de réserver le terme d'« Internet des Objets » aux objets connectés en IP mais ces appels à la rigueur terminologique n'ont en général que peu d'impact. Bref, chercher des solutions pour l'« Internet des Objets » en général n'a que peu de chances d'aboutir, vu la très grande variété de situations que ce terme recouvre.

Mais revenons au début, au cycle de vie de nos objets connectés (section 2 du RFC). Comme la variété des objets connectés est très grande, le RFC choisit de partir d'un exemple spécifique, un système de gestion de bâtiment. Ce système contrôle la climatisation, le chauffage, la ventilation, l'éclairage, la sécurité, etc. Un tel système représente de nombreux objets, dont certains, notamment les capteurs installés un peu partout, peuvent être très contraints en ressource (processeur lent, énergie fournie uniquement par des batteries, etc). Pire, du point de vue des protocoles réseau, certains de ces objets vont passer beaucoup de temps à dormir, pour économiser l'énergie, et ne répondront pas aux autres machines pendant ce temps. Et les objets seront sans doute fabriqués par des entreprises différentes, ce qui soulèvera des questions amusantes d'interopérabilité.

La figure 1 du RFC représente un cycle de vie simplifié. Je le simplifie encore ici. L'objet est successivement :

  • fabriqué,
  • il peut rester assez longtemps sur l'étagère, attendant un acheteur (ce qui contribue à l'obsolescence de son logiciel),
  • installé et configuré (probablement par différents sous-traitants),
  • mis en service,
  • il va fonctionner un certain temps puis verra des évenements comme une mise à jour logicielle,
  • ou des changements de sa configuration,
  • à un moment, il cessera d'être utilisé,
  • puis sera retiré du bâtiment (à moins qu'il soit oublié, et reste actif pendant des années sans qu'on s'en occupe),
  • mais il aura peut-être droit à une reconfiguration et une remise en service à un autre endroit, recommençant le cycle,
  • sinon, il sera jeté.
Les différents objets présents dans le bâtiment ne seront pas aux mêmes étapes au même moment.

Le RFC remarque que le cycle de vie ne commence pas forcément à la fabrication de l'objet physique, mais avant. Pour des objets comportant du logiciel, le cycle de vie commence en fait lorsque la première bibliothèque qui sera utilisée est écrite. Les logiciels des objets connectés ont une forte tendance à utiliser des versions anciennes et dépassées des bibliothèques, notamment de celles qui assurent des fonctions de sécurité. Les bogues ont donc une longue durée de vie.

La sécurité est une question cruciale pour les objets connectés, car ils sont en contact avec le monde physique et, si ce sont des actionneurs, ils agissent sur ce monde. Comme le note Schneier, une bogue sur un objet connecté, ce n'est plus seulement un programme qui plante ou un fichier qu'on perd, cela peut être des atteintes physiques aux humains. Et les objets sont nombreux : pirater une machine ne donne pas beaucoup de pouvoir à l'attaquant, mais s'il arrive à trouver une faille lui permettant de pirater via l'Internet tous les objets d'un vendeur donné, il peut se retrouver à la tête d'un botnet conséquent (c'est exactement ce qui était arrivé avec Mirai).

Quels sont les risques exactement ? La section 3 du RFC décrit les différentes menaces, une liste longue et un peu fourre-tout. Avant tout, le code peut être incorrect, bogué ou mal conçu. C'est le cas de tout logiciel (ne croyez pas un instant les commerciaux qui assurent, sans rien en savoir eux-mêmes, que « le logiciel est conforme à l'état de l'art et aux préconisations de [insérer ici le nom d'un organisme quelconque] »). Mais comme vu plus haut, les conséquences sont plus graves dans le cas des objets connectés. En outre, il y a deux problèmes logiciels qui sont davantage spécifiques aux objets connectés : les mises à jour, pour corriger les bogues, sont plus difficiles, et rarement faites, et le logiciel est globalement négligé, n'étant pas le « cœur de métier » de l'entreprise vendeuse. On voit ainsi des failles de sécurité énormes, qui n'arrivent plus dans l'informatique plus classique.

Autre raison pour laquelle la sécurité des objets connectés est difficile à assurer, le fait que l'attaquant peut avoir un accès physique aux objets (par exemple s'il s'agit d'un type d'objet vendu publiquement). Il peut le démonter, l'étudier, et acquérir ainsi des informations utiles pour le piratage d'autres objets du même type. Si, par exemple, tous les objets d'un même type partagent une clé cryptographique privée, elle pourrait être récupérée ainsi (l'objet connecté typique n'est pas un HSM). Un modèle de sécurité comme celui de la boite noire ne s'applique donc pas. Dans le futur, peut-être que les PUF seront une solution ?

La sécurité impose de mettre à jour le logiciel de l'objet régulièrement. Mais cette mise à jour ouvre elle-même des failles de sécurité. Si le processus de mise à jour n'est pas sécurisé (par exemple par une signature du logiciel), un malveillant pourra peut-être y glisser sa version du logiciel.

Ensuite, l'objet, même s'il fonctionne comme prévu, peut faire fuiter des informations privées. S'il envoie des informations à des tiers (c'est le cas de presque tous les objets conçus pour l'usage domestique) ou s'il transmet en clair, il permet la surveillance de son propriétaire. Le chiffrement est évidemment indispensable, mais il ne protège pas contre les extrémités de la communication (le sextoy connecté qui envoie les informations sur son usage au vendeur de l'objet) et, s'il n'est pas accompagné d'une authentification du partenaire avec qui on communique, ile ne protège pas contre l'homme du milieu. Une des difficultés de l'authentification est qu'il faut bien, avant la communication, avitailler l'objet en informations (par exemple les clés publiques de ses correspondants), un défi pour des objets fabriqués en masse. Avitailler une fois l'objet sur le terrain est tout aussi difficile : ces objets n'ont souvent pas d'interface utilisateur. Cela impose des solutions comme le TOFU (faire confiance la première fois, puis continuer avec le même correspondant) ou bien l'appairage (on approche deux objets, on appuie sur un bouton et ils sont désormais appairés, ils ont échangé leurs clés).

Les objets ont souvent une histoire compliquée, étant composée de l'assemblage de divers composants matériels et logiciels, parfois promenés sur de longues distances, entre beaucoup d'entreprises différentes. Une des attaques possibles est de s'insérer quelque part dans cette chaîne d'approvisionnement et d'y glisser du logiciel ou du matériel malveillant. Est-ce que quelqu'un sait vraiment ce que fait cette puce dont on a acheté des dizaines de milliers d'exemplaires à un revendeur ? Dans le cas extrême, c'est l'objet entier qui peut être remplacé par un objet apparemment identique, mais malveillant.

Les objets connectés sont souvent dans des lieux qui ne sont pas physiquement protégés. Par exemple, les capteurs sont placés un peu partout, et parfois accessibles à un attaquant. Une fois qu'on peut mettre la main sur un objet, il est difficile d'assurer sa sécurité. Des informations confidentielles, comme une clé privée, peuvent alors se retrouver entre les mains de l'attaquant. Transformer chaque objet connecté en un coffre-fort inviolable n'est évidemment pas réalistes.

Les objets communiquent entre eux, ou bien avec des passerelles les connectant à l'extérieur. Cela ouvre de nouvelles possibilités d'attaque via le routage. Les objets connectés se servent souvent de protocoles de routage non sécurisés, permettant au malveillant d'injecter de fausses routes, permettant ainsi, par exemple, de détourner le trafic vers une machine contrôlée par ce malveillant.

Enfin, il y a la menace des attaques par déni de service. Les objets sont souvent contraints en ressources et sont donc particulièrement vulnérables aux attaques par déni de service, même légères. Et les objets ne sont pas forcément victimes, ils peuvent être aussi devenir zombies et, recrutés par un logiciel malveillant comme Mirai, être complices d'attaques par déni de service comme cela avait été le cas en octobre 2016. (Un outil comme Shodan permet de trouver facilement des objets vulnérables et/ou piratés.)

Bon, ça, c'étaient les menaces. Mais on n'est pas resté les bras ballants, on a déjà des mécanismes possibles pour faire face à ces attaques. La section 4 de notre RFC décrit l'état de l'art en matière de connexion des objets connectés, et de leur sécurisation.

Déjà, il existe plusieurs protocoles pour les objets connectés, comme ZigBee, BACnet ou DALI. Mais l'IETF se focalise évidemment sur les objets qui utilisent IP, le seul cas où on puisse réellement parler d'« Internet des Objets ». IP tel qu'il est utilisé sur les ordinateurs classiques n'est pas forcément bien adapté, et des groupes ont développé des adaptations pour les réseaux d'objets (voir par exemple le RFC 4944). De même, il existe des normes pour faire tourner IP sur des tas de couches physiques différentes, comme Bluetooth (RFC 7668), DECT (RFC 8105) ou NFC (RFC pas encore publié). Au-dessus d'IP, le protocole CoAP (RFC 7252) fournit un protocole applicatif plus adapté aux objets que le HTTP classique.

Questions formats, on a également le choix. On a JSON (RFC 8259), mais aussi CBOR (RFC 7049) qui, lui, est un format binaire, sans doute plus adapté aux objets contraints. Tous les deux ont des solutions de sécurité, par exemple la famille JOSE pour signer et chiffrer les documents JSON, et son équivalent pour CBOR, CORE (RFC 8152).

Le problème de la sécurité de l'IoT est connu depuis longtemps, et ce ne sont pas les solutions techniques qui manquent, que ce soit pour protéger les objets connectés, ou pour protéger le reste de l'Internet contre ces objets. Certains de ces protocoles de sécurité ne sont pas spécifiques aux objets connectés, mais peuvent être utilisés par eux, c'est le cas de TLS (RFC 8446). Une excuse classique des fabricants d'objets connectés pour ne pas sécuriser les communications avec TLS est le caractère contraint de l'objet (manque de ressources matérielles, processeur, mémoire, énergie, etc). Cet argument peut jouer pour des objets vraiment contraints, des capteurs bon marché disséminés dans l'usine et ne fonctionnant que sur leur batterie mais beaucoup d'objets connectés ne sont pas dans ce cas, et ont largement les moyens de faire tourner TLS. Quand on entend des fabriquants de télévisions connectées ou de voitures connectées expliquer qu'ils ne peuvent pas utiliser TLS car ce protocole est trop coûteux en ressources, on rit ou on s'indigne car c'est vraiment un argument ridicule ; une télévision ou une voiture ont largement assez de ressources pour avoir un processeur qui fait tourner TLS. (Je n'utilise que TLS et SSH pour communiquer avec un Raspberry Pi 1, avec son processeur à 700 MHz et sa consommation électrique de 2 W.)

Outre les protocoles, la sécurité repose sur des règles à suivre. La section 4.3 liste les règles formalisées existantes. Ainsi, GSMA a publié les siennes, BITAG également, le DHS étatsunien s'y est mis, l'ENISA aussi et notre RFC liste de nombreux autres documents. Si les fabriquants d'objets connectés ne sont pas au courant, ce n'est pas faute d'information, c'est bien de la mauvaise volonté !

C'est d'autant plus grave que, comme l'a illustré le cas de Mirai, les objets connectés non-sécurisés ne sont pas un problème que pour le propriétaire de l'objet, mais peuvent également toucher tout l'Internet. Il est donc logique que beaucoup de voix s'élèvent pour dire qu'il faut arrêter de compter sur la bonne volonté des fabricants d'objets connectés, qui ont largement démontré leur irresponsabilité, et commencer à réguler plus sévèrement. (C'est par exemple une demande du régulateur étatsunien FCC.)

Cette disponibilité de très nombreuses solutions techniques ne veut pas dire que tous les problèmes sont résolus. La section 5 du RFC fait ainsi le point sur les défis qui nous restent, et sur lesquels chercheu·r·se·s et ingénieur·e·s devraient se pencher. D'abord, certains objets sont contraints en ressources (pas tous, on l'a vu), comme détaillé dans le RFC 7228. L'Internet est un monde très hétérogène, connectant des machines ayant des ressources très diverses, via des réseaux qui ont des capacités hautement variables. Pour ces objets contraints (qui sont une partie seulement des « objets », une caméra de vidéo-surveillance n'est pas un objet contraint), il est raisonnable de chercher à optimiser, par exemple la cryptographie. Ainsi, la cryptographie à courbes elliptiques (RFC 8446) demande en général moins de ressources que RSA.

Les attaques par déni de service sont un autre défi pour les objets connectés, qui disposent de peu de ressources pour y faire face. Des protocoles qui permettent de tester qu'il y a une voie de retour (return routability ou returnability) peuvent aider à éviter certaines attaques que des protocoles sans ce test (comme le DNS ou comme d'autres protocoles fondés sur UDP) rendent facile. C'est pour cela que DTLS (RFC 6347) ou HIP (RFC 7401) intègrent ce test de réversibilité. Évidemment, cela n'aide pas pour les cas de la diffusion, ou bien lorsque le routage est contrôlé par l'attaquant (ce qui est souvent le cas dans les réseaux « mesh ».) Autre protection, qui existe par exemple dans HIP : forcer l'initiateur d'une connexion à résoudre un problème, un « puzzle », afin d'éviter que les connexions soient « gratuites » pour l'initiateur. La principale limite de cette solution est qu'elle marche mal si les machines impliquées ont des capacités de calcul très différentes (un objet contraint contre un PC). Il y a également le cas, non mentionné par le RFC, où l'attaquant dispose d'un botnet et ne « paie » donc pas les calculs.

L'architecture actuelle de l'Internet n'aide pas au déploiement de certaines solutions de sécurité. Ainsi, un principe de base en sécurité est d'avoir une sécurité de bout en bout, afin de ne pas dépendre d'intermédiaires malveillants ou piratés, mais c'est rendu de plus en plus difficile par l'abus de middleboxes, qui interfèrent avec beaucoup de comunications. On est donc forcés d'adapter la sécurité à la présence de ces middleboxes, souvent en l'affaiblissant. Par exemple :

  • Il faut parfois partager les clés avec les middleboxes pour qu'elles puissent modifier les paquets, ce qui est évidemment une mauvaise pratique,
  • Le chiffrement homomorphe peut aider, en permettant d'effectuer certaines opérations sur des données chiffrées, mais toutes les opérations ne sont pas possibles ainsi, et les bibliothèques existantes, comme SEAL, n'ont pas les performances nécessaires,
  • Remonter la sécurité depuis le niveau des communications (ce que fait TLS) vers celui des données échangées pourrait aider. C'est ce que font COSE (RFC 8152), JOSE (RFC 7520) ou CMS (RFC 5652).

Une fois déployés, les objets connectés vont rester en fonctionnement des années, voire des décennies. Il est donc crucial d'assurer les mises à jour de leur logiciel, ne serait-ce que pour réparer les failles de sécurité qui ne manqueront pas d'être découvertes, qu'elles soient dans le code ou dans les algorithmes utilisés. Par exemple, si les promesses des ordinateurs quantiques se concrétisent un jour, il faudra jeter RSA et les courbes elliptiques (section 5.8 du RFC).

Mais assurer des mises à jour sûres n'est pas facile, comme le note Bruce Schneier. C'est que le processus de mise à jour, s'il est insuffisamment sécurisé, peut lui-même servir pour une attaque, par exemple en envoyant du code malveillant à un objet trop naïf. Et puis comment motiver les vendeurs à continuer à fournir des mises à jour logicielles des années après que le dernier exemplaire de ce modèle ait été vendu ? Capitalisme et sécurité ne vont pas bien ensemble. Et il se peut tout simplement que le vendeur ait disparu, que le code source de l'objet ne soit plus disponible, et qu'il soit donc impossible en pratique de développer une mise à jour. (D'où l'importance, même si le RFC ne le dit pas, du logiciel libre.) Enfin, si la mise à jour doit être effectuée manuellement, il est probable qu'elle ne sera pas faite systématiquement. (Un rapport de la FTC états-unienne détaille également ce problème.)

Mais les mises à jour automatiques posent également des tas de problèmes. Par exemple, pour des ampoules connectées (une idée stupide, mais le monde de l'IoT est plein d'idées stupides), il vaut mieux mettre à jour leur logiciel le jour que la nuit. Et il vaut mieux que toutes les ampoules ne soient pas mises à jour en même temps. Et les mises à jour supposent que le système ait été conçu pour cela. Par exemple, en cryptographie, il est souvent nécessaire de remplacer les algorithmes cryptographiques qui ont été cassés avec le temps, mais beaucoup d'objets connectés utilisent des systèmes cryptographiques mal conçus, qui n'ont pas d'agilité cryptographique. (Au passage, la section 5.8 du RFC traite le cas des possibles futurs ordinateurs quantiques, et des conséquences qu'ils auront pour la cryptographie. Les objets connectés peuvent rester actifs de nombreuses années, et il faut donc penser loin dans le futur.) Ces points, et beaucoup d'autres, avaient été traités dans un atelier de l'IAB, qui avait fait l'objet du RFC 8240. À l'IETF, le groupe de travail SUIT développe des mécanismes pour aider les mises à jour (mais qui ne traiteront qu'une petite partie du problème).

Rapidement dépassés, les objets connectés posent également des problèmes de gestion de la fin de vie. Au bout d'un moment, le vendeur va arrêter les différentes fonctions, comme les mises à jour du logiciel ou, plus radicalement, comme les serveurs dont dépend l'objet. Cet arrêt peut être volontaire (l'objet n'intéresse plus le vendeur, qui est passé à d'autres gadgets) ou involontaire (vendeur en faillite). Le RFC note qu'une des voies à explorer est la continuation de l'objet avec du logiciel tiers, qui ne dépend plus de l'infrastructure du vendeur. Bien des ordiphones ont ainsi vu leur vie prolongée par CyanogenMod, et bien des routeurs ont bénéficié d'OpenWrt. (D'où l'importance de pouvoir installer ce logiciel tiers, ce qu'interdisent beaucoup de vendeurs.)

Une autre question intéressante de sécurité posée par les objets connectés est la vérification de leurs capacités réelles et de leur comportement effectif. L'acheteur peut avoir l'impression qu'il est le propriétaire de l'objet acheté mais cet objet est suffisamment complexe pour que l'acheteur ne soit pas au courant de tout ce que l'objet fait dans son dos. Le vrai maitre de l'objet est alors le vendeur, qui continue à communiquer avec l'engin connecté. C'est ainsi que des malhonnêtes comme Lidl ou Google avaient installé des micros dans des objets qu'on installe chez soi, et évidemment sans le dire à l'acheteur. Et encore, un micro est un appareil physique, qu'un examen attentif (avez-vous vérifié tous les objets connectés chez vous ?) peut détecter. Mais savoir ce que raconte l'objet connecté à son maitre est plus difficile. Peu d'utilisateurs ont envie de configurer un routeur local, et d'y faire tourner tcpdump pour voir le trafic. Et encore, ce trafic peut être chiffré et l'acheteur (qui, rappelons-le, n'est pas le véritable propriétaire de l'objet, puisqu'il n'a quasiment aucun contrôle, aucune information) n'a pas les clés.

Le problème de fournir des informations à l'utilisateur n'est pas trivial techniquement. Beaucoup d'objets connectés n'ont pas d'interface utilisateur où afficher « je suis en train d'envoyer plein de données sur vous à mon maitre ». Une solution partielle serait une description des capacités de l'engin, et de ses communications, dans un fichier MUD (Manufacturer Usage Description, RFC 8520). Ceci dit, vu le niveau d'éthique dans le monde de l'IoT, gageons que ces fichiers MUD mentiront souvent, notamment par omission.

Puisqu'on a parlé de vie privée, c'est l'occasion de rappeler que l'IoT est une grave menace pour cette vie privée. Le RFC note que, dans le futur, nous serons peut-être entourés de centaines d'objets connectés. (Malheureusement, le RFC parle surtout des risques dus à des tiers qui observeraient le trafic, et très peu des risques dus aux vendeurs qui récoltent les données.) L'IoT permet une intensification considérable du capitalisme de surveillance.

Bref, la situation est mauvaise et, s'il y a en effet quelques progrès (on voit moins souvent des mots de passe identiques pour tous les objets d'un type), ils sont largement annulés par de nouveaux déploiements.

2019-08-14

RFC 8621: The JSON Meta Application Protocol (JMAP) for Mail

Ce nouveau RFC décrit un remplaçant pour le traditionnel protocole IMAP, remplaçant fondé sur le cadre JMAP (JSON Meta Application Protocol, RFC 8620).

Le protocole décrit dans ce RFC fournit les mêmes services qu'IMAP (RFC 3501) : accéder aux boîtes aux lettres de courrier, chercher dans ces boîtes, gérer les messages (détruire les inutiles, par exemple), etc. Par rapport à IMAP, outre l'utilisation du format JSON, l'accent est mis sur la synchronisation rapide, l'optimisation pour les clients mobiles, et sur la possibilité de notifications. JMAP est sans état (pas besoin de connexion permanente). Ce « JMAP pour le courrier » s'appuie sur JMAP, normalisé dans le RFC 8620. JMAP est un protocole générique, qui peut servir à synchroniser bien des choses entre un client et un serveur (par exemple un agenda, ou bien une liste de contacts). Par abus de langage, je vais souvent dire « JMAP » dans cet article alors que je devrais normalement préciser « JMAP pour le courrier », premier « utilisateur » du JMAP générique.

JMAP manipule différents types d'objets. Le plus important est sans doute Email (section 4 du RFC), qui modélise un message. Il s'agit d'une représentation de haut niveau, le client JMAP n'a pas à connaitre tous les détails de l'IMF (Internet Message Format, RFC 5322), de MIME (RFC 2045), etc. Un objet de type Email a une liste d'en-têtes et un corps, et JMAP fournit des méthodes pour accéder aux différentes parties du corps. Il y a même plusieurs représentations d'un message, pour s'adapter aux différents clients. Par exemple, un message MIME est normalement un arbre, de profondeur quelconque, mais un client JMAP peut décider de demander une représentation aplatie, avec juste une liste d'attachements. (La plupart des MUA présentent à l'utilisateur une vue aplatie de l'objet MIME.) Voilà pourquoi l'objet Email a plusieurs propriétés, le client choisissant à laquelle il accède :

  • bodyStructure : l'arbre MIME, c'est la représentation la plus « authentique »,
  • textBody : une liste des parties MIME à afficher quand on préfère du texte,
  • htmlBody : une liste des parties MIME à afficher quand on préfère de l'HTML,
  • attachments : la liste des « pièces jointes » (rappelez-vous que le concept de « pièces jointes » a été créé pour l'interface avec l'utilisateur ; il n'a pas de sens en MIME, qui ne connait qu'un arbre avec des feuilles de différents types).
Les en-têtes doivent pouvoir être internationaux (RFC 6532).

Un message a évidemment des métadonnées, parmi lesquelles :

  • id, un identifiant du message (ce n'est pas le Message-ID:, c'est attribué par le serveur JMAP), contrairement à IMAP, l'identificateur d'un message ne change pas, même quand le message change de boîte, et il peut apparaitre dans plusieurs boîtes à la fois
  • blobIf, un identifiant du message représenté sous la forme d'une suite d'octets, à analyser par le client, par opposition à l'objet de haut niveau identifié par id,
  • size, la taille du message,
  • keywords, des mots-clés, parmi lesquels certains, commençant par un dollar, ont une signification spéciale.
En IMAP, les mots-clés spéciaux sont précédés d'une barre inverse. En JMAP, c'est le dollar. Parmi ces mots-clés, $seen indique que le message a été lu, $answered, qu'on y a répondu, $junk, que le serveur l'a classé comme spam, etc. Ces mots-clés sont dans un registre IANA.

Et quelles opérations sont possibles avec les objets de type Email ? Ce sont les opérations génériques de JMAP (RFC 8620, section 5). Ainsi, on peut récupérer un message avec Email/get. Cette requête :

[[ "Email/get", {
        "ids": [ "f123u456", "f123u457" ],
        "properties": [ "threadId", "mailboxIds", "from", "subject",
          "receivedAt", "header:List-POST:asURLs",
          "htmlBody", "bodyValues" ],
        "bodyProperties": [ "partId", "blobId", "size", "type" ],
        "fetchHTMLBodyValues": true,
        "maxBodyValueBytes": 256
      }, "#1" ]]      
    
peut récupérer, par exemple, cette valeur :
      
[[ "Email/get", {
     "accountId": "abc",
     "state": "41234123231",
     "list": [
       {
         "id": "f123u457",
         "threadId": "ef1314a",
         "mailboxIds": { "f123": true },
         "from": [{ "name": "Joe Bloggs", "email": "joe@example.com" }],
         "subject": "Dinner on Thursday?",
         "receivedAt": "2013-10-13T14:12:00Z",
         "header:List-POST:asURLs": [
           "mailto:partytime@lists.example.com"
         ],
         "htmlBody": [{
           "partId": "1",
           "blobId": "B841623871",
           "size": 283331,
           "type": "text/html"
         }, {
           "partId": "2",
           "blobId": "B319437193",
           "size": 10343,
           "type": "text/plain"
         }],
         "bodyValues": {
           "1": {
             "isTruncated": true,
             "value": "<html><body><p>Hello ..."
           },
           "2": {
             "isTruncated": false,
             "value": "-- Sent by your friendly mailing list ..."
           }
         }
       }
     ],
     "notFound": [ "f123u456" ]
     }, "#1" ]]

    
Notez que le client a demandé deux messages, mais qu'un seul, le f123u457, a été trouvé.

Tout aussi indispensable, Email/query permet de demander au serveur une recherche, selon de nombreux critères comme la date, les mots-clés, ou bien le contenu du corps du message.

Email/set permet de modifier un message, ou d'en créer un (qu'on pourra ensuite envoyer avec EmailSubmission, décrit plus loin). Notez qu'il n'y a pas de Email/delete. Pour détruire un message, on utilise Email/set en changeant la propriété indiquant la boîte aux lettres, pour mettre la boîte aux lettres spéciale qui sert de poubelle (rôle = trash).

Comme IMAP, JMAP pour le courrier a la notion de boîte aux lettres (section 2 du RFC). Une boîte (vous pouvez appeler ça un dossier ou un label si vous voulez) est un ensemble de messages. Tout message est dans au moins une boîte. Les attributs importants d'une boîte :

  • Un nom unique (par exemple Vacances ou Personnel), en Unicode (RFC 5198),
  • Un identificateur attribué par le serveur (et a priori moins lisible par des humaines que ne l'est le nom),
  • Un rôle, optionnel, qui indique à quoi sert la boîte, ce qui est utile notamment si le serveur peut être utilisé en JMAP et en IMAP. Ainsi, le rôle inbox identifie la boîte où le courrier arrive par défaut. (Les rôles figurent dans un registre IANA créé par le RFC 8457.)
  • Certains attributs ne sont pas fixes, par exemple le nombre total de messages contenus dans la boîte, ou bien le nombre de messages non lus.
  • Les droits d'accès (ACL, cf. RFC 4314.) Les permissions sont par boîte, pas par message.

Ensuite, on utilise les méthodes JMAP pour accéder aux boîtes (révisez donc le RFC 8620, qui décrit le JMAP générique). Ainsi, pour accéder à une boîte,, on utilise la méthode JMAP Mailbox/get, qui utilise le /get JMAP (RFC 8620, section 5.1). Le paramètre ids peut être nul, cela indique alors qu'on veut récupérer tous les messages (c'est ce qu'on fait dans l'exemple ci-dessous).

De même, pour effectuer une recherche sur le serveur, JMAP normalise la méthode /query (RFC 8620, section 5.5) et JMAP pour le courrier peut utiliser Mailbox/query.

Par exemple, si on veut voir toutes les boîtes existantes, le client JMAP envoie le JSON :

[[ "Mailbox/get", {
     "accountId": "u33084183",
     "ids": null
}, "0" ]]
    
et reçoit une réponse du genre (on n'affiche que les deux premières boîtes) :
[[ "Mailbox/get", {
     "accountId": "u33084183","state": "78540",
     "state": "78540",
     "list": [{
         "id": "MB23cfa8094c0f41e6",
         "name": "Boîte par défaut",
         "role": "inbox",
         "totalEmails": 1607,
         "unreadEmails": 15,
         "myRights": {
               "mayAddItems": true,
               ...},
	       {
         "id": "MB674cc24095db49ce",
         "name": "Personnel",
	 ...
    
Notez que state est l'identificateur d'un état de la boîte. Si on veut ensuite récupérer les changements, on pourra utiliser Mailbox/changes avec comme paramètre "sinceState": "88540".

Dans JMAP, les messages peuvent être regroupés en fils de discussion (threads, section 3 du RFC). Tout message est membre d'un fil (parfois membre unique). Le RFC n'impose pas de méthode unique pour constituer les fils mais suggère :

  • D'utiliser les en-têtes du RFC 5322 (In-Reply-To: ou References: indiquant le Message-Id: d'un autre message).
  • Et de vérifier que les messages ont le même sujet (après avoir supprimé des préfixes comme « Re: »), pour tenir compte des gens qui volent les fils. Cette heuristique est imparfaite (le sujet peut avoir changé sans pour autant que le message soit sans rapport avec le reste du fil).

On peut ensuite accéder aux fils. Le client envoie :

[[ "Thread/get", {
       "accountId": "acme",
       "ids": ["f123u4", "f41u44"]
}, "#1" ]]      
    
Et récupère les fils f123u4 et f41u44 :
[[ "Thread/get", {
       "accountId": "acme",
       "state": "f6a7e214",
        "list": [
          {
              "id": "f123u4",
              "emailIds": [ "eaa623", "f782cbb"]
          },
          {
              "id": "f41u44",
              "emailIds": [ "82cf7bb" ]
          }
...
    

Un client qui vient de se connecter à un serveur JMAP va typiquement faire un Email/query sans conditions particulières, pour recevoir la liste des messages (ou alors en se limitant aux N messages les plus récents), puis récupérer les fils de discussion correspondants avec Thread/get, récupérer les messages eux-mêmes. Pour diminuer la latence, JMAP permet au client d'envoyer toutes ces requêtes en une seule fois (batching), en disant pour chaque requête qu'elle doit utiliser le résultat de la précédente (backreference, membre JSON resultOf).

JMAP permet également d'envoyer des messages. Un client JMAP n'a donc besoin que d'un seul protocole, contrairement au cas courant aujourd'hui où il faut IMAP et SMTP, configurés séparement, avec, trop souvent, l'un qui marche et l'autre pas. Cela simplifie nettement les choses pour l'utilisateur. Cela se fait avec le type EmailSubmission (section 7 du RFC). Deux importantes propriétés d'un objet de type EmailSubmission sont mailFrom, l'expéditeur, et rcptTo, les destinataires. Rappel important sur le courrier électronique : il y a les adresses indiquées dans le message (champs To:, Cc:, etc, cf. RFC 5322), et les adresses indiquées dans l'enveloppe (commandes SMTP comme MAIL FROM et RCPT TO, cf. RFC 5321). Ces adresses ne sont pas forcément identiques. Lorsqu'on apprend le fonctionnement du courrier électronique, la distinction entre ces deux catégories d'adresses est vraiment cruciale.

Un EmailSubmission/set va créer l'objet EmailSubmission, et envoyer le message. Ici, on envoie à john@example.com et jane@example.com un message (qui avait été créé par Email/set et qui avait l'identificateur M7f6ed5bcfd7e2604d1753f6c) :

[[ "EmailSubmission/set", {
        "accountId": "ue411d190",
        "create": {
          "k1490": {
            "identityId": "I64588216",
            "emailId": "M7f6ed5bcfd7e2604d1753f6c",
            "envelope": {
              "mailFrom": {
                "email": "john@example.com",
                "parameters": null
              },
              "rcptTo": [{
                "email": "jane@example.com",
                "parameters": null
              },
              ...
              ]
            }
          }
        },
        "onSuccessUpdateEmail": {
          "#k1490": {
            "mailboxIds/7cb4e8ee-df87-4757-b9c4-2ea1ca41b38e": null,
            "mailboxIds/73dbcb4b-bffc-48bd-8c2a-a2e91ca672f6": true,
            "keywords/$draft": null
          }
        }
      }, "0" ]]      
    
Anecdote sur l'envoi de courrier : les premières versions de « JMAP pour le courrier » utilisaient une boîte aux lettres spéciale, nommée Outbox, où on mettait les messages à envoyer (comme dans ActivityPub).

JMAP a d'autres types d'objets amusants, comme VacationResponse (section 8), qui permet de faire envoyer un message automatiquement lorsqu'on est absent (l'auto-répondeur du serveur doit évidemment suivre le RFC 3834, pour éviter de faire des bêtises comme de répondre à une liste de diffusion). On crée un objet avec VacationResponse/set et hop, l'auto-répondeur est amorcé.

Et je n'ai pas parlé de tout, par exemple JMAP permet de pousser des changements depuis le serveur vers le client, si la boîte aux lettres est modifiée par un autre processus (RFC 8620, section 7).

JMAP a le concept de capacités (capabilities), que le serveur annonce au client, dans un objet JSON (rappel : JSON nomme « objets » les dictionnaires), et sous la forme d'un URI. JMAP pour le courrier ajoute trois capacités au registre des capacités JMAP, urn:ietf:params:jmap:mail pour dire qu'on sait gérer le courrier, urn:ietf:params:jmap:submission, pour dire qu'on sait en envoyer (cf. RFC 6409, sur ce concept de soumission d'un message), et urn:ietf:params:jmap:vacationresponse pour dire qu'on sait gérer un auto-répondeur.

Le courrier électronique pose plein de problèmes de sécurité intéressants. La section 9 de notre RFC les détaille. Par exemple, les messages en HTML sont particulièrement dangereux. (Il est toujours amusant de voir des entreprises de sécurité informatique envoyer leur newsletter en HTML, malgré les risques associés, qui sont aujourd'hui bien connus.) Le RFC rappelle donc aux clients JMAP (mais c'est valable pour tous les MUA) que du JavaScript dans le message peut changer son contenu, qu'un message en HTML peut récupérer du contenu sur l'Internet (via par exemple un <img src=…), ce qui trahit le lecteur et fait fuiter des données privées, que CSS, quoique moins dangereux que JavaScript, permet également des trucs assez limites, que les liens en HTML ne pointent pas toujours vers ce qui semble (<a href="http://evil.example/">cliquez ici pour aller sur le site de votre banque https://good-bank.example</a>), etc. Pour faire face à tous ces dangers du courrier en HTML, le RFC suggère de nettoyer le HTML avant de l'envoyer au client. Attention, outre que c'est une modification du contenu, ce qui est toujours délicat politiquement, le faire proprement est difficile, et le RFC recommande fortement d'utiliser une bibliothèque bien testée, de ne pas le faire soi-même à la main (il y a trop de pièges). Par exemple, en Python, on peut utiliser lxml, et son module Cleaner, ici en mode extrémiste qui retire tout ce qui peut être dangereux :

    
from lxml.html.clean import Cleaner
...
cleaner = Cleaner(scripts=True, javascript=True, embedded=True, meta=True, page_structure=True,
                                      links=True, remove_unknown_tags=True,
                                      style=True)

Mais il est probablement impossible de complètement sécuriser HTML dans le courrier. Le RFC explique à juste titre que HTML augmente beaucoup la surface d'attaque. Une organisation soucieuse de sécurité ne devrait pas traiter le HTML dans le courrier.

La soumission du courrier (cf. RFC 6409) pose également des problèmes de sécurité. Imaginez un client JMAP piraté et qui serve ensuite à envoyer du spam de manière massive, utilisant le compte de l'utilisateur ignorant de ce piratage. Les MTA qui acceptent du courrier ont des mécanismes de défense (maximum N messages par heure, avec au plus M destinataires par message…) mais ces mécanismes marchent d'autant mieux que le serveur a davantage d'information. Si la soumission via JMAP est mise en œuvre par un simple relais vers un serveur SMTP de soumission, certaines informations sur le client peuvent être perdues. De tels relais doivent donc veiller à transmettre au serveur SMTP toute l'information disponible, par exemple via le mécanisme XCLIENT.

JMAP a été développé essentiellement au sein de FastMail, qui le met en œuvre sur ses serveurs. Il existe une page « officielle » présentant le protocole, qui explique entre autres les avantages de JMAP par rapport à IMAP. Vous y trouverez également des conseils pour les auteurs de clients, très bien faits et qui donnent une bonne idée de comment le protocole marche. Ce site Web est un passage recommandé.

On y trouve également une liste de mises en œuvre de JMAP. Ainsi, le serveur IMAP bien connu Cyrus a déjà JMAP en expérimental. Le MUA K-9 Mail a, quant à lui, commencé le travail.

2019-08-13

☕︎ Holisme

Considérer la somme de ses actions et intentions comme un tout. Lâcher-prise sur celles des autres. Ou du moins essayer.

The reasons I’m leaving aren’t a mystery. I’m committed to the AI Now Institute, to my AI ethics work, and to organizing for an accountable tech industry — and it’s clear Google isn’t a place where I can continue this work.

[…]

The stakes are extremely high. The use of AI for social control and oppression is already emerging, even in the face of developers’ best of intentions. We have a short window in which to act, to build in real guardrails for these systems, before AI is built into our infrastructure and it’s too late.

Onward! Another #GoogleWalkout Goodbye (cache)

Il y aura toujours quelqu’un de plus désespéré pour prendre le relais. Fragiliser des personnes pour qu’elles acceptent l’inacceptable fait partie du système. Triste et impossible à endiguer si l’on ne prend pas en compte les réactions de celles et ceux qui ont le privilège de pouvoir encore choisir.

Le capitalisme construit du perdant-perdant-1%.

Success, for any project, always requires a shift from fast-paced experimentation to a more conservative focus on stability and integrations. Which is interesting in its own right. It could be fun. The privacy and power dynamics involved with selling a SaaS to universities while serving a very vulnerable student population, however, are very worrying.

Weeknote 18 - Uncertainty and Discomfort (cache)

De la responsabilité de ce que l’on produit. Difficile de faire le moins de dégâts possibles et d’être rémunéré pour cela.

De l’impact ? Mais contre/envers qui ?

I found that among 80 tiny home downsizers located across the United States, ecological footprints were reduced by about 45% on average. Surprisingly, I found that downsizing can influence many parts of one’s lifestyle and reduce impacts on the environment in unexpected ways.

Are tiny houses really better for the environment?, study asks (cache)

S’intéresser à ces choses là, c’est prendre conscience du coût d’un avocat ou d’une livraison en véhicule motorisé.

Aussi :

Also - yes, thank you - I know that most pollution is caused by companies, not people eating sausages, but I also wonder how I’m going to look E in the face when she asks what I did about the planet being shot to shit and say “absolutely nothing”. So being a vegetarian is one thing.

Week 48: Cheese sandwiches (cache)

Fresh sourdough costs three times more than an average loaf. Milk in glass costs more per pint. Fruit and vegetables cost more per item when not in plastic, they’re the bigger varieties, the tastier ones, the organic ones. It’s only expensive meat and fish out on the counters, the nice cuts. And at the deli it’s only fancy cheese to choose from.

Value ranges are always in plastic.

Plastic Free July (cache)

C’est un des choix du moment : payer le double pour le même produit qui n’est pas emballé dans du plastique. La main invisible du marché.

Le plastique, c’est pratique (cache).

Deux mois et demi après, j’ai la tête moins encombrée et je peux suivre le fil de mes pensées, de ce qui me travaille, m’attriste et me réjouit.

☕️ Journal : Organiser visuellement {l’espace,les pensées} (cache)

Je répondais récemment par courriel :

J’en ressors souvent avec une sorte de soulagement, pas par le poids de la régularité mais par la charge mentale que toutes ces pensées occasionnent. Si c’est publié ça peut sortir de mon esprit, les pensées actuelles me semblent être consignées. Et peuvent servir de points de repères pour de futures réflexions. Ou me permettent de les oublier plus facilement, de passer à autre chose.

Je me demande très souvent si je devrais publier tout cela dans un carnet, est-ce que cela produirait la même émotion/sensation ? Ou avec une personne en particulier ? Je me sentirais peut-être coupable/responsable d’asséner ces pensées, ici j’ai l’impression que ça reste dilué et que les personnes qui viennent lire consentent à accepter de telles idées.

General Ideas Protection Regulation?

Citation libre/adaptée de la semaine :

Le meilleur moment pour utiliser son propre domaine, c’était il y a 20 ans. Le deuxième meilleur moment, c’est maintenant.

Mon domaine est un arbre, les GAFAM sont de l’huile de palme.

Blogging, as a community and a practice, continues to be refined to this day thanks to the dedication of web users everywhere. But its sharpest point was made the day Mena Trott decided that a blog could be more than just some text on a page. It could be one of a kind.

The Evolution of Blogging (cache)

Il y a 18 ans de cela…

Thomas a depuis publié une réponse (cache). Et j’y réponds plus tard.

2019-08-08

Cyberattaque

Des livres parlant de « cyberattaques » ou de « cybersécurité », il y en a plein. C'est un thème à la mode et les historiens du futur, lorsqu'ils étudieront la littérature du passé, noteront sans doute que les années 2010 étaient marquées par l'importance de ce thème. Mais ce livre a un angle original : ni un roman, ni un « reportage » sensationnaliste, ni une pseudo-réflexion sur la « cyberguerre », c'est un récit vu de l'intérieur d'une grosse perturbation, le passage de NotPetya dans l'entreprise où travaille l'auteure. Derrière le passionnant récit « sur le terrain », c'est peut-être l'occasion de se poser quelques questions sur l'informatique et la sécurité.

J'avoue ne pas savoir dans quelle mesure ce récit est authentique. L'auteure raconte à la première personne ce qu'a vécu l'entreprise où elle travaillait. Angeline Vagabulle est un pseudonyme, soit parce que l'entreprise ne souhaitait pas que ses cafouillages internes soient associés à son nom, soit parce que l'auteure a fait preuve d'imagination et romancé la réalité. Mais le récit est très réaliste et, même si cette entreprise particulière n'existe pas, les évènements relatés dans ce livre ont tous bien eu lieu dans au moins une grande entreprise dans le monde.

Ceux et celles qui ont vécu un gros problème informatique dans une grande entreprise multinationale les reconnaitront : le DSI qui se vante dans des messages verbeux et mal écrits que l'entreprise est bien protégée et que cela ne pourrait pas arriver, les conseils absurdes (« ne cliquez pas sur un lien avant d'être certain de son authenticité »), l'absence de communication interne une fois que le problème commence (ou bien son caractère contradictoire « éteignez tout de suite vos ordinateurs » suivi de « surtout n'éteignez pas vos ordinateurs »), la langue de bois corporate (« nous travaillons très dur pour rétablir la situation »), la découverte de dépendances que personne n'avait sérieusement étudié avant (« ah, sans les serveurs informatiques, on ne peut plus téléphoner ? »), l'absence de moyens de communications alternatifs. Il faut dire que l'entreprise décrite ici a fait fort : non seulement les postes de travail sur le bureau mais tous les serveurs étaient sous Windows, évidemment pas tenus à jour, et donc vulnérables à la faille EternalBlue. Au passage de NotPetya, tous les fichiers sont détruits et plus rien ne marche, on ne peut plus envoyer de propositions commerciales aux clients, on ne peut plus organiser une réunion, on ne peut même plus regarder le site Web public de la boîte (qui, lui, a tenu, peut-être était-il sur Unix ?) Et cela pendant plusieurs semaines.

Le ton un peu trop « léger », et le fait que l'héroïne du livre surjoue la naïve qui ne comprend rien peuvent agacer mais ce livre n'est pas censé être un guide technique du logiciel malveillant, c'est un récit par une témoin qui ne comprend pas ce qui se passe, mais qui décrit de manière très vivante la crise. (En italique, des encarts donnent des informations plus concrètes sur la cybersécurité. Mais celles-ci sont parfois non vérifiés, comme les chiffres de cyberattaques, a fortiori comme leur évaluation financière.)

(Le titre est clairement sensationnaliste : il n'y a pas eu d'attaque, cyber ou pas, NotPetya se propageait automatiquement et ne visait pas spécialement cette entreprise.)

En revanche, j'ai particulièrement apprécié les solutions que mettent en place les employés, pour faire face à la défaillance de l'informatique officielle. Comme les ordiphones ont survécu, WhatsApp est largement adopté, et devient l'outil de communication de fait. (Ne me citez pas les inconvénients de WhatsApp, je les connais, et je connais l'entreprise qui est derrière. Mais, ici, il faut se rappeler que les différents sites de la boîte n'avaient plus aucune communication.) Il reste à reconstituer les carnets d'adresses, ce qui occupe du monde (« C'est John, du bureau de Dublin, qui demande si quelqu'un a le numéro de Kate, à Bruxelles, c'est pour pouvoir contacter Peter à Dubaï. ») Beaucoup de débrouillardise est déployée, pour pallier les conséquences du problème. Une nouvelle victoire du shadow IT, et la partie la plus passionnante du livre.

Ce livre peut aussi être lu comme une critique de l'entreprise. Avant même le problème informatique, l'auteure note que sa journée se passait en réunion « sans même le temps d'aller aux toilettes ». On peut se demander s'il est normal qu'une journée de travail se passe exclusivement en réunions et en fabrication de reportings, sans rien produire. Il est symptomatique, d'ailleurs, qu'on ne sait pas exactement quel travail fait l'héroïne dans son entreprise, ni dans quel service elle travaille, ni d'ailleurs ce que fait l'entreprise.

L'auteure s'aventure à supposer que le problème est partiellement de la faute des informaticiens. « Ils feraient mieux de se concentrer sur leur boulot, en l'occurrence le développement d'applications et de systèmes sans failles. » C'est non seulement très yakafokon (développer un système sans faille est vraiment difficile) mais surtout bien à côté de la plaque. On sait, sinon faire des applications sans faille, du moins faire des applications avec moins de failles. On sait sécuriser les systèmes informatiques, pas parfaitement, bien sûr, mais en tout cas bien mieux que ce qu'avait fait l'entreprise en question. On le sait. Il n'y a pas de problème d'ignorance. En revanche, savoir n'est pas tout. Encore faut-il appliquer et c'est là que le bât blesse. Les solutions connues ne sont pas appliquées, à la fois pour de bonnes et de mauvaises raisons. Elles coûtent trop cher, elles ne plaisent pas aux utilisateurs (« le système que tu nous dis d'utiliser, j'ai essayé, il est peut-être plus sécurisé, mais qu'est-ce qu'il est moche ») et/ou aux décideurs (« ce n'est pas enterprise-grade » ou bien « on n'a pas le temps, il faut d'abord finir le reporting du trimestre précédent »). D'ailleurs, après une panne d'une telle ampleur, est-ce que l'entreprise en question a changé ses pratiques ? Gageons qu'elle aura continué comme avant. Par exemple, au moment du passage de NotPetya, l'informatique était sous-traitée au Portugal et en Inde. Aucun informaticien compétent dans les bureaux. Est-ce que ça a changé ? Probablement pas. L'expérience ne sert à rien, surtout en matière de cybersécurité.

Déclaration de potentiel conflit d'intérêt : j'ai reçu un exemplaire gratuitement.

2019-08-06

☕︎ 1%

Essayer d’être à l’écoute de soi avant de pouvoir être à l’écoute des autres. Devenir le 1% de sa vie, prendre conscience des 99 autres. Savoir décliner lorsqu’on n’est pas en forme. Prendre soin de ma propre attente.

We should direct our attention to find ways to solve problems affecting our own health, our environment, the world we live in. A good example of action for developers is the world’s first online hackathon to help fix the climate, running between today and end of August.

WDRL 270 (cache)

J’apprends via l’une de mes publications préférées l’existence de ce hackathon. J’aurais presque envie de participer avec un truc qui germe depuis quelques semaines. Merci Anselm.

Au passage, pourquoi préféré ? En partie pour la forme : aucun traçage des liens sur lesquels j’ai cliqué.

Once subscribed, you’ll receive newsletter emails; the opening of the message or clicks on the links are not tracked (though sometimes, the links included may be non-public links, which allows to count overall clicks from the newsletter; such links are the same for all subscribers, hence not connected to your identity).

Privacy Policy (cache)

C’est tellement inhabituel dans ce milieu. Apprendre à remercier les 1% qui m’inspirent et qui me permettent de garder l’espoir d’un monde moins noir.

But those 1% do have to recognise - we ALL have to recognise - that they are enormously privileged. That they are lucky to be able to do what they do. That they have won a grand industry prize that allows them to ignore all the things that most teams have to deal with.

For most teams are not able to just do what they want. They are constrained by the organisation that they exist within. They must produce code that will reliably work and be easily maintained over the next several years. They can’t afford to retain someone who will innovate a new codebase and then move on, leaving others to puzzle over it. They can’t hire a 10x Engineer Ninja who will reimplement a brochure-ware website in a client-side framework and then ignore those users who are excluded by it.

No, most teams are very boring. I’m really glad about that. We need boring. Boring is what gives stability. Boring is what allows web teams to concentrate on building robust websites, and focussing on user needs. Boring is what allows teams to produce elegant long-life solutions that do not need to be babysat and stroked by a magical engineering gnome.

The Real Dark Web (cache)

La réalité est plus complexe, il existe tout un spectre de technologies ennuyantes et à maintenir. Différents niveaux d’acceptation, de souffrances aussi. Et parfois d’accomplissement, s’il y a de la maintenance c’est probablement qu’il y a un usage.

Ce qui manque parfois cruellement aux 1% qui en parlent le plus…

Whatever works for you, invest in that. It’s more important than ever before because once they get to know you better than you know yourself, it’s game over for you. They can manipulate you and control you and you will not even realize this is happening. Because they have hacked you.

Yuval Harari on social inequality and the naivete of tech CEOs

Se connaître mieux qu’un algorithme afin d’être en capacité de pouvoir résister.

Introspection vs. algospection.

Le récit de la croissance verte a donc le même statut que le climato-scepticisme aux États-Unis : un discours de légitimation qui permet aux dirigeants de dissimuler l’égoïsme de leur action et aux citoyens de continuer à vivre comme si de rien n’était. Un anthropologue extraterrestre qui viendrait nous étudier, ou un historien du futur qui s’intéresserait à notre époque, ne verraient pas de différence de fonction entre les deux ; seulement deux variantes géographiquement situées du même récit de légitimation. Le citoyen européen qui mord à la croissance verte n’est pas différent du climato-sceptique américain, dont pourtant il se moque. Et, du point de vue de l’anthropologue extraterrestre ou de l’historien du futur, un journaliste français qui se félicite de voir le gouvernement promouvoir les éoliennes ne commet pas un crime moins grand que le journaliste de Fox News qui explique que le réchauffement climatique est un complot des chinois.

ZAD, nature, culture et recomposition des mondes : un entretien avec Alessandro Pignocchi (cache)

Tout est dit. La paille dans l’œil du voisin est peut-être en plastique mais on se retrouve avec le même champ de vision une fois qu’on se ballade avec une en inox.

Ces illustrations <3

Tl;dr : je me lance dans une nouvelle expérimentation pour tenter de réduire l’éco-anxiété et le surplus de charge mentale que je ressens trop fortement depuis quelques semaines en faisant une pause "réseaux sociaux" d’un mois et demi environ.

Pause (cache)

Idem ici, de manière définitive. Il y aura probablement moins de liens au dehors. Plus de liens en dedans.

Les réponses sont en nous, tout ça.

We continue to feel incredibly uncomfortable about playing the role of content arbiter and do not plan to exercise it often.

[…]

Cloudflare is not a government. While we’ve been successful as a company, that does not give us the political legitimacy to make determinations on what content is good and bad. Nor should it. Questions around content are real societal issues that need politically legitimate solutions. We will continue to engage with lawmakers around the world as they set the boundaries of what is acceptable in their countries through due process of law. And we will comply with those boundaries when and where they are set.

Terminating Service for 8Chan (cache)

C’est peu de dire que je ne porte pas dans mon cœur un service qui centralise autant et j’ai conscience du jesaispasquoiwashing qu’il y a dans ce billet. Toujours est-il qu’il me semble approprié et bénéfique dans le signal porté. Oui, il est possible de refuser des clients lorsqu’on opère un service.

N’oubliez pas que Shopify (cache) n’a pas du tout la même vision des choses…

Citation de la semaine :

1% today is better than 50% tomorrow or some distant and impossible far-flung future.

1% Better (cache)

Programming Elixir

Ce livre présente le langage de programmation Elixir, un langage, pour citer la couverture, « fonctionnel, parallèle, pragmatique et amusant ».

Elixir est surtout connu dans le monde des programmeurs Erlang, car il réutilise la machine virtuelle d'Erlang pour son exécution, et reprend certains concepts d'Erlang, notamment le parallélisme massif. Mais sa syntaxe est très différente et il s'agit bien d'un nouveau langage. Les principaux logiciels libres qui l'utilisent sont Pleroma (c'est via un travail sur ActivityPub que j'étais venu à Pleroma et donc à Elixir) et CertStream.

Comme tous les livres de cet éditeur, l'ouvrage est très concret, avec beaucoup d'exemples. Si vous voulez vous lancer, voici un exemple, avec l'interpréteur iex :

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

Interactive Elixir (1.8.2) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> "Hello"
"Hello"
iex(2)> 2 + 2
4
    
Mais on peut aussi bien sûr mettre du Elixir dans un fichier et l'exécuter :
% cat > test.exs 
IO.puts 2+2

% elixir test.exs
4
    

Elixir a évidemment un mode Emacs, elixir-mode (site de référence sur Github). On peut l'utiliser seul, ou bien intégré dans l'environnement général alchemist. J'ai utilisé MELPA pour installer elixir-mode. Une fois que c'est fait, on peut se lancer dans les exercices du livre.

Quelles sont les caractéristiques essentielles d'Elixir ? Comme indiqué sur la couverture du livre, Elixir est fonctionnel, parallèle, pragmatique et amusant. Voici quelques exemples, tirés du livre ou inspirés par lui, montrés pour la plupart en utilisant l'interpréteur iex (mais Elixir permet aussi de tout mettre dans un fichier et de compiler, chapitre 1 du livre).

Contrairement à un langage impératif classique, les variables ne sont pas modifiées (mais on peut lier une variable à une nouvelle valeur, donc l'effet est proche de celui d'un langage impératif) :

iex(1)> toto = 42
42
iex(2)> toto
42
iex(3)> toto = 1337
1337
iex(4)> ^toto = 1
** (MatchError) no match of right hand side value: 1
    (stdlib) erl_eval.erl:453: :erl_eval.expr/5
    (iex) lib/iex/evaluator.ex:249: IEx.Evaluator.handle_eval/5
    (iex) lib/iex/evaluator.ex:229: IEx.Evaluator.do_eval/3
    (iex) lib/iex/evaluator.ex:207: IEx.Evaluator.eval/3
    (iex) lib/iex/evaluator.ex:94: IEx.Evaluator.loop/1
    (iex) lib/iex/evaluator.ex:24: IEx.Evaluator.init/4
iex(4)> ^toto = 1337
1337
    
Dans les deux derniers tests, le caret avant le nom de la variable indique qu'on ne veut pas que la variable soit redéfinie (chapitre 2 du livre).

Elixir compte sur le pattern matching (chapitre 2 du livre) et sur les fonctions beaucoup plus que sur des structures de contrôle comme le test ou la boucle. Voici la fonction qui calcule la somme des n premiers nombres entiers. Elle fonctionne par récurrence et, dans un langage classique, on l'aurait programmée avec un test « si N vaut zéro, c'est zéro, sinon c'est N plus la somme des N-1 premiers entiers ». Ici, on utilise le pattern matching :

iex(1)> defmodule Test do
...(1)> def sum(0), do: 0
...(1)> def sum(n), do:  n + sum(n-1)
...(1)> end
iex(2)> Test.sum(3)
6
    
(On ne peut définir des functions nommées que dans un module, d'où le defmodule.)

Naturellement, comme dans tout langage fonctionnel, on peut passer des fonctions en paramètres (chapitre 5 du livre). Ici, la traditionnelle fonction map (qui est dans le module standard Enum) prend en paramètre une fonction anonyme qui multiplie par deux :

iex(1)> my_array = [1, 2, 8, 11]   
[1, 2, 8, 11]
iex(2)> Enum.map my_array, fn x -> x*2 end
[2, 4, 16, 22]
    
Cela marche aussi si on met la fonction dans une variable :
iex(3)> my_func = fn x -> x*2 end
#Function<7.91303403/1 in :erl_eval.expr/5>
iex(4)> Enum.map my_array, my_func
[2, 4, 16, 22]
    
Notez qu'Elixir a une syntaxe courante mais moins claire pour les programmeurs et programmeuses venu·e·s d'autres langages, si on veut définir une courte fonction :
iex(5)> Enum.map my_array, &(&1*2)
[2, 4, 16, 22]
    
(Et notez aussi qu'on ne met pas forcément de parenthèses autour des appels de fonction.)

Évidemment, Elixir gère les types de données de base (chapitre 4) comme les entiers, les booléens, les chaînes de caractères… Ces chaînes sont en Unicode, ce qui fait que la longueur n'est en général pas le nombre d'octets :

iex(1)>  string = "Café"
"Café"
iex(2)> byte_size(string)
5
iex(3)> String.length(string)
4
    
Il existe également des structures de données, comme le dictionnaire (ici, le dictionnaire a deux élements, nom et ingrédients, le deuxième ayant pour valeur une liste) :
defmodule Creperie do
  def complète do
    %{nom: "Complète", ingrédients: ["Jambon", "Œufs", "Fromage"]}
  end

À propos de types, la particularité la plus exaspérante d'Elixir (apparemment héritée d'Erlang) est le fait que les listes de nombres sont imprimées comme s'il s'agissait de chaînes de caractères, si ces nombres sont des codes ASCII plus ou moins imprimables :

iex(2)> [78, 79, 78]
'NON'

iex(3)> [78, 79, 178]
[78, 79, 178]

iex(4)> [78, 79, 10]
'NO\n'

iex(5)> [78, 79, 7]
'NO\a'

iex(6)> [78, 79, 6] 
[78, 79, 6]
    
Les explications complètes sur cet agaçant problème figurent dans la documentation des charlists. Pour afficher les listes de nombres normalement, plusieurs solutions :
  • Pour l'interpréteur iex, mettre IEx.configure inspect: [charlists: false] dans ~/.iex.exs.
  • Pour la fonction IO.inspect, lui ajouter un second argument, charlists: :as_lists.
  • Un truc courant est d'ajouter un entier nul à la fin de la liste, [78, 79, 78] ++ [0] sera affiché [78, 79, 78, 0] et pas NON.

À part cette particularité pénible, tout cela est classique dans les langages fonctionnels. Ce livre va nous être plus utile pour aborder un concept central d'Elixir, le parallélisme massif (chapitre 15). Elixir, qui hérite en cela d'Erlang, encourage les programmeuses et les programmeurs à programmer en utilisant un grand nombre d'entités s'exécutant en parallèle, les processus (notons tout de suite qu'un processus Elixir, exécuté par la machine virtuelle sous-jacente, ne correspond pas forcément à un processus du système d'exploitation). Commençons par un exemple trivial, avec une machine à café et un client :

defmodule CoffeeMachine do

  def make(sugar) do
    IO.puts("Coffee done, sugar is #{sugar}")
  end

end

CoffeeMachine.make(true)
spawn(CoffeeMachine, :make, [false])
IO.puts("Main program done")
    
Le premier appel au sous-programme CoffeeMachine.make est classique, exécuté dans le processus principal. Le second appel lance par contre un nouveau processus, qui va exécuter CoffeeMachine.make avec la liste d'arguments [false].

Les deux processus (le programme principal et celui qui fait le café) sont ici séparés, aucun message n'est échangé. Dans un vrai programme, on demande en général un minimum de communication et de synchronisation. Ici, le processus parent envoie un message et le processus fils répond (il s'agit de deux messages séparés, il n'y a pas de canal bidirectionnel en Elixir, mais on peut toujours en bâtir, et c'est ce que font certaines bibliothèques) :

defmodule CoffeeMachine do

  def make(sugar) do
    pid = self() # PID pour Process IDentifier
    IO.puts("Coffee done by #{inspect pid}, sugar #{sugar}")
  end

  def order do
    pid = self()
    receive do
      {sender, msg} ->
     	send sender, {:ok, "Order #{msg} received by #{inspect pid}"}
    end
  end
  
end

pid = spawn(CoffeeMachine, :order, [])
IO.puts("Writing to #{inspect pid}")
send pid, {self(), "Milk"}

receive do
  {:ok, message} -> IO.puts("Received \"#{message}\"") 
  {_, message} -> IO.puts("ERROR #{message}")
after 1000 -> # Timeout after one second
  IO.puts("No response received in time")
end
    
On y notera :
  • Que l'identité de l'émetteur n'est pas automatiquement ajoutée, c'est à nous de le faire,
  • L'utilisation du pattern matching pour traiter les différentes types de message (avec clause after pour ne pas attendre éternellement),
  • Que contrairement à d'autres langages à parallélisme, il n'y a pas de canaux explicites, un processus écrit à un autre processus, il ne passe pas par un canal. Là encore, des bibliothèques de plus haut niveau permettent d'avoir de tels canaux. (C'est le cas avec Phoenix, présenté plus loin.)

spawn crée un processus complètement séparé du processus parent. Mais on peut aussi garder un lien avec le processus créé, avec spawn_link, qui lie le sort du parent à celui du fils (si une exception se produit dans le fils, elle tue aussi le parent) ou spawn_monitor, qui transforme les exceptions ou la terminaison du fils en un message envoyé au parent :

defmodule Multiple do
  
  def newp(p) do
    send p, {self(), "I'm here"}
    IO.puts("Child is over")
    # exit(:boom) # exit() would kill the parent
    # raise "Boom" # An exception would also kill it
  end

end

child = spawn_link(Multiple, :newp, [self()])
    
Et avec spawn_monitor :
defmodule Multiple do
  
  def newp(p) do
    pid = self()
    send p, {pid, "I'm here"}
    IO.puts("Child #{inspect pid} is over")
    # exit(:boom) # Parent receives termination message containing :boom
    # raise "Boom" # Parent receives termination message containing a
                   # tuple, and the runtime displays the exception
  end

end

{child, _} = spawn_monitor(Multiple, :newp, [self()]) 
    

Si on trouve les processus d'Elixir et leurs messages de trop bas niveau, on peut aussi utiliser le module Task, ici un exemple où la tâche et le programme principal ne font pas grand'chose à part dormir :

task = Task.async(fn -> Process.sleep Enum.random(0..2000); IO.puts("Task is over") end)  
Process.sleep Enum.random(0..1000)  
IO.puts("Main program is over")      
IO.inspect(Task.await(task))                                                                        
    
Vous pouvez trouver un exemple plus réaliste, utilisant le parallélisme pour lancer plusieurs requêtes réseau en évitant qu'une lente ne bloque une rapide qui suivrait, dans cet article.

Les processus peuvent également être lancés sur une autre machine du réseau, lorsqu'une machine virtuelle Erlang y tourne (chapitre 16 du livre). C'est souvent présenté par les zélateurs d'Erlang ou d'Elixir comme un bon moyen de programmer une application répartie sur l'Internet. Mais il y a deux sérieux bémols :

  • Ça ne marche que si les deux côtés de l'application (sur la machine locale et sur la distante) sont écrits en Elixir ou en Erlang,
  • Et, surtout, surtout, la sécurité est très limitée. La seule protection est une série d'octets qui doit être la même sur les deux machines. Comme elle est parfois fabriquée par l'utilisateur (on trouve sur le Web des exemples de programmes Erlang où cette série d'octets est une chaîne de caractères facile à deviner), elle n'est pas une protection bien solide, d'autant plus que la machine virtuelle la transmet en clair sur le réseau. (Chiffrer la communication semble difficile.)
Bref, cette technique de création de programmes répartis est à réserver aux cas où toutes les machines virtuelles tournent dans un environnement très fermé, complètement isolé de l'Internet public. Autrement, si on veut faire de la programmation répartie, il ne faut pas compter sur ce mécanisme.

Passons maintenant à des exemples où on utilise justement le réseau. D'abord, un serveur echo (je me suis inspiré de cet article). Echo est normalisé dans le RFC 862. Comme le programme est un peu plus compliqué que les Hello, world faits jusqu'à présent, on va commencer à utiliser l'outil de compilation d'Elixir, mix (chapitre 13 du livre, il existe un court tutoriel en français sur Mix).

Le plus simple, pour créer un projet qui sera géré avec mix, est :

%  mix new echo
    
Le nouveau projet est créé, on peut l'ajouter à son VCS favori, puis aller dans le répertoire du projet et le tester :
    
%  cd echo
%  mix test
Les tests ne sont pas très intéressants pour l'instant, puisqu'il n'y en a qu'un seul, ajouté automatiquement par Mix. Mais ça prouve que notre environnement de développement marche. Maintenant, on va écrire du vrai code, dans lib/echo.ex (vous pouvez voir le résultat complet).

Les points à noter :

  • Le livre de Dave Thomas ne parle pas du tout de programmation réseau, ou des prises réseau,
  • J'ai utilisé une bibliothèque Erlang.gen_tcp, puisqu'on peut appeler les bibliothèques Erlang depuis Elixir (rappelez-vous que les deux langages utilisent la même machine virtuelle, Beam.) Les bibliothèques Erlang importées dans Elixir ont leur nom précédé d'un deux-points donc, ici, :gen_tcp.
  • Une fois un client accepté avec :gen_tcp.accept, la fonction loop_acceptor lance un processus séparé puis s'appelle elle-même. Comme souvent dans les langages fonctionnels, on utilise la récursion là où, dans beaucoup de langages, on aurait utilisé une boucle. Cette appel récursif ne risque pas de faire déborder la pile, puisque c'est un appel terminal.
  • La fonction serve utilise l'opérateur |>, qui sert à emboiter deux fonctions, le résultat de l'une devenant l'argument de l'autre (comme le tube pour le shell Unix.) Et elle s'appelle elle-même, comme loop_acceptor, pour traiter tous les messages envoyés.
  • La fonction write_line est définie en utilisant le pattern matching (deux définitions possibles, une pour le cas normal, et une pour le cas où la connexion TCP est fermée.)
  • Le code peut sembler peu robuste, plusieurs cas ne sont pas traités (par exemple, que se passe-t-il si :gen_tcp.recv, et donc read_line, renvoie {:error, :reset} ? Aucune définition de write_line ne prévoit ce cas.) Mais cette négligence provient en partie du d'un style de développement courant en Elixir : on ne cherche pas à faire des serveurs qui résistent à tout, ce qui complique le code (la majorité du programme servant à gérer des cas rares). On préfère faire tourner le programme sous le contrôle d'un superviseur (et l'environnement OTP fournit tout ce qu'il faut pour cela, cf. chapitres 18 et 20 dans le livre), qui redémarrera le programme le cas échéant. Au premier atelier Elixir que j'avais suivi, au BreizhCamp, le formateur, Nicolas Savois, m'avait dit que mon code était trop robuste et que je vérifiait trop de choses. Avec Elixir, c'est Let it crash, et le superviseur se chargera du reste. (Dans mon serveur echo, je n'ai pas utilisé de superviseur, mais j'aurais dû.)
Et pour lancer le serveur ? Un programme start-server.exs contient simplement :
import Echo

Echo.accept(7)
    
(7 étant le port standard d'echo) Et on le démarre ainsi :
% sudo mix run start-server.exs
18:54:47.410 [info]  Accepting connections on port 7
...
18:55:10.807 [info]  Serving #Port<0.6>
    
La ligne « Serving #Port » est affichée lorsqu'un client apparait. Ici, on peut tester avec telnet :
% telnet thule echo
Trying 10.168.234.1...
Connected to thule.
Escape character is '^]'.
toto
toto
^]
telnet> quit
Connection closed.
    
Ou bien avec un client echo spécialisé, comme echoping :
% echoping  -v thule
...
Trying to send 256 bytes to internet address 10.168.234.1...
Connected...
TCP Latency: 0.000101 seconds
Sent (256 bytes)...
Application Latency: 0.000281 seconds
256 bytes read from server.
Estimated TCP RTT: 0.0001 seconds (std. deviation 0.000)
Checked
Elapsed time: 0.000516 seconds
   

Et si on veut faire un serveur HTTP, parce que c'est quand même plus utile ? On peut utiliser le même gen_tcp comme dans l'exemple qui figure au début de cet article. Si vous voulez tester, le code est en http-serve.exs, et ça se lance avec :

% elixir server.exs
15:56:29.721 [info]  Accepting connections on port 8080
...
    
On peut alors l'utiliser avec un client comme curl, ou bien un navigateur visitant http://localhost:8080/. Mais ce serveur réalisé en faisant presque tout soi-même est très limité (il ne lit pas le chemin de l'URL, il ne traite qu'une requête à la fois, etc) et, en pratique, la plupart des programmeurs vont s'appuyer sur des cadriciels existants comme Phoenix ou Plug. Par défaut, tous les deux utilisent le serveur HTTP Cowboy, écrit en Erlang (cf. le site Web de l'entreprise qui développe Cowboy, et la documentation.) Pour avoir des exemples concrets, regardez cet article ou bien, avec Plug, celui-ci.

Mix permet également de gérer les dépendances d'une application (les bibliothèques dont on a besoin), via Hex, le système de gestion de paquetages commun à Erlang et Elixir (chapitre 13 du livre). Voyons cela avec une bibliothèque DNS, Elixir DNS. On crée le projet :

 % mix new test_dns
* creating README.md
* creating .formatter.exs
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/test_dns.ex
* creating test
* creating test/test_helper.exs
* creating test/test_dns_test.exs
...

% mix test
Compiling 1 file (.ex)
Generated test_dns app
..

Finished in 0.04 seconds
1 doctest, 1 test, 0 failures
  
On modifie le fichier mix.exs, créé par Mix, pour y ajouter la bibliothèque qu'on veut, avec son numéro de version minimal :
# Run "mix help deps" to learn about dependencies.
defp deps do
    [
      {:dns, "~> 2.1.2"},
    ]
end
  
Et on peut alors installer les dépendances. (Pour utiliser Hex, sur Debian, il faut installer le paquetage erlang-inets, sinon on obtient (UndefinedFunctionError) function :inets.stop/2 is undefined (module :inets is not available).)
% mix deps.get                       
Could not find Hex, which is needed to build dependency :dns
Shall I install Hex? (if running non-interactively, use "mix local.hex --force") [Yn] y
* creating /home/stephane/.mix/archives/hex-0.20.1
  
Le message Could not find Hex [...] Shall I install Hex n'apparaitra que la première fois. Après :
% mix deps.get
Resolving Hex dependencies...
Dependency resolution completed:
New:
  dns 2.1.2
  socket 0.3.13
* Getting dns (Hex package)
* Getting socket (Hex package)
  
Notez qu'Hex a également installé la dépendance de la dépendance (dns dépend de socket.) On peut maintenant exécuter nos programmes :
% cat example.exs
IO.inspect(DNS.resolve("github.com", :a))
    
% mix run ./example.exs
{:ok, [{140, 82, 118, 4}]}
  

En conclusion, je trouve le livre utile. Il est en effet très pratique, très orienté vers les programmeuses et programmeurs qui veulent avoir du code qui tourne dès les premiers chapitres. Concernant le langage, je réserve mon opinion tant que je n'ai pas écrit de vrais programmes avec.

Qui, d'ailleurs, écrit des vrais programmes avec Elixir ? Parmi les logiciels connus :

  • Une mise en œuvre du fédivers, Pleroma.
  • L'excellent serveur de suivi des journaux Certificate Transparency (RFC 6962) CertStream (journaux qu'il est indispensable de surveiller automatiquement pour détecter des faux certificats utilisant votre nom).
  • Le système Nerves de développement de code embarqué.
  • Toujours pour l'IoT, il y a Astarte.
  • Le système de communication audio/vidéo Discord (non libre, contrairement aux trois précédents) l'utilise. Ils publient d'intéressants articles sur les questions de passage à l'échelle, comme celui-ci ou bien cet autre, qui mentionne les limites d'Elixir.
  • Le système de curation de contenu éducatif Moodle.
  • Et le futur système de coordination d'actions Mobilizon sera en Elixir.

Si vous cherchez des ressources supplémentaires sur Elixir, voici quelques idées :

2019-08-02

Qu’est-ce que le numérique ?

2019-08-02 Emmanuelle Bermès - Figoblog - Divers

Cette année, mon été est particulièrement studieux. J’étais donc au bord de la piscine, en train de lire le petit opus de Pierre Mounier Les humanités numériques paru en 2018 à l’issue du séminaire organisé à l’EHESS avec Aurélien Berra, quand je suis tombée sur cette phrase qu’il place sous la plume de Milad Doueihi : « le numérique se fait culture et modifie (…) notre rapport au monde et aux autres hommes, dans toutes ses dimensions ».

Comme cela faisait plusieurs jours que je réfléchissais à ce que pourrait être une définition du numérique, dans le contexte des bibliothèques en général et de la mienne en particulier, je me suis dit que j’allais partager ici cette pensée estivale.

On trouve une pléthore d’auteurs qui, depuis le début des années 2000 environ (je prends si vous avez des références plus anciennes) annoncent que le « numérique » est une révolution dont l’ampleur est comparable à celle de Gutenberg, voire plus importante. Ces auteurs analysent cette évolution sur différents plans : documentaire, scientifique, social… mais ce que je trouve intéressant ici, c’est l’idée d’un impact global embrassant et dépassant tous ces aspects. Il est un peu vain de chercher à définir si l’émergence du livre imprimé – et son impact sur la diffusion des connaissances, des idées et d’une façon plus générale, sur l’évolution des sociétés occidentales – a été « plus » ou « moins » importante que ne l’est celle du « numérique ». Ce qui est intéressant, c’est de reconnaître cet impact culturel, au sens large du mot culture qui englobe toutes les pratiques, connaissances, normes et traditions qui sous-tendent globalement le fonctionnement de la société.

Vu comme une « culture » qui modifie notre rapport au monde, le « numérique » embrasse plusieurs aspects, sans se confondre avec eux. Ils en sont plutôt, à mon avis, des composantes.

Tout d’abord, l’informatique ou plutôt, la micro-informatique telle qu’elle a commencé à conquérir les foyers et les bureaux depuis les années 1980, pour aboutir aujourd’hui dans tous les terminaux « mobiles » (smartphones, etc.) et les objets connectés (montres etc.) qui ne feront que se développer encore davantage. Dans le contexte des bibliothèques et de l’édition, on a pu parler également « d’électronique ». Il s’agit d’une technologie, qui se répand, se perfectionne et se développe, condition nécessaire à l’émergence d’une société numérique, comme la machine à vapeur a été nécessaire à l’émergence d’une société industrielle.

Ensuite, Internet et le web. Les deux ne se recouvrent pas mais le premier est nécessaire au fonctionnement du second, et le second est et a été l’instrument de la démocratisation du premier. Pour qu’une véritable culture numérique puisse émerger, il faut ajouter un autre ingrédient, survenu quelques années après la création du web : la connectivité permanente, partout et tout le temps, pour un coût devenu aussi négligeable – ou en tout cas intégré à nos vies – que l’électricité. Au point qu’être connecté devient aussi indispensable et naturel qu’avoir le chauffage ou la lumière.

Enfin, il y a le « digital » et le « virtuel », qui ne sont pas seulement des mots, des presque synonymes, mais témoignent d’une réalité : l’appropriation du numérique dans certaines pratiques, usages et expériences de la vie.

Entre « digital » et « numérique », il y a davantage qu’un problème d’anglicisme : l’étymologie confère à « digital » une proximité avec la main, les doigts, et donc la dimension artisanale du numérique : quelque chose que chaque individu peut exercer avec ses mains, un outil du quotidien. C’est aussi cette acception qui à mon avis prévaut derrière la « transformation digitale » des entreprises (terme banni depuis longtemps, s’il a jamais été utilisé, dans les bibliothèques). Ainsi, le sens originel de « numérique » fait référence à la dimension mathématique de l’informatique (les zéros et les uns) et se traduirait par « computing » en anglais, tandis que le « digital » anglo-saxon correspondrait à notre « numérique » au sens large. Ce qui ne nous dit pas comment traduire en anglais ce « digital » au sens restreint de « avec les doigts », que l’on utilise parfois en français… Si quelqu’un a une idée !

Quant à « virtuel », il témoigne de l’idée que le numérique a fait émerger dans nos vies des dimensions immatérielles, qui paraissent réelles à nos sens et à nos cerveaux, et même à nos émotions, tout en étant totalement dématérialisées. Prenons par exemple la « réalité virtuelle » : elle n’a rien d’une réalité, il s’agit plutôt d’une sorte de cinéma interactif très performant, qui parvient par l’immersion des sens à nous approcher beaucoup plus près de l’illusion de la réalité qu’un écran en 2 dimensions ou même équipé de lunettes 3D. Le « virtuel » nous immerge dans un monde qui ressemble au nôtre mais est construit de toutes pièces. Si on s’intéresse aux réseaux sociaux, où émergent des dimensions virtuelles liées aux émotions (comme l’amitié virtuelle entre deux personnes qui ne se sont jamais rencontrées « IRL »), le monde « virtuel » apparaît même comme un prolongement ou une extension de celui que nous expérimentons physiquement et spatialement, mais qui, dans les interactions sociales qu’il suscite, est tout aussi « réel ». Ce monde virtuel est aussi un monde d’infini possibles, de potentialités illimitées parce qu’elles sont libérées des contraintes du monde physique.

Le numérique c’est donc tout cela : une technologie faite de terminaux et de réseaux, et son appropriation par les humains dans toutes les dimensions : corporelle, émotionnelle et sociale.

Le numérique n’est donc pas qu’une technologie. Pour en revenir à Gutenberg, l’imprimerie à caractères mobiles n’a pas suffi à elle seule à faire émerger une culture de l’écrit. Celle-ci a pris une nouvelle ampleur lorsqu’on a su fabriquer le papier de manière industrielle, pour un coût très bas. Le livre imprimé a permis, in fine, non seulement à presque tout le monde d’apprendre à lire, mais aussi à écrire, avec les doigts. Des infrastructures comme la poste ont permis de véhiculer l’écrit dans le temps et l’espace, jusque dans l’intime de nos vies. La société s’est ainsi transformée pour augmenter encore la disponibilité de l’écrit, et l’écrit a transformé tous les aspects des relations sociales et les règles qui régissent le monde. La question de la « culture numérique » est donc de savoir si on assiste à un changement de la même ampleur, dans un laps de temps beaucoup plus resserré.

Finalement, au vu de cette définition, que faire du « numérique en bibliothèque » ou du numérique patrimonial ? Dans notre profession, nous utilisons parfois le terme « numérique » pour désigner les collections qui partagent cette caractéristique : acquisitions électroniques, documents numérisés, archives du web etc. (notez l’emploi des différents termes…) Il s’agirait donc encore d’une autre acception. Finalement, le « numérique » en bibliothèque est aussi imprécis que le mot « livre » qui recouvre en fait plusieurs réalités : « le livre » au sens de la culture de l’écrit, et « les livres » au sens des collections.

2019-07-30

☕︎ Exemplarité

J’ai reçu deux courriels coup sur coup cette semaine qui m’ont rappelé pourquoi est-ce que je publiais ici. Ce n’est pas de l’exemplarité au sens de vouloir être exemplaire — ce qui serait à la fois prétentieux et anxiogène — mais de montrer que la voie que j’emprunte est un des multiples possibles. Libre à chacun et chacune de s’en inspirer. Et de documenter d’autres voies.

Quelques jours dans la forêt à être plus cueilleur que pêcheur. Pas vraiment par choix. Encore que. Je me suis même mis à la pêche à la mouche pour être sûr de prendre encore moins de poissons.

Il faut bien s’occuper.

Des bleuets dans une Kuksa Piètre consolation ? C’est quand même plus intéressant de bon matin :-).

J’ai aussi pris le temps de faire quelques photos de vacances. Tenter des trucs. Essayer d’échapper aux bibittes locales (cache). Fuir des idées noires. Dormir de façon suffisamment inconfortable pour ne plus avoir mal qu’au dos.

Du bonheur.

Mon reflet dans mes lunettes En vrai c’est juste une excuse pour montrer mon avancée en terme de couture. Cette sacoche va être exceptionnelle.

Et aussi éviter les tiques qui sont un sacré fléau dans le coin (cache). Je me retiens de faire une blague à base d’éthique.

Faites attention à vos slugs.

I cannot deny my son or myself the ease of modern life, and I have no wish to isolate him from friends and family by insisting on radical changes. A carbon-free life seems a solitary one: no travel to see grandparents, awkward refusals of invitations, precious time with friends replaced by gardening, canning, mending, building, working. I search for political solutions, an advocacy muted by the cowardice of my personal choices. In the end, I am responsible for the gases that are changing the climate and, in raising my son in comfort and convenience, am passing on that responsibility and guilt to him.

We Should Never Have Called It Earth (cache)

Comment se déculpabiliser ? Quel intérêt y a-t-il a dépasser un seuil tolérable ? Peut-être celui de se radicaliser ? Ou juste bloguer en bonne mauvaise conscience ?

Quels sont les exemples accessibles ?

Je me suis mis à cartographier les poubelles sur OpenStreetMap dans le Parc d’à côté au cours de mes promenades matinales. Je me suis demandé si l’information accessible par Internet ne rendait pas la connaissance caduque. Et si la crise actuelle n’était pas justement de se limiter à l’information pour délaisser la transmission. Et donc le rapport à l’autre.

Lorsque j’indique un chemin à quelqu’un, il y a tout un contexte qui vient avec. Et celui-ci sera différent pour chaque personne. Un tracé sur une carte n’a pas d’odeur. Enfin maintenant si, celui des poubelles.

À la base, ces promenades ont pour but de faire le vide. Perdu.

Citation de la semaine :

Pour que les rapports sociaux soient placés sous le signe de l’équité, il faut qu’une société limite d’elle-même la consommation d’énergie de ses plus puissants citoyens.

Énergie et équité, notes de lecture de Thomas sur l’ouvrage d’Ivan Illich (cache)

Je ne vois pas comment aboutir à cette limite sans une révolution.

Une prise de conscience et le bonheur s’échappe…

2019-07-23

☕︎ Timelines

Réflexion sur les lignes de temps, de vie. J’ai un vieux truc pour mes présentations et je me pose pas mal de questions sur la généralisation d’une telle représentation, surtout après avoir vu ces timelines.

Mais avant, la citation de la semaine :

Substack is — to be extremely reductive — paywalled blogging software that sends out an email notification.

Fast Software, Paid Newsletters, Novels (cache)

C’est la façon dont je considère les listes de diffusion actuelles. Une mode entre intimité et incompréhension. Cela ne m’empêche aucunement d’en apprécier quelques unes, une fois converties en blog flux.

“Billionnaire” isn’t a qualification. It’s the description of a person who is hoarding more resources than they could use in 100 lifetimes while other people are starving. It’s the name for a human dragon sleeping on its pile of rubies and gold.

Via mastodon, il semblerait que le compte original ne soit plus accessible.

Est-ce qu’il faut vraiment être devenu milliardaire pour être dans cette position ? Est-ce que chaque choix dans le but d’établir un capital n’est pas déjà une façon de le subtiliser à d’autres ?

Je vais le dire autrement : nous sommes en train d’abandonner la solution du pauvre pour la solution du riche. Le rêve ­rifkinien(1) d’avoir chacun son panneau et sa batterie tout en gardant à peu près le même niveau de consommation matérielle requiert de mettre 30 ou 40 fois plus d’argent sur la table pour y parvenir qu’en recourant aux centrales nucléaires que nous avons déjà. L’idée selon laquelle le nucléaire serait cher et les énergies renouvelables (ENR) pas chères ne correspond à aucun fait observable et augmente, selon moi, la vulnérabilité face à ce qui va se passer à l’avenir.

Jean-Marc Jancovici : « l’Europe est en décroissance ­énergétique depuis 2007 » (cache)

Je n’avais jamais par exemple pensé l’énergie en ce sens et au moment d’investir (le terme aurait dû me mettre la puce à l’oreille…) dans du solaire pour gagner en autonomie j’ai eu ce recul salutaire d’essayer de comprendre si ça pouvait passer à l’échelle. Il y a une difficulté à encourager du local expérimental (cache) qui pourrait rapidement devenir élitiste et capitaliste en privant les autres des ressources nécessaires à sa reproduction.

I’ve always liked to document experiences, and I have a thing for collections and completeness. I decided early that this redesign needed some kind of friendly ’museum of me’ as a way of introducing myself; less about my work and more about my life. The culture we surround ourselves with, the art that speaks to us, and the songs that soundtrack our lives — these things shape our identities. They speak volumes about who we are, and why the things we put into this world look or feel a certain way. There’s so much more to each of us than our professional achievements.

Timeline (cache)

Chacun de nos échanges est une timeline, une publication sur un mur, des gazouillis, un agrégat de stories, des pouets, des courriels, des articles de blog. Ces 20 dernières années du Web n’ont été qu’une façon de les représenter. Il y a des choix pour chacun des items de ces lignes de vie. En tant que créateur, en tant qu’éditeur, en tant qu’hébergeur et en tant qu’audience. C’est l’équilibre de pouvoir entre ces entités qui rend la relation saine.

Les licornes actuelles déstabilisent intentionnellement cette relation.

L’association participe à la réflexion sur l’évolution du droit d’auteur et des licences associées : voir la Licence Contributive Commons (cache) qui est un projet initié par l’association.

Elle place ses contenus originaux sous une licence garantissant le partage du savoir selon des modalités visant à une réciprocité.

Code social de Semeoz (cache)

Maïa annonce la fin de Semeoz (Observatoire des pratiques collaboratives et constructives) et nous invite à récupérer ce que l’on souhaite. Cela me pousse à m’interroger sur la pertinence d’une licence à réciprocité lorsque l’entité créatrice a été dissoute. Comment rester fidèle à une telle licence dans ces conditions ?

While questioning is key to curiosity, it can be tricky to know what to ask. Here are some of my standbys:

  • “Can you say that in more/different words?”
  • “How did you come to that decision?”
  • “Anything else I should know about?”
  • “Whose land is this?”
  • “Who’s missing or misrepresented?”
  • “Who’s telling this story, and why?”

There you have it—six questions for better, deeper living. A curious mind can become a caring mind—the more we know, the more we can appreciate a situation’s nuance and complexity.

Questions for learning (cache)

Différentes questions pour différents niveaux d’écoute (cache). Une façon d’orienter l’échange et donc la relation. Une façon aussi de raconter nos émotions en fonction de son interlocuteur·ice.

Une timeline peut-elle être bi-directionnelle ?

Il aura fallu quelques aiguilles d’acupuncture dans le dos pour percer un abcès psychologique latent. Ou alors c’est juste une question de coussin trop gros, auquel cas ça devient la série la plus stupide et ennuyeuse qui soit.

Et coûteuse, à tous les niveaux. #painline

ILNP DNS processing at the IETF 105 hackathon

The weekend of 20-21 July 2019, in Montréal, was the hackathon preceding the IETF 105 meeting. During this hackathon, I helped to improve the DNS support for the ILNP protocol, in the Knot DNS resolver.

ILNP is an identifier/locator separation network protocol. Each machine has at least one identifier such as 0:0:c:1, which is stable (never changes), and at least one locator such as 2001:8b0:d3:cc22, which may vary often, for instance when the machine moves from one network to another, or when the network is renumbered. The idea is to give stable identities to the machine, while keeping locators for efficient routing. If the locator looks like an IPv6 address, it is not a coincidence, it is because you can use ILNP locators everywhere you would use an IP address (more on that later). Each identifier/locator separation system requires a mapping service to get the locator from the identifier. With ILNP, this mapping service is the old and proven DNS. As the saying goes, "you can solve every problem in computer science just by adding one level of indirection".

ILNP is described in RFC 6740 and the DNS resource records on RFC 6742. These resource records are NID (find the identifier from the domain name) and L64 (find the locator from the domain name). I simplify, there are other records but here are the two I worked with. You can see them online yourself:


% dig NID ilnp-aa-test-c.bhatti.me.uk
...
;; ANSWER SECTION:
ilnp-aa-test-c.bhatti.me.uk. 10	IN NID 10 0:0:c:1
ilnp-aa-test-c.bhatti.me.uk. 10	IN NID 20 0:0:c:2
ilnp-aa-test-c.bhatti.me.uk. 10	IN NID 30 0:0:c:3
...


% dig L64 ilnp-aa-test-c.bhatti.me.uk
...
;; ANSWER SECTION:
ilnp-aa-test-c.bhatti.me.uk. 10	IN L64 10 2001:8b0:d3:cc11
ilnp-aa-test-c.bhatti.me.uk. 10	IN L64 20 2001:8b0:d3:cc22
...

    
ILNP could work just like that. RFC 6742, section 3.2, just recommends that the name servers do some additional processing, and return other possibly useful ILNP records when queried. For instance, if NID records are asked for, there is a good chance L64 records will be needed soon, so the server could as well find them and return them in the additional section of the DNS response (in the two examples above, there is only the answer section).

Current name servers don't do this additional processing. Anyway, this weekend, we went a bit further, implementing an option which is not in the RFC. Following an idea by Saleem Bhatti, the goal was to have the DNS resolver return ILNP records when queried for an AAAA record (IPv6 address). This would allow unsuspecting applications to use ILNP without being modified. The application would ask the IP address of another machine, and a modified name resolution library would get the ILNP records and, if they exist, return to the application the locator instead of the "normal" IP address (remember they have the same syntax).

Now, let's see how to do that in the Knot resolver. Knot has a system of modules that allow to define specific processing for some requests, without modifying the main code. (I already used that at the previous hackathon.) Modules can be written in Lua or C. I choosed C. We will therefore create a ilnp module in modules/ilnp. A module can be invoked at several "layers" during the processing of a DNS request. We will use the consume layer, where the request has been received but not all the answers are known yet:

static int ilnp_consume(kr_layer_t *ctx, knot_pkt_t *pkt) {
   ...
}

KR_EXPORT
int ilnp_init(struct kr_module *module) {
	static kr_layer_api_t layer = {
		.consume = &ilnp_consume,
};
    
The entire module is 83 lines, including test of return values, logging, comments and empty lines. Now, if the module is loaded, Knot will invoke consume() for every DNS request. We need to act only for AAAA requests:
struct kr_request *req = ctx->req;
if (req->current_query->stype == KNOT_RRTYPE_AAAA) {
...
}
/* Otherwise, do nothing special, let Knot continue. */
    
And what do we do when we see the AAAA requests? We ask Knot to add a sub-request to the current requests (two, actually, for NID and L64). And we need also to check if the request is a sub-request or not. So we add some flags in lib/rplan.h:
struct kr_qflags {
...
	bool ILNP_NID_SUB : 1;        /** NID sub-requests for ILNP (ilnp module) */ 
	bool ILNP_L64_SUB : 1;        /** L64 sub-requests for ILNP (ilnp module) */ 
    
And we modify the code to add the sub-requests (kr_rplan_push(), here I show only the NID one) and to test them (req->options.ILNP_..._SUB):

if (req->current_query->stype == KNOT_RRTYPE_AAAA && !req->options.ILNP_NID_SUB && !req->options.ILNP_L64_SUB)
 {
		next_nid = kr_rplan_push(&req->rplan, req->current_query,
			                     req->current_query->sname,  req->current_query->sclass,
			                     KNOT_RRTYPE_NID);
		next_nid->flags.ILNP_NID_SUB = true;
		next_nid->flags.DNSSEC_WANT = true;
                next_nid->flags.AWAIT_CUT = true;
 }

    
And, when the sub-request returns, we add its answers to the additional section (array_push(), again, I show only for NID):
      
 else if (req->current_query->stype == KNOT_RRTYPE_NID && req->current_query->flags.ILNP_NID_SUB) {		
		for (i=0; i<req->answ_selected.len; i++) {
			if (req->answ_selected.at[i]->rr->type == KNOT_RRTYPE_NID) {
				array_push(req->additional, req->answ_selected.at[i]->rr);
			}
		}
	}

    

To test that, we have to load the module (people not interested in ILNP will not run this code, which is good for them, because the extra queries take time):

modules = {'hints', 'view', 'nsid', 'ilnp'}
        
And Knot now gives us the ILNP records in the additional section:
	
% dig @MY-RESOLVER AAAA ilnp-aa-test-c.bhatti.me.uk
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53906
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 6
...
;; ANSWER SECTION:
ilnp-aa-test-c.bhatti.me.uk. 10	IN AAAA	2001:8b0:d3:1111::c

;; ADDITIONAL SECTION:
ilnp-aa-test-c.bhatti.me.uk. 10	IN L64 10 2001:8b0:d3:cc11
ilnp-aa-test-c.bhatti.me.uk. 10	IN L64 20 2001:8b0:d3:cc22
ilnp-aa-test-c.bhatti.me.uk. 10	IN NID 10 0:0:c:1
ilnp-aa-test-c.bhatti.me.uk. 10	IN NID 20 0:0:c:2
ilnp-aa-test-c.bhatti.me.uk. 10	IN NID 30 0:0:c:3

;; Query time: 180 msec
;; MSG SIZE  rcvd: 194

      

A possible option would have been to return the ILNP records only if they are already in the cache, improving performances. (Today, most machines have no ILNP records, so querying them takes time for nothing.) But, as far as I know, Knot does not provide an easy way to peek in the cache to see what's in it.

I also worked on the Unbound resolver. Unbound is not modular so modifications are more tricky, and I was unable to complete the work. Unbound, unlike Knot, allows you to see what is in the cache (added in daemon/worker.c):

rrset_reply = rrset_cache_lookup(worker->env.rrset_cache, qinfo.qname,
					   qinfo.qname_len,
					   LDNS_RR_TYPE_NID, LDNS_RR_CLASS_IN, 0, *worker->env.now, 0);
if (rrset_reply != NULL) {
	    /* We have a NID for sldns_wire2str_dname(qinfo.qname,
	    256)) */
	    lock_rw_unlock(&rrset_reply->entry.lock); /* Read the
	    documentation in the source: it clearly says it is locked
	    automatically and you have to unlock when done. *
}	
      
But NID and other ILNP records are not put into the cache. This is because Unbound does not follow the caching model described in RFC 1034. For performance reasons, it has two caches, one for entire DNS messages and one for resource records. The first one is used for "normal" DNS queries (for instance a TXT record), the second for information that may be needed to answer queries, such as the IP addresses of name servers. If you query an Unbound resolver for a TXT record, the answer will be only in the message cache, not in the resource record cache. This allows Unbound to reply much faster: no need to construct an answer, just copy the one in the cache. But it makes retrieval of data more difficult, hence the resource record cache. A possible solution would be to put ILNP records in the resource record cache (in iterator/iter_scrub.c):
#ifdef ILNP
		if (rrset->type == LDNS_RR_TYPE_NID || rrset->type == LDNS_RR_TYPE_L64 ||
		    rrset->type == LDNS_RR_TYPE_L32 || rrset->type == LDNS_RR_TYPE_LP) {
		  store_rrset(pkt, msg, env, rrset);
		}
#endif
But, as I said, I stopped working on Unbound, lack of time and lack of brain.

Many thanks to Ralph Dolmans and Petr Špaček for their help while I struggled with Unbound and Knot Resolver.

2019-07-21

RFC 8631: Link Relation Types for Web Services

Le Web, ce sont les pages auxquelles on accède depuis son navigateur, avec les textes à lire et les images à regarder. Mais ce sont aussi de nombreuses applications, avec une API, prévues pour être utilisées depuis un programme spécifique, pas depuis le navigateur Web. Ces Web services ont un ou plusieurs URL pour les appeler, et des ressources supplémentaires comme la documentation. Ce nouveau RFC décrit un type de liens hypertextes permettant de trouver l'URL de la documentation d'un service.

Normalement, on peut interagir avec un service Web sans connaitre les détails à l'avance. La négociation de contenu, par exemple (RFC 7231, sections 3.4 et 5.3) permet de choisir dynamiquement le type de données. En combinant les outils de l'architecture Web (URI, HTTP, etc), on peut créer des services plus simples que les anciennes méthodes compliquées, type CORBA. (Le terme de service REST est souvent utilisé pour ces services modernes et simples.) Mais cela ne dispense pas complètement de documentation et de description des services. (La documentation est du texte libre, conçue pour les humains, la description est sous un format structuré, et conçue pour les programmes.) Il faut donc, pour accéder à un service, trouver documentation et description. C'est ce que propose ce RFC, avec de nouveaux types de liens (les types de liens sont décrits dans le RFC 8288).

Notez bien que ce RFC ne dit pas comment doit être écrite la documentation, ou sous quel format structurer la description. Un format de description courant aujourd'hui est OpenAPI, fondé sur JSON. Mais il en existe d'autres comme RAML (fondé sur YAML) ou RSDL, si vous avez des expériences concrètes sur ces langages, ou des opinions sur leurs avantages et inconvénients, je suis intéressé. (Dans le passé, on utilisait parfois WSDL). Ce RFC fournit juste un moyen de trouver ces descriptions. (En prime, il permet également de trouver l'URL d'un service décrivant l'état actuel d'un service, permettant d'informer, par exemple, sur des pannes ou sur des opérations de maintenance.)

Parfois, documentation et description sont fusionnées en un seul ensemble de ressources. Dans ce cas, on n'est pas obligé d'utiliser notre RFC, on peut se contenter du type de lien décrit dans le RFC 5023.

Les quatre nouveaux types de liens (section 4 du RFC) sont :

  • service-doc pour indiquer où se trouve la documentation (écrite pour des humains),
  • service-desc pour donner accès à la description (conçue pour des programmes),
  • service-meta pour l'URI des méta-informations diverses sur le service, comme des informations à caractère juridique (politique « vie privée » du service, par exemple),
  • status pour l'état actuel du service.
Ces types sont notés dans le registre IANA des types de liens (section 6 du RFC).

Un exemple dans un document HTML serait, pour indiquer la documentation :


<link rel="service-doc" type="text/html" title="My documentation"
      href="https://api.example.org/documentation.html"/>      

    
Et dans les en-têtes HTTP, ici pour indiquer la description :
Link: <https://api.example.org/v1/description.json> rel="service-desc";
    type="application/json" 
Si vous voulez voir un exemple réel, il y en a un dans le DNS Looking Glass. Les en-têtes HTTP, et le code HTML contiennent un lien vers la documentation.

La section 5 est consacrée à status, qui permet d'indiquer une ressource sur le Web donnant des informations sur l'état du service. On peut voir par exemple la page de Github ou bien celle de CloudFlare. (Évidemment, il est recommandé qu'elle soit hébergée sur une infrastructure différente de celle du service dont elle indique l'état de santé, pour éviter que le même problème DNS, BGP ou autre ne plante le service et son bulletin de santé en même temps. C'est ce que ne fait pas la page de Framasoft, qui utilise le même nom de domaine.) Aucune obligation sur le contenu auquel mène le lien, cela peut être un texte conçu pour un humain ou pour un programme.

Quelques considérations de sécurité pour finir (section 7 du RFC). D'abord, toute documentation peut être utilisée par les gentils utilisateurs, mais aussi par les méchants attaquants. Il peut donc être prudent de ne donner dans la documentation que ce qui est nécessaire à l'utilisation du service. D'autre part, la description (ce qui est en langage formel, analysable par un programme) peut permettre davantage d'automatisation. C'est bien son but, mais cela peut aider les attaquants à automatiser les attaques. Sans même parler d'attaque délibérée, le RFC note aussi que cette automatisation, utilisée par un programme client mal écrit, peut mener à une charge importante du service si, par exemple, le client se met à utiliser sans limitation toutes les options qu'il découvre.

Enfin, tout programmeur et toute programmeuse sait bien que les documentations ne sont pas toujours correctes. (Ou, plus charitablement, qu'elles ne sont pas toujours à jour.) Le programme client ne doit donc pas faire une confiance aveugle à la documentation ou à la description et doit se préparer à des comportements imprévus de la part du service.

À part le DNS Looking Glass, je n'ai pas encore trouvé de service Web qui utilise ces types de liens. Si vous en voyez un, vous me prévenez ?

2019-07-20

La vente d'une partie du réseau 44

Hier, une partie du préfixe IPv4 44.0.0.0/8 a été vendue à Amazon. Comment ? Pourquoi ? Et c'est quoi cette histoire de ventes d'adresses IP ? Nous allons plonger dans le monde de la gouvernance de l'Internet pour en savoir plus.

D'abord, les faits. Le préfixe vendu est le 44.192.0.0/10 et on peut vérifier, par exemple avec whois, qu'il « appartient » (les juristes hésitent pour savoir s'il s'agit réellement de propriété) à Amazon :

% whois 44.192.0.0
...
NetRange:       44.192.0.0 - 44.255.255.255
CIDR:           44.192.0.0/10
...
Parent:         NET44 (NET-44-0-0-0-0)
Organization:   Amazon.com, Inc. (AMAZO-4)
RegDate:        2019-07-18
Updated:        2019-07-18
    
Comme l'indique la date de mise à jour, cela a été fait hier. Le reste du préfixe 44.0.0.0/8 « appartient » à ARDC (Amateur Radio Digital Communications), une organisation créée pour représenter les intérêts des radioamateurs. En effet, ce préfixe 44.0.0.0/8, comportant 16 777 216 adresses IPv4 avait historiquement été alloué au réseau de radioamateurs, AMPR. (Le site Web officiel de l'ARDC est dans le domaine ampr.org.)
% whois 44.0.0.0
NetRange:       44.0.0.0 - 44.191.255.255
CIDR:           44.128.0.0/10, 44.0.0.0/9
NetName:        AMPRNET
Parent:         NET44 (NET-44-0-0-0-0)
Organization:   Amateur Radio Digital Communications (ARDC)
RegDate:        1992-07-01
Updated:        2019-07-18
    

Pour les amateurs de BGP, notez que le préfixe entier était annoncé par l'UCSD il y a un peu plus d'un mois. Depuis le 4 juin 2019, ce n'est plus le cas, comme le montre RIPE stat, Amazon annoncera sans doute « son » préfixe dans le futur (pour l'instant, ce n'est pas fait).

Les addresses IPv4 sont de plus en plus rares et, logiquement, valent de plus en plus cher. Amazon, avec son épais portefeuille, peut donc en acheter, seule la loi du marché compte. On peut acheter et vendre des adresses IP, comme des bananes ou des barils de pétrole, elles ne sont pas considérées comme des biens communs, et ne sont pas soustraites au marché. Pour diminuer cette pression liée à la pénurie, la bonne solution est évidemment de déployer IPv6 mais beaucoup d'acteurs trainent la patte, voire nient le problème.

Le préfixe 44.0.0.0/8 dépend du RIR ARIN et ARIN estime que la transaction a suivi ses règles : le titulaire du préfixe était d'accord, et le nouveau titulaire était éligible (il pouvait démontrer un besoin d'adresses, ce qui est assez évident pour AWS). Mais quelles questions cela pose-t-il ?

D'abord, je précise que je ne suis pas radioamateur moi-même et que je ne peux donc pas donner une opinion intelligente sur les relations (apparemment pas toujours idylliques) au sein d'ARDC et entre ARDC et les radioamateurs en général.

Car l'une des premières questions posées concernait justement la légitimité d'ARDC. À l'époque où le 44.0.0.0/8 a été alloué, en 1986, assez loin dans le passé de l'Internet (la date de 1992 que donne ARIN est la date de l'entrée dans une nouvelle base de données, pas la date originelle), ARDC n'existait pas. À l'époque, les allocations de préfixes se faisaient de manière non bureaucratique, assez souplement, et sur la base de relations de confiance mutuelle. ARDC a été créé par la suite, en 2011, justement pour gérer les ressources communes, et certains se demandent si cette responsabilité d'ARDC va jusqu'à lui permettre de vendre une partie des ressources communes, même si cet argent (« plusieurs millions de dollars », ce qui est bon marché au cours actuel des adresses IPv4, mais, comme beaucoup de choses dans cette affaire, le montant exact n'est pas public) reviendra au bout du compte à la communauté des radioamateurs. Ce problème de vente d'un bien commun est d'autant plus crucial que l'ARDC est une organisation purement états-unienne, alors qu'il y a des radioamateurs dans le monde entier (et qu'ils ont une fédération internationale qui les représente.)

Il y a aussi des débats, internes à ce monde des radioamateurs, quand au mécanisme de prise de décision, et à l'information envoyée par les décideurs (apparemment inexistante, avant la vente). Mais, comme je l'ai dit, je ne suis pas radioamateur donc je ne peux pas juger.

On peut aussi se poser la question de l'applicabilité des règles d'ARIN. Au moment de la délégation du préfixe 44.0.0.0/8, ARIN n'existait même pas (il n'a été créé qu'en 1997). Comme les autres préfixes du « marais », 44.0.0.0/8 a été récupéré par un RIR, qui a ensuite imposé ses règles. ARIN n'a pas voulu dire si ARDC avait ou non signé un accord - nommé RSA (Registration Services Agreement) ou LRSA (Legacy Registration Services Agreement) selon le cas - pour cette soumission aux règles ARIN.

Notez que cette acceptation des règles de l'ARIN est obligatoire si on veut mettre ses préfixes dans la RPKI. (L'argument d'ARIN étant que la RPKI, elle, a été créé après ARIN.) Ce n'est pas forcément très important en pratique, les réglementations internationales font que le réseau des radioamateurs n'est pas un réseau critique, de toute façon. (Par exemple, le chiffrement est interdit.)

Certains ont défendu la vente en disant que le préfixe vendu n'était pas utilisé (et ne le serait probablement jamais, l'activité de radioamateur ne grossissant pas tant que ça) mais le site Web de l'ARDC montre que 44.224.0.0/15, qui fait partie du préfixe vendu, était bien prévu pour être utilisé (en pratique, l'Allemagne semble ne pas s'en être servi beaucoup).

Toute cette histoire illustre bien le fait que la gestion des adresses IP est tout aussi politique (et business) que celle des noms de domaine, pour lesquels tant (trop) de gens s'excitent. La gouvernance de l'Internet ne se limite pas à la création (ou non) du .gay, du .vin ou du .amazon !

Quelques autres lectures :

  • Si vous voulez le point de vue de la direction d'ARDC sur cette vente, il figure sur leur site Web.
  • Cette vente avait été prévue dans un poisson d'avril il y a quelques années.

2019-07-16

☕︎ Écoute

Citation de la quinzaine : « On me demande souvent à quoi je pense quand je marche. Et bien, je ne pense pas, je vis ! Il y a des moments pour la réflexion et d’autres pour le mouvement. », Sarah Marquis.

When a company first forms, there are no norms or principles guiding how its people should make decisions. It’s basically just what’s in the founders’ heads. With each decision a company makes, its “decision genome” is established and subsequently hardened. You’ve decided in your first month that you’re only going to hire engineers from Top 10 engineering schools? That’s now part of your genome and will determine the composition of your company. You’ve decided to forgo extra profits by keeping your prices low for consumers? That’s now part of your genome. You’ve decided to employ a single dark pattern to trick users into adding more things to their shopping cart? Part of your genome.

Superhuman is Spying on You (cache)

Et sa suite (cache). Tellement emblématique d’une époque. C’est la raison pour laquelle je suis à la recherche aujourd’hui de solutions sans algorithmes (cache), sans être écouté en permanence (cache) sur un fond de « bonne » morale (cache) ou pour m’éduquer (cache). Tout en conservant un journal des échanges potentiels afin de mieux pouvoir… acheter, bien sûr (cache).

Ne pas voir de la malice là où il n’y aurait que du capitalisme. Sur écoutes.

The obvious downside of URL Pages is that the links get very long very quickly. Luckily, some URL shorteners are able to accommodate fairly long URLs (shoutout to TinyUrl). In a strange way, this effectively means the link shortener is acting as the web host since it is responsible for storing the record of the web page’s data.

URL Pages

J’aime bien l’expérimentation, ne pas essayer ceci à la maison (enfin dans la maison des autres en fait). Je suis sûr qu’il y aurait quelque chose à faire pour le versionnement de pages stockées en cache par un ServiceWorker. Lié mais pas trop, j’aime bien voir les essais qui sont réalisés pour standardiser la génération d’un site statique à partir d’une arborescence. Toujours la tentation de publier un truc. En relisant la transcription de cette intervention sur le choix des technologies, je me demande souvent si je ne devrais pas abandonner CommonMark au profit de HTML pour la rédaction et la pérennité.

Corollaire : Karl a toujours raison.

Mais publier sans prendre le temps d’être à l’écoute des utilisateur·ice·s, à quoi bon ?

Au-delà de ça, j’ai pris conscience que mes réseaux sociaux (et dans une certaine mesure la newsletter) proposaient des updates de la vie douce par facilité.
Parce que la difficulté et la tristesse nécessitent plus de recul, parce qu’il faut attendre qu’un peu de clarté se dégage. Et sans doute aussi par pudeur : ce sont des parts qui touchent de près une intimité qui n’a pas forcément vocation à être dévoilée.
Équilibre difficile à atteindre.

Comment l’itinérance a mis notre relation à l’épreuve (cache)

Le web comme espace de partage de bonheurs et d’aigreurs mais beaucoup moins de peurs, d’angoisses, de coups durs, de tristesses. Ou alors a posteriori lorsqu’on est revenu à un état suffisamment correct. Si un jour j’arrête de publier, ce sera peut-être alors le moment de m’aider. Être à l’écoute du silence des autres dans un tel brouhaha. Comment être tenu informé lorsqu’un flux se tarit, anticiper ? (cache)

Aussi, merci beaucoup pour la recette en fin d’article <3.

La technique déforme et exacerbe les problèmes qu’elle est supposée résoudre. Elle nous fait croire qu’elle fournit des solutions neutres et optimales aux problèmes sociaux. Elle nous fait croire qu’elle est le mécanisme même du changement social, alors qu’elle ne fait qu’obscurcir les dynamiques sociales et politiques qui sont à l’oeuvre. La technologie nous fait croire que la vie urbaine n’est qu’un problème technique et nous invite à diagnostiquer sélectivement les problèmes qu’elle pourrait résoudre.

Vers des villes politiquement intelligentes (cache)

Avant les villes politiquement intelligentes, il serait intéressant de laisser les citoyen·ne·s jouer avec la ville. Définir des règles qui leurs conviennent collectivement afin que toutes les voix puissent être entendues. Que la représentation de la ville par une caste ne soit pas la seule imaginable.

Ni enviable.

Pour ma part, j’ai saisi très tôt que je devais impérativement comprendre mon corps et en prendre soin. Garder la santé revient souvent à respecter le rythme de notre corps et à constamment se repositionner en retrouvant son équilibre. Il y a une manière de garder la santé et rester bien loin des médecins. Il s’agit d’un geste que nous arrivons tous à faire et devinez, il est gratuit en plus : il faut dormir, dormir aussi longtemps que le corps vous l’indique.

Sauvage par Nature, Sarah Marquis

Je dois avouer que le fait de ne pas réussir à dormir trop longtemps permet — sans trop de difficultés — d’adopter un rythme circadien… ce qui ouvre d’autres perspectives. Il faudrait que je trouve un moyen de consigner mes réflexions matinales. Si possible numériquement, mais sans être en capacité d’être à l’écoute du bruit numérique.

J’ai l’impression qu’extérioriser sans partager n’aurait pas les mêmes vertus. Écrire sans une certaine écoute fantasmée semble si vain à un égo con(valescent).

J’ai parfois le sentiment que mon mal de dos est dû à une tête trop lourde. Tout un symbole.

RFC 8569: Content Centric Networking (CCNx) Semantics

Certaines personnes trouvent une utilité au réseau centré sur le contenu, où adressage et nommage ne désignent que du contenu, des ressources numériques auxquelles on accède via le réseau. (Cette idée est souvent nommée ICN, pour Information-Centric Networking ou NDN pour Named Data Networking.) Le groupe de recherche ICNRG développe des spécifications pour normaliser certains aspects de ce réseau centré sur le contenu, un projet nommmé CCNx (pour Content Centric Networking). Ce nouveau RFC décrit les concepts de base de CCNx. CCNx est le premier protocole conçu par le groupe ICNRG.

Précisons tout de suite : ce point de vue comme quoi le socle du réseau devrait être l'accès au contenu est très contestable. Il évoque fortement le raccourci de certains journalistes, décideurs, et opérateurs de télécommunication traditionnels comme quoi le seul usage de l'Internet fait par M. Michu serait « accéder à du contenu ». Mais j'ai déjà développé ces critiques dans un autre article il y a huit ans, donc je ne les reprendrai pas ici.

Les acteurs du réseau centré sur le contenu sont notamment :

  • Le producteur (producer ou publisher) qui crée du contenu. Il peut avoir une clé qui lui permet de signer ce contenu.
  • Le consommateur (consumer) qui veut accéder à du contenu.
(Vous noterez qu'il n'y a pas de pair à pair dans ce réseau, ce qui limite certains usages.)

Le protocole CCnx repose sur deux types de messages : Interest, par lequel on signale qu'on aimerait bien récupérer tel contenu, et Content Object, qui transporte un contenu. En général, la machine de l'utilisateur, du consommateur demandeur, enverra un Interest et, si tout va bien, récupérera en échange un ou plusieurs Content Object. Si tout va mal, on aura à la place un InterestReturn, qui signale un problème. Comment sont désignés les contenus ? Par des noms hiérarchiquement organisés, comme dans les URL d'aujourd'hui (section 3 du RFC). Un nom est donc composé d'une série de segments, et la correspondance entre un nom demandé et une entrée de la table de routage est toujours faite de manière exacte, bit à bit. (Pas d'insensibilité à la casse, pas de recherche floue.) Le nom est opaque. Il n'est donc pas forcément lisible par un humain. Comme les noms sont hiérarchiques, un nom peut être exact (le nom entier) ou être un préfixe (correspondant à plusieurs noms). On dit aussi qu'un nom est complet quand il inclut un condensat du contenu (comme dans les magnets de BitTorrent). Le condensat est expliqué plus en détail dans les sections 5 et 7 du RFC. La syntaxe est décrite dans l'Internet Draft draft-mosko-icnrg-ccnxurischeme, qui met les noms CCNx sous forme d'URI. Par exemple, un nom possible est ccnx:/NAME=foo/APP:0=bar. Il n'y a pas de registre de tels noms pour l'instant. Si on veut trouver des noms, le protocole lui-même ne le permet pas, il faudra bâtir des solutions (par exemple un moteur de recherche) au-dessus de CCNx.

CCNx fonctionne en relayant les messages (aussi bien Interest que Content Object) d'une machine à l'autre. Du fait de ce modèle de relayage systématique, il faut ajouter un troisième acteur au producteur et au consommateur, le relayeur (forwarder), qui est toute machine intermédiaire, un peu comme un routeur sauf que le relayeur fait bien plus de choses qu'un routeur. Par exemple, contrairement au routeur IP, le relayeur a un état. Chaque demande d'objet qui passe est mémorisée par le relayeur (dans une structure de données nommée la PIT, pour Pending Interest Table), qui saura donc où renvoyer la réponse. CCNx est sourceless, contrairement à IP : l'adresse source n'est pas indiquée dans la demande.

La FIB (Forwarding Information Base) est la table de routage de CCNx. Si elle contient une entrée pour le contenu convoité, cette entrée indique où envoyer la requête. Sinon, la requête ne peut aboutir. Notez que ce RFC ne décrit pas le protocole par lequel cette FIB sera construite. Il n'existe pas encore d'OSPF ou de BGP pour CCNx.

Comme le contenu peut être récupéré après un passage par pas mal d'intermédiaires, il est crucial de vérifier son intégrité. CCNx permet plusieurs méthodes, de la signature au HMAC. Ainsi, l'intégrité dans CCNx est une protection des objets (du contenu), pas uniquement du canal comme c'est le cas avec HTTPS. CCNX permet également de signer des listes d'objets (des manifestes), la liste contenant un SHA ou un CRC des objets, ce qui permet d'assurer l'intégrité de ceux-ci.

Ces concepts avaient été décrits dans les RFC 7476 et RFC 7927. Le vocabulaire est expliqué dans l'Internet Draft draft-irtf-icnrg-terminology. Maintenant, voyons les détails, sachant que le format précis des messages a été délégué à un autre RFC, le RFC 8609. La section 2 du RFC décrit précisement le protocole.

On a vu que le consommateur commençait l'échange, en envoyant un message de type Interest. Ce message contient le nom de l'objet qui intéresse le consommateur, et éventuellement des restrictions sur le contenu, par exemple qu'on ne veut que des objets signés, et avec tel algorithme, ou bien ayant tel condensat cryptographique de l'objet (le tuple regroupant nom et restrictions se nomme le lien, cf. section 6). Un nombre maximal de sauts restants est indiqué dans le message. Décrémenté par chaque relayeur, il sert à empêcher les boucles (lorsqu'il atteint zéro, le message est jeté). Le producteur, lui, stocke le contenu, indexé par les noms, et signale ces noms sur le réseau pour que les relayeurs peuplent leur FIB (on a vu que le protocole permettant ce signalement n'était pas encore défini, bien que plusieurs propositions existent). Enfin, le relayeur, le troisième type d'acteur, fait suivre les Interest dans un sens (en consultant sa FIB) et les Content Object en sens inverse (en consultant sa PIT).

Le relayeur a également une mémoire (un cache), qui sert notamment à accélérer l'accès au contenu le plus populaire (section 4 du RFC). Il existe des moyens de contrôler l'utilisation de cette mémoire, par exemple deux champs dans un Content Object, la date d'expiration, après laquelle il ne faut plus garder l'objet dans le cache, et la date de fin d'intérêt, après laquelle il n'est sans doute plus utile de garder l'objet (mais on peut quand même si on veut).

La validation des objets, leur vérification, est un composant crucial de CCNx. Elle est spécifiée dans la section 8 du RFC, avec ses trois catégories, la validation utilisant un simple condensat (pas forcément cryptographique), un HMAC ou bien une signature.

On a vu que le troisième type de message de CCNx, après Interest et Content Object, était Interest Return. Il est décrit en détail dans la section 10 de notre RFC. Notez tout de suite qu'il peut ne pas y avoir de réponse du tout, un relayeur n'étant pas forcé d'envoyer un Interest Return s'il ne peut acheminer un Interest. S'il y a un Interest Return, il indique l'erreur, par exemple No Route (aucune entrée dans la FIB pour ce nom), No Resources (le relayeur manque de quelque chose, par exemple de place disque pour son cache), Malformed Interest (un problème dans la demande), Prohibited (le relayeur n'a pas envie de relayer), etc.

Enfin, sur la question cruciale de la sécurité, la section 12 du RFC revient sur quelques points sensibles. Par exemple, j'ai dit plus haut que les objets pouvaient être validés par une signature numérique. Mais où trouve-t-on les clés publiques des producteurs, pour vérifier leur signature ? Eh bien ce point n'est pas actuellement traité. Notez que les relayeurs, eux, ne sont pas obligés de valider et un cache peut donc contenir des données invalides. Les RFC 7927 et RFC 7945 sont des bonnes ressources à lire sur la sécurité des réseaux centrés sur le contenu.

Il existait une version précédente du protocole CCNx, identifiée « 0.x », et décrite dans « Networking Named Content ». Dans 0.x, la correspondance entre le nom demandé dans un Interest et celui obtenu était hiérarchique : le nom demandé pouvait être un préfixe du nom obtenu. La version décrite dans ce RFC, « 1.0 », est plus restrictive ; le nom obtenu doit être exactement le nom demandé. Les fonctions de recherche ne sont pas dans CCNx, elles doivent être dans un protocole de couche supérieure, un Google ou Pirate Bay du réseau CCN. Un exemple d'un tel protocole est décrit dans l'Internet Draft draft-mosko-icnrg-selectors.

Et questions mise en œuvre du protocole CCNx ? Il en existe au moins deux, Community ICN, et CCN-Lite (cette dernière, tournant sur RIOT, visant plutôt l'Internet des objets).

2019-07-07

Repenser la place du numérique dans les SHS

2019-07-07 Gautier Poupeau - Les petites cases - Causeries, Digital humanities, SHS

Une discussion s'est engagée sur la liste DH-FR suite à un message d'un étudiant de Master 2 qui s'interrogeait sur sa capacité à répondre à des offres d'emploi dans le domaine du numérique en SHS. La question en elle-même aussi innocente qu'elle soit est le révélateur d'un malaise profond des rapports entre le numérique et les SHS qui m'ont amené à réagir une première fois sur twitter de manière virulente après avoir répondu à l'étudiant. Mais cette impression ne fait qu'augmenter au fur et à mesure que les messages et les discussions se succèdent. Ces échanges me renforcent aujourd'hui dans ma conviction qu'il est absolument urgent que les SHS réfléchissent à la place du numérique dans leur enseignement et leur recherche, qu'elles y intègrent le rôle de l'ingénieur et qu'elles dépassent le concept d'Humanités numériques. Je vous propose ici une première contribution à cette réflexion vue de ma position d'ancien ingénieur d'études dans les SHS ayant œuvré à la reconnaissance des Digital Humanities, observateur attentif et participant occasionnel à ce mouvement, enseignant formant des ingénieurs issus des SHS.

<!--break-->

Du problème de la définition du rôle de l'ingénieur et du chercheur

Un jour, peut-être, arrêterons-nous d'opposer le travail du chercheur et celui de l'ingénieur dans les SHS ? Peut-être qu'un jour l'un et l'autre groupe reconnaîtront le rôle de chacun ? Alors peut-être arriverons-nous à apaiser les tensions entre ces deux groupes ?

De manière un peu caricaturale, le rôle de l'ingénieur est d'analyser un problème et de trouver une solution, le rôle du chercheur est de poser des questions, une problématique et tout en essayant d'y répondre d'ouvrir la voie à d'autres questions. Pour faire cela, le chercheur peut mobiliser seul des techniques ou technologies ou avoir recours à un ingénieur pour résoudre un problème particulier qui l'aidera à répondre à ses questions. Cela n'est pas nouveau. Viendrait-il à l'esprit d'un chercheur d'imposer l'organisation d'une bibliothèque pour pouvoir y consulter des ouvrages ? de remettre en question les méthodes de conservation mises en oeuvre par des archivistes pour pouvoir analyser un document d'archives ? Non, il ne me semble pas et, pourtant, les compétences d'ingénierie documentaire mises en oeuvre par les bibliothécaires ou par les archivistes et leurs manières de travailler sont bien celles d'un ingénieur.

Cette confusion ingénieur/chercheur est aussi visible dans le recours à des équipes de recherche en informatique pour mener à bien des projets impliquant le numérique en SHS. Les résultats ne sont bien souvent pas à la hauteur des attentes des chercheurs en SHS. En effet, en ayant recours (souvent encouragé par les tutelles au nom de l'interdisciplinarité et de mutualisation des moyens) à des équipes de recherche en informatique, les chercheurs en SHS pensent disposer de forces d'ingénierie technique, mais le rôle du chercheur en informatique est le même que celui en SHS : poser des questions et y répondre et en aucun cas trouver une solution à un problème. Les chercheurs en informatique y voient eux l'opportunité de confronter les réponses qu'ils ont pu trouver dans d'autres contextes ou poser de nouvelles questions. La rencontre entre les équipes se fera dans l'émergence des problématiques mais en aucun cas dans la construction d'une solution technique aboutie et opérationnelle.

Le numérique en général et l'informatique en particulier sont des cas particuliers tant ils ont pénétré toutes les strates de notre quotidien et laissé croire à une facilité apparente ou du moins une accessibilité simplifiée aux solutions. Mais, au-delà de la technique elle-même, le travail de l'ingénieur est aussi de formaliser le problème, de le modéliser, de l'analyser afin de préciser le besoin et de trouver la solution la plus adéquate. Un ingénieur n'est pas un spécialiste du métier qu'il doit aider. En l'occurrence, il n'est pas de son ressort de produire l'analyse d'une source, mais il doit donner les moyens aux chercheurs de mener cette analyse et/ou d'en valoriser les résultats. Il est un spécialiste de la résolution de problèmes en mobilisant à la fois sa capacité à écouter le métier, son savoir-faire d'analyse et de compréhension du problème et ses compétences techniques (ici dans le numérique) pour déployer la solution au problème.

Mais, pour parvenir à cela, il doit exister un lien de confiance entre l'ingénieur et le métier (ici la recherche en SHS) auquel il doit apporter une solution. Or, c'est bien cela le problème et les échanges sur la liste le montrent bien : ce lien de confiance n'existe pas. D'après mon expérience, le milieu de la recherche publique en SHS est l'endroit où la suspicion à l'égard de l'ingénieur est la plus élevée. D'ailleurs, cela va de pair avec une vision diabolisée du secteur privé. J'ai l'impression que ce manque de confiance provient d'une méconnaissance, d'une impression de concurrence entre les deux (cf. la question de la co-signature très symptomatique de ce point de vue) et de rôles qui ne sont pas clairement établis. Cela s'explique certainement par le fait que la recherche et l'enseignement ont constitué les débouchés majoritaires voire exclusifs des SHS jusqu'à présent. Elles sont donc peu en contact avec d'autres types d'organisations dans lesquels l'ingénieur tient une place prépondérante (d'ailleurs, il en va de même pour le manager... mais c'est un autre débat).

Or, le numérique en général et la place de la donnée et de son traitement en particulier sont en train de faire évoluer ces débouchés naturels. De plus en plus de sociétés prennent conscience de l'intêret de recruter des profils issus des SHS pour leur capacité d'analyse des données et de compréhension des processus qui y sont liés. Les SHS doivent s'emparer de cette tendance qui leur permettra non seulement de répondre à la demande du marché et d'offrir à leurs étudiants de nouveaux débouchés, mais aussi de mieux intégrer les rôles de l'ingénieur et du chercheur dans la recherche elle-même.

Or, comment former à un métier dont on ne comprend pas les ressorts ? Il est donc urgent que les SHS comprennent le rôle de l'ingénieur dans et en dehors de la recherche. Cette compréhension passe peut-être par l'invention de ce que peut être un ingénieur en SHS ? Un ingénieur disposant de compétences dans le domaine du numérique issu des SHS ? Un positionnement original pour une vision originale du métier de l'ingenieur ?

Mais, cela ne va-t-il pas de pair avec le fait d'arrêter de faire des "Humanités numériques" le porte-étendard du numérique en SHS ?

La fin des humanités numériques ou la nécessaire digitalisation des SHS

Le terme Digital Humanities est apparu dans la 1ère moitié des années 2000 dans les pays anglo-saxons. Il est issu d'un mouvement qui visait à :

  • rassembler sous un seul étendard toutes les initiatives existantes, éparses et en perte de vitesse autour de l'utilisation de l'informatique par les différentes disciplines des SHS issues de la première révolution de l'informatique des années 70 et 80 ;
  • refléter les changements en cours avec l'explosion du Web ;
  • constituer un groupe de pression à même de peser au niveau institutionnel et au niveau de la recherche pour la prise en compte de la question "numérique" dans les SHS.

Il a été traduit en français par "Humanités numériques" suite au 1er That Camp en 2010 et à la publication du manifeste des Digital Humanities. Pour faire simple, il désignait alors la volonté d'intégrer naturellement le numérique, en tant qu'il est un ensemble de technologies, au sein de la recherche en SHS. C'était donc une vision d'ingénieur qui était mise en avant. Deux problèmes ont émergé. D'une part, pour les raisons évoquées précédemment, il est alors apparu que la seule manière de rendre ce mouvement légitime aux yeux des SHS était d'en faire une discipline (une transdiscipline pour reprendre les termes du manifeste), c'est-à-dire de lui associer une recherche, une épistémologie, une organisation institutionnelle. D'autre part, une double confusion terminologique est venue s'ajouter. En effet, là où les anglo-saxons ont forgé le terme digital studies pour désigner les études sur le numérique, le terme "Humanités numériques" a aussi été utilisé dans ce contexte et, enfin, pour aujouter de la confusion à la confusion, "Humanités numériques" désigne aussi dans certains établissements l'enseignement de l'impact du numérique sur les organisations.

En réalité, pourquoi serait-il nécessaire de faire des "humanités numériques" une discipline ? Ne s'agit-il pas plutôt de compétences et de techniques utiles pour mener une recherche dans les différentes disciplines des SHS ? La disciplinarisation de l'utilisation du numérique en SHS a impliqué son intellectualisation et par là même la minimisation des aspects les plus techniques de cette question, une absence de réflexion sur ce qu'implique le numérique dans toutes les strates de la recherche en SHS (forcément c'est réservé aux Humanités numériques...) sans compter les guerres de territoires qui apparaissent immanquablement avec des postures épistémologiques ou institutionnelles. Finalement, à force de porter comme un étendard les "Humanités numériques", les SHS confinent cette problématique et risquent de louper le tournant du numérique et par là même de perdre pied avec la société. Le numérique ne constitue pas un problème à part.

Les physiciens et les biologistes utilisent de manière massive l'informatique mais il n'existe pas pour autant une discpline spécifique pour cela. Ces compétences sont intégrées à leur cursus de formation et mises en oeuvre par les chercheurs ou par des ingénieurs qui les accompagnent. Aujourd'hui, dans les organisations publiques ou privées, la question du numérique n'est plus seulement l'apanage des directions informatiques et encore moins d'une nouvelle direction spécifique mais bien de l'ensemble de l'organisation. Il faut en faire de même dans les SHS : dépasser les "humanités numériques" qui enferment la discussion à un espace, réinterroger la place du numérique en SHS et ne pas le concevoir comme une chose à part mais bien l'intégrer au sein même de l'ensemble de ses strates. Il sera alors possible :

  • de réinterroger les débouchés naturels des SHS et de former les ingénieurs issus des SHS dont les entreprises ont tant besoin pour faire face à la révolution numérique et à l'explosion des données ;
  • de faire émerger des nouvelles questions induites par la place du numérique dans notre société ;
  • de faire émerger de nouvelles questions par l'utilisation des technologies numériques ;
  • de repositionner ingénieur et chercheur à leur juste place dans la recherche ;
  • d'améliorer la visibilité des travaux des chercheurs à l'intérieur et à l'extérieur de la recherche
  • d'intégrer au recrutement des enseignants-chercheurs des compétences techniques dans le domaine du numérique sans avoir besoin de parler de double cursus.

Bref, pour paraphraser Paul Bertrand, peut-être serait-il temps d'appeler à la fin nécessaire et heureuse des humanités numériques ? Ce terme n'était finalement peut-être que le signe d'une étape dans l'appropriation du numérique par les SHS. Il est temps de passer à une nouvelle étape, celle où le numérique est une composante naturelle et intégrée des SHS et de l'ensemble de ses disciplines.

2019-07-02

☕︎ Anxiété

Citation de la semaine : “Not only is my glass half empty, it’s not what I ordered.” — Catherine Tate (Traduction libre : « non seulement mon verre est à moitié vide mais ce n’est même pas ce que j’avais commandé. »)

Cela fait plus d’un an que je ressens cette solastalgia. Bon en vrai ça doit faire plus de trente ans et le fait d’être en couple puis de devenir parent n’arrange pas les choses dans ce qui est aussi appelé éco-anxiété.

En arrière-plan, toujours : l’effondrement, la catastrophe, le jugement. Le mur qui s’approche. Godzilla, qu’on voit arriver à l’horizon, extrêmement lentement, et du coup on est tous posés sur la plage avec des jumelles pour le regarder avancer, et les plus entreprenants vendent des glaces aux badauds, et les plus finauds font des projections et magouillent dans l’espoir de tirer leur épingle du jeu au bout du compte, d’autres font du jetski ou je ne sais quelle absurdité pour profiter de l’instant, chacun s’arrange comme il peut avec ce qui vient, mais en tout cas je pense qu’on a tous admis la réalité de ce qui nous attend, même si on ne peut pas encore en prendre pleinement conscience – tant mieux, sans doute.

Le silence (cache)

Peut-être qu’il faut faire péter le bunker de filtre qui m’entoure ou tout simplement ne plus y aller.

Peut-être qu’il faut créer son propre bonheur. Réussir à oublier le reste.

Peut-être qu’il faut se taire et regarder des bâtiments s’effondrer avec la bonne musique.

Peut-être qu’il faut arrêter les vidéos en streaming.

Parce qu’il est de bon ton désormais de dégainer sa paille métallique, son tote bag à légumes, sa brosse à dent en bambou et son bout de charbon dans sa gourde (disclaimer : j’en possède également). J’achète trois fois plus cher des œufs de poules élevées en plein air qui ont à peine moins souffert que les autres, je constate que les magasins bio du coin vendent des fruits exotiques importés du Pérou, et j’ai l’impression que la responsabilisation écologique à l’échelle individuelle n’est qu’une vaste blague. J’aime clamer que les quelques comportements écoresponsables que j’entretiens sont avant tout pour laver ma conscience, tout en sachant qu’au fond je me réfugie dans le défaitisme qui m’ôte toute notion de culpabilisation. Alors je jette des objets encore fonctionnels et j’en consomme d’autres parce que ça me rassure, parce que ça me remplit, et j’essaie fort de me dire que je ne suis pas une si mauvaise personne.

Remplir le vide (cache)

Mais s’exclure c’est perdre le fil. Se perdre. Perdre contact avec une réalité. Celle des riches toujours plus riches (cache). Des un peu moins riches toujours plus excluant (cache). De l’armée qui va devoir se reconvertir en pompiers (cache).

To come back to the theme of this thread, I think we should not let the overarching question be “When would the climate catastrophe happen?”, but “Until when can we guarantee that we would avoid major risks to people & the environment?” (20/n)

Thread Twitter

De plus en plus convaincu qu’il y aura juste de plus en plus d’esclaves pour servir de moins en moins de riches. J’aime cette métaphore de la chute qui fait de plus en plus mal en fonction de la hauteur (en nombre de degrés). Il suffit d’avoir suffisamment de personnes empilées/mourantes au moment de sa propre chute pour ne pas y laisser sa peau. En attendant un cygne noir combiné à de la bêtise humaine.

Remember:

  1. The Ocean is suffocating.
  2. Forests are being annihilated.
  3. Pollinators are being wiped out.
  4. Billions need climate chaos help.
  5. Large mammals won’t survive.
  6. Our crops will soon fail.
  7. Extinction is accelerating.
  8. Plastic is in our lungs.
  9. Arctic Ice is disappearing.
  10. Antarctica is collapsing.
  11. The Amazon is dying.
  12. Rivers are toxic.
  13. The Air is poisonous.
  14. Coral reefs are doomed.
  15. Millions - mostly black and brown children, women & men - are dying due to the Ecological Catastrophe, every year.
  16. Greenland ice is melting.
  17. Heatwaves will kill billions.
  18. Mass Starvation has begun.
  19. BILLIONS, yes, mostly black & brown children, women & men, seem set to die in the Ecological and Global Warming Catastrophe - unless all systems are revolutionised towards justice.
  20. The seasons are forever broken.
  21. Permafrost is collapsing. 😱
  22. Mega-storms are getting worse.
  23. Bees are critically endangered.
  24. Corporate capitalism has wrecked our natural world, but it is never be too late to organise fairer societies based on real cooperation.
  25. Insects are vanishing.
  26. The Ocean is acidifying.
  27. Seabirds are starving.
  28. Sea levels are rising.
  29. Fertile soils are disappearing.
  30. Scientists see that, alongside fossil fuel burning, animal agriculture is a major cause of this ecological and climate nightmare.
  31. The jet stream is fractured.
  32. Glaciers are melting.
  33. Orangutans face annihilation.
  34. Sharks are being wiped out.
  35. Butterflies are in danger.
  36. Fish are disappearing.
  37. Plankton are dying.
  38. Deserts are expanding.
  39. Mountains are being destroyed.
  40. Trees are diseased.
  41. Beaches are being washed away
  42. Lakes are shrinking.
  43. Waterfalls are dry.
  44. Giraffes will soon be gone.
  45. Starfish are being massacred.
  46. Frogs are near extinction.
  47. Whales are committing suicide.
  48. Worms are struggling to live.
  49. Tropical diseases will explode.
  50. Plant extinction is out of control.

Un autre thread sur Twitter (ça va aller jusqu’à 100)

Une Terre que l’on recouvre d’une couche de plastique, héritage du bref passage de l’Humanité sur ce bout de caillou. La tête dans un sac jusqu’à l’asphyxie.

Je regarde mes voisins avec leur SUV de deux tonnes par personne. Leurs maudites tondeuses (cache). Leurs barbecues de bœuf quotidiens. Et je pleure.

Raft urbain Se laisser glisser. Emporté par le flux. Jusqu’au barrage.
Broyé par ce monde en besoin d’énergie.

J’en ai plein le dos de ce monde. Et il me le fait bien comprendre chaque matin. Je ne peux même plus criser tranquille dans mon coin (cache).

2019-06-21

☕︎ À lier

J’avais partagé des paroles de femmes sans commentaires l’année dernière. Ici je reste silencieux tout en changeant un peu la donne (l’ordre n’est pas significatif).

Se dire féministe est un terme politique. Si vous, hommes cisgenres, vous dites féministes, vous vous appropriez une lutte qui est précisément contre vous. De fait, vous la décrédibilisez. Un homme cisgenre n’a rien à gagner des luttes féministes, puisque ces luttes visent à lui faire perdre du pouvoir et à affaiblir la domination de sa classe sociale sur les autres. Cette perte de pouvoir est nécessaire à l’établissement d’une société plus égalitaire. Le féminisme ne prétend pas apporter un changement bénéfique aux hommes cisgenres, mais bien au reste de la société. Alors oui, vous êtes pétris de bonnes intentions et vous voulez aider à déstigmatiser le féminisme. Mais en vous appropriant ce terme, vous le rendez ridicule. Ridicule, parce que nous luttons contre un système qui vous favorise. Comment vous faire confiance ? Comment croire en votre sincérité, en votre foi dans le renversement d’une oppression qui vous bénéficie ?

Un homme peut-il être féministe ? (cache)

Par ailleurs, votre article renvoie à une vision dichotomique des genres en disant clairement que l’un se bat contre l’autre. Alors qu’aujourd’hui on assiste à l’émergence d’une “fluidité des genres”. La vision dichotomique de ces deux essences n’a plus de sens. Au contraire, il faudrait voir la féminité et la masculinité (absolues) comme les deux extrêmes d’un spectre disposant d’une infinité de nuances. Nier la possibilité pour les hommes de se joindre à la lutte féministe c’est nier une grande partie de ces nuances et la possibilité pour chacun de naviguer au sein du spectre selon les moments de nos vies. J’ajouterais que cette idée de nuance et fluidité entre les genres est essentielle pour déconstruire les stéréotypes et améliorer les conditions des femmes/LGBT etc.

Un commentaire de l’article « Un homme peut-il être féministe ? » sus-cité (cache)

La question de savoir si un homme peut ou ne peut pas être féministe est une question qui revient souvent, et qui est importante. L’idée est de situer d’où on parle et, n’étant pas une femme, je ne peux pas dénoncer les violences qui leur sont faites de la même manière qu’elles le feraient. Mais je sais aussi que cette explication est une porte ouverte pour une conversation plus longue donc quand une personne me demande si je suis féministe, et que je n’ai pas le temps de tout expliquer, je dis « oui ».

Je préfère cependant le terme « d’allié », car en dépit de toute l’empathie et la compassion dont je suis capable, je reste un homme blanc qui n’a jamais souffert du sexisme, que la société n’incite pas au quotidien à se sentir mal dans sa peau ou dans son travail ou dans son rôle de père… ma vie est très paisible, si on la compare à celle des militantes féministes qui sont harcelées chaque jour.

Allié (cache)

Voilà comment j’ai découvert la raison et la manière dont je ne parvenais pas à écouter quand une femme me parlait de sexisme.

Prendre conscience du rôle que jouent mon comportement et mes pensées, a été une étape décisive dans mon cheminement. J’ai compris que les mécanismes qui m’aveuglent font partie intégrante de ma subjectivité. Aussi pouvais-je être certain que ces mécanismes de défense se déclencheraient à nouveau dans des conditions similiaires, et que pour les contrebalancer, l’écoute et l’empathie ne suffisent pas.

Ce Qui Se Passe En Moi Quand Une Femme Me Parle De Sexisme (cache)

Tu le sais : une partie de toi se perçoit comme un mec bien, mais elle en doute quand même un peu. Cette partie de toi a très envie d’entendre d’autres personnes te rassurer, te confirmant que tu es un mec bien.

Petit Guide D Aikido Partie 1 (cache)

Si tu ne comprends pas, ou si tu es surpris, réjouis-toi. L’incompréhension n’est pas un échec, c’est le début d’un processus d’apprentissage. La surprise, c’est le signe que tu découvres quelque chose de nouveau. Si cette conversation ne t’éclaire pas aujourd’hui, peut-être contribuera-t-elle à une prise de conscience, plus tard ?

Petit Guide D Aikido Partie 2 (cache)

Google est sexiste et accepte assez mal que l’on en fournisse les preuves. Ce monde est sexiste. Les algorithmes sont sexistes puisqu’ils ne sont que la reproduction (parfois augmentée) de nos propres biais et de nos propres systèmes de valeurs ou d’anti-valeurs.

Mais au final et par-delà l’instanciation subjectivée de nos ressentis à la lecture de ces résultats, il y a ce que nous montrons et ce que nous acceptons de voir, qui est ce que nous tous, êtres humains, algorithmes et plateformes, ce que nous tous, nous tolérons. Ce que nous sommes vraiment. Et ce que nous devenons collectivement.

Lesbienne raisonnable ? Quand Sapho pas, sapho pas. (cache)

Féminisme et antispécisme ne doivent pas être perçus comme deux luttes séparées mais comme des mouvements solidaires qui se battent contre des formes de domination liées par un agenda largement commun. Les féministes, et plus généralement les militant·e·s progressistes, ne peuvent faire l’impasse d’une remise en question de la violence envers les autres animaux : ne pas remettre en question le spécisme revient à contribuer aux mêmes schémas de violence, d’arbitraire et d’injustice que ceux qui fondent le patriarcat, la suprématie blanche et le capacitisme.

Féminisme et cause animale (cache)

One of my mom groups has a thread that is just women listing and recommending which kind of protection they take when them when they go out running (Ie. pepper spray, alarm necklaces, whistles, etc) in case you wondered what being a woman is like

Tweet de Amanda Deibert (voir réponses)

Par contre je n’adhère pas à la vue du « seule les victimes peuvent en parler et ont un avis légitime », pas plus là que sur d’autres sujets. En fait c’est même tout le contraire. Par principe tous les impliqués dans une question ont une vue biaisée, la victime autant que l’oppresseur. C’est bien pour ça qu’en justice on impose un juge neutre au milieu.

Le problème c’est qu’ici il n’y a personne de neutre.

De la difficulté d’évoquer le féminisme (cache)

SÉLECTION

Cette planète rassemble les principaux carnets web d'auteurs francophones traitant de XML. Ces blogs sont souvent bilingues français/anglais et éclectiques. Cette page rassemble l'ensemble de leurs billets et vous permet de sélectionner ceux que vous voulez voir.


Lien permanent pour cette sélection :
feed /actualites/planete/xmlfr/fr/
Les documents publiés sur ce site le sont sous licence " Open Content".

Valid XHTML 1.0 Transitional

logo DYOMEDEA
Conception, réalisation et hébergement

Questions ou commentaires
redacteurs@xmlfr.org