摘要

  • W3C 安全兴趣组 9 月 22 日发布的《Threat Model for the Web》草案，把文档／来源执行环境与浏览器控制的 API 调解区分开，并分别标出请求及返回值、事件或错误。
  • 前一天的版本把用户代理概括成一个进程。新图仍只是逻辑模型，不是在规定 Chromium、Gecko 或 WebKit 的真实进程划分。
  • 对网页的调用记录进行审查，不能据此直接认定权限由谁授予、隔离在哪里执行；这是本文的审查推论，并非 W3C 新设的合规要求。

一段网页脚本要求使用某项敏感能力时，开发者很容易记录函数名、参数和返回结果。这样的日志回答的是网页做了什么，却未必回答浏览器允许了什么。用户看到的按钮可能是网站绘制的界面，也可能是浏览器自身掌控的提示；两者在权限问题上并不是同一位决策者。如果把一次成功调用写成“浏览器已经认可”的证据，审查就从过程跳到了结论。

9 月 22 日的草案为这一步提供了一张更清楚的底图。最高层 L0 将 PO-02 定义为文档与来源的执行环境，把 PO-01 定义为浏览器控制的调解。DF-05 是前者送出的 Web API 请求，包含调用、选项或参数；DF-06 是后者返回的值、Promise 完结、事件、状态或者错误。TB-02 不是某款产品的沙盒名称，而是区分不同来源和上下文权限的一组抽象边界。远端网站和用户则被单独列为外部实体。

这确实是一天之内的文本变化，但不能夸大成浏览器安全机制刚被发明。9 月 21 日版的 L0 把用户代理写作单一进程 P0，以 S0 表示浏览器管理的状态，再用较宽泛的流线连接网站、网络与操作系统。旧版已经指出：若要知道哪个组件存储状态、调解权限或执行隔离，必须查看更细的浏览器模型。新版的新闻增量，是把网页发出请求及浏览器作出回应的往返直接放进最高层。

低一层的模型进一步描写特权浏览器功能、处理不可信网页内容的执行环境，以及网络、存储和操作系统能力的入口。它提醒审查者：做出安全检查的部件，与运行网页代码的部件，未必拥有同样的权限。但不同浏览器的具体实现并不一致；L0 文本也明确说它不宣称 Chromium、Gecko、WebKit 必须有某一种进程边界。不能拿这张图为任何现行产品背书。

文件本身的权威边界同样需要辨清。它是安全兴趣组认可的 Group Note 草案，不是 W3C 或其成员认可的正式建议。这个系列早在 5 月就已发表初稿。威胁分析与控制措施章节仍注明尚未完成。三份一手材料都没有报告某款浏览器被攻破、一次权限测试通过，或某条 API 从此必须新增弹窗。

更实际的用法，是把审查记录拆成网页请求、浏览器裁决、回到网页的结果，以及具体实现在哪里执行该裁决四栏。草案使中间那道边界不再隐身；真正存在的控制，仍要靠产品与配置的证据说明。

来源