无形的墙：reCAPTCHA Mobile Verification 如何将硬件认证扩展到桌面端

多年来，对抗机器人的战斗一直通过日益复杂的谜题展开：识别红绿灯、选择人行横道以及点击复选框。然而，一场根本性的转变正在发生。Google 正在超越行为分析和简单的谜题，转向基于硬件的认证 (hardware-based attestation)，这一举措实际上允许服务提供商要求提供加密证明，以确认用户正在使用经过批准的设备和经过认证的操作系统。

虽然这被呈现为一种打击欺诈和机器人的安全措施，但这一转变的影响——特别是通过新的 "reCAPTCHA Mobile Verification"——远超出了缓解机器人的范畴。它代表了我们访问开放网络方式的一种潜在架构转变，从“你知道什么”或“你的行为如何”的模型转向“你拥有什么硬件”。

硬件认证的机制

这一转型的核心是诸如 Google 的 Play Integrity API 和 Apple 的 App Attest API 之类的 API。这些系统允许开发者验证应用程序是否运行在真实的、未经修改的设备和经过认证的操作系统版本上。

在历史上，这些都是以移动端为中心的工具。然而，Google 现在正通过 reCAPTCHA Mobile Verification 将这种逻辑引入桌面端。其过程简单但影响深远：当桌面用户遇到无法通过传统手段通过的 reCAPTCHA 时，可能会被提示使用智能手机扫描二维码。该智能手机必须是经过认证的 Android 设备（运行 Google Mobile Services）或 iOS 设备。随后，移动设备将执行硬件认证并为桌面会话“背书”。

安全功能还是反竞争工具？

Google 和 Apple 将这些 API 描述为安全所必需的，特别是对于银行和政府服务。然而，包括 GrapheneOS 项目在内的批评者认为，这是反竞争行为的伪装。

GrapheneOS 的视角

GrapheneOS 是一个专注于隐私和安全的 Android 分支，是附带损害的一个主要例子。尽管 GrapheneOS 可能比许多经过认证的 Android 版本更安全，但它被禁止通过 Play Integrity API 的“强完整性 (strong integrity)”级别，因为它没有获得 Google Mobile Services (GMS) 的许可，也不遵守 Google 限制性的许可协议。

“当 Google 允许那些十年都没有补丁的设备，却不允许一个安全性更高的操作系统时，其安全借口显然是虚假的。这完全是为了通过 GMS 许可来强化他们的垄断。”

“锁定”效应

通过将硬件认证作为通过 reCAPTCHA 的要求，Google 创造了一种局面，即 Linux 桌面、OpenBSD 或自定义 Android ROM 的用户可能会发现自己被排除在互联网的绝大部分之外。如果一个网站要求使用“已验证”的设备来通过验证码，而验证的唯一方式是通过 Google 或 Apple 认证的设备，那么这种双头垄断实际上就成为了互联网访问的守门人。

更广泛的生态系统影响

机器人的终结（以及爬虫）

一些观察人士指出，此举是对 AI 代理和网络爬虫的战略打击。通过要求在无头浏览器 (headless browser) 中难以伪造的硬件支持密钥，Google 可以有效地终结从其搜索结果和其他受保护界面进行的大规模自动化数据采集。

监管悖论

当前的监管格局中存在着一种苦涩的讽刺。虽然欧盟多年来一直在因反竞争行为对 Google 和 Apple 进行罚款，但一些欧盟政府同时正在强制在数字 ID、年龄验证和支付系统中使用 App Attest 和 Play Integrity。这创造了一个循环，即监管机构正在鼓励他们声称反对的锁定行为。

是否有替代方案？

对于希望避免参与这种硬件认证生态系统的网站所有者来说，选择虽然有限但确实存在。虽然 Cloudflare 和 Google 占据了市场主导地位，但仍存在一些开源替代方案，如 Anubis 和 Cap，而像 Proton 这样的公司已经开发了自己的内部验证码解决方案以维护用户隐私。

结论：互联网访问的未来

硬件认证是强大的安全工具，但当它通过 reCAPTCHA 应用于通用网络时，它面临着将互联网从开放协议转变为许可系统的风险。当访问政府服务或银行的能力取决于拥有特定品牌的硬件并运行特定的专有操作系统时，“开放网络”就成了一个误称。未来的挑战在于，监管机构和开发者能否找到一种在不牺牲使用任意硬件和软件的权利的情况下验证人类身份的方法。