Usenet的早期历史（下）

我们当时意识到 Usenet 需要一种管理系统，而这种系统将需要某种形式的身份验证，包括对用户、站点甚至帖子的验证。但是，我们最终没有添加任何验证机制，我们为什么没有这样做也是一个有趣的故事。（注意：这篇文章的大部分内容源自我早些时候发布的一个帖子。¹ ）

这个问题的解决方案显然涉及公钥密码技术，我们（协议的最初开发者Tom Truscott，已故的 Jim Ellis 以及我自己）都听说过这项技术：当时所有厉害的极客都应该看过马丁·加德纳在《科学美国人》1977 年 8 月刊²上的“数学游戏”专栏（需要付费订阅），其中介绍了公钥加密技术和 RSA 算法的概念。而且Rivest、Shamir和Adleman的技术论文³早就发表了；我们也都读过那篇论文。实际上，我们手上还有陷门背包加密（trapdoor knapsack encryption）的代码：第 7 版 Unix 系统包含了用于公钥加密和解密的xsend 命令，而 Usenet 正是运行在这个系统之上。

我们不知道的是如何验证站点的公开密钥。如今，我们会使用由证书颁发机构颁发的证书来完成这项工作。证书在当时已经被发明出来，但我们并不知晓这项技术，当然也没有搜索引擎可以帮助我们。[人工检索工具？确实可以，但问题在于我们能否找到编入索引的相关学士论文，除此之外，我们也需要具备足够的知识来阅读此类论文。RSA 论文没有给出任何提示，它只提到了一个“公共文件”或类似电话簿的东西。它还提到了来自“计算机网络”的签名消息（原文中加了引号！），但除了 Usenet ，我们并没有这样的网络。而且，签名消息并不是证书。] 就算我们知道证书是什么，当时也还没有证书颁发机构，更何况我们也不可能在创建 Usenet 的同时创建一个证书颁发机构。

问题还不止于此，我们甚至不知道正确的参数设置：密钥长度应该用多长（早期论文中的估值太低了）、什么样的算法才是安全的（xsend命令使用的算法在几年后被攻破）等问题都困扰着我们。也许有人可以做出一些准确的猜测，但我们当时一无所知，并且清楚地认识到自己的知识盲区。

接下来我们要考虑的是邻居验证（neighbor authentication）：利用泛洪算法，理论上每个站点都可以知道并验证其邻居站点。但这个方法实际上却行不通。首先，冒充一个看起来更远的站点易如反掌。每个 Usenet 消息⁴都包含一个Path:行（line）；想要伪造消息的人只需要声称自己离目标站点几跳（hop）远就可以了。（著名的 “kremvax 恶作剧”⁵就是这样得逞的。）

当时勉强可以使用不同的uucp登录名来对应不同的站点，但是除了管理这些额外的登录名所带来的麻烦之外，我们还不确定rnews程序能否正确处理这种情况。

还存在一个更加微妙的问题。Usenet 消息是通过一个通用的远程执行工具进行传输的。运行在特定计算机上的 Usenet 程序会执行以下 Unix 命令：

uux neighborsite!rnews

其中，neighborsite 是下一个要执行rnews命令的计算机的名称。(我知道你会问：是的，当时允许远程执行的命令列表非常少；安全性也不完善，但这并不是我这里要讨论的问题。) 麻烦的是，站点上任何对此了解的人都可以使用uux命令；该命令无法轻易限制仅被授权用户使用。任何人都可以生成他们自己的伪造控制消息，而不会受制于 Usenet 界面内置的身份验证和健全性检查。是的，我们当时就意识到了这个问题。

那么可以确保uux的安全吗？这个问题本身非常复杂，现在我不想深入探讨。请相信我，不要试图争辩诸如 setgid()、包装（Wrapper）程序之类的概念。当时我们判断（我现在也这样认为）这样的解决方案不会被采用。将rnews作为远程执行命令所需的微小配置更改已经是一个足够高的门槛，因此我们为那些无法进行该更改的站点提供了替代机制。

这样一来，我们别无选择。那时并不存在实现加密解决方案的基础设施，而uux命令也让通过 Usenet 程序本身实施安全措施变得徒劳无功。因此，我们选择什么都不做。也就是说，我们没有实施一种虚假的安全机制：这种机制只会让人产生受保护的错觉，却无法提供真正的安全保障。

这在当时是一个正确的选择。

然而事情并非如此简单。在 1979 年，这是一个正确的决策，但之后的时间里这个决策就未必正确了。有以下几个原因：首先，当时只有极少人能访问 Usenet，这些用户大多是计算机专业的学生和大型科技公司的技术人员，因此社区氛围在某种程度上能够起到自我约束的作用：如果有人行为太过出格，他们的学校或雇主会对其进行处罚。我们确实预料到有些人会违规操作。

正如我在前文所述，我们当时大大低估了 Usenet 的用户人数和信息量。一方面，大型网络对管理的需求会急剧增加，其中就包括处理违规人员和信息泛滥等问题。另一方面，仅从统计角度看，大型网络会相对出现更多的恶意行为者。此外，网络接入的日益普及化意味着越来越多的人不会受到学校或雇主的制约。

和前文 1981 年的 Usenet 逻辑图相比，1982 年的 Usenet 已经变得非常复杂了（图片由Steven M. Bellovin 教授提供）

B-news（稍后我会详细解释）确实设置了控制消息（控制消息是一种特殊的 Usenet 帖子，用于执行某些管理操作。其包含特殊的指令，能够对新闻组和文章的管理进行自动化处理）。它们虽然必要且实用，但也存在被滥用的情况。垃圾信息经常受到自动删除程序（cancelbots）的打击，但这些自动程序很有可能会被坏人利用。而且，在线规范并不总是符合所有人的期望。Usenet 社区愿意采取技术手段来解决第一次大规模的垃圾信息爆发⁶，但其他问题，比如真正的新纳粹分子（在misc.kids新闻组中由 NAMBLA⁷ 成员发布的帖子）以及soc.motss⁸ 新闻组中的恶意行为者等，则需要通过社会施压来解决。（注意：Usenet 上很早就出现了第一个新纳粹分子。我并没有夸张，但我不会提及他的名字，以免给他带来更多关注。）

在此，我想分享一些经验教训。首先，技术上的诚信至关重要。其次，安全和功能性之间的平衡并非固定不变——环境和需求都会随着时间而改变。B-news 在取消消息功能大规模使用和滥用之前就已经存在了很长一段时间，此前其用户群体保持着良好的行为规范，并非是因为没有发现 B-news 的安全漏洞：1982 年我在贝尔实验室面试时， Dennis Ritchie 对我说的第一句话就是：“B-news 是个恶魔工具！” 最后，规范很重要，但整个社区必须共同决定如何执行这些规范。

关于公钥加密问题，我还有一些感想。1979 至 1981 年间，Usenet 软件正在开发之中。那时，公钥密码学尚未获得专利，也没有关于加密技术出口许可的规定。如果我们当时眼光更长远一些，或者更具前瞻性，我们完全可以将相关功能嵌入到软件之中。这样一来，该代码将在任何专利颁发之前广泛传播，使得专利执行变得极其困难。然而，这也意味着我和Tom、Jim 以及 Steve Daniel（Usenet 软件首个发布版本的开发者）可能会面临来自联邦调查局的严厉盘问。但毫无疑问，网络密码学的历史将会因此改写。试想一下，如果密码学在 80 年代早期就已经普及，那么如今的网络世界将会是怎样一番景象呢？这是一个非常值得探讨的有趣话题。

正如我在前文所述，我们确实预料到了可能出现的滥用问题，并在最初的公开声明中对此发出了警告：

显然，我们最担心的还是通过uucp连接发动黑客攻击。（对于同时熟悉 uucp 和安全领域的我们来说，如果认为uucp是安全的，那么显然有些天真。颇具讽刺的是， Jim Ellis 和我最后都成为了安全领域的专家……）

然而，我们还担心其他滥用行为。声明中提到了过度消耗资源的风险；这一点我们从 Dennis Ritchie 在《贝尔系统技术期刊》上发表的一篇文章⁹中有所了解。引用他的话来说：

值得注意的是，我们在公告中提出的“很容易发现……”部分与 Ritchie 的结论存在相似之处。

不过，根本问题在于我们当时对如何应对一无所知，甚至不清楚会遇到哪些具体问题。我本人确实担心过安全问题 —— 1971 年左右，我抓到了人生中的第一个黑客。当时，有可疑活动触发了一条控制台消息，我便去检查了相关程序的打孔卡（是的，就是打孔卡！）。不过安全问题并不是我当时的关注领域。话虽如此，当Robert Morris 和 Ken Thompson 发表了那篇关于密码的著名论文（Password Security: A Case History） ¹º后，我编写了一个简易的密码猜测器，并告知一些人他们设置的密码有多么糟糕。（我收到过一个回复：“我的密码是 ‘abscissa’，其他人根本不知道怎么拼写，所以不会有问题。”呃……）我们应该是在发明 Usenet 时期收到了那本《通讯ACM》，但具体是什么时候看到的那篇论文，我已经记不清了。

当时我们是否担心过网络喷子和其他网络上的恶劣行为？从 40 年后的今天来看，很难回答。就像前文提到的，我们确实预料到有人会将二手车广告发布在不适当的地方。但我们无法预料到，仅仅几年时间，Usenet 就会发展成那个样子。

我们计划在 1980 年 1 月的 Usenix 会议上发布 Usenet。那时候的 Usenix 会议规模还比较小，通常在大学里举行，氛围也比较轻松随意，不需要预订酒店会议室等场地。[我已记不清 Usenix 究竟从什么时候开始变成如今正式的学术会议，但肯定是 1984 年或之前，因为那一年我还在后来被称为年度技术大会（Annual Technical Conference）的会议项目委员会任职。] 这一次的会议在博尔德（Boulder）¹¹，我并没有参加，不过 Tom Truscott 和 Jim Ellis 都去了。

除了公告本身，我们当然还需要经过验证的代码，而我的原型代码显然无法满足要求。虽然我现在已经记不清我所开发的 C 语言版本到底有哪些缺陷，但其中一个可能的问题是无法配置哪些相邻站点会接收哪些新闻组。Stephen Daniel（同样来自杜克大学计算机科学系）编写了后来被称为“A-news”的代码。其中一个重要改动是能够支持多个层级结构（hierarchies），而不仅仅是原来的“NET”或“NET.*  ”。（作者注：我在前文中曾经说过，为了向多个站点分发新闻组，我的版本切换到了“NET. *”，而非单一NET。我现在无法确定的是，这个功能是在我的 C 语言版本还是 Steve Daniel 的版本中加入的。我只知道，他的版本肯定支持其他层级结构，而我的肯定不支持。）生产版本中也可以配置站点将接收哪些新闻组或层级。为了确保程序正常运行，这个配置必须放在一个文件中，而不是内置到代码中的数组。

数组的使用有时并不明显。在分发新闻组时，uucp就使用了一个数组¹²来列出允许远程站点执行的命令。

char *Cmds[] = {"mail","rmail","lpr","opr","fsend","fget",NULL};/*  to remove restrictions from uuxqt *  redefine CMDOK 0 * *  to add allowable commands, add to the list under Cmds[] */

为了允许执行rnews，系统管理员必须修改源代码（当时大多数人都拥有 Unix 的源代码）并重新编译。从现在的角度来看，这是一个明显的错误决定，但当时或许情有可原：你还能做什么呢？可用的命令少得可怜。（需要说明的是，我已经记不清fsend、fget或opr的具体用途。我猜想它们可能用于发送和接收文件，以及打印到一台位于贝尔实验室默里山计算中心的霍尼韦尔计算机上。这让我想到了/etc/passwd文件中古老 的GCOS¹³ 字段。）

为了解决这个问题，我们提供了一个 mail-to-rnews 程序。发送站点可以直接通过电子邮件发送文章，而非直接执行rnews程序。守护进程（daemon）会定时运行，自动检索电子邮件并将其传递给rnews程序。之所以需要定时运行守护进程，是因为当时的邮件系统无法直接将邮件发送到程序或文件。（这么做是否是出于安全考虑？并非如此，而是遵循了当时 Unix 追求简洁的设计理念。当然，这也确实提高了安全性。）因此，A-news 程序的远程站点配置文件也需要知道一个要执行的命令。

正式公告可在此处查看（从第15页开始）：https://www.tuhs.org/Archive/Documentation/AUUGN/AUUGN-V02.4.pdf。公告中包含一些值得关注的要点：首先，正如我在本文第三部分所述，公告中规定了杜克大学可以向其轮询的站点收取电话费；杜克大学教职人员对该项目给予了大力支持。与此同时，北卡罗来纳大学的教职人员也知道我参与了 Usenet 的开发。

回顾早期 Usenet 发展历程，一个颇有意思的细节是当时我们对于 Usenet 大规模应用场景的设想。“最早的文章可能会涉及 bug 修复、问题报告和求助。” 鉴于我们当时对系统方面的密切关注，我们设想中的 Usenet 内容更接近于最终出现的新闻组comp.sys.unix-wizards。值得一提的是，当时不仅在 Usenix（最初名为 Unix 用户组）等组织内，而且在 IBM 大型机世界，程序员之间都存在着非常浓厚的互助文化。维基百科上关于 SHARE 的文章¹⁴对此进行了很好的解释。

从一开始，SHARE 程序库（SHARE library）就是 SHARE 的一个重要资源。最初，IBM 以源代码形式发布软件，系统程序员常常对其进行一些小的本地改动或添加，然后与其他用户交换这些修改。SHARE 程序库以及这种分布式开发的过程，是开源软件的主要起源之一。

另一个设想是利用 Usenet 查找有趣的源代码，但要避免将其扩散到整个网络。因为当时软件通常比较大，电话费用也相对昂贵。公告中估计，夜间通话费约为每三分钟 0.5 美元。这听起来还算合理，但即使在美国，不同距离的费率也会有所不同。在那个年代，300 bps（即每秒 30 字节）的速度下，最多只能传输 5400 字节。考虑到协议开销，我们保守估计为 3000 字节，也就是每分钟 1 千字节。以uucp的源代码为例，其大小约为 120 KB。按照 1KB/秒的速度传输，需要两个小时，花费约 20 美元。如果考虑到通货膨胀¹⁵，这相当于今天的 60 多美元。然而，大多数人并不需要大部分软件包。此外，杜克大学当时只有两个自动拨号器，无法提供足够的带宽向多个站点发送大文件。如果强行这样做，就会阻塞其他站点的新闻传输。因此，当时的提议是建立一个中央存储库，由某个站点（如杜克大学）负责维护。用户可以根据需要从该存储库中检索所需的软件。这种模式后来被 UUNET 采纳，我将在下文中介绍。

不过最有意思的是，Usenet 公告中完全没有提到任何非技术用途。我们完全忽略了社交讨论、兴趣爱好交流、政治辩论或类似的其他话题。即使我们考虑过这些，也会局限在本地使用——毕竟，谁会想和从未见过面的人讨论这些话题呢？

很长一段时间里，我的预测似乎过于乐观了（我当时预计每天会有1-2篇文章发表）。到了夏天，只有四个新站点加入：里德学院、俄克拉荷马大学（至少我认为uucp上的节点uok是它）、vax135（另一台贝尔实验室计算机），最重要的是，加州大学伯克利分校也加入了。它通过uucp连接到贝尔实验室，并接入了ARPANET。

理论上来说，如果 Usenet 获得指数级增长，即使增长速度缓慢，也终将覆盖全世界。但前提是，不会出现导致增长率变为负数的“死亡”。不过，这个假设并不合理。当时我和 Jim Ellis、Tom Truscott、Steve Daniel 都计划完成学业（最后我们都实现这一目标，顺利毕业了）。如果到那时 ，Usenet 还没有向继任者证明它的价值，他们就会任其消亡。此外，大学教职人员或贝尔实验室管理层也有可能叫停它。所以 Usenet 很容易在起步阶段就夭折。但幸运的是，在加州伯克利大学，有人做出了正确的决定。

Mary Horton¹⁶当时是伯克利的一名博士研究生。（毕业后，她加入了贝尔实验室。在她和我以及一些同事的努力下，TCP/IP 在贝尔实验室投入使用，在那里这项技术有时被称为“数据报异端”。当然，那时的电话网络还是电路交换……）Mary Horton 意识到有两个非技术的 ARPANET 邮件列表（而我们对此一无所知）将会让潜在的 Usenet 用户产生极大的兴趣：HUMAN-NETS 和 SF-LOVERS。她设置了一个网关，将这些邮件列表转发到 Usenet 讨论组。这些列表后来被移动到fa（“来自 ARPANET”）层级中。有关这部分内容的更详细叙述，请参考Ronda Hauben 的著作¹⁷。有了真正的流量来源，向人们推广 Usenet 就变得容易多了。其实人们更希望连接到真正的 ARPANET ，但这在当时很难实现，而学生也根本不可能自己设置：ARPANET 连接仅限于与 DARPA 签订研究合同的机构。最终，加州伯克利大学的网关实现了 Usenet 和电子邮件的双向连接，使得网络之间能够进行类似 Usenet 的通信。

显然，SF-LOVERS 邮件列表是科幻迷的聚集地；和现在一样，系统管理员往往都是科幻小说的忠实粉丝。HUMAN-NETS 则有些难以描述。本质上，它讨论的是网络的普及对社会的影响。如果 HUMAN-NETS 延续至今，它将成为讨论在线隐私、虚假新闻以及仇恨言论等问题的天然场所，同时也涉及网络的积极效应：比如获取世界上大部分的知识，包括多年前常常难以获取的一手资料，以及促进人与人之间更便捷的交流。

事实上，当时网关在技术上是否合规并不明确。ARPANET 原本只允许授权的 ARPANET 站点使用；那么为什么会允许它与另一个网络建立连接呢？据我所知，官方说法是认为这项技术仅在伯克利大学内部使用，所以才批准；但给我的实际印象是，人们将它看成了一个有趣的实验。官方限制的原因是为了防止政府资助的网络与当时尚处于萌芽阶段的私人数据网络竞争；而 Usenet 是非商业性的，所以并没有被视为威胁。

在 ARPANET 上，uucp电子邮件地址由uucp明确路径和 ARPANET 主机名构成。这是在域名系统¹⁸出现之前；当时 ARPANET 采用的是扁平（flat）的命名空间。我的地址应该是这样的：

research!duke!unc!smb@BERKELEY

但也可以是

research!duke!unc!smb at BERKELEY

在那个时代，at可以与@相互替换……

随着站点数量的增长，新闻组和文章数量也随之增加，A-news 用户界面的局限性愈发凸显。Mary设计了一套新的方案，由高中生Matt Glickman实现，这套方案最终演变为B-news¹⁹。

B-news 加入了诸多改进，其中最重要的便是能够按新闻组阅读文章，并支持乱序阅读。相比之下，A-news 仅按文章到达顺序显示内容，且只存储最近阅读的文章编号。此外，输入文件格式也更接近电子邮件格式，更加方便用户使用。下面是来自RFC 1036²º的示例：

From: jerry@eagle.ATT.COM (Jerry Schwarz)Path: cbosgd!mhuxj!mhuxt!eagle!jerryNewsgroups: news.announceSubject: Usenet Etiquette — Please ReadMessage-ID: <642@eagle.ATT.COM>Date: Fri, 19 Nov 82 16:14:55 GMTFollowup-To: news.miscExpires: Sat, 1 Jan 83 00:00:00 -0500Organization: AT&T Bell Laboratories, Murray Hill在一行空行之后，便是消息内容。

From:和Path:行的同时加入是 B-news 最有趣的改进。From:用于发送电子邮件，而Path:则用于追踪哪些站点已经接收过该文章。此外，还存在一种隐含假设：即会有合适的 ARPANET-to-uucp网关（可通过 DNSMX记录识别）来处理电子邮件的转发。不过，当时这样的网关在很大程度上还是一种愿景，混合模式地址仍然是主流。

B-news 还加入了控制消息功能。正如前文所述，这些没有经过验证的消息很可能导致恶意行为。除了取消消息之外，控制消息主要用于创建新的新闻组——任意创建新闻组反而会影响其扩展。

控制消息还支持网络映射，但效果并没有达到我们的预期。简单来说，senduuname消息的目的就是让站点计算出到达目的地的最短uucp路径，这样一来，用户不再需要费力记住长路径，同时又提供了比简单重走 Usenet 路径更短的邮件路径。（这项功能也提升了可靠性，因为uucp邮件，特别是经过多个 hop 后，并不完全可靠。）我的代码（在 Peter Honeyman²¹彻底重写后，成为了我发表的第一篇论文²²）发挥了作用，但却从未被正确集成到邮件系统中，这使得短路径甚至比长路径还不可靠。

最后，系统内部也进行了改进。A-news 把所有消息都放在一个目录里，但随着消息数量的增加，这种做法严重影响了性能。而 B-news 为每一个新闻组都设置了单独目录，并在目录下设置子目录，从而反映了它的层级结构。

Usenet 的发展也带来了负面影响：一些站点开始变得不愿意继续承担负载。贝尔实验室研究部门曾是其中一个主要转发站点，但当时的部门主管 Doug McIlroy²³意识到 Usenet 的增长速度非常快，转发负载有可能使站点过载——星形网络在面对大规模扩展时效率较低。因此，他下令停止邮件转发。这本可能会导致非常严重的问题，但幸运的是，其他一些站点开始承担这部分负载，其中最重要的便是 DEC 公司 Unix 工程组的decvax。

这项工作由Bill Shannon和Armando Stettner²⁴领导。另一个重要的转发站点是seismo，由地震研究中心的Rick Adams²⁵运营。Rick 后来创立了 UUNET，成为美国第一个商业互联网服务提供商。在贝尔实验室，由Gary Murakami管理的ihnp4也成为了一个核心站点。（有趣的是，虽然我在 1982 年底才加入贝尔实验室，但我并没有创建另一个站点。当时年纪尚轻，我认为自己无法承担这项任务。但这并非因为管理层不了解 Usenet；事实上，在我第一天上班时，我的中心主任（比我高三级）就向我打招呼说：“嗨，Steve，我曾在 Netnews 上看到过你的愤怒言论。” 这件事让我很早就意识到，网络上的言行确实可以传达一个人的声誉。

更多负载问题请见下文。

重命名事件（The Great Renaming）²⁶在 Usenet 历史上具有重大意义，因为它涉及诸多方面，包括技术、资金和治理等。从个人角度来看（请记住，本系列博文仅仅是我的个人回忆），它也标志着我作为“官方”管理 Usenet 的终结。之所以为“官方”加引号，是因为对于一个扁平化、分布式的系统来说，想要真正掌控它绝非易事，因为它缺乏内置的验证控制机制。

与 Usenet 许多其他重大变化一样，“重命名”的原因在于流量的增长。这里并不是指个人消耗的流量，而是站点发送、接收和存储的流量。简单来说就是流量太大了。而当时新闻组的命名结构又加剧了这一问题：它过于扁平，缺乏有效的层级结构来管理负载。现有的层级结构[比如“net”、“f”（表示“来自 ARPA”，即进入Usenet 新闻组的 ARPA 网络邮件列表）、以及“mod”（表示审核过的新闻组）]并非基于语义，而是基于内容的呈现方式：任何人均可发帖（net）、从邮件列表中转发（fa）、或者由审核者控制（mod）。显然，为了便于管理，必须要采取一些措施。但是谁拥有做出此类决定的权威和权力呢？

虽然理论上 Usenet 的所有节点都是平等的，但实际情况并非如此。技术上来说，虽然 Usenet 连接被认为是一个图 （graph）²⁷，但实际上它更类似于一组星形网络 （star networks）：极少数节点的连接度极高，它们既为众多末端站点提供信息，也相互之间进行通信。这些节点之间的连接构成了 Usenet 事实上的网络骨干，而这些主要节点的管理员则掌握着巨大的权力。他们与少数 Usenet 的“老前辈”（包括我和Gene Spafford²⁸）共同组成了后来被称为“骨干联盟” （Backbone Cabal）的组织。骨干联盟在法律上并没有权力；然而在实际操作中，任何被整个联盟排斥的新闻组都将无法在流量源头区域之外获得广泛传播。

在采取措施之前的很长一段时间里，人们已经意识到这一问题的存在。比如，Chuq von Rospach²⁹发表的这篇文章³º可以说是第一个详细提案。其核心思想与最终采用的方案一致：将新闻组按主题和信噪比进行层级组织。信噪比在当时是一个很严重的问题；某些新闻组里的“噪音”比许多网页上的“评论”还要多。不过，结果是一样的：站点可以通过广泛的分类来轻松选择他们想要接收的内容，而不是通过冗长的新闻组列表。

与电子前线基金会（Electronic Frontier Foundation）的说辞³¹相反，这项改进从来不是为了通过审查（即使是为了防止 Usenet 因制造某种丑闻引发众怒进而威胁到项目生存而设计的审查）。我们从没有向管理层隐瞒过任何骨干站点；正如我在前文所述，管理层非常清楚 Usenet 的存在，并且愿意为骨干站点承担电话费用。（文中说“公司规模太大，以至于其与 Usenet 相关的长途电话费在每月巨额账单中微不足道” —— 很抱歉，我所接触的任何组织都不会有这样的操作。每个子部门都有自己的预算，必须自行支付电话费。）确实存在预算问题和对丑闻的担忧，但根据我的回忆，这些问题更多出现在一些非骨干站点。骨干站点必须管理它们的 feed，而这就需要层级结构。

关于 Usenet 为什么要“重命名”，维基百科将其归结为两个主要原因：一是列出哪些站点将接收哪些新闻组所带来的复杂性，二是 seismo 到欧洲的海外链路成本问题。这一说法也许是对的；我个人对其他事的具体记忆已经模糊，但我可以确定的是，负载问题一直是一个主要因素。

最终的重命名方案经过了大量讨论，并对最初的提案进行了修改。方案被采纳后，随即引发了反对行动。为了摆脱“骨干联盟”的控制，alt层级作为一组新闻组被创建出来，并且取得了成功。究其原因，是因为技术已经发生了变化。一方面，电话费用在下降；另一方面，互联网的普及意味着 Usenet 不再需要通过按分钟计费的电话传输。1986 年初发布的 RFC 977³² 提出了通过互联网传输 Usenet 的标准。换句话说，骨干联盟对内容和分发的控制只是名义上的。alt层级的成功表明 Usenet 已经度了一个关键点：少数节点的消失并不会毁掉 Usenet。作为对这种局面的回应（至少是部分原因），“骨干联盟”逐渐销声匿迹，——但这也留下了一个悬而未决的治理问题：谁能够或应该控制网络？

Usenet 讨论的早期话题之一便是新闻组的创建方式。当时，新闻组的创建主要依靠投票表决，尽管这种方式存在一些缺陷和不足，但也促进了对改进方案的探讨³³ 。另一个备受关注的问题是垃圾信息和不当内容的泛滥，如“自动取消程序”的出现等。此外，人们从很早就开始担忧法律责任³⁴、司法管辖权³⁵、版权³⁶等问题，这些问题至今仍未得到有效解决。基本上，围绕新闻组的管理方式，当时的核心争论集中在两种截然不同的观点之间：完全放任不管与实施某种形式的控制。然而，后者不仅需要就谁拥有控制权达成共识，还需要创建合适的技术来执行控制。这两个问题也一直延续至今，我将在下一部分内容中继续探讨。

Usenet 已经走过了 40 年的历程。回首往昔，我们不禁要问：当初的设计决策是否正确？在当时的技术条件下，如果我们能够有所预见并通过学习某些知识后采取措施，有哪些事我们可以做得更好？对于当下的经验教训又有哪些？

现在想来，一些决策显然是正确的。对于当时预期的通信量和连接性，泛洪算法是唯一可行的选择。按理来说，我们应该设计一个“have/want”协议，但好在之后很容易就能添加这样的功能 —— 以NNTP（Network News Transfer Protocol，网络新闻传输协议）的形式。早在80年代中后期，关于如何构建“have/want”协议（甚至在拨号连接上）就曾有过讨论。事实上，最初的 Usenet 公告中就明确包含了这种协议的变体：

通过支持“按需获取新闻”（news on demand）功能，可以进一步减少流量。可以将一篇文章（如 x.c）提交到没有任何人订阅的新闻组（如 “NET.bulk”）。然后，任何节点都可以通过文章名称请求该文章，这将沿着请求者到贡献系统的路径生成一系列新闻请求。理想情况下，只需要少数几个请求就能找到 x.c 的副本。虽然“按需获取新闻”功能需要每个节点都拥有网络路由图，但无论如何这种做法都是可取的。

同样，我们几乎可以肯定，建立一组相连的星形节点（当然也包括杜克大学）的计划是正确的决定。当时很少有站点拥有自动拨号器，但大多数站点都有一些拨入端口。

缺乏加密验证和相应的控制机制虽然是个比较棘手的问题，但我仍然认为我们当时做出了正确的决定。首先，彼时学术界的密码学文献还非常匮乏。我们只是听说过 DES、RSA 和陷门背包（trapdoor knapsacks）等加密算法，却不知道后两者实际应用的工程参数。就像我在前文提到的那样，我们甚至不知道去寻找某篇有可能解决这个问题的学士论文。如今，我对密码学有了更深入的了解，或许能利用 1979 年的工具解决这个问题（但请注意，当时加密哈希函数还没出现）。但在那时，我确实对这些一无所知。

而且，这里还存在一个更隐晦的问题。加密工具用于执行政策，但当时我们并不知道这些政策应该是什么。事实上，我们在公告中明确地表示过这一点：

这是一个关键点：如果你不知道想要什么样的政策，就无法设计出与之对应的执行机制。同样，你必须清楚由谁负责执行政策，才能确定谁应该持有加密密钥等重要权限。

今天的在线社区在这个问题上从未给出令人满意的答案。Twitter（现更名为X）曾称自己是“言论自由党的言论自由派”³⁷；而如今，它在如何处理特朗普的推文³⁸ 等问题上举步维艰，并且出现了要求监管社交媒体的呼声。再加上国际层面的因素，这就变成了一个异常棘手的问题 —— 而 Usenet 在架构设计上就是去中心化的。

Usenet 从未尝试解决治理问题（即使在其非常有限的话题领域内）。如今，实现一个让发帖人可以取消自己文章的方案非常简单。但除此之外，很难决定控制权应该交给谁。Usenet 最好的尝试是骨干联盟和创建新闻组的投票机制，但前者在“重命名大事件”后解散了，因为它被认为缺乏公众的认可，而后者则非常容易被滥用。

在技术上，使用阈值密码学让选定的 N 个中的 M 个“受托人”来管理 Usenet 是可行的，但在政治上却行不通， 除非“投票者”（如何定义投票者？如何确保每个 Usenet 用户只有一票投票权？）能够就如何选择 Usenet 受托人以及他们的权力范围达成一致。全球范围内，对于政府应该如何产生或应该拥有哪些权力都还没有达成共识；即使只针对 Usenet，引入加密机制也无法解决这个问题。

我们确实在设计中犯了一个重大失误：我们都没有预料到 Usenet 会如此成功。我们从没问过自己：“如果流量远超预期该怎么办？”

在一些细节方面，我们其实可以做得更好。新闻组一开始就可以采用层级结构，并从一开始就建立更多层级分类。虽然最初的层级划分可能并不完美，但像计算机、其他科学、人文社科、地区和部门等分类都很明显，与最终的划分结果也较为接近。

一些更实质性的改进可以从头文件格式入手，使其更具扩展性。我们虽然不了解RFC 733³⁹（即 ARPANET 当时的邮件标准），但应该可以轻松找到。不过，我们确实很清楚在文章开头使用字符“A”的重要性——便于修改协议。（题外话：添加版本指示符很容易，但要确保其与下一个版本兼容却并非易事，因为这往往需要预知未来版本的语法和语义。B-news 并没有以“B”开头的文章，因为这与其头文件格式不兼容。）

最成功的功能也存在一些不足之处，如无法按新闻组浏览文章，也无法在同一个新闻组内按时间顺序阅读文章。讽刺的是，Twitter 即使到了今天也存在同样的问题：你只能看到单一的“时间线”，没有便捷的方法标记推文以便稍后阅读，也无法将不同的发帖人归类到不同的类别（“推文组”？）。是的，存在“列表”功能，但将内容加入列表并不意味着你在主时间线中不会再次看到它。（题外话：也许这就是我花太多时间在 Twitter 上的原因，无论是我的主账号还是摄影账号。）

怀着对技术往昔的追忆，如果我决定重新设计 Usenet，它会是什么样子呢？

不，我不会再设计 Usenet 了。暂且不论世界需不需要另一个充斥噪音的社交网络，光是人类的注意力就难以应付如此庞大的信息量。Usenet 时代的在线用户数量相对较少，但其信息密度就已经让用户不堪重负了。如今互联网用户数量激增，已经达到了数十亿。我的意思是，就算我为新一代的 Usenet 列出许多显而易见的特性，比如分布式、点对点、加密验证、隐私保护等等，但人们仍然无法处理如此庞大的信息，并且像非法内容、极端分子、网络喷子、组织管理等棘手问题也仍然存在。世界已经前进，我也一样。如今的交流方式多种多样，也许确实有新的需求，但 Usenet（这种试图支持许多不同话题的单一基础设施）可能不是最合适的模式。

还有一个更微妙的地方。Usenet 作为一种存储转发式的批处理网络，其设计受限于当时的技术。如今，我们拥有了功能丰富的永远在线网络，人与网络的交互方式将会且应该发生彻底的改变。比如，也许我们可以只与同时在线的用户互动——这或许是一件好事。

Usenet 应运而生于那个时代，但类似的创造在当时的环境下也必然会出现。正如科幻作家 Robert Heinlein 在The Door into Summer⁴º中所言：“只有到了该修铁路的时候，才会有人去修。”这句话的推论是，当修建铁路成为必要时，人们总会采取行动。BBS⁴¹要比 Usenet 稍早一些，但直到上世纪 80 年代 Hayes 智能调制解调器的普及，它们才得以广泛应用。此外，1981 年创立的 CSnet⁴²（一个介于 ARPANET 和拨号站点之间的官方邮件网关）的目标也与 Usenet 有相似的地方。我们常开玩笑说，教授们想要做点什么，通常会写个提案，然后拿到一大笔资金。而我们这些研究生则直接撸起袖子干，不用等什么文书和官方批准。

与这些同时期的创造相比，Usenet 则有所不同。BBS 在 FidoNet⁴³出现之前一直采用单一站点模式，而 Usenet 从一开始就是分布式网络。CSnet 则拥有中心化的管理机构，而 Usenet 则有意奉行自由放任的原则，在设计上允许边缘区域的有机生长，不依赖任何需要资金支持的中央站点。尽管存在一些缺陷，Usenet 却在长达 20 多年的时间里连接了全球众多用户，直到今天社交网络的崛起。虽然用户群和使用模式发生了变化，但 Usenet 历经 40 余年依然存在。

注释:

1. https://www.cs.columbia.edu/~smb/blog/2018-02/2018-02-23.html

2. https://www.scientificamerican.com/article/mathematical-games-1977-08/

3. https://dl.acm.org/doi/10.1145/359340.359342

4. https://groups.csail.mit.edu/cis/theses/kohnfelder-bs.pdf

5. https://www.newsweek.com/april-fools-day-april-fools-kremvax-kremlin-soviet-union-usenet-piet-beertema-318451

6. https://www.wired.com/1999/04/the-spam-that-started-it-all/

7. https://en.wikipedia.org/wiki/North_American_Man/Boy_Love_Association

8. https://slate.com/technology/2014/08/online-gay-culture-and-soc-motss-how-a-usenet-group-anticipated-how-we-use-facebook-and-twitter-today.html

9. https://archive.org/details/bstj57-6-1947

10. https://dl.acm.org/doi/10.1145/359168.359172

11. 博尔德是美国科罗拉多州的一座城市，位于落基山脉的山脚下，距离丹佛市西北约25英里（40公里）。博尔德以其自然美景、户外活动和健康生活方式而闻名，同时也是科罗拉多大学博尔德分校的所在地。

12. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/uucp/uuxqt.c

13. https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/man/man5/passwd.5

14. https://en.wikipedia.org/wiki/SHARE_(computing)

15. https://www.in2013dollars.com/us/inflation/1980?amount=100

16. https://en.wikipedia.org/wiki/Mary_Ann_Horton

17. http://www.columbia.edu/~rh120/ch106.x10

18. https://www.rfc-editor.org/rfc/rfc882.html

19. https://www.rfc-editor.org/rfc/rfc1036.html

20. https://www.rfc-editor.org/rfc/rfc1036.html

21. http://www.citi.umich.edu/u/honey/

22. https://www.cs.columbia.edu/~smb/papers/pathalias.paper.pdf

23. https://www.cs.dartmouth.edu/~doug/

24. https://en.wikipedia.org/wiki/Armando_Stettner

25. https://en.wikipedia.org/wiki/Rick_Adams_(Internet_pioneer)

26. https://en.wikipedia.org/wiki/Great_Renaming

27. 图（Graph）是由节点和连接这些节点的边组成的一种数学结构。图可以用来表示各种关系，例如网络连接、社交关系、路线等。图论是研究图及其性质和应用的数学分支。

28. Gene Spafford，全名Eugene H. Spafford，是一位计算机科学家和安全专家，以其在计算机安全领域的杰出贡献而闻名。他是美国普渡大学的教授，同时也是Purdue CERIAS（计算机安全研究与教育中心）的创始人和主任。

29. https://www.chuq.me/about-chuq

30. https://groups.google.com/g/net.news/c/VlDhiCyknOQ

31. https://www.eff.org/deeplinks/2019/11/altinteroperabilityadversarial

32. https://www.rfc-editor.org/rfc/rfc977.html

33. https://groups.google.com/g/net.news/c/Nl1BOAmIuic

34. https://groups.google.com/g/net.news/c/Nl1BOAmIuic

35. https://groups.google.com/g/net.news/c/pRe7iZPX-M8

36. https://groups.google.com/g/net.news/c/-YT1GJA7hQ8

37. https://www.theguardian.com/media/2012/mar/22/twitter-tony-wang-free-speech

38. https://www.vanityfair.com/news/2019/06/jack-dorsey-twitter-may-finally-censor-trump-warning-label

39. https://datatracker.ietf.org/doc/pdf/rfc733.pdf

40. The Door into Summer 是一部由美国科幻作家 Robert A. Heinlein 于 1956 年创作的小说。主角 Daniel Boone Davis 是一位成功的发明家，开发了一系列家用机器人。然而，他却遭到了未婚妻和商业伙伴的背叛，失去了公司和发明。失意的 Dan 选择冷冻休眠，30年后在未来醒来。醒来后，他不仅要适应新的环境，还要面对过去的阴影和复仇。在这个过程中，Dan 发现了时间旅行的秘密，并利用这一能力改变了自己的命运。

41. https://www.nytimes.com/2019/12/20/technology/randy-suess-dead.html

42. CSnet 是 Computer Science Network 的缩写，是在 1981 年成立的一个国际性计算机网络。它最初由美国国家科学基金会（NSF）资助，旨在为大学和研究机构提供计算机通信服务。CSnet 的目标是通过提供廉价的网络连接来促进学术界之间的合作和信息交流，尤其是在计算机科学领域。

43. FidoNet 是一个全球性的计算机网络，于 1984 年由 Tom Jennings 创建。它主要用于在电子邮件和文件传输流行之前，通过拨号调制解调器连接的 BBS 交换消息和文件。FidoNet 使用一套标准协议，使得不同系统之间能够有效通信，是早期互联网的重要前驱之一。

    
    

作者简介：

Steven M. Bellovin 是哥伦比亚大学计算机科学系教授，专注于安全、隐私及公共政策研究。Bellovin 在贝尔实验室和 AT&T 实验室研究所（担任AT&T Fellow）工作多年后，于2005年加入哥伦比亚大学。他在研究生期间共同创立了 Usenet，并因此与 Tom Truscott 和 Jim Ellis 一起获得了1995年 Usenix 终身成就奖。2023年，他与 Matt Blaze 和 Susan Landau 一起因在计算机安全和隐私方面的公共政策工作再次获得该奖。Bellovin 还获得了 2007 年 NIST/NSA 国家计算机系统安全奖，并入选了网络安全名人堂。他曾担任联邦贸易委员会首席技术官以及隐私和公民自由监督委员会的技术学者。

他是美国国家工程院院士，曾任美国国家科学、工程和医学院计算机科学和电信委员会委员。他著有Thinking Security（国内出版名为《阻击黑客：技术、策略与案例》）并合著Firewalls and Internet Security: Repelling the Wily Hacker。

最后再次附上由Steven M. Bellovin 教授提供的Usenet珍贵资料：

原文链接：https://www.cs.columbia.edu/~smb/blog/2019-11/2019-11-14.html

致谢:

感谢赵军老师对本文的审校。

特别感谢 Steven M. Bellovin 教授将《Usenet的早期历史》一文授权 The Nexus 翻译及发布。