摘要

  • HotJava 小程序把部分浏览器扩展从预先安装的处理程序改为随网页传来的 Java 代码，并在读者电脑上执行。
  • 这种灵活性依赖本地权限策略；Sun 的 Alpha2 文档明确说公钥加密当时尚未实现，之后的独立审查也在 HotJava Alpha3 中发现了安全缺陷。

1995 年，网页可以描述一个交互对象，但传统浏览器必须事先知道怎样解释它。HotJava 提供了另一种补上能力的办法：页面引用 Java 小程序，浏览器下载程序，再在自身内部运行。网络传送的不只是文档，也包括解释文档所需的一部分机制。

Sun 把这种设计描述为摆脱固定格式和协议清单的途径。新的图像格式可以连同显示程序一起提供，新协议也可以带上自己的处理程序。HotJava 白皮书设想，读者不必逐一安装每个新软件。这些是设计目标与示例，不等于新机制已在全网普及。

这一变化也重写了兼容性安排。Alpha2 小程序指南说明，程序可嵌入 HTML；不认识新标签的浏览器可以忽略它，继续显示页面其余部分。静态内容还能降级呈现，但新行为只有 HotJava 能执行。作者不用等待每家浏览器厂商加入新处理程序，就能提供更丰富的页面；读者则需要兼容运行环境，并允许代码在本机运行。

因此，读者的电脑成为关键边界。Sun 在 1995 年 10 月的白皮书把类型检查、字节码验证和运行时控制列为防护措施。但版本说明限定了这份承诺：Alpha2 是面向 Solaris/SPARC 的原型，README 明确指出公钥加密尚未实现。限制程序能做什么，与确认程序由谁提供，是两个不同的问题。

Alpha3 文档把权限策略摆到用户面前。安全设置提供从禁止小程序访问，到仅允许来源主机、特定防火墙网络，再到不受限制的多个级别。文件读写也受路径列表控制；默认写入路径为空，但系统管理员可以配置。安全边界并非一句“Java 是安全的”，而是围绕远程程序设置的规则、默认值和管理选择。

1995 年的公开讨论已触及这一区别。W3C 的 www-talk 邮件列表参与者争论：隔离执行环境是否足够，还是还需证明下载代码确实来自可信来源。这只是一场有分歧的讨论，并非社区共识。1996 年，Drew Dean、Edward Felten 与 Dan Wallach 独立检查 HotJava Alpha3，记录了多项缺陷，包括拒绝服务风险。后来的审计不能说明每位 1995 年用户当时知道什么，却说明沙箱必须持续接受测试与维护，不能被当成永久保证。

HotJava 的历史意义在于移动了扩展点：内容作者可以把可执行行为与页面一同发送，读者及其管理员则承担决定本地程序可触及哪些资源的责任。新增浏览器能力所需的协调成本降低了，终端侧的安全保障负担却上升了。史料支持的是一个原型和一套曾被争论的架构，而非普及规模、绝对安全或 Web 使用方式变化的量化结论。

史料与证据边界