Web 开放性或遭重大打击！谷歌四名工程师推出 WEI 方案，可让广告拦截变成历史

最近，谷歌提出了一项名为“Web 环境完整性（WEI）”的提案，由其四名工程师撰写。这是一种确定浏览器是否可信的方法，有助于防范欺诈和其他不良行为。

谷歌在 Chrome 中进行原型设计，目前看起来它已经被推送到了 Chromium 中。另外，苹果去年已经开发和部署了一个极其相似的系统，现已集成到 MacOS 13、iOS 16 和 Safari 中。

但互联网社区中也有人担心，这正是大家最不愿看到的“网络的终结”：“这是对开放Web的重大打击之一，可能为少数科技巨头主导的数字体系铺平了道路。”“这几乎让广告拦截变成了不可能的事情”......

提案背景

这项提案于今年 4 月以代码形式出现，并在 5 月份正式公布，但并未引起技术社区的过多关注。上周五被定为在拟规范草案并更新后，才引起了关注 Chromium 开源项目 Blink 渲染引擎的人们的在意。

谷歌工程师们将 WEI 描述为浏览器客户端通过第三方（例如 Google Play）同服务器建立信任的一种方式，由该第三方提供可证明客户端环境完整性的令牌。

简单来说，WEI 为浏览器提供了一种方法，能够证明其正按网站运营商的预期工作、没有受到操纵。举例来说，如果大家拥有一个 Web 页面游戏网站并想要确定玩家没有作弊，那就可以使用 WEI 来确定接入的客户端纯粹、合法，且没有运行任何作弊代码。

对于那些不希望自动机器人跑来发帖或点赞的网站，WEI 也能帮上大忙——所有参与活动必须通过可接受且未更改的浏览器来完成。对于想要通过浏览器发布内容和广告的经营者来说，肯定不希望自己的努力最后都被发给了机器人。

这也标志着整个 Web 将走向新的时代：网站只接受经过授权的、正式发布的浏览器。

而由于 Chromium 不仅是谷歌 Chrome 浏览器的基础，更是微软 Edge、Brave 等众多其他浏览器的基础，因此一旦 WEI 得到部署和采用，很可能对网络产生广泛的影响。

规范草案解释道，“Web 环境完整性 API 允许用户代理向证明者申请裁量，该裁量可用于验证 Web 环境的完整性。这些裁量将通过管线传送给依赖方，并在期间验证其真实性。Web 环境完整性机制最适合检测各类欺诈性 Web 环境。”

从解释“Web 环境”的待办事项相关链接来看，这项提案目前仍未公布太多细节。

该 API 的既定目标是解决网络上长期存在的各种问题：社交媒体操纵与造假；机器人检测；在应用程序中滥用 WebView；批量网络劫持与账户创建；在网络游戏中作弊；入侵设备；以及密码猜测尝试。

然而，这里的“滥用”并没有明确定义。因此，尽管规范作者提到目标是“提供一种对抗性强、且长期可持续的反滥用解决方案”时，但其实很难确定其要打击哪些对象。

概念并不新鲜

在网络交互当中建立信任的思路并不新鲜。Android 和 iOS 生态系统都已存在用于验证原生应用的类似 API。行业内也出现了类似的提案——例如 PrivacyPass、Trust Token API 以及 UserConfidenceScore 等。WEI 的前身最初于 2022 年 4 月被提出，当时就引发了关于设计后果的担忧和质疑。

总体来讲，如果人们不信任建立该技术的实体，那么为 Web 客户端建立信任机制就会变得更加困难。

WEI 于 4 月底在 W3C 反欺诈社区小组中接受了审议，并作为浏览器功能开发的正常迭代过程被部分发布到网络之上。

尽管该规范尚处于设计阶段，但上周很快有批评意见出现，开始占领 WEI 的 GitHub repo 甚至针对提案作者进行谩骂。谷歌开发者的回应是，将评论权调整为仅向此前为该 repo 做过贡献的用户开放，同时发布了一份行为准则文件、提醒人们保持文明。

反馈意见中的担忧包括：可能违反欧盟数据规则；所有网络交互都须接受认证——但谷歌明确否认了这一点；新浏览器难以继续发展；人们对谷歌普遍不信任；担心 Web 领域出现 DRM（数字版权管理）；拦截能力可能存在限制等等。

有 15 年全栈开发经验的 Alex Ivanovs 就直言谷歌此举就是想让广告拦截变为“不可能”。

而更多人认为这不仅仅是广告拦截的问题，这也意味着“竞争”的结束。

仅可在 Chrome、Safari 或 Edge 上浏览互联网（无需修改或扩展），意味着不允许浏览器的竞争。

只能在 macOS、Windows、Android 或 iOS 上浏览互联网，意味着不允许操作系统领域的竞争。

只有谷歌才能抓取互联网，意味着搜索引擎也没有了竞争。

对垄断的恐惧

作为 iOS 设备越狱工具 Cydia 的开发者，Jay Freeman（又名「Saurik」）在一篇帖子中，将该提案描述成基于广告的商业模式之下“Web 必将踏上的一条不归路”。

在一封采访邮件中，Freeman 表示很长一段时间以来，Web 最初采取的开放标准、可供任何人构建兼容浏览器的立场早已被打破。如今的软件正变得越来越复杂。

在他看来，由于被塞进了越来越多的功能以满足 Web 内容发布者的期待，其实只有少数几款浏览器能跟得上时代变化。

“如果网站开始要求「用户证明自己使用的是这小部分值得依赖的浏览器之一，即未对其原始行为做出修改，而后才愿意向真实用户展示其广告」，那么未来市面上恐怕再难觅浏览器新秀的踪影。”

Freeman 还认为，WEI 的问题绝不仅限于阻碍浏览器市场的正常竞争。

他强调，“我觉得这里还有更大的利害关系——比如剥夺了大家对计算机的控制权。这项功能要想成立，唯一的原因也许就是大多数人都在计算机上采用到 DRM 技术，比如 Arm TrustZone 和英特尔 SGX。”

“马斯克现在希望每个人只使用官方 Twitter 应用跟他的服务对接；Reddit 近期也在朝着类似的方向发展：向应用程序公开可信计算原语，意味着可以确保仅官方客户端才能正常访问网站。如果谷歌也加入这波潮流甚至予以推动，那么我相信这不仅是对开放 Web 的重大打击之一，甚至也是对我们迄今为止所看到的、对运行通用计算机的基本自由的严重侵犯——自此之后，我们将无法信任运行在「不可信」操作系统上的浏览器。”

Freeman 补充称，“我当然相信谷歌至少在其提出的用例上是诚实的……只是这样的倾向性令人感到不安：广告发布者希望自己基于广告的商业模式继续起效，所以才要求用户只能使用匹配这个前提的受信浏览器。所以这个规范的本质，似乎更像是要求用户自己向内容发布者证明，他们没有运行任何广告拦截器。”

提案是否会被搁置或丢弃？

本周一，Mozilla 公司 Web 平台高级首席工程师 Brian Grinstead 也对该提议表达了反对。

“Mozilla 公司反对这项提议，因为它违背了我们对于 Web 原则和发展愿景的初衷。……检测欺诈和无效流量确实是个颇具挑战的问题，我们也有意参与并帮助解决。但是，这项提案没有解释它要如何在列出的用例上取得实质性进展，而且在实际采用后还会带来明显的缺点。”

在熟悉浏览器技术开发的群体中，微软 Edge 合作伙伴产品经理、谷歌前高级工程师 Alex Russell 也在 Mastodon 上发帖，敦促人们在 WEI 充分发展成熟前先不要急于做出判断。

Russell 指出，“特别是在早期设计阶段，很多想法都大有问题。但没关系，API 设计就是需要经历这样的问题空间，而探索其潜力的最佳方法不是推断最坏的情况，而是展示工作内容并证明其至少拥有哪些价值。”

前谷歌工程师、现供职于 Tailscale 的 Chris Palmer 上周在另一篇 Mastodon 帖子上，认为这项提案是个坏主意。

他写道，“远程认证严重冲击了激励措施。如果把客户变成了自己的敌人，那你离失败也就不远了。而如果一套框架把广告发布者的客户变成了自己的敌人，那这东西就应该被扔进垃圾堆里。”

自由技术顾问 Ondřej Pokorný同样在 Mastodon 上表达了类似的观点。“整个「隐私沙箱」和其他想要取代「合法」第三方用例的提案，最大的问题就在于其中提出的各种 API 把浏览器从用户代理变成了双重代理。这虽然符合广告商和其他企业者的利益，但却往往与用户利益存在冲突。”

Palmer 补充称，“最好的结果，就是谷歌明天一早就直接撤回这项提议。其中已经没有任何调整和修复的余地，唯一的选择是丢弃然后道歉。”

面对大量的负面讨论，谷歌工程师给大家初步的回应是： WEI 的目标是提供设备可信的信号，让网络更加私密和安全，并且还留有一个余地，通过保留措施防止平台级别的锁定。比如在一定比例的情况下，例如 5% 或 10%，WEI 证明会被故意省略，看起来像用户选择退出 WEI 或设备不支持 WEI 一样。最后他们还强调了会“将继续公开设计、讨论和辩论”，但反对在个人页面讨论问题，随后他们锁定了该 Github 页面并从个人页面中删除了此提案。

显然，他们的回复作用有限，网友点评：谷歌这相当于在说“我们是好人，相信我！”

参考链接：

https://www.theregister.com/2023/07/25/google_web_environment_integrity/?td=rt-3a

https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd

https://github.com/mozilla/standards-positions/issues/852

https://httptoolkit.com/blog/apple-private-access-tokens-attestation/

https://github.com/RupertBenWiser/Web-Environment-Integrity/issues/28

https://beehaw.org/post/6820219

https://news.ycombinator.com/item?id=36875226