XMLfr : l'espace XML francophone

Ce court RFC spécifie les précautions que doit prendre une mise en œuvre de TCP pour éviter qu'un attaquant ne puisse deviner le numéro de séquence initial. Rien de nouveau, les précautions en question étant programmées dans TCP depuis de nombreuses années, juste un rappel et une mise à jour du précédent RFC sur ce sujet, le RFC 1948.

Pour comprendre le problème de sécurité des numéros de séquence, et les solutions présentées dans ce RFC, il vaut mieux revenir à l'attaque qui exploitait les anciennes vulnérabilités. C'est fait dans l'annexe A du RFC, que je reprends ici.

Le but de l'attaquant est de s'en prendre à un serveur qui autorise par adresse IP. À l'époque du RFC 1948, cela concernait rsh mais, de nos jours, SSH a complètement remplacé cet archaïque protocole. Aujourd'hui, ce serait plutôt un serveur DNS qui authentifie le transfert de zones ainsi, ou bien un serveur SMTP qui autorise seulement certaines adresses IP à passer par lui - même s'il ferait mieux de se servir du RFC 4954, ou encore un serveur HTTP qui ne permet l'invocation de certaines actions qu'aux utilisateurs de certaines adresses. En deux mots, dès que l'autorisation se fait par adresse IP uniquement, il faut s'assurer que vous utilisez un TCP qui mette en œuvre les recommandations de ce RFC 6528.

On le sait, il est trivial pour un attaquant d'envoyer des paquets avec une fausse adresse IP source (le RFC 2827, censé l'empêcher, n'étant quasiment pas déployé). Mais, dans ce cas, l'attaquant ne reçoit pas les réponses. Or, si on veut maintenir une connexion TCP avec sa victime, il faut lui envoyer des paquets avec les données qu'elle attend, notamment le numéro de port et les numéros de séquence. Sinon, la victime va jeter ces paquets TCP qui lui sembleront anormaux. Pour les numéros de port, le RFC 6056 s'en occupe. Pour les numéros de séquence, voyons ce qui se passe. Tout paquet TCP doit inclure ces numéros, un pour chaque sens de la conversation (RFC 793, section 3.3). Ce numéro identifie l'octet suivant à envoyer. Une ouverture de connexion TCP normale ressemble donc, pour le cas où Alice veut parler à Bob, à :

• Alice->Bob: [SYN] ISNa, null (Alice envoie un paquet TCP où le bit SYN est mis, avec un numéro de séquence initial ISNa - ISN = Initial Sequence Number.)
• Bob->Alice: [SYN] ISNb, ACK(ISNa+1) (Bob répond qu'il est d'accord, envoie son propre ISN - rappelez-vous qu'il y a deux séquences d'octets, une dans chaque direction - et accuse réception de l'ISN d'Alice.)
• Alice->Bob: [] ISNa, ACK(ISNb+1) (Alice est d'accord et cela termine la «  triple poignée de mains » qui ouvre une connexion TCP.)

% tcpdump -S -n -r tmp/3wayhandshake.pcap
reading from file tmp/3wayhandshake.pcap, link-type EN10MB (Ethernet)
09:47:53.086347 IP 192.134.6.69.39859 > 149.20.4.72.9418: Flags [S], seq 3366079112, ...
09:47:53.242880 IP 149.20.4.72.9418 > 192.134.6.69.39859: Flags [S.], seq 3075029842, ack 3366079113, ...
09:47:53.242910 IP 192.134.6.69.39859 > 149.20.4.72.9418: Flags [.], ack 3075029843, ...

Le deuxième paquet n'a été accepté par Alice que parce qu'il contenait un numéro de séquence attendu. Mëme chose pour le troisième. Un attaquant qui procéderait au hasard, envoyant des numéros de séquence quelconques, n'aurait aucune chance que ses paquets soient acceptés. Imaginons maintenant que l'attaquant puisse connaître les numéros de séquence utilisés. Bob fait confiance à Alice mais Mallory, l'attaquant, va se faire passer pour Alice. Mallory n'est pas situé sur le chemin entre Alice et Bob (sinon, cela serait trivial, il lui suffirait d'écouter le réseau) :

• AliceM->Bob: [SYN] ISNa, null (Mallory, utilisant l'adresse source d'Alice, envoie un paquet TCP où le bit SYN est mis, avec un numéro de séquence initial ISNa.)
• Bob->Alice: [SYN] ISNb, ACK(ISNa+1) (Bob répond qu'il est d'accord, envoie son propre ISN et accuse réception de l'ISN qu'il croit venir d'Alice. Mallory ne recevra pas ce paquet, qui ira à la vraie Alice. Mallory ne sait donc pas ce que vaut ISNb, et doit deviner. En cas de divination juste, son paquet suivant est accepté.)
• AliceM->Bob: [] ISNa, ACK(ISNb+1) (Mallory, utilisant l'adresse source d'Alice, termine la triple poignée de mains. Bob croit qu'il est connecté à Alice alors qu'il va accepter les paquets de Mallory.)

À noter qu'Alice, elle, reçoit l'accusé de réception de Bob, auquel elle ne s'attend pas. Elle va donc émettre un paquet RST qui va fermer la connexion. Diverses techniques permettent à l'attaquant de réussir quand même (par exemple en montant au même moment une attaque DoS contre Alice pour ralentir ses paquets, donnant à l'attaque le temps de réussir).

C'est pour répondre à cette attaque que le RFC 1948 avait été écrit en 1996, documentant la pratique qui était devenue courante, de générer des numéros de séquence, sinon aléatoires, en tout cas imprévisibles. (Un article plus récent et plus détaillé sur la vulnérabilité initiale était celui de Shimomura, T., Technical details of the attack described by Markoff in NYT, envoyé sur Usenet, en comp.security.misc, Message-ID: <3g5gkl$5j1@ariel.sdsc.edu>, en 1995.) Notre RFC 6528 met à jour ce RFC 1948. La section 2 expose les principes d'un bon algorithme de génération d'ISN (Initial Sequence Number), la section 3 décrit l'algorithme proposé. Commençons par celui-ci. Il tient en une formule :

ISN = M + F(localip, localport, remoteip, remoteport)

Notez que, bien que MD5 ait de nombreuses faiblesses cryptographiques pour d'autres utilisations, il est parfaitement sûr pour celle-ci (et bien plus rapide que ses concurrents).

La section 2, elle, définissait le cahier des charges : qu'attend t-on d'un algorithme de sélection de l'ISN ? D'abord, il n'est pas forcé d'empêcher des vieux paquets IP qui traînent dans le réseau d'être acceptés. Pour cela, il vaut mieux compter sur l'état TIME_WAIT de TCP (après la fin d'une connexion, garder l'état pendant deux MSL - Maximum Segment Life, cf. RFC 1323). Ça ne marche pas forcément si les connexions sont créées à un rythme très rapide mais c'est la seule solution sûre (mais consommant de la mémoire). On peut lire à ce sujet deux articles sur les générateurs d'ISN, leurs avantages et inconvénients, « Strange Attractors and TCP/IP Sequence Number Analysis » et « Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later ».

Compte-tenu de ces risques, une génération aléatoire de l'ISN suffirait. Mais elle aurait l'inconvénient de de ne pas permettre de deviner si un nouveau paquet TCP appartient à une ancienne connexion ou pas. L'idée de base de ce RFC est donc de créer un espace de numéros de séquence par identificateur TCP (le tuple {adresse IP locale, port local, adresse IP distante, port distant}) et, dans chacun de ces espaces, de suivre les règles d'incrémentation progressive de l'ISN du RFC 793.

Pour ceux qui veulent pousser l'analyse de sécurité, la section 4 prend de la hauteur et rappelle quelques points importants. D'abord que la vraie solution serait évidemment de protéger les paquets IP par de la cryptographie comme le fait IPsec, ou au niveau TCP comme le fait le TCP-AO du RFC 5925 (TLS ou SSH ne suffisent pas, ils n'empêchent pas une attaque par déni de service avec des faux paquets TCP RST).

La section 4 fait aussi remarquer que rien n'est parfait et que l'algorithme proposé dans notre RFC a des effets de bord, comme de permettre le comptage du nombre de machines qui se trouvent derrière un routeur NAT, ce qui peut être une information qu'on souhaiterait garder privée.

Et, surtout, elle rappelle que toutes les précautions de notre RFC 6528 ne s'appliquent que si l'attaquant est en dehors du chemin entre les deux pairs TCP. S'il est sur le chemin et qu'il peut écouter le réseau, elles ne servent à rien.

Quels sont les changements depuis le RFC 1948 ? Il n'y a pas de changement sur le fond (l'algorithme est le même donc un TCP compatible avec le RFC 1948 l'est également avec le RFC 6528). Les changements sont résumés dans l'annexe B. Le statut du RFC a changé (désormais sur le chemin des normes), les exemples maintenant dépassés par l'évolution des techniques ont été mis à jour ou supprimés,

On l'a dit, les précautions décrites dans ce RFC sont présentes dans les implémentations depuis longtemps. Pour un exemple de mise en œuvre de cet algorithme, on peut regarder le code source de NetBSD. Il se trouve en sys/netinet/tcp_subr.c. Son comportement est contrôlé par la variable sysctl iss_hash. Mise à 1, elle indique qu'il faut utiliser l'algorithme ci-dessus. À 0, qu'il faut utiliser une valeur aléatoire. Prenons le premier cas, celui de notre RFC. On voit la génération du secret (un nombre aléatoire, issu de cprng_strong()) puis le hachage MD5 de l'identifiant de connexion avec le secret :

	/*
	 * If we haven't been here before, initialize our cryptographic
	 * hash secret.
	 */
	if (tcp_iss_gotten_secret == false) {
		cprng_strong(kern_cprng,
			     tcp_iss_secret, sizeof(tcp_iss_secret), 0);
		tcp_iss_gotten_secret = true;
	}

        /*
	 * Compute the base value of the ISS.  It is a hash
	 * of (saddr, sport, daddr, dport, secret).
	 */
	MD5Init(&ctx);
	MD5Update(&ctx, (u_char *) laddr, addrsz);
	MD5Update(&ctx, (u_char *) &lport, sizeof(lport));
	MD5Update(&ctx, (u_char *) faddr, addrsz);
	MD5Update(&ctx, (u_char *) &fport, sizeof(fport));
	MD5Update(&ctx, tcp_iss_secret, sizeof(tcp_iss_secret));
	MD5Final(hash, &ctx);
	memcpy(&tcp_iss, hash, sizeof(tcp_iss));

        return (tcp_iss);

__u32 secure_tcp_sequence_number(__be32 saddr, __be32 daddr,
				 __be16 sport, __be16 dport)
{
	u32 hash[MD5_DIGEST_WORDS];

	hash[0] = (__force u32)saddr;
	hash[1] = (__force u32)daddr;
	hash[2] = ((__force u16)sport << 16) + (__force u16)dport;
	hash[3] = net_secret[15];

	md5_transform(hash, net_secret);

Dans l'ensemble du travail engagé pour améliorer la sécurité du routage sur l'Internet, un sous-problème important est celui de la gestion des clés. En cryptographie, c'est souvent par une faiblesse dans cette gestion que les systèmes de sécurité sont compromis. Le groupe de travail KARP de l'IETF est occupé à améliorer les protocoles de gestion de clés et son premier RFC, ce RFC 6518, expose les propriétés attendues des futurs protocoles de gestion des clés des routeurs.

Prenons par exemple N routeurs OSPF qui veulent s'authentifier les uns les autres. La technique du RFC 2328 est d'avoir un secret partagé par tous les routeurs du même réseau local. Les messages OSPF sont concaténés avec ce secret, le résultat de la concaténation est ensuite condensé cryptographiquement, ce qui permettra au destinataire de s'assurer que l'émetteur connaissait bien le secret. Ce secret partagé est une clé cryptographique. Qui va la générer ? Comment la distribuer de façon sûre ? Comment la changer facilement et rapidement si le secret est compromis (ou, tout simplement, si un employé quitte l'entreprise) ? Ce genre de questions est la problématique de gestion de clés. Dans le cas d'OSPF, actuellement, la quasi-totalité des opérateurs de routeurs fait cela à la main (on se logue sur chaque routeur et on change le secret...) ou, à la rigueur, via un protocole général de configuration des routeurs. Peut-on faire mieux ? C'est en tout cas ce que va essayer de faire le groupe KARP.

C'est que les mécanismes actuels ne sont pas satisfaisants. Comme le rappelle la section 1 du RFC, lors d'un colloque en 2006 (cf. RFC 4948), les participants avaient dénoncé la vulnérabilité des routeurs aux tentatives de prise de contrôle et appelé à durcir leur sécurité. Quatre axes d'amélioration avaient été identifiés, améliorer la gestion des routeurs (groupe de travail OPSEC), améliorer les IRR, valider les annonces de route (groupe de travail SIDR), et enfin sécuriser les communications entre routeurs (groupe de travail KARP), ce qui fait l'objet de ce RFC. Les informations de routage sont échangées via un protocole et la protection de ce protocole se fait par la cryptographie. Qui dit cryptographie dit clés. Lorsqu'un routeur cherche une clé pour protéger un message, où demande-t-il ? Pour l'instant, il n'y a pas de mécanisme standard et KARP va essayer d'en développer un. Le plus courant aujourd'hui est la gestion manuelle des clés (l'opérateur configure les clés, les change à la main - lorsqu'il y pense, les communique via PGP, SCP voire sans aucune sécurité) mais le RFC estime que le futur est dans des mécanismes automatisés de gestion de clés, les KMP (pour Key Management Protocol). Un KMP, par exemple, change automatiquement les clés au bout d'une période pré-définie.

Compte-tenu de la variété des protocoles de routage, et du transport qu'ils utilisent, ce sera un mécanisme abstrait, pas un protocole précis (ce RFC 6518 n'a donc pas d'implémentation, il définit juste un cadre). Plus précisement, KARP va concevoir les interfaces abstraites entre le système de gestion de clés et le protocole de routage, puis, pour chaque protocole de routage, la correspondance entre cette interface abstraite et le protocole réel. Un projet ambitieux.

Maintenant, au boulot. Qu'est-ce qui est déjà fait dans ce RFC ? La section 2 classe les protocoles de routage selon leurs propriétés. L'idée est que les protocoles de routage qui partagent les mêmes propriétés pourront, avec un peu de chance, utiliser les mêmes mécanismes de gestion de clés. Première propriété, le type de message. Certains protocoles sont de type un-vers-un : les messages d'un routeur sont envoyés à un autre routeur. Les UPDATE BGP (RFC 4271) fonctionnent ainsi. Mais c'est aussi le cas de LDP (RFC 5036), de BFD (RFC 5880) et même d'OSPF (RFC 2328 dans certaines conditions (liens point -à-point). D'autres protocoles fonctionnent en un-vers-plusieurs. Un routeur diffuse sur le réseau local l'information de routage. C'est le mode de fonctionnement le plus courant d'OSPF et c'est aussi celui de RIP (RFC 2453). Enfin, il y a les protocoles utilisés pour le multicast.

Deuxième propriété pour classer les protocoles de routage, proche de la précédente mais pas identique, le fait que la clé soit par groupe ou par pair. Dans BGP ou LDP, les clés sont individuelles, on a une clé différente par pair. Dans OSPF, la clé est la même pour tous les pairs d'un groupe.

La section 3 liste ensuite les points auxquels il faut penser lorsqu'on envisage un protocole de gestion de clés, un KMP. Le RFC 4107 fournit les bases générales et notre RFC l'adapte aux protocoles de routage. Entre autres, il faudra penser aux paramètres à passer avec le système de gestion de clés, comme la durée de vie pour les clés, l'identificateur de l'association de sécurité (SPI dans IPsec, KeyID dans TCP-AO, etc), l'algorithme de chiffrement et plusieurs autres.

Deux points sont soulignés par le RFC, les questions particulières des clés asymétriques (section 3.1) et le cycle de vie des clés (section 3.2). Les clés asymétriques sont souvent une bonne solution aux problèmes de sécurité : déjà utilisées par les routeurs (lorsqu'ils sont administrés via SSH), générées sur le routeur, elles peuvent n'avoir jamais besoin de le quitter (le RFC ne le dit pas clairement mais on peut même imaginer un petit HSM dans le routeur). Générées aléatoirement, elles ne peuvent pas être devinées comme le sont tant de mots de passe choisis par des humains. Il faut juste faire attention à leur taille, pour limiter les risques des attaques par force brute (RFC 3766). L'algorithme classique pour ces clés est RSA mais les algorithmes à base de courbes elliptiques commencent à se répandre, et permettent d'utiliser des clés plus courtes.

Quant au cycle de vie des clés, notre RFC insiste surtout sur la nécessité d'avoir des remplacements (rollover) de clés qui soient discrets : un remplacement de clés ne devrait pas casser les sessions de routage existantes, car cela imposerait des recalculs lourds des tables de routage, se propageant dans tout le réseau, et entraînant parfois des perturbations dans la connectivité. (Le RFC ne le cite pas mais la traditionnelle authentification MD5 de BGP - RFC 2385 - n'a pas cette propriété. Changer la clé impose de relancer les sessions BGP. C'est sans doute une des raisons pour lesquelles ces clés ne sont jamais changées, même quand tout le monde les connait.)

Pourquoi, d'ailleurs, faut-il changer les clés de temps en temps ? Il peut y avoir des raisons cryptographiques (progrès de la cryptanalyse, mais le RFC note qu'en pratique, ce sont les cas les plus rares, des problèmes moins prestigieux scientifiquement sont bien plus communs), des raisons liées au personnel (départ d'un ingénieur qui connaissait les clés), des raisons plus urgentes (compromission d'une machine où étaient stockées des clés). Même s'il n'y a aucune raison immédiate de changer, un remplacement des clés de temps en temps peut être nécessaire pour s'assurer qu'un attaquant qui a obtenu une clé et l'utilise discrètement (de manière purement passive), ne puisse pas profiter de son butin éternellement.

Lorsque les procédures de changement de clés sont manuelles, les changements peuvent être en eux-mêmes une source de vulnérabilité (l'erreur est humaine...).

Après ces préliminaires, la section 4 dessine le travail futur. Il y a deux chantiers génériques (indépendants du protocole de routage) importants, le premier étant un pré-requis du second :

• Doter tous les protocoles de routage de mécanismes leur permettant l'agilité des algorithmes (changer d'algorithme facilement, contrairement au RFC 2385, qui ne permettait que MD5) et celle des clés (changer de clés sans casser les sessions entre routeurs). À l'heure actuelle, c'est très loin d'être le cas.
• Une fois ces mécanismes en place, développer un KMP, un Key Management Protocol permettant la gestion et le remplacement automatique des clés. Ce dernier protocole devrait être aussi indépendant du protocole de routage que possible.

Avec une gestion manuelle des clés, on ne peut gérer de manière raisonnablement sûre que des petits réseaux. La deuxième étape sera donc de déployer le mécanisme de gestion automatique.

Le travail d'amélioration de chaque protocole de routage est décrit en section 4.2 sous forme d'une liste de tâches :

• Analyser le protocole actuel pour déterminer de façon précise quels sont ses mécanismes de sécurité présents,
• Déterminer ce qui lui manque pour atteindre le premier état de sécurité souhaité (agilité des algorithmes et possibilité de changer de clés en vol),
• Analyse des étapes nécessaires pour aller du premier point au deuxième sans tout casser, en faisant particulièrement attention aux questions de déployabilité dans le monde existant,
• Analyser le futur KMP (protocole de gestion de clés) pour ce protocole de routage particulier : a-t-il des demandes spécifiques ?
• Déterminer ce qui manque pour atteindre le deuxième état de sécurité (gestion automatique des clés),
• Normaliser l'adaptation du KMP à ce protocole et déployer le résultat.

On l'a vu en section 2, KARP classe les protocoles de routage en catégories selon leurs propriétés. La section 5 examine les points qui sont spécifiques à chaque catégorie. BGP, LDP et quelques autres sont dans la catégorie « messages un-vers-un et clés par pair ». BGP fonctionne toujours sur TCP, LDP parfois sur TCP et parfois sur UDP. Pour le cas de TCP, une bonne partie du travail a déjà été faite dans le groupe TCPM, avec la technique d'authentification AO (RFC 5925) qui a les propriétés voulues pour la première phase du travail de KARP (agilité des algorithmes et changement de clé facile). Il ne reste donc que le cas de LDP sur UDP.

Pour la catégorie « un-vers-plusieurs avec clés par groupe », qui comprend OSPF, IS-IS et RIP, rien de générique n'est fait. Le problème est ici bien plus difficile, d'autant plus que ces protocoles n'utilisent pas en général de protocole de transport standard, et ne peuvent donc pas réutiliser un mécanisme fourni par la couche 4 (comme peut le faire BGP avec AO).

BFD est un cas à part et qui nécessitera sa propre équipe. Par exemple, il est beaucoup plus sensible aux délais que les autres. Pour lui, une milliseconde est très longue.

On l'a vu, ce RFC répète régulièrement qu'il est essentiel de prévoir un déploiement incrémental des nouveaux mécanismes de sécurité. Pas question d'ignorer l'existant. La section 6 insiste sur ce point. Contrairement à une attitude fréquente chez les experts en sécurité, qui est de chercher une solution parfaite, KARP va essayer de trouver des solutions qui puissent être déployées par étapes, sans casser le routage actuel, même si ces solutions ne sont pas les meilleures, question sécurité. Par exemple, les routeurs configurés avec les nouveaux mécanismes doivent pouvoir interagir sans ennuis avec les vieux routeurs non sécurisés.

Un des problèmes de sécurité les plus difficiles dans l'Internet est celui des attaques par déni de service (section 7). Ces attaques touchent aussi les routeurs et les protocoles de routage. Il ne faut donc pas que les nouvelles techniques conçues dans le cadre du groupe KARP aggravent le problème. Par exemple, les calculs cryptographiques peuvent être coûteux, surtout pour les ressources matérielles souvent limitées des routeurs, et les protocoles ne doivent donc pas permettre à un attaquant de faire faire au routeur une énorme quantité de ces calculs. Pour éviter cela, il faut permettre au routeur de faire des vérifications non-cryptographiques, donc bien plus légères, avant de se lancer dans les calculs compliqués. Par exemple, le RFC 5082 utilise le TTL du paquet entrant (quelque chose de trivial à vérifier) pour empêcher certaines attaques. Il est important, dans le cadre de KARP, de développer et de documenter de telles alternatives. D'autre part, le protocole doit être conçu de manière à ce que ce soit l'initiateur de la connexion (un attaquant potentiel) qui ait le plus de travail cryptographique à faire, et qui doive maintenir un état pendant ce temps.

La section 9 du RFC, la traditionnelle section sur la sécurité, détaille quelques points précis qui n'avaient pas trouvé leur place dans le reste du RFC. Par exemple, il est important de considérer aussi si le protocole de routage qu'on veut protéger est un IGP ou un EGP (certains protocoles peuvent être utilisés pour les deux, comme BGP avec son mode iBGP). Les deux sont sans doute aussi importants mais les menaces et les solutions ne seront pas forcément les mêmes. Un routeur purement interne et qui n'a aucun accès à l'Internet est ainsi sans doute moins menacé qu'un routeur BGP posé sur un point d'échange avec des dizaines d'autres routeurs inconnus.

Autre question transversale, celle des clés partagées ou uniques. Faut-il utiliser la même clé à plusieurs endroits ? Le débat est simple : c'est la sécurité (clés uniques !) contre la commodité (clés partagées). Actuellement, dans la grande majorité des environnements, les opérateurs ont choisi la commodité, réutilisant la même clé à plusieurs endroits. Les clés des routeurs sont stables dans l'espace (utilisées dans plusieurs routeurs) et dans le temps (on les change rarement, voire jamais et certains routeurs gardent la même clé toute leur vie). L'un des buts de KARP est de casser ce dilemne « sécurité ou commodité » en fournissant des mécanismes de gestion de clés qui soient sûrs (clés uniques) tout en étant faciles à déployer.

Enfin, la section 9.4 discute du dernier problème transversal, la distribution des clés. La méthode la plus courante aujourd'hui est un mécanisme « hors-bande », par exemple l'administrateur qui se connecte en SSH au routeur et entre manuellement les clés dans la configuration. Ça ne passe pas tellement à l'échelle (il faudrait automatiser les connexions SSH, par exemple avec Capistrano, pour faire l'opération sur N routeurs). Et changer toutes les clés en cas, par exemple de départ d'un administrateur (ou, pire, en cas de compromission de la clé) est trop lent. L'approche d'un KMP, protocole de gestion de clés, est donc préférée par KARP, comme nous l'avons déjà vu. Mais le RFC ne cache pas que le KMP a ses propres problèmes : lenteur au début (davantage de calculs cryptographiques) et surtout risques liés au manque de maturité des programmes, les KMP étant encore chose récente.

Une des possibilités envisagées est de réutiliser un KMP existant comme IKE, adapté au monde du routage, mais tournant en dehors du protocole de routage. L'autre possibilité est un nouveau KMP, embarqué dans le protocole de routage. Mais la décision n'est pas encore prise.

Juste à temps pour pouvoir encore appeler ça résolutions ! Seulement 4 billets et quelques pensées en 2011. On peut dire que l'année n'aura pas été très riche en écrits, même si j'essaye de me forcer à écrire en anglais par ailleurs (très douloureux exercice compte tenu de mon niveau).

Retour sur 2011 :

• Découvrir : au Japon depuis 4 mois, l'intégration est encore plus difficile que prévue mais les découvertes sont au rendez-vous, j'ai encore beaucoup de mal à écrire sur le Japon alors je n'en dis pas plus ;
• Concrétiser : le GR20 m'a (re)donné le goût à la montagne et à l'activité sportive, au-delà de la semaine de marche c'est la démarche qui m'a fait progresser, au point d'avoir envie de faire le Mont Fuji en courant ;
• Transmettre : pas de stage finalement et avec le recul c'est pas plus mal compte-tenu du rush d'avant départ cet été. Je n'ai pas du tout renoncé à transmettre cela dit :-).

Rediriger

Tout d'abord techniquement, j'ai décidé de consolider mon identité numérique sur larlet.fr et d'y rediriger/aggréger tous mes contenus éparpillés sur divers noms de domaines. Ce blog est le dernier sur la liste et il va y passer dès que j'aurai choisi s'il reste dynamique ou si je fais un export statique. Les commentaires seront définitivement coupés dans les prochains jours quelle que soit la solution retenue.

Redirection professionnelle également, je suis en pleine réflexion sur ce que j'ai envie de faire par la suite. J'ai quelques idées complètement déconnectées, d'autres plus proches du Web. Ça se terminera peut-être par une pluri-activité, en tout cas j'ai bien envie de me rapprocher de la terre, de la forêt, de la montagne.

Économiser

Vivre dans le plus grand centre commercial du monde vous permet d'avoir une réflexion sur la consommation et ses gaspillages. Je suis de plus en plus écœuré par cette mascarade, par une société qui a transformé le citoyen en consommateur au détriment de son humanité et de sa sociabilité.

Je suis en pleine démarche de déconsommation et je compte relocaliser mon alimentation à mon retour en France. Je ne peux plus continuer en détournant le regard. Je suis en train de revoir complètement ma façon d'appréhender les choses avec ce nouvel angle de vue. Il est temps de faire preuve d'intelligence et de se ré-adapter.

Débattre

Une idée n'est vivante que lorsqu'elle est débattue pour paraphraser Christopher McCandless dans Into The Wild. C'est une chose qui me manque énormément ici et qui me donne des idées pour la suite, le débat français devrait être au patrimoine mondial de l'UNESCO au même titre que le repas français ;-).

J'ai bien envie de lancer des groupes de discussion physiques (vs. numériques) sur des problémantiques locales afin de faire avancer les choses à mon échelle. Je ne crois plus à une volonté citoyenne soldée d'une action qui serait plus étendue que l'échelle de la commune. Si l'année dernière j'avais des envies de GeeksSansFrontières évoqué lors des rencontres Django, je me dis maintenant qu'un GeeksLocaux serait peut-être moins sexy et ambitieux mais au combien plus efficace.

Ces résolutions peuvent paraîtrent déprimantes (ou dans l'air du temps…) mais elles ont également une part excitante d'espoir et d'inconnu qui sont extrêmement motrices. 2012 sera l'année d'un changement politique personnel au sens politeia du terme, je laisse le spectacle lassant de la politikè à d'autres.

Dans une précédente note sur les première pratiques scripturales dans les activités de commerce et de transactions économiques, je rappelais que, avec l’invention de la monnaie, une figure avait émergée en la personne du « changeur », qui évolua lui-même vers la fonction du « banquier » quand il se mit à faire « travailler » la trésorerie générée par son activité de change. Cette nouvelle activité lui imposa d’inventer de nouveaux jeux d’écritures, des écritures comptables.

Si « Jeux d’écriture » renvoie aujourd’hui à des jeux pour l’apprentissage de l’écriture dans les moteurs de recherche web, l’expression est également un euphémisme pour désigner des malversations comptables et financières. En ce dernier sens, le jeu d’écriture est perçu comme un tour de passe-passe potentiellement frauduleux.

En dehors des question des transactions économiques, par exemple dans l’informatique, il m’apparaît évident que l’on a à faire à des jeux d’écritures. Un protocole, un compilateur, un programme, tout cela peut parfaitement être qualifié de jeu d’écriture. Serveurs et clients web inter-échangent via un jeu d’écriture. (Un style d’architecture décrit toujours les règles d’un jeu d’écriture)

Il est beaucoup moins évident pour moi de parler de jeu d’écriture à propos des oeuvres littéraires. Il y a bien des styles et des genres mais, bien qu’on puisse dire que ces oeuvres répondent à des règles, je n’arrive pas à me les représenter comme relevant des jeux d’écriture dont je parle ici, ou alors de manière très lointaine, si ce n’est métaphoriquement.

Pour qu’il y ait jeu d’écriture, il faut qu’il y ait une volonté de reproductibilité, d’abord pour soi-même puis pour les autres. Un auteur peut être seul avec son oeuvre, pas celui qui utilise des jeux d’écritures. La pratique scripturale n’est pas la même dans les deux cas. Dans le jeu d’écriture dont je parle ici, la règle est manifeste et il faut la respecter. En ce sens, la littérature est beaucoup plus transgressive dans ses pratiques de l’écriture.

Les jeux d’écriture ont ainsi une fonction collective évidente : les recettes, les méthodes et les techniques de ces jeux d’écriture ont vocation à être adoptées et partagées en constituant des communautés de jeux d’écritures. Autour de chaque jeu d’écriture, des communautés de pratiques se constituent (quelles soient disciplinaires, corporatiste ou politiques).

Il y a donc des jeux d’écritures comptables, juridiques, mathématiques, informatiques, etc. À cette perspective selon le point de vue des champs disciplinaires il faudrait rajouter une perspective temporelle. En effet, l’évolution du processus de grammatisation (cf. Les enjeux de la grammatisation des relations) – aujourd’hui à son stade numérique – tend vers des pratiques de plus en plus poussées avec des techniques de jeu d’écriture qui s’automatisent, parfois en « temps réel » comme c’est le cas dans les écritures spéculatives de la finance.

Plus le processus de grammatisation progresse, plus les jeux d’écritures deviennent des puissances effectives. On se rend compte que la « virtualité » du numérique est en fait ce qui opère notre monde via des jeux d’écritures (centrales nucléaires, toutes les formes de transports, et c’est encore plus le cas pour les activités tertiaires des Banques, de la Finance et des Assurances).

Il m’apparaît également que les jeux d’écriture relèvent tous d’une approche algorithmique et en ce sens s’inscrivent dans le « devenir algorithmique » dont j’ai déjà eu l’occasion de parler ces dernières années.

Par ailleurs, les jeux d’écritures sont également des technologies de transfert : de savoirs, de propriétés, de biens. Jamais ces technologies de transfert n’ont été aussi puissantes, c’est ce que l’on perçoit quand on oppose – même si c’est à tort –  l’économie « virtuelle » de la finance à l’économie « réelle » de la production.

L’écriture qui n’est pas simplement un jeu d’écriture, celle de la poésie, de la philosophie, des humanités, de la littérature et des sciences humaines est pourtant plus que jamais nécessaire car c’est de sa richesse et de sa vitalité que naissent des analyses critiques de ces jeux d’écriture, véritable « bras armé » des technologies de transfert.

Related posts:

1. Le code et l’écriture Après la publication de Littérature du code et la lecture...
2. Nous vivons un miracle Le « miracle grec » vient du fait que les techniques d’écriture,...
3. Le devenir algorithmique Le processus de grammatisation décrit par Sylvain Auroux n’est pas...

Je n’ai pas encore regardé le film, mais je viens de terminer la lecture des Sentiers de l’Utopie, un livre-film d’Isabelle Fremeaux et John Jordan.

J’ai beaucoup aimé cette balade parmi quelques hauts lieux de l’Utopie en Europe et cette lecture renforce mon sentiment que pour surmonter la crise que nous vivons, les seules solutions réalistes sont celles qui sont qualifiées d’utopiques!

En 2008 déjà, en lisant les motions déposées pour le congrès de Reims du PS, j’avais été surpris de remarquer que la seule motion qui semblait prendre pleine conscience de l’ampleur de la crise et proposer des solutions proportionnées était la motion “F” du mouvement Utopia.

L’utopie a mauvaise presse : les utopies que l’on a voulu appliquer à grande échelle au vingtième siècle se sont toutes soldées de manière tragique.

Si aujourd’hui les utopies sont les seules à proposer des solutions réalistes, c’est que nous sommes à un moment charnière où pour sauver notre civilisation il nous faut modifier profondément nos habitudes pour instaurer plus d’équité ce qui est habituellement qualifié d’utopiste.

Les Sentiers de l’Utopie nous font découvrir des lieux qui expérimentent, chacun à sa manière, des modes d’interaction différents. Ce ne sont pas des dogmes à suivre aveuglément mais autant de laboratoires dont les découvertes seront précieuses pour trouver des solutions plus générales.

Pour terminer ce billet, deux images glanées hier soir dans un Paris où il allait geler opour la première fois de l’hiver alors que je me rendais à pieds à la conférence de Christian Vélot sur les plantes mutées à la mairie du deuxième arrondissement :

• une terrasse ouverte et chauffée, où l’on chauffe l’extérieur pour que quelques consommateurs puissent déguster une bière à l’extérieur plutôt qu’à l’intérieur.
• à quelques mètres, un sans abri se recroqueville, adossé à un sac à dos pour se préparer à passer la nuit qui sera glaciale.

Un gaspillage inutile de ressources non renouvelables dont les plus démunis sont totalement dépourvu, comment mieux illustrer la crise dans laquelle nous nous enfonçons?

Lire le billet PhotosNormandie a cinq ans – un bilan en forme de FAQ sur Culture Visuelle.... Lire PhotosNormandie a cinq ans – un bilan en forme de FAQ

Lire le billet Unes sur Culture Visuelle.... Lire Unes

Une discussion animée vient d'avoir lieu sur la liste du groupe de travail IETF DANE, qui travaille à permettre l'utilisation de certificats dans le DNS (en simplifiant, il s'agit de remplacer X.509 par DNSSEC, voir mon exposé aux JRES). La question était « Lorsqu'il y a eu des redirections vers un autre nom de domaine, quel nom chercher dans le certificat ? Celui de départ ? Celui d'arrivée ? »

Prenons un exemple concret pour voir. Supposons un protocole nommé PDP (pour Pur Distribution Protocol) qui permet de récupérer des contenus (musique, films, etc) qui avaient été auparavant chargés sur un serveur. Pour trouver le serveur adéquat, mettons que cet hypothétique PDP utilise les enregistrements SRV du DNS (RFC 2782), afin d'assurer la répartition de charge, et la résistance aux pannes. Mettons que le domaine microupload.example ait deux serveurs, on aurait quelque chose comme :

_pdp._tcp.microupload.example.    SRV     0 0 6642  content.example.com.
                                  SRV     1 0 6642  content.backup.example.

Vous y êtes ? Vous avez vraiment cherché ? Bon, alors, maintenant, des éléments de réponse. Le problème du groupe DANE avait été enregistré comme ticket #28 mais, si vous n'avez pas lu le RFC 6394, ce n'est pas trop grave, la question n'est pas du tout spécifique à DANE. Elle a même fait l'objet d'un RFC entier, le RFC 6125, que je trouve personnellement peu lisible. Son principal mérite est de montrer que la question de l'identité n'est pas triviale du tout et qu'elle peut signifier des choses différentes selon la personne.

Et la question n'est pas non plus spécifique aux enregistrements SRV comme dans l'exemple ci-dessus. On aurait la même question, par exemple avec des MX.

Alors, une liste de raisons en faveur du premier choix, utiliser le nom de départ (ici, microupload.example) :

• Le nom de départ est celui que voit l'utilisateur. C'est celui en lequel il a confiance. C'est le nom du service, pas celui du serveur du moment.
• Si la résolution DNS n'est pas sécurisée (par exemple avec DNSSEC), rien ne prouve que le SRV obtenu est légitime. X.509 ne servirait à rien dans ce cas. (Notez que, dans le cas spécifique de DANE, DNSSEC est obligatoire donc, si on décide que le nom utilisé par DANE sera le premier, il sera sécurisé par DNSSEC de toute façon.)

• Dans le cas d'un serveur qui héberge des services pour des milliers de domaines différents, il faudra gérer beaucoup de certificats.
• Il existe plusieurs méthodes pour avoir plusieurs certificats sur la même machine. Si la méthode choisie est de mettre tous les noms dans un même certificat, celui qui se connecte peut apprendre la liste de tous les clients (au sens affaires, pas au sens protocole réseau) du serveur juste en regardant le certificat.
• Dans le cas où le serveur n'est pas géré par la même organisation que le domaine (ce qui est fréquent aujourd'hui), une stricte coordination sera nécessaire. Si le domaine acquiert un nouveau certificat, il leur faudra s'assurer qu'il est bien installé sur le serveur.

Mais, puisque le problème est connu depuis longtemps, que spécifient les différents RFC sur les protocoles qui utilisent TLS ? Eh bien, souvent, ce n'est pas clair. Essayez de lire le RFC 3207 pour voir ce que devrait faire un bon client SMTP, par exemple. Le vocabulaire peu stable du RFC ne permet guère de trancher. L'avis dominant est toutefois que SMTP doit utiliser le domaine d'arrivée. Donc, s'il y a un MX :

michu.example.     IN      MX      10 mail.provider.example

Mais, et c'est là que cela devient amusant, d'autres protocoles ont pu faire des choix différents ! C'est ainsi que XMPP spécifie le contraire, on doit utiliser le domaine du début, avant toute redirection (RFC 6120, section 5.4.3.1). Et pour HTTP ? Ce dernier n'utilise pas d'enregistrement DNS de redirection (comme les MX ou les SRV). Il ne reste donc comme possibilité de piège, au niveau DNS, que les CNAME. Ceux-ci sont délicats car, contrairement aux SRV ou MX, la bibliothèque qui fait la résolution ne donne pas forcément à l'application (ici, le navigateur), une indication sur la présence ou non d'un alias (un enregistrement CNAME). Le RFC 2818 n'est pas parfaitement clair mais semble de toute façon avoir choisi aussi l'approche « domaine de départ » (ici, celui qui est dans l'URI).

Et que va faire le groupe DANE ? La question n'est pas encore définitivement tranchée mais ce sera probablement « chaque protocole se débrouille » car il est trop difficile de spécifier un choix qui convienne à tous.

La Haute-Savoie est unique, notamment en TIC. Mais cela va changer, hélas.

En pointe pour les TIC en général

Le paysage haut-savoyard des TIC est totalement inédit pour les services publics : depuis 1995 (soit plus de 16 ans !) toutes les écoles sont connectées à Internet, comme les collèges, les lycées, les mairies, les bibliothèques, les offices du tourisme, les centres hospitaliers et autres services publics du département. Et cela sur décision du Conseil Général. C'est le CRI 74 (Centre de Ressources Informatiques) qui a assuré cette mission, reprise par le CITIC 74 (Centre de l'Informatique et des Technologies de l'Information et de la Communication) créé en 2007.

C'est une « mission de service public » en tant que « Fournisseur de services internet pour les collectivités » (sic), à laquelle il faut ajouter « Hébergement de sites web et gestion des noms de domaines, Messagerie, Sécurité, Filtrage des spams et des virus, Filtrage des sites web indésirables, Assistance, Développement, Formation, Support et hot-line, Gestion des systèmes d'information scolaires » ! La liste officielle sur la page TIC du site du Conseil Général est impressionnante [1].

Mais fin 2012, ce panorama inédit en France va disparaître. La décision a été officialisée lors de la réunion du Conseil Général des 13 et 14 décembre à propos du budget primitif 2012. L'ordre du jour indique laconiquement : « Dissolution du CITIC 74 au 31 décembre 2012 » (sic) [2]. L'expression est forte. Le point a été traité. La presse locale l'a relaté. C'est acté.

Les écoles, collèges, lycées, mairies, hôpitaux et autres structures publiques connectées vont donc devoir se tourner vers d'autres prestataires, ceux présents dans le département ou ailleurs : fin des services Internet via un service public.

En pointe pour les logiciels libres (et les standards ouverts) en particulier

En Haute-Savoie, l'infrastructure réseau mise en place utilise massivement et délibérément des logiciels libres (et des formats ouverts). L'argent public des financements a donc été investi de manière très importante dans les logiciels libres, avec notamment du développement d'outils propres aux besoins. Ils ont été mis à disposition, comme par exemple le logiciel PingOO, « produit phare du CITIC 74 » (sic). L'action du CITIC pour les logiciels libres a aussi permis d'aider des associations comme Sésamath, Framasoft et quelques autres. Sans oublier des manifestations comme les différentes éditions de LibreEdu qui étaient un rendez-vous important.

Sans le savoir et sans le souligner (hélas), le département est sans doute l'un de ceux en tête des utilisateurs de logiciels libres : tous les habitants de Haute Savoie sont des Monsieur Jourdain du logiciel libre. Ces logiciels ne vont pas disparaître avec le CITIC, y compris ceux développés comme PingOO. Mais leur utilisation n'est pas aussi assurée dans le dispositif qui prendra la suite le 1er janvier 2013. Souhaitons que le grand bébé CITIC ne soit pas jeté avec la neige de son bain.

Merci

Que dire pour finir ? Il ne s'agit pas de remercier pour la décision prise, mais de saluer les personnes du CRI/CITIC qui ont fait vivre ce dispositif totalement à part en France : Cécile Blonay, Directrice de l'actuel CITIC74, Jean-Claude Fernandez, Directeur de l'ancien CRI74, Sébastien Delcroix, Directeur technique du CITIC74, et les équipes de développeurs, de techniciens et d'administratifs. Chapeaux bas et merci !

Le CITIC 74 va mourir, vivent ses logiciels libres : je l'écris avec regret et tristesse.

Sources et liens :

• [1] Page Conseil Général de Haute-Savoie - Les TIC, http://www.cg74.fr/pages/fr/menu-general/les-actions/amenagement-du-territoire/les-tic-309.html
• [2] Invitation presse, format PDF, http://www.cg74.fr/download/site-principal/document/presse/ip/ip_seanceplenierecg74_budget2012.pdf

Le 26 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

D'un côté, l'Assemblée nationale et Xavier Niel, le patron de Free. De l'autre, la société Disney et ses parcs et employés.

Pour chacun, quel est le point commun du 25 janvier 2012 ? Les formats !

Le premier a été auditionné mais ne portait pas de cravate, ni de costume : une petite entorse au code vestimentaire tacite [1]. La seconde a annoncé que le port de la barbe n'est plus interdit aux employés en contact avec le public à partir de début février : une petite révolution dans les critères physique officiels [2].

Dans chaque cas on a donc une apparence au format défini (formatée ?). Un format ouvert plus ou moins fort.

Sources et liens :

• [1] Article Sans cravate ni costume, Xavier Niel déshabille Free à l'Assemblée, de Vincent Hermann, le 25 janvier 2012, http://www.pcinpact.com/news/68547-xavier-niel-commission-assemblee-nationale-questions-defense.htm
• [2] Article Disneyland autorise la barbe, le 25 janvier 2012, http://www.slate.fr/lien/49127/disney-autorise-barbe

Autres articles sur FOo :

• Le format vestimentaire (UBS)
• Le format vestimentaire (Lascaux et Brégançon)
• Un format du beau ?

Le 25 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

Des cartes postales au ton décalé ? Oui, celles des suisses Plonk & Replonk, qui ont un format (ouvert) de détournement de sens et d'images.... C'est ce qui était indiqué dans ce (court !) article de janvier 2010.

Bonne nouvelle : ces Suisses exposent à L'Adresse Musée de La Poste à partir du 26 janvier.

Le 24 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

En avance : telle est de nos jours l'approche du calendrier dans l'actualité. Noël débute en octobre et la rentrée en juillet. C'est aussi le cas des anniversaires qui sont célébrés bien avant la date précise. Ainsi des émissions, des rencontres et des journaux ont marqué les 10 ans de la mort de Pierre Bourdieu dès le début de janvier 2012. Il est pourtant décédé ce 23 janvier.

Et les formats ? Le formatage (des esprits) et le bon format (à avoir, à transmettre) sont des éléments de sociologie. Pierre Bourdieu en a mis en lumière et en a expliqué dans de nombreux domaines (école, art, culture, élite,...) : il les a rendu ouverts.

Le 23 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

Il m'est arrivé quelque chose de curieux avec mon ancienne Freebox, une v5. Elle servait entre autres de borne Wi-Fi. Et tout à coup, son signal Wi-Fi est devenu dix fois plus faible, non captable par beaucoup d'appareils.

Elle avait plusieurs clients différents, par exemple un smartphone HTC Desire, une tablette Packard Bell Liberty Pad, un ordinateur portable Dell, etc. Tous étaient contents et pouvaient se connecter de tout l'appartement. Et, un soir, fini. Le signal avait terriblement baissé. Le smartphone ne voyait plus rien. Plus de Wi-Fi pour lui. La tablette pouvait encore se connecter, mais uniquement lorsqu'elle était dans la même pièce que la Freebox. L'ordinateur portable avait la puce la plus sensible : il y arrivait encore de tout l'appartement, mais avec de fréquentes déconnexions.

Bien que le problème ait frappé tous mes appareils en même temps, j'ai cherché si le problème ne venaient pas d'eux (par exemple, s'il ne fallait pas que j'essaie un autre fichier binaire « radio » sur CyanogenMod pour le smartphone). J'ai aussi tenté de changer le canal Wi-Fi de la Freebox, sans résultat.

Le problème a été résolu lors du remplacement de la Freebox v5 par une v6 Révolution. Tout refonctionne comme avant. C'était donc bien un problème matériel (comme me l'avait suggéré un employé de Free, lors d'une réception officielle prestigieuse). La v5 accusait son (pourtant jeune) âge et ses circuits commençaient à casser.

De quoi philosopher sur la fragilité des engins numériques que nous accumulons chez nous.

Au fait, j'ai renvoyé l'ancienne Freebox à Free (elles ne sont pas vendues mais mises à la disposition de l'abonné). Quelqu'un sait comment prévenir Free qu'elle ne marche pas bien et ne doit donc pas être utilisée ? Sans passer par le support officiel, ses heures d'attente et ses questions débiles « avez-vous rebooté votre ordinateur ? ». Selon @LALIGNEDEFREE, les Freebox de retour sont systématiquement testées et il n'est donc pas nécessaire de signaler un problème.

J'ai obtenu de suggestions intéressantes (mais trop tard pour tester, la boîte étant repartie) :

• De @fuktop13 et de nombreux autres : ce serait un problème d'alimentation électrique. Lorsque celle-ci faiblit, certaines fonctions de la boîte sont plus affectées que d'autres. Il faudrait alors changer ladite alimentation. Le nombre de témoignages reçus (y compris par des employés de Free) me pousse à privilégier cette théorie.
• De @RenaudGuerin, l'idée que ce pourrait être un faux contact avec l'antenne (qui est externe, sur la Freebox v5).
• Jean-Philippe Pick suggère un problème logiciel : le logiciel de la boîte est mis à jour automatiquement au démarrage de celle-ci (je n'ai pas fait attention si cela avait été le cas avant la panne) et une nouvelle version aurait pu avoir des problèmes avec la puce Ralink de la Wi-Fi.

Les 70 ans

Le BCRA a été créé il y a 70 ans : le Bureau central de renseignement et d'action de la France Libre a été mis à l'honneur par l'actuelle DGSE (Direction générale de la sécurité extérieure) créé en 1982 et qui en est issue. Une cérémonie s'est tenue aux Invalides le 17 janvier 2012 pour marquer cet anniversaire. Une action de communication qui tranche avec le format discret logique de ce triple service.

La carte

Autre action, une carte de vœux pour l'année 2012 : elle a été éditée et adressée notamment à des journalistes qui couvrent les questions militaires et de défense (comme Jean-Dominique Merchet). Une carte en ligne sur le site Web mais surtout éditée au format papier, un format ouvert.

Le 22 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

Troisième note sur les Savoirs de l’écriture en Grèce ancienne qui s’appuie sur l’article de Mario Lombardo : “Marchands, transactions économiques, écriture”.

Cette note est également pour moi l’occasion de revenir sur une remarque d’Alain Pierrot formulée lors d’un « Atelier Technologies Relationnelles » consacré à la “Guerre Civile Numérique” ; à une citation de Finley( Les premiers temps de la Grèce) qui faisait remarquer que les Grecs, contrairement à ce qui s’était passé au Proche et Moyen-Orient, se distinguèrent en utilisant l’écriture pour la poésie plutôt que pour le commerce, Alain Pierrot me fit remarquer que le texte de Finley n’était pas de première fraîcheur et que, depuis, l’avancée des travaux rappelait l’importance du commerce dans la diffusion et l’utilisation de l’écriture.

Il se trouve que l’article de Mario Lombardo permet d’enrichir le débat.

Marchands, transactions économiques, écriture

Aristote lui même, en soulignant l’utilité de l’écriture, mentionnait le khrématismos et l’oikonomie : les “affaires” et « l’administration du patrimoine”. Seulement voila, les grecs ont semblé ignorer les fameuses tablettes d’argiles du Proche-Orient et nous n’avons que peu de documents attestant la primauté de l’écriture pour les transactions économiques.

La position de Mario Lombardo consiste à dire que si l’écriture s’est effectivement diffusée via son utilisation économique et commerciale, c’est bien dans les domaines de l’instruction formelle et de la production littéraire d’une part, et , de l’autre, celui du pouvoir politique et des lois”(p. 161) qu’elle s’est développée de manière beaucoup plus significative :

“l’utilisation de l’écriture dans les transactions économiques, et plus généralement dans le domaine économique tout entier, aussi bien public que privé, a somme toute une importance secondaire.” p. 162

L’origine mercantile de l’alphabet

Il faut donc éprouver et ré-interroger la théorie de “l’origine mercantile de l’alphabet”.

Deux raisons à cela. D’une part une raison technologique qui tient à l’écriture alphabétique :

“avec l’extrême simplicité de son répertoire de signes et la transparence (non-ambiguïté) intrinsèque de ses “messages”, liée à l’introduction des signes représentant les voyelles”

D’autre part, deuxième raison à la diffusion de l’écriture en Grèce, le caractère décentralisé de la société grecque :

“ avec leur structures relativement fluides, ouvertes, dépourvues d’instance centrales importantes dans l’organisation politique, économique et religieuse, caractérisée par l’essentiel par l’existence d’une pluralité, plus ou moins articulée et diversifiée, de sujets qui se reconnaissent et s’affrontent en tant que tels dans un espace qualifié, pour cette raison, comme celui d’une communauté.” p.165

Sans nier l’évidence des relations commerciales comme facteur de diffusion de l’écriture alphabétique en Grèce (en référence aux relations commerciale avec les phéniciens qui inventèrent l’alphabet), Mario Lombardo souligne que cette thèse souffre de quelques problèmes, à commencer par le fait que l’écriture grecque n’a pas développée un système numérique avant le VI° siècle, date à partir de laquelle de nombreuses variantes se développèrent certes, mais “qui se situent tous essentiellement à l’intérieur de l’écriture alphabétique grecque et se placent vraisemblablement dans une phase relativement avancée de son histoire.” pp 170-171.

L’argument qui veut que l’écriture se soit développée dans un contexte exclusivement lié aux transactions commerciales semble donc fortement réducteur.

Les “trademarks”

Pour instruire son investigation, Mario Lombardo va s’appuyer sur une pratique bien particulière, à savoir les “inscriptions de propriété” qui constituent la plus grande partie des inscriptions alphabétiques les plus anciennes conservées.

Il s’agit de noms propres, d’abréviation ou de signes, et parfois de formules du genre “j’appartiens à un tel” ou “ceci appartient à” que l’on retrouve sur les amphores commerciales :

“Il n’est peut-être pas hasardeux de voir un rapport significatif entre les premières formes d’utilisation de l’écriture alphabétique, d’une part, et l’émergence et la diffusion d’un “proprietorial concern” ”. p.173

Cette pratique scripturale des “trademarks” était utilisée notamment entre les commerçants et les artisans : le premier notifiait son choix de modèle à produire en marquant de son sceau alphabétique celui-ci. L’écriture joue ici un rôle de repérage et de mémorisation de la commande passée par le commerçant à l’artisan.

Ce qui n’était au départ qu’une simple marque va progressivement s’enrichir. À la signature du commerçant va s’ajouter plusieurs détails : la nature des vases, leur nombre, des indications de prix, etc. Et Lombardo d’en proposer une des fonctions essentielle de l’écriture :

“Il s’exprime ici une fonction fondamentale de l’écriture : la mise en ordre de données hétérogènes, dont la présence dans une pratique scripturale aussi condensée et aussi elliptique renvoie vraisemblablement à l’existence, dans le monde des activités commerciales, de pratiques d’enregistrement de la comptabilité répandues.” p.177

L’inscription de la dette monétaire

Au moins dès 500 avant J.-C. les inscriptions relevant des trademarks font état d’une retranscription des différentes monnaies. Il faut donc prendre en considération la diffusion de la monnaie frappée qui a dû induire des pratiques d’écriture nouvelles. L’examen des documents conservés montrent que le premier emploi de l’écriture se fait “sous la forme de reconnaissances, d’enregistrement et d”’inscription de dette”. On trouve ainsi des plaquettes de plomb, toujours vers 500 av J.-C. qui présentent une structure formelle assez standardisée :

“nom du créancier au datif, avec sa subdivision civique d’appartenance ; nom du débiteur au nominatif ; reconnaissance de la dette (opheilei) ; montant de la dette exprimée quelque fois en chiffres, parfois en lettres, vraisemblablement avec référence implicite à l’unité monétaire courante ; noms des deux témoins.” pp 179-180.

On connaît l’importance des “symbola” objets ou documents divisés en deux et qui fonctionnaient comme des marques de reconnaissance destinées à rappeler les obligations entre deux personnages portant sur des biens (cf. Ph Gauthier, “Symbola, Les étrangers et la justice dans les cités grecques”, Nancy, 1972). Pour les affaires les plus courantes, les symbola suffisait certainement, mais il semble que pour les affaires à la fois plus complexes et plus risquées (transport de marchandise par des voies maritimes peu sûres), l’utilisation de l’écriture joua un rôle décisif qu’il faut mettre en parallèle avec le développement de la monnaie métallique.

Monnaie et jeux d’écriture

La fin de l’article de Mario Lombardo m’a un peu déroutée et j’ai dû m’y reprendre à plusieurs lectures pour y voir plus clair. La cause de ma confusion provenait certainement du manque d’attention aux différences entre “commerce”, “monnaie” et “banque” que je mettais plus ou moins indistinctement sous la catégorie “économie commerciale”.

[Un nom revient dans les références de Lombardo, il s’agit de R. Bogaert avec “Banques et banquiers dans les cités grecques” et “Les origines antiques de la banque de dépôt” (introuvables, alors je vais me rabattre sur “La banque en Occident” )]

L’activité bancaire va se développer en même temps qu’apparaissent des pratiques scripturales qui s’expriment dans la notion de diagraphê :

Quand un banquier reçoit une assignation de l’un de ses clients, il l’indique dans son livre et envoie une note (diagraphê) au bénéficiaire pour l’informer qu’il dispose d’un avoir à la banque. En règle générale, quand il s’y présente, muni de la diagraphê, en vue d’encaisser son dû, il signe pour acquit (hypographê =signature) le document qui demeure en possession de la banque. (Bogaert, La banque en occident, pp 27-28)

Bogaert précise bien que ce n’est qu’après l’apparition de la monnaie (“l’invention des premières pièces métalliques en Occident est l’œuvre des Grecs d’Asie Mineure au VIIe siècle av. J.‑C.” Wikipedia) que la banque va se développer entre le V et le IV° siècle notamment au travers les activités des changeurs de monnaie, les “argyramoiboi”. En effet, ce n’est pas une monnaie mais une multitude de monnaies qui apparaissent et font émerger le besoin de change monétaire. Le changeur est celui qui vend ses services et son expertise en matière de monnaie (connaissance des cours de change, connaissance des différentes monnaie, expertise pour de la fausse monnaie, etc.).

Historiquement, le développement de la monnaie dans l’ensemble des cités Grecques, va donc voir apparaître les “changeurs”, ces derniers vont se retrouver ensuite en situation de trésorerie et pouvoir faire des prêts en faisant travailler l’argent qui ne leur appartient pas. C’est là que l’activité bancaire apparaît : elle était depuis longtemps une activité de prêt et de dépôt mais c’est à ce moment là, en Grêce, quand le changeur commence à faire travailler l’argent des déposants que le Banquier “moderne” apparaît, et avec lui la Banque.

Le syngraphê où le contrat comme technologie de confiance.

C’est ensuite dans le champ de la dette, et plus précisément de la dette monétaire, que l’on constate une utilisation relativement formalisée de l’écriture, donc socialement reconnue. D’abord utilisée pour les besoins des commerçants, dont le banquier Apollodore déclare que la plupart de ses clients – titulaires de comptes de dépôts et de paiement – sont toujours en voyage, et pour des activités commerciales à haut risque liées aux destinations lointaines, on voit apparaître le syngraphé, le contrat écrit.

Le contrat écrit offre de nouvelles garanties qui vont permettre de prendre de nouveaux risques dans les activités du commerce maritime à longue distance et notamment avec des partenaires étrangers. Garanties somme toute “psychologiques” précise Lombardo en rappelant que :

“le dépôt en banque s’effectuait sans que la présence de témoins fut nécessaire, par le simple enregistrement sur les registres bancaires”. p. 184.

La rationalité d’une comptabilité écrite couplée à des contrats va donc être un vecteur progressif de diffusion de l’écriture (diffusion qui est aussi une invention qui modifie les pratiques scripturales). À cette évolution socio-économique fait écho un usage politico-juridique de l’écriture (publication des lois et reconnaissance de dette).

Quoiqu’il en soit, on retiendra que les voies de diffusion et d’évolution des pratiques scripturales sont stimulées par l’invention des monnaies. Avec la monnaie et l’écriture les grecs ont pu :

“compenser et neutraliser le caractère socialement anonyme, la “volatilité” et “l’invisibilité” des rapports d’obligation monétaire.”

L’écriture permettant ainsi au domaine monétaire naissant de répondre aux exigences internes de la communauté socio-politique en mettant de la confiance dans cette nouvelle technologie, constituant par là une technologie de confiance basée sur l’écriture, sur des jeux d’écritures.

Related posts:

1. Les savoirs de l’écriture en Grèce ancienne (2) : Aux origines de la codification écrite des lois en Grèce Deuxième note sur le livre « Les savoirs de l’écriture en...
2. Les savoirs de l’écriture en Grèce ancienne (1) L’espace de la publicité : ses opérateurs intellectuels dans la...
3. La vérité sur l’assassinat de JFK ? La séance d’Ars Industrialis d’hier m’a appris quelque chose de...

Un des principaux mécanismes de gestion de l'espace disque dans PostgreSQL est le tablespace. Un tablespace est un répertoire où on place des données du SGBD. Mais, si on change d'avis, comment changer une base de tablespace ?

La tablespace par défaut d'une base se déclare à la création :

% createdb --tablespace grosdisque experience

=> SELECT datname AS database, spcname AS tablespace, spclocation AS directory 
          FROM pg_database INNER JOIN pg_tablespace 
          ON pg_tablespace.oid = pg_database.dattablespace;
     database      |     tablespace     |   directory   
-------------------+--------------------+---------------
 template1         | pg_default         | 
 essais            | pg_default         | 
 experience        | grosdisque         | /some/where/big
...

Et si on s'est trompé, si on a oublié de mettre la base sur le bon tablespace, si la base a grossi au delà de ce qui était prévu ? Depuis la version 8.4 de PostgreSQL, il existe un moyen simple, la commande ALTER DATABASE :

essais=> ALTER DATABASE experience SET TABLESPACE autreendroit;
ERROR:  database "experience" is being accessed by other users
DETAIL:  There are 1 other session(s) using the database.

(Ah oui, il faut qu'aucune session n'accède à la table, ce qui peut
être contraignant.)

essais=> ALTER DATABASE experience SET TABLESPACE autreendroit;
ALTER DATABASE

Et si on gère une base dans une version antérieure de PostgreSQL, et qu'on ne peut pas migrer ? Rien n'est perdu. Il y a bien sûr la solution « bourrin » d'une commande pg_dump, d'une re-création de la base sur le nouveau tablespace, puis d'un pg_restore. C'est très lent, et cela empêche d'accéder à la base en écriture pendant ce temps.

Une solution plus astucieuse est documentée par Lode : elle utilise le fait que le tablespace n'est pas forcément par base mais peut être configuré par table et qu'il est possible, même avant la version 8.4 de PostgreSQL, de changer une table de tablespace. Le principe est donc :

essais=> ALTER DATABASE experience SET default_tablespace = autreendroit;

(Cette première commande changera le tablespace pour les *futures*
tables.)

essais=> ALTER TABLE premiere_table SET TABLESPACE autreendroit;
essais=> ALTER TABLE deuxieme_table SET TABLESPACE autreendroit;
...

Oui, il faut le faire pour toutes les tables, et pour les index également. Ce n'est pas très pratique. Lode automatisait avec PHP, je préfère le faire avec le shell :

% psql --tuples-only -c 'SELECT tablename FROM pg_tables' experience > tmp/tables
% for table in $(cat tmp/tables); do
   echo $table
   psql -c "ALTER TABLE $table SET TABLESPACE autreendroit;" experience
done

% psql --tuples-only -c 'SELECT indexname FROM pg_indexes' experience >  tmp/indexes
% for idx in $(cat tmp/indexes); do
   echo $idx
   psql -c "ALTER INDEX $idx SET TABLESPACE autreendroit;" experience
done

Après, à vous de voir si cela ne serait pas plus simple de migrer vers un PostgreSQL >= 8.4. Mais les grosses bases de données sont souvent des choses fragiles, avec lesquelles on ne peut pas jouer comme on veut. J'ai récemment utilisé la vieille méthode pour une base qu'il aurait été risqué de migrer.

La 74e Convention internationale des disques de collection (CIDISC), se tient le samedi 21 et dimanche 22 janvier 2012 à l'Espace Champeret.

Disques vinyl 78-tours, 45-tours, 33-tours, voire phonogrammes, Minidisc, LaserDisc, CD audio ou SACD. Avant l'ère des fichiers. Des formats physiques (les supports) et des formats d'enregistrement/codage (l'analogique, le numérique). Avec toujours LA première question : où sont les appareils avec leurs câbles pour lire ces disques ? Et la deuxième question : si on arrive à les lire, les formats numériques sont-ils ouverts ?

Le 21 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

En attendant la publication des photos et vidéos sur le site du Retour à la Terre, voici le texte que j’avais préparé pour mon intervention lors de l’inauguration officielle du magasin de la Rive Gauche le 18 janvier.

Catherine est inquiète parce qu’elle ne sait pas ce que je veux vous dire ce soir…

Elle me connaît pourtant bien puisque cela fait plus de trente ans que nous vivons ensemble !

Nous avons la chance d’avoir étudié dans une grande école (l’École Centrale) où nous nous sommes rencontrés mais avons toujours eu du mal à nous intégrer au monde des grandes entreprises.

Je l’ai devancé en devenant consultant indépendant il y a bientôt quatorze ans.

Lorsqu’elle a souhaité à son tour quitter Renault il y a quatre ans, nous avions un peu d’économies, pas beaucoup parce que l’argent n’a jamais été notre objectif principal mais suffisamment pour acheter par exemple un petit deux pièces dans le quartier où nous habitons.

Nous avons décidé d’utiliser ce petit pécule pour qu’elle puisse mener à bien un projet qui lui tenait à cœur et quatre ans plus tard sommes réunis ici pour inaugurer son deuxième magasin.

Le succès est donc au rendez vous.

Quarante emplois directs (et au moins la moitié d’emplois indirects) ont été crées et des dizaines de milliers de clients ont été sensibilisés aux problèmes environnementaux et ont mangé bio et d’une manière plus responsable.

Je suis très fier de Catherine pour ce succès.

Je suis également heureux de voir qu’elle s’est épanouie professionnellement pendant ces quatre années comme jamais auparavant.

Je le suis un peu moins de la voir fatiguée comme elle ne l’a jamais été.

Quand on rentre dans un des deux magasins du Retour à la Terre, ce que l’on voit peut sembler facile et tomber sous le sens.

Je vis aux côtés de Catherine et je peux vous dire que créer ce cercle vertueux est au contraire un combat de tous les instants :

• Un combat contre les concurrents de la grande distribution et d’autres commerces spécialisés qui n’ont pas les mêmes exigences.
• Un combat contre les fournisseurs quand ils glissent dans leurs catalogues des produits certifiés AB mais contenant des arômes non bio, sur-emballés, pleins d’huile de palme, ou importés de l’autre bout de la planète alors qu’ils poussent chez nous.
• Un combat contre les clients qu’il faut éduquer et à qui il faut expliquer pourquoi ils ne trouveront chez nous ni tomates, ni litchis ni foie gras pour leurs réveillons.
• Un combat au sein de la coopérative Biocoop pour essayer de maintenir une ligne aussi droite que possible.
• Et parfois même un combat au sein de l’équipe qu’il faut convaincre que le magasin doit être impeccablement tenu, qu’il vaut mieux faire 40 commandes à 40 petits producteurs qu’une seule commande à un industriel et parfois même pourquoi travailler plus pour gagner plus n’est pas une bonne idée et pourquoi seule Catherine et dans une moindre mesure nos deux directeurs de magasin peuvent faire des heures supplémentaires au Retour à la Terre.

Je sais que ce type de combat est chose courante pour beaucoup de nos invités.

Insecticides, plastiques, déchets, cancers, OGM, brevets sur le vivant, grande distribution, industrie de la viande, villes en transition, paysans sans terre, nucléaire, gaz de schiste, … au cours des débats organisés par Catherine, je me suis souvent senti dérouté et découragé par la diversité de ces luttes.

Il y a pourtant une constante : le refus de la marchandisation des biens communs de l’humanité.

Prenons par exemple le problème de l’eau, particulièrement éloquent parce qu’il représente un combat que beaucoup considèrent comme déjà perdu.

L’eau est essentielle à la vie, elle recouvre 72% de notre planète et notre corps est composé d’eau à 65%.

Pourtant, vous souvenez vous quand vous avez bu pour la dernière fois de l’eau qui ne soit pas « produite » par une des multinationales qui se sont emparé de son « marché » ou par une des rares compagnies des eaux qui soit publique ?

Pour moi, c’était en juillet dernier, en randonnée avec notre fils Samuel à plus de 2000m d’altitude dans les Alpes.

Et même dans un endroit aussi préservé, il nous a fallu filtrer l’eau des torrents de montagne dans un filtre en céramique, merveille de haute technologie suisse, pour la boire sans risque.

Cet accaparement de l’eau, des semences, de la nourriture, des terres, du sous sol, des idées, des déchets, de l’énergie, des logiciels, des données privées, de l’argent, … et même du « droit à polluer » par quelques privilégiés qui contrôlent une poignée de multinationales est intolérable sur le plan des principes, mais aujourd’hui il ne s’agit plus ce cela.

Le problème est pourtant simple.

Nous sommes 7 milliards sur une planète aux ressources finies qui ne peut nourrir sa population de manière durable que si ses ressources sont exploitées de manière raisonnable et distribuées avec un minimum d’équité et c’est précisément de cela dont il s’agit pour chacun de ces combats.

Combattre les dérives actuelles sous toutes leurs formes n’est plus seulement une question de principes mais une question de survie pour nous et pour notre civilisation !

Merci à tout ceux qui mènent cette lute essentielle à leur manière et sur tous les fronts.

Ce mercredi 18 janvier 2012, Formats-Ouverts.org s'associe (à sa petite échelle) aux protesations contre les lois SOPA et PIPA envisagées aux USA.

Pour protester contres ces lois, le site Wikipedia en anglais est en blackout toute la journée et explique pourquoi (en anglais), comme Identi.ca. Et Framablog explique aussi la situation (en français) : si ces lois étaient votées, elles « endommageraient gravement l’Internet libre et ouvert ». Ce dernier repose sur des standards ouverts.

Le 18 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

PAS de SOPA ni de PIPA !

Le 17 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

Un court RFC pour un format simple : le type MIME multipart/report permet d'envoyer des rapports structurés au sujet d'un message. Ce RFC est la dernière version de la norme sur multipart/report, marquée par un léger allègement des règles d'utilisation.

Pas de grands changements, sinon. L'idée de base de multipart/report est de pouvoir faire des messages à propos des messages. Par exemple, un avis de non-remise (RFC 3461) est un message disant qu'un message n'a pu être remis, et intégrant le message originel. Un rapport ARF (RFC 5965) est un message disant qu'un message est abusif (spam, par exemple) et intégrant également le message originel. D'où l'idée d'avoir un type commun pour tous ces « messages sur les messages », et c'est multipart/report, normalisé dans notre RFC 6522, qui succède au RFC 3462 (qui succédait lui-même au RFC 1892). Ce type multipart/report est très largement utilisé depuis longtemps, et par de nombreux logiciels.

La présentation détaillée du type « rapport » figure en section 3. Voici d'abord un exemple d'un tel message, ici pour indiquer une non-délivrance, généré par un MTA Postfix :

Date: Wed, 11 Jan 2012 13:45:44 +0000 (UTC)
From: MAILER-DAEMON@bortzmeyer.org (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: bortzmeyer@nic.fr
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
        boundary="154CD3AC2C.1326289544/mail.bortzmeyer.org"
Content-Transfer-Encoding: 8bit

This is a MIME-encapsulated message.

--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

[La première partie du rapport, lisible par un humain.]

This is the mail system at host mail.bortzmeyer.org.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Delivery report
Content-Type: message/delivery-status

[La deuxième partie du rapport, conçue pour être analysée par des
programmes.]

Reporting-MTA: dns; mail.bortzmeyer.org
X-Postfix-Queue-ID: 154CD3AC2C
X-Postfix-Sender: rfc822; bortzmeyer@nic.fr
Arrival-Date: Wed, 11 Jan 2012 12:24:50 +0000 (UTC)

Final-Recipient: rfc822; nothere@nowhere.example
Action: failed
Status: 5.4.4
Diagnostic-Code: X-Postfix; Host or domain name not found. Name service error
    for name=nowhere.example type=AAAA: Host not found

--154CD3AC2C.1326289544/mail.bortzmeyer.org
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

[Puis le message originel, dans la troisième partie du rapport.]

Notez surtout le découpage en trois parties (la dernière est optionnelle) :

• Une partie qui contient un message en format libre et en langue naturelle.
• Une partie structurée (dans l'exemple ci-dessus, avec la syntaxe message/delivery-status du RFC 3464).
• Le message originel.

Si on trouve le message originel trop gros, la troisième partie peut se composer uniquement des en-têtes du message. Elle aura alors le type message/rfc822-headers (section 4 de notre RFC).

Naturellement, les messages multipart/report ne sont pas plus authentifiés que les autres messages : il faut donc éviter d'agir automatiquement lors de leur réception (section 7).

Le seul changement de fond depuis le RFC 3462 concerne une ancienne restriction : multipart/report ne pouvait apparaître qu'au plus haut niveau du message (rappelez-vous que MIME est récursif, un message MIME peut contenir d'autres messages MIME). Cela interdisait, par exemple, de faire un multipart/report au sujet d'un multipart/report. Il semble bien que personne ne mettait en œuvre cette restriction et ce nouveau RFC 6522 l'a donc supprimé. (Voir section 1.)

PAS de SOPA ni de PIPA !

Le 16 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

PAS de SOPA ni de PIPA !

Le 15 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

Deuxième note sur le livre « Les savoirs de l’écriture en Grèce ancienne » avec l’article de Giorgo Camassa.

Aux origines de la codification écrite des lois en Grèce

L’utilisation de l’alphabet en Grèce ancienne concerne une multiplicité d’activités, rappelle Giorgio Camassa : mais pour quelle raison les anciens grecs ont-ils fixé par écrit les codes de la lois ?

Ce qui est pour nous évident aujourd’hui – que législatif et écriture aillent de pair – n’a pas toujours été le cas. Alors où, dans quel lieu, les premières lois écrites furent-elles rédigées ?

Il semble y avoir un consensus sur l’idée que l’oeuvre de codification des lois aurait plutôt eu lieu dans les colonies que dans les métropoles. Et d’ailleurs “nomos” (la loi) dérive de la même racine que “nemein” (distribuer, répartir, allouer,..) : on s’imagine que la nécessité de répartir les terres entre les colons fut une motivation première pour écrire les lois, c’est à dire écrire les répartitions.

Mais en se focalisant trop tôt sur les colonies grecques, n’oublie-t-on pas trop vite la Crête dont il nous reste un nombre d’inscription juridique beaucoup plus nombreux que n’importe quelle région de la Grèce ?

Pour Giorgio Camassa, le cas de la Crête n’est pas convoqué pour lui attribuer une quelconque paternité dans l’écriture des lois, mais plutôt pour souligner que cette nouvelle écriture fut en Crête précédée et accompagnée par l’existence d’un corpus de lois transmises oralement. Camassa rappelle que, pour lui, l’existence d’une transmission orale d’un corpus législatif est la condition sine qua non pour la fixation précoce d’un code de loi écrites.

Les pratiques orales de législation sont elles-même baignées d’une culture poétique et lyrique :

Il semble en effet difficile de se soustraire à la suggestion qu’en Crête, plus clairement qu’ailleurs, l’art de la législation était inséparable de la précellence de la parole rythmique, capable de forger l’âme, grâce à ses pouvoirs évocateurs et psychagogiques, mais capable aussi d’intervenir activement sur la réalité en la transformant” p.145

C’est seulement dans le cadre d’une culture législative orale que, lentement et non à travers une crise :

“l’opinion publique citoyenne, forte de tout son poids, demanda avec insistance un plus grand contrôle sur le système jurique par l’intermédiaire de la publication des lois”. The Local Scripts of Archaic Greece, Oxford, 1961, p.43

Après la question du lieu, vient la question du comment : comment s’est opérée cette transition ?

Dans une tradition orale, la perception de la loi par les individus est quelque chose d’absolu et d’immuable : les modifications sont imperceptibles et “la loi d’une génération ne peut pas être mise en comparaison avec celle d’une autre”.

Mais, même une fois écrite, la loi reste associée à son caractère immuable, et partout en Grèce et jusqu’à Aristote se manifeste l’hostilité au changement des lois établies.

N’y a-t-il pas là un paradoxe :

“au moment-même où, avec le début d’une codification écrite, s’ouvre la voie, d’abord, à la perception et, ensuite, à la pratique du changement, on se préoccupe immédiatement d’éviter ce dernier”. p.149

Giorgio Camassa y voit la force du conditionnement exercé par la prédominance de la culture orale au sein même de la période écrite qui s’ouvre. Ce qui est une manière pour lui d’articuler tradition orale et tradition écrite sans avoir a postuler la nécessité de l’écriture pour autoriser l’oeuvre du législateur.

Et d’ailleurs, l’écriture elle-même n’était-elle pas destinée à être vue plus qu’à être réellement lue ? Comme le rappelle Marcel Détienne, l’écriture pénètre dans l’espace public en se montrant et en s’affichant :

“Gravés sur les édifices publics ou sur les stèles placées dans les lieux ou se déroulait la vie communautaire, les codes sont de clairs exemples d’une écriture destinée à être vue plutôt que lue”. p.151

Related posts:

1. Les savoirs de l’écriture en Grèce ancienne (1) L’espace de la publicité : ses opérateurs intellectuels dans la...
2. Les savoirs de l’écriture en Grèce ancienne (3) : Marchands, transactions économiques, écritures Troisième note sur les Savoirs de l’écriture en Grèce ancienne...
3. Le stade anal de l’écriture Faites l’expérience suivante la prochaine fois que vous irez sur...

PAS de SOPA ni de PIPA !

Le 14 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

Le samedi 14 janvier, le CRANS organisait une install party à l'ENS à Cachan. J'y ai fait un exposé sur le thème « Peut-on se passer de moteurs de recherche ? ». Toutes les informations sont disponibles sur le site officiel (la vidéo devrait y apparaître un de ces jours).

L'introduction est « Aujourd'hui, beaucoup d'utilisateurs dépendent entièrement d'un moteur de recherche pour toute navigation sur l'Internet. On entend même des enseignants de collège dire aux élèves « Pour aller sur Wikipédia, tapez "wikipedia" dans Google » Pourquoi est-ce une mauvaise idée ? Quels sont les inconvénients des moteurs de recherche ? Que se passe-t-il lorsqu'une panne ou la censure modifie le résultat d'une recherche ? Quels sont les points forts des moteurs de recherche, où ils sont utiles ? À quoi sert le DNS et pourquoi est-ce important de comprendre les noms de domaine ? »

Les transparents sont disponibles :

• Version adaptée à l'écran,
• Version adaptée à l'impression,
• Source en LaTeX/Beamer.

Et, si vous n'avez pas pu venir, ce n'est pas grave, Norman a fait une excellente vidéo sur le sujet, « Maintenant, j'ai Google ».

PAS de SOPA ni de PIPA !

Le 13 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

PAS de SOPA ni de PIPA !

Le 12 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

PAS de SOPA ni de PIPA !

Le 11 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

PAS de SOPA ni de PIPA !

Le 10 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

PAS de SOPA ni de PIPA !

Le 9 janvier sur Formats-Ouverts.org :

• en 2011, en 2010, en 2009, en 2008, en 2007, en 2006 et en 2005.

La sortie, le 30 décembre 2011, du décret n° 2011-2122 relatif aux modalités d'arrêt de l'accès à une activité d'offre de paris ou de jeux d'argent et de hasard en ligne non autorisée, décret qui permet à l'ARJEL de demander le blocage d'un site de paris ou de jeux en ligne, a ramené sur le devant de la scène la question du blocage via le DNS. En effet, le décret dit explicitement « Lorsque l'arrêt de l'accès à une offre de paris ou de jeux d'argent et de hasard en ligne non autorisée a été ordonné, [...] les [FAI] procèdent à cet arrêt en utilisant le protocole de blocage [sic] par nom de domaine (DNS) ». Il existe plusieurs façons de comprendre cette phrase. Si le FAI décide de mettre en œuvre cet arrêt en configurant ses résolveurs DNS pour mentir, un moyen simple de contourner cette censure sera alors pour les utilisateurs de changer de résolveur DNS. Est-ce simple ? Est-ce réaliste ? Des logiciels peuvent-ils aider ?

D'abord, un petit rappel de vocabulaire, car j'ai déjà lu pas mal d'articles sur le sujet, où l'auteur est plein de bonne volonté et veut vraiment aider les autres à contourner la censure, mais où il ne connait pas vraiment le DNS et où il utilise un vocabulaire approximatif, voire complètement faux. Il y a deux sortes de serveurs DNS : la première, ce sont les serveurs faisant autorité, qui sont ceux qui contiennent les données (par exemple, les serveurs de DENIC ont la liste de tous les noms de domaine en .de, des serveurs de la société NS14 font autorité pour le domaine shr-project.org, etc). L'ARJEL ou un autre censeur ne peut pas toujours agir sur eux car ils peuvent être situés en dehors de la juridiction française.

Et il y a les résolveurs DNS. Ils ne connaissent au démarrage aucune donnée et servent uniquement de relais et de caches (stockage temporaire de données). Ils sont typiquement gérés par votre FAI ou bien par le service informatique de votre boîte. Ce sont eux qui sont indiqués à la machine cliente (en général par le protocole DHCP), qui les utilisera à chaque fois qu'elle aura une question (c'est-à-dire pas moins d'une centaine de fois pour la seule page d'accueil de CNN).

Si on veut censurer en France l'accès à un site de jeu en ligne, par le protocole DNS, c'est un bon endroit pour attaquer. Il en existe d'autres, mais que je garde pour d'autres articles. Modifier le comportement du résolveur est facile (les logiciels ont déjà ce qu'il faut pour cela) et certains FAI le faisaient déjà pour des raisons financières.

Mais c'est aussi une technique de censure relativement facile à contourner : l'utilisateur de la machine cliente peut changer la configuration de son système pour utiliser d'autres résolveurs que ceux de son FAI, par exemple ceux de Telecomix, qui promettent de ne pas censurer. C'est cette technique qui est discutée dans cet article.

Si vous lisez les forums un peu au hasard, vous trouverez souvent des allusions à cette méthode, de la part de geeks vantards qui affirment bien haut « rien à foutre de leur censure à la con, je change mon DNS car je suis un top-eXpeRz et je surfe sans filtrage ». La réalité est plus complexe. Prenons l'exemple d'une machine Ubuntu (il y a peu près les mêmes problèmes sur Windows ou Mac OS X). La liste des résolveurs DNS utilisés figure dans le fichier /etc/resolv.conf. Suffit-il d'éditer ce fichier, comme on le lit souvent (et bien à tort) ?

• Déjà, il faut rappeler au frimeur de forum que la grande majorité des utilisateurs de l'Internet n'ont même pas idée qu'ils peuvent choisir (et je ne parle pas seulement du résolveur DNS, mais aussi du navigateur, du système d'exploitation, etc). Si on veut que la solution soit accessible à tout le monde, pas seulement à quelques geeks auto-proclamés, elle doit être simple.
• Même sur Ubuntu, tout le monde ne sait pas éditer un fichier système (surtout qu'il faut être root).
• Le frimeur à grande gueule qui écrit sur forum.blaireaux.com/index.php découvrira vite, s'il essayait ce qu'il prêche, qu'éditer resolv.conf n'est pas la bonne méthode, car le client DHCP effacera ses modifications à la prochaine connexion. Il faut modifier la configuration dudit client DHCP (cela varie énormément selon le système et le logiciel installé ; sur ma Debian, en ce moment, c'est /etc/resolvconf/resolv.conf.d/head).
• Sur certains systèmes d'exploitation, changer un réglage aussi banal est très difficile. Par exemple, sur Android (merci à Aissen pour les informations), les serveurs DNS utilisés sur le réseau mobile ne sont pas modifiables et, sur le Wi-Fi, on ne peut les changer que si on coupe DHCP. Comme la publicité fait tout son possible pour migrer les utilisateurs vers les accès Internet sur téléphone mobile, bien plus contrôlés et moins libres, l'avenir est inquiétant.
• Une fois qu'on sait quel fichier éditer et comment, reste la question, que mettre dans ce fichier ? Il existe plusieurs résolveurs publics situés en dehors du pouvoir de l'ARJEL, et le plus souvent cité est OpenDNS. Intéressant paradoxe : pour échapper à la censure et garder sa liberté de citoyen, on utilise un résolveur menteur, qui pratique lui-même la censure (et parfois se trompe). Utiliser OpenDNS, c'est se jeter dans le lac pour éviter d'être mouillé par la pluie. Sans compter leurs autres pratiques, comme l'exploitation des données personnelles (le résolveur DNS utilisé sait tout de vous... chaque page Web visitée lui envoie au moins une requête...). À noter qu'on peut avoir aussi un résolveur local à sa machine, ce point est traité un peu plus loin.

Pour résoudre tous ces problèmes, on peut écrire des documentations (exemples à la fin de cet article). Mais la plupart des utilisateurs auront du mal à les suivre et je pense donc que la bonne solution est la disponibiité d'un logiciel qui automatise tout cela. Quel serait le cahier des charges d'un tel logiciel ?

• Tourne sur les systèmes utilisés par M. Toutlemonde (Windows, Android, Ubuntu, etc).
• Indépendant de l'application (le DNS ne sert pas que pour le Web) et marche donc avec tous les services (c'est pourquoi je n'ai pas discuté dans cet article des extensions Firefox comme MAFIAAFire ou DeSOPA - ce dernier ayant en outre un mode de fonctionnement très bizarre).
• Simple à utiliser.
• Vient avec une liste pré-définie de bons résolveurs. Je préférerais que cette liste n'inclue pas les résolveurs menteurs comme ceux d'OpenDNS. En tout cas, il est impératif qu'on puisse ajouter les résolveurs de son choix.
• M. Toutlemonde va certainement avoir des problèmes pour décider s'il doit se servir de « Telecomix » ou « Comodo » ou « Level-3 » pour ne citer que quelque uns des résolveurs publics les plus fameux. Il faudrait donc que le logiciel teste ces résolveurs automatiquement, pour leurs performances, bien sûr (la plupart des articles trouvés sur le Web sur le thème « comment choisir son résolveur DNS ? » ne prennent en compte que leur vitesse, pas leur sincérité, contrairement à cet article) mais aussi pour leur obéissance à la censure. Le logiciel devrait venir avec une liste de domaines peut-être censurés (wikileaks.org, etc) et tester les réponses des résolveurs candidats. Ce n'est pas facile à faire car il faut aussi connaître les bonnes réponses, et elles peuvent changer. Peut-être le logiciel devrait-il interroger des résolveurs de confiance pour avoir cette information ? Le fait de tester pourrait même permettre de choisir automatiquement un résolveur, ce qui serait certainement meilleur pour M. Toutlemonde.
• Autre cas vicieux (merci à Mathieu Goessens), celui des résolveurs DNS qui, en violation des bonnes pratiques, contiennent des données spécifiques qu'on ne trouve pas dans le DNS public. C'est le cas de pas mal de portails captifs de hotspots, par exemple. dnssec-trigger gère ce problème en ayant un mode spécial, manuellement activé, « Hotspot sign-on ». Mais il y a pire : certains FAI (notamment Orange) utilisent des données non publiques pour certains services réservés aux clients (VoIP, serveur SMTP de soumission, etc) donc une solution qui gère la connexion initiale ne suffit pas. La seule solution dans ce cas est d'avoir un mécanisme d'aiguillage qui envoie les requêtes pour certains domaines à certains résolveurs.

Compte-tenu de ce cahier des charges, quels sont les logiciels qui conviennent aujourd'hui ? Il n'en existe aparemment qu'un seul, DNS Jumper (je ne suis pas sûr d'avoir mis un lien vers le site officiel, ce logiciel n'a pas de références bien précises et, son source n'étant pas distribué, on peut être inquiet de ce qu'il fait). DNS Jumper tourne sur Windows, assure les quatre premières fonctions de mon cahier des charges mais pas l'avant-dernière : il ne vérifie pas que le résolveur est digne de confiance. Il est décrit, par exemple, dans « Easily Switch Between 16 DNS Servers with DNS Jumper » (l'article est un peu ancien, le logiciel s'est perfectionné depuis), ou, en français, dans « DNS Jumper - Changez rapidement de serveurs DNS ».

Les autres logiciels restent à écrire (un truc comme DNS Helper ne compte pas, puisqu'il ne permet de changer... que pour les DNS de Google). Mais que les censeurs ne se réjouissent pas, les logiciels vont vite sortir, écrire un tel programme n'est pas un exploit technique, et la demande est forte, avec le décret ARJEL déja cité pour la France, SOPA pour les États-Unis, etc.

Sur le problème général de changer manuellement ses résolveurs DNS, un bon article est « How to Change DNS Server » de Remah (Windows seulement).

Quelques petits détails techniques pour finir : on peut parfaitement installer un serveur DNS résolveur sur sa propre machine (enfin, sur un ordinateur portable, pas sur un smartphone). La résolution DNS sera alors entièrement sous le contrôle d'un logiciel qu'on gère, fournissant ainsi le maximum de sécurité. Le processus n'est pas très compliqué sur Unix, ni même sur Windows (merci à Gils Gayraud et Mathieu Bouchonnet pour leur aide sur Windows). On peut le rendre encore plus simple avec des logiciels astucieux comme dnssec-trigger, qui ne teste pas la censure (son but est tout autre) mais pourrait servir de point de départ à un paquetage simple d'installation, vraiment utilisable par M. Toutlemonde (ce n'est pas encore le cas). Par contre, un tel résolveur local a des conséquences négatives sur l'infrastructure du DNS : comme il n'y a plus de cache partagé (avec le résolveur/cache du FAI, une requête pour www.bortzmeyer.org reste en mémoire et bénéficie à tous les clients du FAI), les serveurs faisant autorité verront leur charge s'accroître.

Pour éviter cet inconvénient, une des solutions serait pour le résolveur local de faire suivre les requêtes aux résolveurs du FAI (de tels résolveurs sont nommés forwarders). Mais cela implique de détecter lorsque le résolveur du FAI ment, pour le court-circuiter dans ce cas. DNSSEC fournit une piste intéressante pour cela mais, début 2012, les résolveurs ayant cette fonction forwarder (BIND et Unbound) n'ont pas de tel service de détection et de contournement.

Pire encore, on peut combiner le résolveur local (ou le remplacer) avec des fichiers statiques locaux (/etc/hosts sur Unix, C:\WINDOWS\system32\drivers\etc\hosts sur Windows) mais la maintenance de tels fichiers serait un cauchemar.

Cela ne veut pas dire que cela n'arrivera pas : dans ce maelstrom d'attaques et de contre-attaques, les solutions les plus mauvaises seront certainement déployées par certains acteurs et le futur est sombre pour le système de résolution de noms.

Pour limiter certains risques de sécurité, des opérateurs réseaux filtraient en entrée de leur réseau les adresses IP non encore allouées (dites bogons). Les adresses IPv4 étant désormais totalement épuisées, cette pratique n'a plus lieu d'être et ce RFC demande donc que ces filtres soient démantelés.

L'idée était d'empêcher l'usage de ces préfixes IP non alloués. Ils représentaient des cibles tentantes, par exemple pour un spammeur qui voulait des adresses jetables et non traçables : on trouve un bloc non alloué, on l'annonce en BGP (puisqu'il n'est pas alloué, il n'y a pas de risque de collision), on envoie son spam et on arrête l'annonce BGP (voir les articles cités à la fin). Pour éviter cela, et d'autres attaques analogues, l'habitude s'est prise de filtrer les bogons, ces préfixes non alloués. Certains opérateurs rejetaient les annonces BGP pour ces bogons, d'autres bloquaient sur le pare-feu les paquets ayant une adresse source dans ces préfixes non alloués. Ces pratiques étaient largement documentées par exemple sur le site de référence sur les bogons.

Cette pratique a toujours posé des problèmes, notamment celui de la « débogonisation ». Lorsqu'un préfixe qui n'était pas alloué le devient, il faut toute une gymnastique pour le retirer des filtres existants, sachant que beaucoup de ces filtres ne sont que rarement mis à jour. On voit ainsi des messages sur les listes de diffusion d'opérateurs réseaux avertissant de l'arrivée prochaine d'un nouveau préfixe et demandant qu'il soit supprimé des filtres. Voici deux exemples de ces annonces en 2004 et en 2005. Pour permettre aux opérateurs de tester que tout va bien après cette suppression, les RIR mettent souvent un beacon, un amer, dans le préfixe, une adresse IP qu'on peut pinguer pour tester, comme le recommande le RFC 5943. Tout ce travail faisait donc que la chasse aux bogons était contestée depuis longtemps.

À noter (section 2) que le terme de bogon a été défini dans le RFC 3871, qui recommande leur blocage. Ce même RFC 3871 décrit en détail le problème que posent les bogons et la raison de leur éradication. Le terme de martien, plus flou (il vient du RFC 1208), est appliqué à toutes sortes de paquets dont l'adresse source est anormale (dans le DNS, il a un autre sens, celui de paquet de réponse à une question qui n'a pas été posée).

La section 3 représente le cœur du RFC : elle formule la nouvelle règle. Celle-ci, tenant compte de l'épuisement des adresses IPv4 est simple : tous les préfixes IPv4 sont désormais alloués ou réservés. Il ne faut donc filtrer que les réservés. Les autres peuvent désormais tous être une source légitime de trafic IP. La chasse aux bogons et les difficultés de la débogonisation faisant partie du folklore de l'Internet depuis très longtemps, c'est donc une page d'histoire qui se tourne. (Les adresses IPv6 sont, elles, loin d'être toutes allouées et ne sont donc pas concernées.)

La section 4 rappelle que l'autorité pour cette liste de préfixes réservés est le RFC 5735, ou son éventuel futur successeur. On y trouve par exemple les adresses privées du RFC 1918 ou bien les adresses réservées à la documentation du RFC 5737. Les listes de bogons qu'on trouve sur le réseau, comme celle de TeamCymru sont désormais réduites à ce groupe.

À noter que l'assertion « Tous les préfixes sont désormais alloués » ne vaut que pour les préfixes de longueur 8 (les « /8 ») distribués aux RIR. Certains peuvent filtrer à un niveau plus fin, en distinguant dans ces /8 les adresses que les RIR ont affectés de celles qui ne le sont pas encore. Comme le rappelle la section 3.2, cette pratique est risquée, les affectations par les RIR changeant vite. Le RFC demande donc que, si on a de tels filtres, ils soient changés au moins une fois par jour.

Pour en apprendre plus sur les bogons, on peut regarder la bonne analyse faite par BGPmon. On voit finalement peu d'annonces BGP de bogons (6 seulement en 2011), la plupart pour le préfixe 198.18.0.0/15 des mesures de performance (RFC 5735). Un bon résumé des bogons et de la débogonisation avait été fait par Dave Deitrich en 2005.

Quelques articles sur les trucs utilisés par des méchants (spammeurs, par exemple), en connexion avec les bogons :

• « Understanding the network-level behavior of spammers » par Anirudh Ramachandran (Georgia Tech) et Nick Feamster (Georgia Tech). Très bonne analyse technique des trucs réseaux utilisés par les spammeurs. C'était le première article à mettre en évidence le truc d'annoncer en BGP des préfixes bogons, d'envoyer le spam, puis d'arrêter l'annonce BGP.
• « Practical BGP Security: Architecture, Techniques and Tools » (page 3)
• Le premier témoignage, en 2002.

Voici la vidéo ( 45 min) de l’intervention d’Alain Giffard lors d’une séance de travail du groupe « Technologies Relationnelles » d’Ars industrialis.

La séance était consacrée à la « guerre civile numérique » et il m’a semblé que les propos d’Alain Giffard étaient précieux pour re-contextualiser ce concept de guerre civile numérique qui reprend le titre d’un ouvrage de Paul Jorion paru en Mai 2011 :

Related posts:

1. Morceaux choisis de la séance publique Ars Industrialis avec Paul Jorion Quatre vidéos choisies de la rencontre au théâtre de la...
2. Le numérique dans l’économie et la cognition de l’attention C’est le titre du prochain débat d’Ars Industrialis qui aura...
3. Les techniques de soi : séance publique d’Ars Industrialis du 19 Juin 2010 Voici les vidéos de la séance sur les techniques de...

Lorsqu'on effectue une mesure active sur un réseau informatique, un agent de mesure vise une cible distante connue, et le résultat de ce test nous servira à en déduire les performances du réseau. Comment nommer cette cible ? En français, les deux termes les plus courants semblent amer et mire.

Un exemple d'un tel test est l'utilisation d'une simple commande ping :

% ping -c 3 www.arcep.fr
PING www.arcep.fr (81.200.177.80) 56(84) bytes of data.
64 bytes from bastet.publicis-technology.com (81.200.177.80): icmp_req=1 ttl=51 time=74.8 ms
64 bytes from bastet.publicis-technology.com (81.200.177.80): icmp_req=2 ttl=51 time=70.3 ms
64 bytes from bastet.publicis-technology.com (81.200.177.80): icmp_req=3 ttl=51 time=73.0 ms

--- www.arcep.fr ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 70.399/72.760/74.808/1.826 ms

Le premier terme, amer, vient de la navigation maritime et désigne normalement un repère fixe et connu, sur lequel l'équipage d'un bateau peut faire des tests. C'est une jolie origine et ça fait penser aux pirates, donc ça embête la HADOPI, ce qui est très bien. C'est le terme privilégié dans ce blog.

Le second mot, mire, vient de la géodésie (et n'a rien à voir avec la mire de l'ORTF). Il est utilisé par exemple par l'ARCEP (voir sa consultation publique lancée fin 2011, question n° 19).

On pourrait sans doute trouver encore d'autres candidats comme balise.

Et en anglais ? Contrairement à ce qui arrive souvent en informatique, la situation n'y est pas meilleure. On trouve parfois beacon mais qui, dans le domaine des réseaux informatiques, désigne plus souvent un système qui émet spontanément (au lieu de simplement répondre à une sollicitation), comme par exemple les beacons BGP du RIPE. Dans les RFC, on trouve souvent simplement target, que je trouve trop militaire, ou bien landmark, qui est quasiment l'équivalent d'amer.

Si l'ARJEL est moins connue des internautes que l'HADOPI, les gens qui suivent de près l'actualité de l'Internet savent qu'elle est à la pointe de la censure, ayant été la première organisation en France à ordonner le bloquage de sites Web aux FAI. Mais dans quels buts ?

Après l'affaire Stan James, qui avait fait connaître l'ARJEL aux internautes, cette organisation vient de récidiver avec un décret (« n° 2011-2122 du 30 décembre 2011 relatif aux modalités d'arrêt de l'accès à une activité d'offre de paris ou de jeux d'argent et de hasard en ligne non autorisée ») qui impose aux FAI de bloquer l'accès aux sites de jeux d'argent en ligne listés par ladite ARJEL. Sur le moment, les commentateurs ont surtout noté que ce décret était le premier texte de censure à mentionner explicitement le DNS et à l'imposer comme mécanisme de blocage.

Mais cette remarque, quoique factuellement exacte, ne répond pas à la question « pourquoi faut-il bloquer l'accès à ces sites ? ». On le fait pour la pédo-pornographie (loi LOPPSI qui, en théorie, limite la censure à cette raison), ou pour défendre le modèle d'affaires des ayant-trop-de-droits (dans le contexte de la loi HADOPI, même si celle-ci ne mentionne pas explicitement de censure). La pédo-pornographie, c'est grave, aucun doute là-dessus. Même chose sur la baisse des revenus de l'industrie du divertissement. C'est très grave et il faut réprimer impitoyablement ceux qui voudraient partager la culture.

Mais l'ARJEL, qui ne s'occupe pas de pédo-pornographie ou de show business, pourquoi veut-elle censurer ? Parce que les jeux d'argent sont immoraux, avec la pression qu'ils exercent sur les plus faibles, pour les pousser à jeter leur argent en l'air dans des jeux qui ne leur rapportent rien, que des déceptions ? Mais non, voyons, ce n'est pas la raison, puisqu'il existe des jeux légaux. Prendre l'argent dans les poches des plus vulnérables a été pendant longtemps un monopole de la Française des Jeux mais, désormais, d'autres acteurs peuvent participer. À condition de verser une part des revenus de leur sale métier à l'État (pardon, on dit « payer des impôts »). Et c'est là que la censure intervient. Pour protéger le business de ceux qui paient une part à l'État, il faut interdire les autres. Le décret cité plus haut permet donc cette censure.

L'ARJEL fait valoir que les sites de jeux en ligne légaux ne sont pas uniquement légaux parce qu'ils paient mais aussi parce qu'ils respectent certaines obligations, comme d'afficher un petit avertissement « attention, le jeu est dangereux ». Mais c'est un argument très hypocrite : on sait que le jeu est dangereux, mais on gagne de l'argent avec.

À noter que cette extension des impôts via les jeux en ligne fait l'objet d'un fort consensus gauche-droite, la gauche a déjà sa place à l'ARJEL, via la responsable des questions numériques chez François Hollande, qui avait pourtant essayé de cacher son rôle à l'ARJEL (à l'ENA, personne ne l'avait prévenue qu'il était difficile en 2011 de garder secrètes ce genre d'informations ?).

Cet article a été repris par le Monde et par l'Informaticien qui l'ont tous les deux attribué, bien à tort, à mon employeur (qui n'y est pour rien). Apparemment, la même chose arrive à Tristan Nitot donc je ne me plains pas.

Lors de discussions sur la mesure des performances de l'Internet (par exemple au sein du « groupe de travail multilatéral sur la qualité de service » de l'ARCEP), il est fréquent de voir des désaccords sur le fait de mesurer la QoS (Quality of Service) ou bien la QoE (Quality of Experience). La première concerne des mesures plutôt techniques, proches du fonctionnement du réseau. La seconde cherche à mesurer la satisfaction de l'utilisateur, ce fameux M. Toutlemonde. Quelle est la bonne approche ?

Si on vise à fournir une information à ce brave monsieur, le problème semble simple : il faut mesurer la QoE car c'est la seule qui l'intéresse. M. Toutlemonde ne veut probablement pas connaître la latence (RFC 2679 et RFC 2681), la capacité (RFC 5136) ou le taux de perte de paquets (RFC 2680). Ce qu'il veut, prétendent les gens qui parlent pour lui (M. Toutlemonde n'est jamais présent aux réunions mais on le cite tout le temps), c'est télécharger des films ou de la musique le plus vite possible. Certes, les métriques citées plus haut ont une influence nette sur sa QoE mais elle est indirecte et peu compréhensible.

Donc, cela semble réglé, la QoE est la seule chose qui importe. Seuls des barbus pas lavés comprennent quelque chose aux métriques techniques du RFC 2330 et il ne faut donc pas exposer ce pauvre M. Toutlemonde à des notions techniques. Mais, en fait, c'est plus compliqué que cela.

D'abord, la QoE a la particularité de se mesurer de bout en bout. On l'a dit, ce qui intéresse M. Toutlemonde, c'est « je clique pour voir un film, combien de temps attendre avant de le voir ». La QoE ne peut pas donc se mesurer de manière objective sans avoir accès à l'ordinateur de l'utilisateur, puisqu'elle dépend de toute la chaîne. Ainsi, si le PC Windows de M. Toutlemonde est farci de virus et que cela le ralentit, la QoE est moins bonne, quelle que soit la capacité de la fibre optique. Cela réduit fortement l'applicabilité de la QoE. Même dans un monde de Minitels où l'opérateur contrôlerait le terminal de l'utilisateur, il faudrait encore tenir compte des performances du serveur (si on regarde france.fr le jour de son inauguration, ça va très lentement, quels que soient les efforts des FAI pour fournir un bon réseau). On ne sait donc plus très bien qui est responsable des mauvaises performances.

Ensuite, la mesure de la QoE suppose la définition d'une activité typique (j'ai entendu des vagues propositions du genre « le surf sur les cent sites Web les plus populaires »). Cette définition est une mauvaise idée dans son principe. Contrairement à la téléphonie, où le réseau était conçu pour une application, et où il était donc facile de mesurer la qualité du réseau (avec des techniques comme PESQ), l'Internet sert à beaucoup de choses différentes. Un échantillon d'activités serait arbitraire : pourquoi les gens qui font du jeu en ligne ou de la messagerie instantanée, qui ont surtout besoin d'une faible latence, accepteraient-ils l'échantillon soi-disant représentatif des téléchargeurs, qui ont surtout besoin de capacité ?

Pire, cette idée d'« activité typique » empêcherait toute comparaison temporelle, puisque l'échantillon d'activités changerait d'une année sur l'autre, au gré des modes.

Enfin, l'échantillon typique a un énorme défaut si on veut l'utiliser pour des mesures qui seront publiées, genre « le classement des meilleurs FAI » : il encourage les opérateurs à optimiser leur réseau uniquement pour ce qui est mesuré. Si on intègre Facebook (très à la mode où moment où j'écris cet article) dans l'échantillon, tous les FAI feront des efforts pour avoir une bonne connectivité avec Facebook et oublieront le reste.

Dernier problème avec la QoE, l'absence de normalisation. Autant les métriques techniques sont rigoureusement définies (par le groupe de travail IPPM de l'IETF ou bien, si on y tient, par le SG-12 de l'UIT, qui produit des documents comme la Recommandation Y.1540, « Internet protocol data communication service - IP packet transfer and availability performance parameters »), autant les mesures de QoE sont souvent d'une grande subjectivité, définies de manière floue, et jamais discutées collectivement (contrairement aux normes comme les RFC cités plus haut). La plupart ne dépassent pas le niveau « ce soir, ça rame !!! » des forums de discussion bas de gamme. C'est évidemment plus compréhensible que « la latence unidirectionnelle est de 132 milli-secondes pour des paquets de Type-P TCP-80 » mais la technique doit être rigoureuse, avant d'être attirante.

Pour que des mesures massives et objectives soient possibles, il faut donc se concentrer sur des métriques techniques, reflétant le fonctionnement du réseau, comme celles indiquées plus haut. On peut toujours ajouter ensuite des mesures « de plus haut niveau », plus proches du ressenti de l'utilisateur, mais cela ne peut être qu'une fois qu'on dispose de mesures solides proches du réseau.

Un exemple de telles mesures, celles que fournit le projet Normandie Sans Fil : http://www.normandie-sansfil.com/index.php?p=4.

Un autre débat dans le même groupe ARCEP est discuté dans « Où doit-on mesurer la capacité réseau, chez le FAI ou plus loin ? ».

La consultation publique lancée par l'ARCEP fin 2011 utilise un vocabulaire différent en parlant de mesures techniques pour la QoS et de mesures orientées vers les usages pour la QoE.

Pendant les discussions sur la mesure de la capacité (souvent improprement nommée « débit » ou « bande passante ») d'un accès à l'Internet (par exemple au sein du « groupe de travail multilatéral sur la qualité de service » de l'ARCEP, créé suite à la septième proposition de l'ARCEP sur la neutralité du réseau), un point qui revient souvent est celui de l'endroit où doit se terminer la mesure. Cet endroit doit-il être chez le FAI ou plus loin dans l'Internet ?

Le but est de vérifier les offres commerciales existantes. Si un FAI annonce sur des grands panneaux publicitaires un débit (sic) de 100 Mb/s, est-ce vrai ? Une étude de la FCC, aux États-Unis, « Measuring broadband America », semblait indiquer que non, que la capacité réelle était bien plus basse. Il est donc normal que les autorités de régulation veulent effectuer des mesures indépendantes de la capacité réellement vendue au client. A priori, le problème est simple. On met une sonde (matérielle ou logicielle) chez le client, une terminaison de mesure quelque part dans l'Internet (avec la plupart des logiciels cités plus loin, c'est le même programme qui tourne aux deux extrêmités, ce qui permet de voir le lien des deux côtés) et on regarde (il existe plusieurs outils libres pour faire cette mesure, voir par exemple mon article sur le RFC 6349).

Mais la position de la terminaison est cruciale :

• Si celle-ci est située sur le réseau du FAI, on rate complètement la mesure du point le plus important : l'interconnexion du FAI avec l'extérieur. La plupart du temps, les exagérations dans la publicité (promettre 100 Mb/s qu'on ne pourra pas délivrer) se situent justement dans cette interconnexion, qui coûte très cher au FAI, et sur laquelle il est donc tentant d'économiser. Beaucoup d'entre eux ont donc des réseaux internes relativement rapides et des connexions lentes avec le reste du monde. Ne pas mesurer cette connexion extérieure nous priverait de l'information la plus importante. (C'est pourtant ce que fait Grenouille et c'est justement une des plus grosses limites de leurs mesures.)
• Mais le FAI ne contrôle pas tout l'Internet. Si les mesures ont des conséquences (par exemple, obliger le FAI à publier des chiffres défavorables, ou bien lui imposer de changer sa publicité), il peut sembler injuste de tester le FAI sur des points qu'il ne contrôle pas. Si on mesure un débit avec l'Université de Yaoundé, et que le maximum atteignable est très bas, ce n'est pas la faute du FAI français.

Comment résoudre ce problème ? Je ne vois pas de solution parfaite. Le mieux serait sans doute de publier les deux indicateurs : « capacité réseau interne » et « capacité avec certains points externes ». Comme souvent en métrologie, on ne peut pas espérer s'en tirer avec un seul chiffre, même si c'est ce que les publicitaires préféreraient.

Après la parution initiale de cet article, plusieurs personnes ont fait des remarques, nuançant tel ou tel point. Merci sur Twitter à lucasdicioccio, AlexArchambault, Grunt_ et bitonio. Les points à compléter :

• La capacité au retour n'est pas forcément la même qu'à l'aller, soit parce que le lien lui-même est asymétrique (ADSL), soit parce que le chemin n'est pas toujours le même au retour. C'est pour cela qu'il faut effectuer la mesure en envoyant des données dans les deux directions. (Il faut que je teste les logiciels mentionnés dans mon article sur le RFC 6349 pour voir comment ils gèrent cela.)
• J'ai écrit que la connectivité externe était sans doute la plus importante, pour l'abonné de base qui veut joindre Netflix ou Wikipédia. Cela ne serait pas vrai si les techniques pair-à-pair (avec des optimisations comme Alto) étaient plus répandues. Malheureusement, ces techniques sont diabolisées, réprimées par des organisations comme l'HADOPI, et pas encouragées par les acteurs commerciaux, qui ne pensent que « accès au contenu », terme qui est pour eux synonyme de TF1. Comme l'a souvent noté FDN, beaucoup des problèmes de performance de l'Internet disparaitraient si on arrêtait de l'utiliser comme un Minitel.
• En parlant de connectivité interne et externe, j'ai supposé qu'il n'y avait que ces deux cas. En fait, comme l'explique bien Éric Daspet, dans son article cité plus loin, il y a de nombreuses sortes de connectivités externes : si le FAI français ne peut clairement pas être responsable de ce qui se passe loin de lui (cas de l'université de Yaoundé), en revanche, il est responsable de ses liens immédiats. S'il refuse de peerer avec Google, les lenteurs d'accès de ses abonnés à YouTube sont bien de sa faute.

Pour une définition plus rigoureuse de la notion de capacité, et pour une explication de ses différences avec la bande passante, on peut consulter le RFC 5136. Quant au débit, il représente l'utilisation effective du réseau, la capacité étant son potentiel maximum. Un bon article scientifique sur ce problème de mesure de la capacité fournie par le FAI est « Broadband Internet Performance: A View From the Gateway ». Suite à mon article, Éric Daspet a écrit « Où doit-on mesurer la capacité réseau », qui revient notamment en détail sur la responsabilité du FAI dans les connexions extérieures (par une bonne politique de peering, etc). Enfin, un autre débat qui a eu lieu dans le même groupe de travail ARCEP est également discuté sur mon blog, dans « Que doit-on mesurer, la QoS ou la QoE ? ».

La consultation publique lancée par l'ARCEP fin 2011 utilise une autre terminologie (voir notamment la question n° 19). La machine visée par la mesure est nommée mire et le projet soumis à consultation a trois sortes de mires, mire proches (situées dans un endroit bien connecté à beaucoup de FAI), mires lointaines (Yaoundé...) et mires commerciales (gros services très populaires comme YouTube). On notera qu'il n'existe pas de mires internes, situées sur le réseau du FAI.

Chaque 31 décembre, le Président de la République présente ses vœux télévisés. Une intervention au style établi, avec ses caractéristiques, ses règles, ses coutumes : un format ouvert.

Le livre Bonne année, la France ! édité par le Documentation française analyse cet exercice de communication et de style personnel avec les vœux présidentiels de 1958 à 2010.

Le 31 décembre sur Formats-Ouverts.org :

• en 2010, en 2009, en 2008, en 2007, en 2006, en 2005 et en 2004

En 1921 était créé la société Filofax qui commercialise depuis cette date ses fameux organiseurs : étui (en cuir au début) avec calendrier, bloc-notes, agenda, carnet d'adresses.

D'un côté, le format papier, ouvert. De l'autre, le format papier plus fermé avec les dimensions propres aux recharges de la marque et de ses modèles.

Le 30 décembre sur Formats-Ouverts.org :

• en 2010, en 2009, en 2008, en 2007, en 2006, en 2005 et en 2004