Résumé

  • La RFC 1135 a conservé le désaccord sur l’intention et sur les responsabilités après l’incident. C’était un mémo informatif, pas une norme ni un code adopté par tout l’Internet.
  • L’équipe du MIT séparait l’explication d’une faille et de ses algorithmes de la publication du code désassemblé. L’appel du CPSR à publier les descriptions des failles ne tranchait pas la question distincte du code source.
  • Les sources montrent des choix concurrents, pas une politique universelle de divulgation, une histoire complète de la presse ou la preuve qu’une position a été adoptée partout.

Le mot « divulgation » recouvrait deux décisions

Le samedi 5 novembre 1988, des chercheurs du MIT ont débattu de la publication du code désassemblé du ver. Leur chronologie indique que l’équipe a décidé de ne pas le rendre public pendant la crise. Elle précise aussi que ses membres ne voulaient pas cacher le fonctionnement du programme : ils comptaient décrire ses algorithmes pour que d’autres puissent comprendre l’incident. Leur crainte était concrète : modifier une ligne et recompiler un programme fonctionnel demandait moins d’effort que de le recréer à partir d’une explication.

Ce n’était donc pas un choix binaire entre secret et ouverture. Une description technique, un listing source, un correctif et une copie privée transmise à un autre chercheur sont des objets distincts, destinés à des publics différents et porteurs de risques différents. Le compte rendu du MIT évoque une éventuelle diffusion ultérieure, une fois les sites corrigés. Il s’agit de la décision rapportée par l’équipe, pas d’un ordre de l’administration du MIT ni d’une règle applicable à tous les opérateurs. La chronologie du MIT décrit directement ce choix.

Un autre document contemporain rend cette distinction visible. En décembre 1989, Jon Reynolds a consacré la RFC 1135 aux suites de l’incident et y a présenté des déclarations de l’Internet Activities Board, de la National Science Foundation, du MIT et de Computer Professionals for Social Responsibility. Le mémo se présente comme le récit d’un événement survenu sur l’Internet et précise qu’il ne spécifie aucune norme. Il est utile parce qu’il conserve le désaccord; ce statut limite aussi ce que sa publication peut démontrer. La RFC 1135 archive des positions, mais ne prouve pas que la communauté en a adopté une.

Quatre prises de parole ne font pas un code commun

La RFC 1087, publiée par l’IAB en janvier 1989, décrit l’Internet comme une infrastructure de recherche partagée et rattache la responsabilité professionnelle à sa disponibilité. Elle qualifie d’inacceptables les actes visant l’accès non autorisé, la perturbation, le gaspillage, l’altération de l’intégrité des informations ou l’atteinte à la vie privée. Elle avertit aussi que les expériences à l’échelle de l’Internet peuvent toucher des personnes extérieures au projet et que des mesures de sécurité peuvent devenir contre-productives si elles entravent la libre circulation de l’information. Cette déclaration associe prudence et ouverture; elle ne décrit pas un organe central chargé de trancher toutes les sanctions locales. La RFC 1087 est explicitement une déclaration de politique de l’IAB.

La RFC 1135 rapporte une autre priorité dans la déclaration du comité consultatif de la division de la NSF, datée de novembre 1988. Selon le résumé de Reynolds, ce texte incluait la négligence aussi bien que la perturbation volontaire et encourageait les organisations qui exploitaient des réseaux à publier leurs propres politiques éthiques et procédures disciplinaires. La responsabilité devait ainsi être exercée par les institutions qui administraient les systèmes concernés. Dans le passage conservé par la RFC 1135, cela ne crée pas une instance universelle d’application.

La déclaration du MIT sur l’usage responsable des ordinateurs précédait le ver. La RFC 1135 la décrit comme une règle de campus portant sur l’usage prévu, la vie privée, la sécurité, l’intégrité des systèmes et la propriété intellectuelle. Une règle interne peut gouverner les membres et les systèmes d’une université; sa présence ne la transforme pas en loi pour l’Internet.

Le CPSR défendait, pour sa part, la publication des descriptions de failles comme moyen de les corriger. Son texte soutenait l’échange ouvert et mettait en garde contre les politiques qui entraveraient la circulation des idées entre chercheurs. Mais « publier la description d’une faille » ne signifie pas « diffuser une copie fonctionnelle de l’exploit ». Le compte rendu du MIT marque précisément cette différence. Mis côte à côte, les deux documents montrent que le slogan de l’ouverture peut masquer plusieurs décisions distinctes.

La RFC 1135 rapporte la position du CPSR; elle ne constitue pas à elle seule une histoire complète de toutes ses actions.

Expliquer et rendre le code réutilisable n’avait pas le même coût

Les chercheurs du MIT écrivaient qu’il ne fallait pas cacher les détails du fonctionnement du programme. Ils distinguaient toutefois la publication du code, car un destinataire aurait pu plus facilement y ajouter une modification destructive et le reconstruire. Leur chronologie rapporte que l’équipe a gardé son code désassemblé hors de la publication générale pendant la réponse immédiate, tout en discutant des algorithmes et en travaillant avec d’autres chercheurs. Elle mentionne aussi la position de Jerry Saltzer, favorable à une éventuelle publication après que les sites auraient eu le temps d’installer les correctifs.

Cette distinction ne résout pas tous les risques. La rétention du code peut compliquer une vérification indépendante; sa publication peut réduire l’effort nécessaire pour réutiliser le programme. Une explication peut aider les défenseurs tout en fournissant des informations à une personne capable de reconstruire la méthode. Un correctif peut offrir aux opérateurs une réparation concrète sans trancher le niveau de détail technique à verser aux archives publiques. Les sources rapportent une décision d’équipe et les arguments qui l’entouraient, mais ne mesurent pas l’effet de chaque option. La conclusion de l’équipe du MIT cite la disponibilité du code et l’ouverture parmi les questions soulevées par l’incident.

C’est pourquoi « l’Internet a choisi la divulgation » serait une affirmation trop large. La RFC 1135 juxtapose plusieurs déclarations sans fournir de décompte d’adoption, de vote, de registre de diffusion ni d’audit ultérieur. Son récit du débat entre la fuite accidentelle et la diffusion volontaire ne constitue pas non plus une conclusion sur l’intention. Il montre qu’un auteur contemporain a consigné des interprétations concurrentes et rejeté l’infestation comme moyen acceptable de révéler des failles. Il ne peut pas établir à lui seul le mobile de l’auteur du programme.

La presse formait une autre frontière, sans être un acteur unique

La RFC 1135 critique une couverture sensationnaliste et rapporte que certains chercheurs de Berkeley ont jugé la présence de la presse perturbatrice. La chronologie du MIT donne un tableau plus local : l’équipe dit que son service de presse a regroupé les demandes autour d’une conférence et tenu les journalistes à distance de l’analyse. Les chercheurs rapportent aussi que de nombreux journalistes posaient des questions sincères, tout en décrivant des affirmations erronées et l’attente d’une démonstration spectaculaire.

Ces récits ne se contredisent pas nécessairement. Ils décrivent des expériences différentes et montrent pourquoi « les médias » ne doivent pas être traités comme une institution uniforme. Le service de presse pouvait protéger le temps des chercheurs tout en ouvrant un canal public; un titre ou une rumeur pouvait malgré tout déformer ce que le public croyait savoir. La RFC 1135 témoigne du regard de son auteur en 1989, tandis que la chronologie du MIT rend compte d’une équipe. Aucun des deux documents ne recense toute la presse ni ne chiffre les retards.

Cette frontière compte parce que l’interprétation publique pouvait avoir des effets concrets. Présenter l’attaquant comme un héros risquait de recadrer un acte non autorisé en service rendu à la sécurité; une fausse annonce de nouvelle flambée pouvait absorber l’attention. Les documents étayent l’existence de ces problèmes de communication, mais pas l’idée que la presse a causé l’incident ou dirigé la réponse technique.

Ce que la RFC a pu conserver

La RFC 1135 n’est pas un code éthique applicable à tout l’Internet. Elle conserve un moment où plusieurs organisations ont formulé des responsabilités à des échelles différentes : une politique de l’IAB pour une infrastructure partagée, une recommandation de la NSF adressée aux opérateurs et institutions, des règles de conduite préexistantes sur le campus, et une défense de la recherche ouverte par une organisation de la société civile. Le compte rendu du MIT ajoute la distinction entre publier des méthodes et distribuer le code exécutable. Les archives ne montrent pas que ces vues ont été conciliées ni adoptées partout.

La note 64 de Heng Lu, écrite bien plus tard, offre un cadre d’interprétation utile : publier n’est pas la même chose qu’implémenter ou adopter dans les systèmes en fonctionnement. Cette doctrine de conception date de 2026; elle n’est pas une preuve sur 1988 et ne doit pas être attribuée à l’IAB ou à Reynolds. Utilisée avec prudence, elle suggère une question historique : un texte publié décrivait-il un principe, ou les documents montrent-ils qu’une organisation l’a mis en pratique? Pour la RFC 1135, la réponse est souvent la première.

Le legs documentaire n’est donc pas une règle unique de divulgation, mais une série de choix séparables : décrire une faille, expliquer un algorithme, transmettre un correctif, partager un code source avec un groupe limité ou publier le code fonctionnel. Chaque choix modifie qui peut examiner, réparer, reproduire ou réutiliser le contenu. Le mémo de 1989 rend le désaccord lisible. Il ne donne à aucune institution le pouvoir de décider pour tous les réseaux.

Sources