HADOPI : An interoperable and modular XML bullshit

L’HADOPI a aujourd’hui publié un document intéressant à plusieurs égards. Il s’agit d’un appel à expérimentations émanant des Labs. Il commence à dessiner quelque chose qui ressemble de manière très; très… très lointaine à de la « sécurisation d’accès Internet », un terme qui à ce jour ne veut strictement rien dire. Je vous avais déjà expliqué que si l’on veut sécuriser un accès Internet, il existe bien un moyen, mais qui a un léger inconvénient dans le cadre implicite fixé par HADOPI. Ce cadre implicite, c’est « empêcher l’utilisation, frauduleuse ou non, des connexions Internet à des fins de téléchargement illégal ». On a beau vous raconter n’importe quoi aujourd’hui sur la mission divine de l’HADOPI qui va d’un coup de baguette magique protéger vos accès Internet, jusqu’à preuve du contraire, c’est bien pour faire la chasse au partage qu’elle a été votée. Et qu’on ne vienne pas me tanner avec la pédagogie, on aurait pu en parler si le délit de contrefaçon avait été supprimé dans le cadre d’un téléchargement… mais c’est loin d’être le cas. Le moyen de sécurisation de l’accès Internet auquel je fais référence n’est en outre qu’une brique pouvant concourir, couplé à de bonnes pratiques, à la sécurité de vos données et de vos échanges sur Internet. Il s’agit d’un VPN, chiffrant de bout en bout vos connexions. Et l’inconvénient est de taille puisque cette solution qui sécurise pour le coup vos communications rend sourds et aveugles nos amis de TMG… et donc l’HADOPI parfaitement inutile. Les Labs de l’HADOPI se secouent donc les neurones pour innover. Les neurones ont beau être au rendez-vous, si ces dernières s’agitent autour d’une problématique mensongère, vous vous doutez bien qu’au final on obtiendra une belle bouillabaisse, mais certainement pas de quoi « sécuriser un accès Internet ». Le document, disponible ici, souligne que cette initiative émane des Labs en totale liberté et se veut un préalable à l’adoption de spécifications fonctionnelles de « moyens de sécurisation » (MS) d’accès Internet. C’est clair pour vous ? … Et bien pas pour moi.

☠ Reposons le problème

Alors qu’on ne sait toujours pas où la responsabilité d’un internaute s’arrête dans ce que le texte de loi appelle « sécurisation d’une connexion Internet », l’objectif est ici d’inventer une nouvelle génération de logiciel qui n’est :

• ni un antivirus,
• ni un firewall
• ni un logiciel de contrôle parental
• ni un IDS (système de détection d’intrusion)…

Christine Albanel l’avait appelé un « contre-logiciel », j’aimais beaucoup ce terme car on ne savait pas trop ce que ce logiciel devait contrer, mais on se doutait bien qu’elle allait nous en sortir une bonne. Au détour d’une question parlementaire, nous apprenions que le « contre-logiciel » de Christine Albanel, c’était OpenOffice, la suite bureautique qu’elle confondait avec un firewall. Exit donc les antivirus, les firewalls, les solutions de contrôle parental, les IDS et les contre-logiciels, on parle maintenant assez sobrement de « moyen de sécurisation »… mais un moyen de sécurisation qui ne sait pas trop ce qu’il doit sécuriser. Le « moyen de sécurisation » c’est donc un peu de tout ça sans vraiment l’être et surtout, sans objectif clairement définit en matière de résultat attendu. Si vous me suivez jusque là, vous devez sentir vous aussi que dés le début, ça s’engage plutôt mal.

☠ Re-Reformulation de la problématique

Aujourd’hui, soit quand même plus de 3 ans après l’adoption d’HADOPI 2, alors que nous sommes dans une phase répressive assumée, les labs sont investis d’une mission plutôt casse gueule :

« Travailler à l’élaboration d’un bidule qui va permettre de spécifier un machin nouveau qui fait des trucs innovants mais qui restent à définir ». (NDLR : « putain 3 ans! »)

Comme nous sommes assurés qu’il ne peut ici s’agir de spécifier un moyen de sécurisation d’accès Internet qui sécurise la connexion de l’abonné au niveau :

• de l’accès à son réseau local ;
• l’accès à son système ;
• de la protection de son patrimoine informationnel ;
• de la protection de son identité numérique ;
• du transport de ses données sur le réseau…

bref de la sécurité quoi… comme ce qu’une connexion sécurisée devrait apporter en terme de garanties pour protéger contexte et contenu des communications (pas de chiffrement surtout dés fois que ça empêcherait TMG de flasher les internautes), on s’oriente vers notre fameux « truc ».

☠ Un appel à expérimenter le truc qui fait des bidules

C’est déjà moins simple non ? Mais tenez vous bien, ce n’est pas terminé.

Le document nous apporte tout de même de bonnes nouvelles. Le truc devra être :

• Interopérable : les geeks se réjouissent, il vont pouvoir installer le même truc sur le Windows, leur GNU Linux, sur leur BSD, sur leur Mac, et même sur leur Smartphone… je sens que tu exultes toi le geek.
• Modulaire : à vous les joies de l’écriture de plugins à truc pour faire d’autres machins que les bidules pour lesquels il est prévu initialement… (Régis tu as un bout de pomme de terre sur la joue…).
• Encore plus modulaire ! Tu ne t’es pas gavé avec l’écriture de tes plugins à truc pour faire d’autres machins ? Que dirais tu de listes et de règles qui interagissent avec la chose ?… les mots commencent à me manquer.
• Compatible avec des plugins à trucs qui font des bidules, et autorisant des listes et règles qui font des choses différentes des machins du truc… PFIIIIOUUUUU !

Que nous manque t-il ? hummm wait… Une API bien sûr ! Et pas n’importe quelle API, pas une API de gonzesses, une API d’hommes ! Une vraie ! En XML et tout ! Une API transversale et interopérable ! La transversalité et l’interopérabilité d’une API permettant d’écrire des plugins du truc pour faire des bidules, passés au shaker avec les listes et les règles pour faire des choses sur le machin… je pense que nous le tenons notre concept.

☠ Et ça aurait pu être pire !

La bonne nouvelle ? La bonne nouvelle, nous la devons au fait que malgré une problématique mensongère, mal posée de manière délibérée et parfaitement à côté de la plaque de ce qu’elle prétend être, ce soit Jean-Michel Planche qui travaille sur ce dossier, entouré de personnes plutôt cortiquées, et qu’il le fait dans un esprit d’ouverture et de transparence appréciable. Nous avons échappé au MPLS et la priorisation de trafic en coeur de réseau, aujourd’hui abandonné pour un « truc » côté utilisateur. Le document s’oriente donc vers un MMF : un Moyen de Maîtrise des Flux réseaux laissant toute latitude à l’utilisateur et qui respectera les RFC relatives aux DNS (… t’enflamme pas Régis, c’est juste afin de mieux les filtrer, c’est pas avec ça que t’auras ton BIND DNSSEC censorship proof à la maison en deux clics).

☠ An interoperable and modular XML bullshit

Vous savez quoi ? Je vous disais déjà en 2009 que ces moyens de sécurisation seraient une arlésienne. Aujourd’hui j’en suis définitvement convaincu. La cause était d’ailleurs entendue quand le rapporteur Muriel Militello avouait que le débat technique ne l’intéressait pas. Nos parlementaires ont voté un texte de merde… ils auront donc du caca, mais interopérable, modulaire et en XML.

Internautes, on vous la mise bien profond avec HADOPI… et c’est pas terminé.