摘要

  • RFC 1135 记录了对蠕虫意图和事件后责任的不同说法；它是信息性备忘录，不是标准，也不是全 Internet 共同采用的行为守则。
  • MIT 团队区分了说明漏洞及其算法与公开反编译源码。CPSR 主张公布漏洞说明，并没有因此替源码发布这个单独问题作出结论。
  • 现存材料能证明当时存在不同选择，不能证明全网形成了统一披露政策、媒体报道有完整记录，或某一立场已被所有参与者采纳。

“披露”把两个动作压成了一个

1988 年 11 月 5 日星期六下午，MIT 研究人员讨论是否公开蠕虫的反编译源码。团队的事件纪事记载，他们决定在危机期间不公开这份源码；但他们也不想隐藏程序的内部工作方式，仍计划解释所用算法，让其他人理解事件。团队给出的理由很实际：在一个可运行的程序上加一行破坏性代码并重新编译，比从一份说明重新做出程序容易得多。

这不是“保密”与“开放”二选一。技术说明、源代码清单、防御性补丁，以及私下交给另一位研究人员的副本，是不同的材料，面对不同受众，也带来不同风险。MIT 的记录提到，等各站点有时间安装修复后，团队再考虑是否扩大分发。这是研究团队记录下来的决定，不是 MIT 行政部门下达的命令，更不是所有 Internet 运营者都必须遵守的规则。MIT 事件纪事直接记载了这项选择。

另一份同期记录把这种差异放到了台面上。1989 年 12 月，Jon Reynolds 通过 RFC 1135 回顾蠕虫事件，并列出 Internet Activities Board、National Science Foundation、MIT 和 Computer Professionals for Social Responsibility 的声明。备忘录称自己是在介绍一个 Internet 事件，也明确说它不规定任何标准。它的价值在于保留了分歧；同样的文本身份也限制了它能证明什么。RFC 1135是各方立场的档案，不是全体社群已经采纳其中一方的投票记录。

四份声明没有组成一部共同守则

IAB 于 1989 年 1 月发布的 RFC 1087 把 Internet 描述为共享研究基础设施，并把专业责任与其持续可用性联系起来。它将蓄意未经授权访问、干扰、浪费资源、破坏信息完整性和侵犯用户隐私列为不可接受的行为。它还提醒，面向整个 Internet 的实验可能影响研究者之外的人；安全措施如果妨碍信息自由流动，也可能适得其反。这份声明同时强调谨慎与开放，却没有提出一个中央机构来裁定每个站点的纪律处分。RFC 1087明确是一份 IAB 政策声明。

RFC 1135 对 NSF 一个分部顾问小组 1988 年 11 月声明的概述，重点略有不同。按 Reynolds 的转述，该声明把疏忽和蓄意干扰都纳入伦理问题，并鼓励网络管理机构公布自己的行为政策和纪律程序。它把行动责任指向管理具体系统的组织；在 RFC 1135 保留的文字中，这并没有建立一个全网通用的执法机构。

MIT 的计算机负责任使用声明早于蠕虫事件。RFC 1135 把它描述为校园层面的行为规则，涉及预期用途、隐私、安全、系统完整性和知识产权。大学规则可以约束自己的成员和系统，但它的存在不会自动使它成为 Internet 法规。

CPSR 则主张公布安全漏洞的说明，认为这样有助于修复。它维护开放交流，并反对妨碍研究者交换想法的政策。但“公布漏洞说明”并不等于“发布可运行的攻击程序”。MIT 团队的记录明确区分了这两者。把这些材料并读，可以看到“开放”这个口号背后有几种不同的披露决定。RFC 1135 引述了 CPSR 的立场；它本身并不是 CPSR 所有行动的完整独立史料。

解释漏洞和降低复用门槛，代价不同

MIT 研究人员写道，不应隐瞒程序如何运行的详细知识。但他们认为公开源码是另一回事，因为接收者可以更容易地加入破坏性改动并重新构建程序。团队纪事记载，响应事件期间，他们没有把反编译源码公开，同时继续讨论算法、与其他研究人员合作。文中还记录了 Jerry Saltzer 的意见：等受影响站点有时间安装补丁后，可以再考虑发布。

这一区分并没有消除风险。保留源码可能让独立核验更困难；公开源码则可能减少再次利用程序所需的工作量。解释原理可以帮助防守者，也可能向有能力重建方法的人提供信息。补丁可以让运营者获得实际修复，却没有替公共档案中的技术细节划定统一界限。材料记载的是一个团队的决定和围绕它的论据，并没有测量每个选项对最终结果的影响。MIT 团队的结论把源码可得性和开放交流都列为事件带来的问题。

因此，“Internet 选择了披露”是过度概括。RFC 1135 并列了多份声明，却没有提供采纳统计、投票结果、分发记录或事后合规审计。它对蠕虫究竟是测试中意外逃逸还是被故意放出的讨论，也不是对意图的裁决。它只能说明一位同期作者记录了相互竞争的说法，并反对把蠕虫感染当成揭露漏洞的正当手段；单凭该文无法判定程序作者的动机。

媒体是一道边界，却不是一个统一行动者

RFC 1135 批评了耸动的报道，并转述一些 Berkeley 研究人员认为媒体干扰了工作。MIT 事件纪事给出了较局部的描述：团队称其新闻办公室把采访请求集中到一场记者会，并让记者远离大部分分析工作。研究人员也表示，许多记者确实在认真提问；同一份纪事同时记下了错误说法，以及媒体期待出现可拍摄的戏剧性场面。

这两种说法可以同时成立。它们描述的是不同经历，也说明不能把“媒体”当作意见和行为完全一致的机构。新闻办公室能保护研究者的时间并提供公共说明渠道；标题或传言仍可能扭曲公众对事件的理解。RFC 1135 是其作者在 1989 年的观察，MIT 纪事则是一个团队的视角。两者都不是对所有报道的普查，也没有量化报道造成的延迟。

这种边界之所以重要，是因为公众叙事可能产生实际影响。把攻击者称作英雄，可能把未经授权的行为改写成安全服务；没有根据的新一轮爆发消息，则可能占用注意力。材料支持这些沟通问题曾被记录下来，却不支持“媒体导致了事件”或“媒体控制了技术响应”的结论。

RFC 1135 留下了什么

RFC 1135 不是适用于整个 Internet 的伦理守则。它保存了一个时期中不同组织对责任范围的描述：IAB 面向共享基础设施的政策、NSF 对运营网络的组织提出的建议、既有的校园行为规则，以及民间组织对开放研究的辩护。MIT 的记录补充了公布方法与分发可执行源码之间的区别。档案没有显示这些立场后来达成一致，或被全网采纳。

Heng Lu 的 Note 64 写于多年以后，提供了一个解释视角：发布不等于实施，也不等于运行系统的参与者已经采纳。这套设计原则形成于 2026 年，不是 1988 年的证据，也不应归到 IAB 或 Reynolds 名下。谨慎使用它，可以提出一个历史问题：公开文本是在陈述原则，还是组织的实际运行记录显示它已落实？就 RFC 1135 而言，证据往往只能支持前者。

因此，这份档案留下的不是一条已经解决的披露规则，而是一组可分开的选择：描述漏洞、解释算法、发送补丁、向有限群体分享源码，或公开可运行代码。每种选择都会改变谁能检查、修复、复现或再次利用这些材料。1989 年的备忘录让这场分歧变得可见；它没有授权任何机构替所有网络作决定。

来源