Resumen
- RFC 1135 dejó constancia del desacuerdo sobre la intención y las responsabilidades posteriores al incidente. Era un memorando informativo, no una norma ni un código adoptado por todo Internet.
- El equipo del MIT distinguió entre explicar una vulnerabilidad y sus algoritmos y publicar el código descompilado. La defensa de CPSR de publicar descripciones de fallas no resolvió la decisión distinta sobre el código fuente.
- Las fuentes muestran opciones en conflicto, no una política universal de divulgación, un relato completo de la prensa ni la prueba de que alguna postura se adoptara en toda la red.
Una sola palabra ocultaba dos decisiones
La tarde del sábado 5 de noviembre de 1988, investigadores del MIT debatieron si publicar el código descompilado del gusano. Su cronología indica que el equipo decidió no hacerlo público durante la crisis. También explica que no quería ocultar el funcionamiento del programa: pensaba describir sus algoritmos para que otros entendieran lo ocurrido. El riesgo que señaló era práctico. Añadir un cambio destructivo y recompilar un programa funcional exigía menos esfuerzo que reconstruirlo a partir de una explicación.
No era una elección binaria entre secreto y apertura. Una descripción técnica, un listado de código, un parche y una copia privada enviada a otro investigador eran objetos diferentes, con públicos y riesgos distintos. El relato del MIT dice que el equipo consideró una posible distribución posterior, cuando los sitios hubieran instalado las correcciones. Esa fue la decisión que documentó el equipo; no una orden de la administración del MIT ni una regla para todos los operadores de Internet. La cronología del MIT describe directamente la decisión.
Otro registro contemporáneo hizo visible la diferencia. En diciembre de 1989, Jon Reynolds dedicó RFC 1135 a las consecuencias del incidente y presentó declaraciones de la Internet Activities Board, la National Science Foundation, el MIT y Computer Professionals for Social Responsibility. El memorando se define como un informe sobre un hecho de Internet y dice que no especifica ninguna norma. Su valor está en conservar el desacuerdo; ese mismo estatus limita lo que su publicación puede probar. RFC 1135 archiva posturas, pero no demuestra que la comunidad adoptara una.
Cuatro declaraciones no formaron un código común
La RFC 1087 de enero de 1989 describió Internet como una infraestructura de investigación compartida y vinculó la responsabilidad profesional con su disponibilidad. Consideró inaceptables los actos deliberados de acceso no autorizado, interrupción, desperdicio, daño a la integridad de la información o invasión de la privacidad. También advirtió que los experimentos a escala de Internet podían afectar a personas ajenas al proyecto y que las medidas de protección podían ser contraproducentes si obstaculizaban el libre flujo de información. La declaración combinaba prudencia y apertura; no describía un órgano central capaz de resolver cada sanción local. RFC 1087 es explícitamente una declaración de política de la IAB.
RFC 1135 presenta otro énfasis en la declaración de noviembre de 1988 del panel asesor de una división de la NSF. Según el resumen de Reynolds, incluía la negligencia además de la interrupción deliberada y animaba a las organizaciones que administraban redes a publicar sus propias políticas éticas y procedimientos disciplinarios. La recomendación apuntaba a actuar dentro de las instituciones responsables de sistemas concretos. En el texto que conserva RFC 1135 no se establece un organismo universal de cumplimiento.
La declaración del MIT sobre el uso responsable de computadoras era anterior al gusano. RFC 1135 la describe como una guía de campus sobre el uso previsto, la privacidad, la seguridad, la integridad de los sistemas y la propiedad intelectual. Una regla universitaria puede gobernar a sus integrantes y sistemas; su existencia no la convierte en ley para Internet.
CPSR, en cambio, defendía publicar descripciones de las fallas de seguridad como una vía eficaz para corregirlas. Su declaración defendía el intercambio abierto y advertía contra políticas que restringieran la circulación de ideas entre investigadores. Pero “publicar la descripción de una falla” no equivale a “publicar una copia funcional del exploit”. El relato del equipo del MIT marca precisamente esa diferencia. Leídos en conjunto, los registros muestran un espectro de divulgación en el que el lema de la apertura puede ocultar decisiones distintas.
RFC 1135 cita la postura de CPSR; no es por sí solo una historia independiente y completa de todas sus acciones.
Explicar y facilitar la ejecución tenían costes distintos
Los investigadores del MIT escribieron que no debía ocultarse el conocimiento detallado del programa. Aun así, consideraron diferente publicar el código, porque un receptor podía añadir con más facilidad un cambio destructivo y reconstruirlo. Su relato dice que durante la respuesta inmediata retuvieron del público su código descompilado, a la vez que discutían los algoritmos y colaboraban con otros investigadores. También registra el argumento de Jerry Saltzer a favor de una posible publicación después de que los sitios tuvieran tiempo para instalar los parches.
La distinción no eliminaba todos los riesgos. Retener el código podía dificultar una comprobación independiente; publicarlo podía reducir el esfuerzo necesario para reutilizar el programa. Una explicación podía ayudar a los defensores y, a la vez, aportar información a quien pudiera reconstruir el método. Un parche podía dar a los operadores una reparación concreta sin zanjar qué nivel de detalle técnico debía quedar en el archivo público. Las fuentes documentan una decisión de equipo y sus argumentos, no miden cuánto cambió el resultado cada opción. La conclusión del equipo del MIT incluye la disponibilidad del código y la apertura entre las cuestiones que dejó el incidente.
Por eso, afirmar que “Internet eligió divulgar” sería demasiado amplio. RFC 1135 coloca varias declaraciones una junto a otra, pero no ofrece un recuento de adopción, una votación, un registro de distribución ni una auditoría posterior de cumplimiento. Su propia descripción del debate entre una fuga accidental y una liberación deliberada tampoco determina la intención. Muestra que un autor contemporáneo registró relatos enfrentados y rechazó la infestación como forma aceptable de exponer fallas. No basta para establecer el motivo del autor del programa.
La prensa fue otra frontera, no un actor uniforme
RFC 1135 critica la cobertura sensacionalista y cuenta que algunos investigadores de Berkeley encontraron perturbadora la presencia de la prensa. La cronología del MIT ofrece una perspectiva más local: el equipo dice que su Oficina de Noticias agrupó las solicitudes en una conferencia y mantuvo a los periodistas lejos de gran parte del trabajo de análisis. Los investigadores también dicen que muchos reporteros hicieron preguntas sinceras, aunque relatan afirmaciones erróneas y expectativas de una demostración visual espectacular.
Los relatos no son incompatibles. Describen experiencias diferentes y muestran por qué “los medios” no deben tratarse como una institución uniforme. La oficina de prensa podía proteger el tiempo de los investigadores y, al mismo tiempo, abrir un canal público; un titular o rumor podía distorsionar lo que el público creía que había ocurrido. RFC 1135 refleja la evaluación de su autor en 1989 y la cronología del MIT, la perspectiva de un equipo. Ninguna es un censo de toda la prensa ni cuantifica retrasos.
La frontera importaba porque la interpretación pública podía tener efectos prácticos. Presentar al atacante como un héroe podía convertir un acto no autorizado en un supuesto servicio de seguridad; anunciar un nuevo brote sin fundamento podía consumir atención. Las fuentes sostienen que esos problemas de comunicación fueron registrados, no que la cobertura causara el incidente o dirigiera la respuesta técnica.
Lo que RFC 1135 pudo conservar
RFC 1135 no es un código ético para todo Internet. Sus páginas conservan un momento en que distintas organizaciones describieron responsabilidades a escalas distintas: una política de la IAB para la infraestructura compartida, una recomendación de la NSF para operadores e instituciones, reglas de conducta del campus ya existentes y una defensa de la investigación abierta por parte de una organización civil. El relato del MIT añade la separación entre publicar métodos y distribuir código ejecutable. El archivo no muestra que esas posturas se reconciliaran o se adoptaran universalmente.
La Nota 64 de Heng Lu, escrita mucho después, ofrece un marco de lectura: publicar no es lo mismo que implementar o adoptar en sistemas en funcionamiento. Esa doctrina de diseño es de 2026; no constituye evidencia sobre 1988 ni debe atribuirse a la IAB o a Reynolds. Aplicada con cuidado, ayuda a formular una pregunta histórica: ¿un texto publicado describía un principio o hay registros de que una organización lo pusiera en práctica? En RFC 1135, a menudo la evidencia respalda lo primero.
El legado documental no es, por tanto, una regla de divulgación ya resuelta. Es una serie de decisiones separables: describir una falla, explicar un algoritmo, enviar un parche, compartir el código con un grupo limitado o publicar el programa funcional. Cada opción cambia quién puede examinar, reparar, reproducir o reutilizar el material. El memorando de 1989 vuelve visible el desacuerdo. No concede a una institución la facultad de decidir por todas las redes.
Fuentes
- Jon Reynolds, RFC 1135, “The Helminthiasis of the Internet” y su registro en RFC Editor.
- Internet Activities Board, RFC 1087, “Ethics and the Internet” y su registro en RFC Editor.
- Mark Eichin y Jon Rochlis, cronología del MIT y conclusión de “With Microscope and Tweezers”.
- Eugene H. Spafford, “The Internet Worm Program: An Analysis”.
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
