Google Cloud Fraud Defence 只是 WEI 的重新包装

# Google Cloud Fraud Defence 不过是 WEI 的重新包装 来源：https://privatecaptcha.com/blog/google-cloud-fraud-defence-wei/ 2026年5月，Google [宣布](https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-fraud-defense-the-next-evolution-of-recaptcha/) 推出“Google Cloud Fraud Defense —— reCAPTCHA 的下一步进化”。该公告描述了一种二维码挑战，用户需要用手机扫描二维码以证明人类身份。 Google 在2023年因标准机构反对而终止了 Web Environment Integrity。如今，三年后，相同的设备认证机制以商业产品形式推出。 开放网络之所以幸存，是因为没有任何一家公司可以决定哪些硬件是“合法”的、可以用于访问网络。Google 决心打破这一现状——现在通过一次 reCAPTCHA 更新来实现。 目录 - [Google 在2023年已经尝试过这个](#google-already-tried-this-in-2023) - [二维码将被绕过](#the-qr-code-will-be-bypassed) - [二维码认证码和设备认证并不新鲜](#qr-auth-codes-and-device-attestation-are-not-new) - [设备认证排斥最需要隐私的用户](#device-attestation-bars-the-users-who-need-privacy-most) - [“合法”的追踪](#legitimate-tracking) - [最后想法](#final-thoughts) ## Google 在2023年已经尝试过这个 WEI 提交 2023年6月，一位名叫 Yoav Weiss 的 Google 工程师向 Chromium 项目提交了一份 [提案](https://github.com/chromium/chromium/commit/6f47a22906b2899412e79a2727355efa9cc8f5bd)，名为 *“Web Environment Integrity”*。这种机制很直接：浏览器会要求设备硬件签署一份加密认证，证明浏览器未被修改且运行在 Google 认证的硬件上。网站可以验证签名，并决定是流畅地提供内容还是增加挑战。当然，该提案将其框架为保护网络完整性，防止机器人和自动抓取。 Mozilla 在数天内发布了 [正式立场](https://github.com/mozilla/standards-positions/issues/852)。该提案 *“违背用户利益”*，并 *“创建了一个由操作系统和设备供应商控制的封闭互联网”*。电子前沿基金会 将其 [称为](https://www.fsf.org/blogs/community/web-environment-integrity-is-an-all-out-attack-on-the-free-internet) “Chrome 对网络进行 DRM 的计划”，指出根据设计，只有运行在 Android 或其他认证硬件上的 Chrome 才能轻松通过认证，从而在结构上将流量引向 Google 生态系统，这并非副作用，而是必然结果。 Google 在发布三周后撤回了 WEI。Chromium GitHub 线程关闭。公开宣告死亡。 2026年5月，Google [宣布](https://cloud.google.com/blog/products/identity-security/introducing-google-cloud-fraud-defense-the-next-evolution-of-recaptcha/) Google Cloud Fraud Defense，并在博客文章中将其描述为 *“reCAPTCHA 的下一步进化”*。该系统通过二维码挑战用户：用手机扫描以确认人类身份。要求页面指定了符合条件的硬件：*“安装了 Google Play Services 的现代 Android 设备，或现代 iPhone/iPad”*。 *“安装了 Google Play Services”* 在这个句子中意义重大。Google Play Services 是 Google 的闭源软件层，运行在认证过的 Android 设备上，并提供认证 API——特别是 Play Integrity API——用于证明设备未被修改且已获得 Google 批准。没有 Play Services 的设备无法满足 Fraud Defense 所需的 Play Integrity 检查级别。这不是一个等待工程解决的技术限制。这**就是**机制本身。 WEI 审查流程，无论其局限性如何，都要求 Google 公开捍卫该机制。提案被撤回是因为反对理由成立。而对于 Fraud Defense，没有任何流程需要回应。产品发布了。要求页面上线了。那些在 2023 年被记录在案的反对意见所指向的相同认证基础设施，现在成为了一项商业服务的基础，任何拥有 Google Cloud 结算账户的组织都可以使用。 ## 二维码将被绕过 QR Captcha 挑战的工作原理是这样的：用户遇到 Fraud Defense 提示，被要求用手机摄像头扫描二维码。手机通过 Google 的 Play Integrity API 进行认证，确认设备是认证硬件。该确认信息返回给源网站，作为人类身份的证明。 其破解方式很简单：机器人操作员将摄像头对准屏幕——使用现成的硬件即可实现简单的自动化。对于需要 Play Integrity 认证的操作，一台兼容的 Android 设备价格大约 `$30`（准确来说是沃尔玛的 `$29.88` [链接](https://www.walmart.com/ip/Straight-Talk-Motorola-Moto-g-2025-5G-64GB-Blue-Prepaid-Smartphone-Locked-to-Straight-Talk/14552506783)）——对于专业机器人农场来说，批量购买设备只是固定成本，不会对运营造成实质性干扰。 还有一个值得注意的失败点：一位事件响应专业人士在 [HN 帖子](https://news.ycombinator.com/item?id=48039362) 中提出了一个独立于机器人问题的担忧： > 我们该如何现实地教会 HR 部门的 Susan 区分真正的 Google Captcha 二维码和恶意的钓鱼二维码——实际上这是不可能的。 二维码挑战训练用户扫描代码以访问网站。钓鱼活动将立即利用这种被训练出来的行为。 ## 二维码认证码和设备认证并不新鲜 在苹果世界中，iOS App Attestation 验证应用是否通过 App Store 安装且未被修改。它控制的是应用：一个用户购买 iPhone 时自愿选择进入的围墙花园。将其扩展到开放网络浏览则完全不同：它将 URL 访问权限依赖于私人公司认证过的硬件。此前没有这种应用于开放互联网的先例。应用商店是选择加入的生态系统，有明确的条款。而网络本不应有硬件层面的条款。 Smart ID 基于二维码的认证系统本身已经存在一段时间了。爱沙尼亚的 [Smart ID](https://www.smart-id.com/) 使用二维码验证用户，但仅限于有明确边界和用户同意的资源：银行门户、政府服务、健康记录。用户选择进行身份验证。受保护的资源事先定义。范围明确。Google Cloud Fraud Defense 将设备认证应用于开放网络，应用于操作员选择封锁的任何 URL，没有同等的同意架构，没有目的限制，而且很可能用户完全不知道他们的硬件身份正在充当访问凭证。 ## 设备认证排斥最需要隐私的用户 Google Play Integrity 认证需要 Google Play Services。[GrapheneOS](https://grapheneos.org/) 是经过安全加固的 Android 分支，被 EFF 推荐，并被高风险环境中的记者、律师和活动人士使用，默认情况下不附带 Play Services。它支持一个沙盒兼容层，可以运行部分 Play Services 功能，但这不能满足 Fraud Defense 所需的 `MEETS_DEVICE_INTEGRITY` 级别。[LineageOS for microG](https://lineageos.org/)（一个针对希望使用开源替代方案的用户的注重隐私的 Android 发行版）同样失败。任何排除 Play Services 的自定义 ROM 都会失败。 Firefox for Android 未出现在 Google 声明的 Fraud Defense 浏览器支持列表中。这并非疏忽。Firefox 出于设计原因未集成 Google Play Integrity——Mozilla 在 2023 年关于设备认证的立场非常明确，并且至今仍然适用。实际效果是：最注重隐私的主流移动浏览器的用户默认被排除在验证访问之外，不是因为他们可能是机器人，而是因为他们使用的软件拒绝参与 Google 的认证架构。 ## “合法”的追踪 治理问题是显而易见的反对理由。追踪问题则较少受到关注。 每次 Fraud Defense 挑战成功解决时，都会向 Google 发送一个信号：这个经过认证的设备在此时访问了此网站。设备认证不仅限制访问——它还会产生归属信息。一个具有稳定硬件身份的设备会创建一个跨越会话、浏览器和隐私浏览模式的持久标识符。定义哪些硬件“合法”的公司，同时也在积累该硬件在开放网络上访问过的记录。这不是欺诈防御的副作用。这是将验证绑定到经过认证的设备身份这一决策的架构性结构结果。 在技术上存在一个可行的替代方案，它既避免了治理问题，也避免了追踪问题。Private Captcha 和 [类似的工作量证明系统](https://privatecaptcha.com/blog/self-hosted-captcha-comparison-2026/) 发布加密挑战，需要与（非）正比于数量的计算工作。一个人类解决单个挑战只需付出微不足道的代价。一个机器人农场运行并发会话时，每增加一次尝试都会面临指数级的计算成本；而 AI 代理无论推理能力多强，消耗 GPU 周期来运行，都会面临相同的代价。无需传输硬件标识符。无需任何认证。没有认证层来决定谁可以参与。用户隐私在结构上得到保护，而非仅仅被承诺。 ## 最后想法 Google Cloud Fraud Defense 不是一次 reCAPTCHA 更新。二维码是可见机制，但设备认证才是真正的产品。每一个已解决的挑战都告诉 Google，哪个经过认证的硬件在什么时间访问了哪个网站。那些在 2023 年被标准机构拒绝的相同基础设施，现在在商业发布的背后运行，积累着归属数据——而 WEI 作为公开提案时，绝不可能被允许在未受质疑的情况下积累这些数据。具有讽刺意味的是，与它旨在“改进”的版本类似，它同样无法阻止机器人。