Chrome 想终结“去邮箱复制验证码”，但隐私真的更好了吗？

Google 为 Email Verification API 开放了 Chrome Origin Trial。这是一项 WICG 提案，允许浏览器确认访问者拥有其输入的电子邮件地址，而无需发送任何邮件。试用从桌面版 Chrome 150 开始，Gmail 是首个参与的服务提供商。

这一构想旨在取代大家熟悉的一次性验证码或魔法链接。目前，用户输入电子邮件地址后，需要离开当前页面前往收件箱，复制验证码再返回，这种上下文切换常常会导致用户流失。该提案采用三方模型，浏览器位于网站（“验证方”）和邮箱服务提供商（“签发方”）之间。如果用户已经登录邮箱服务，浏览器会在后台获取一个签名令牌并将其填入表单，服务器则在表单提交时验证该令牌。Google 指出，签发方不会知道是哪家网站发起了请求。

对于开发者而言，前端实现相当直接。电子邮件字段需要添加 autocomplete 提示，并增加一个携带会话绑定 nonce 的隐藏输入字段：

<input id="email"><input nonce={nonce}>

复制代码

更繁重的工作位于服务器端，需要使用服务提供商的密钥检查令牌签名。Resend 的 Phil Nash 撰写了一篇介绍整个流程的实践指南，还发布了一个 npm 软件包和一个 Next.js 示例，用于处理令牌解析和验证。

在 Hacker News 上，一名开发者表示，在注册过程中跳转到收件箱“简直是最糟糕的上下文切换”，电子邮件验证已经让他放弃了“几十次，甚至可能几百次”注册。另一名用户指出，验证邮件经常被拦截或过滤到垃圾邮件中，而用户无法判断邮件只是延迟还是已经丢失，因此，移除这一环节确实是一项改进。

“用户隐私得到了增强，因为请求由浏览器中转，签发方不知道是哪一个 Web 应用发起了请求。”如今，每个 Web 应用都会在验证后向你发送欢迎邮件、入门邮件或提醒邮件。（用户隐私并没有得到增强）

所以，我们得到了一套什么问题都没有解决、却让一切变得更加复杂的新流程。（从长远来看，复杂性帮助的是大公司，伤害的是小公司）

另一名评论者认为，签发方无法得知请求来自哪家网站并不是一项功能，而是“功能性缺陷”。依赖每个接收方使用不同地址的开发者，例如使用 name+site@example.com 的开发者，指出只要邮箱服务提供商无法证明这些别名，流程仍然必须回退到传统方式。其他人则将其比作 FedCM，认为它正在像密码管理器曾经做过的那样，把身份能力整合进浏览器。

如果用户没有在 Chrome 中登录 Gmail，网站就会回退到传统的确认邮件；现有的语法、MX 和 SMTP 检查服务仍然可以覆盖该 API 无法处理的电子邮件地址。

已经开始测试的团队应关注破坏性变更。Chrome 的十月更新在 Chrome 154 中加入了 Android 和第三方 Origin Trial，将 Sec-Fetch-Dest 的签发值重命名为 email-verification，并从 Chrome 156 开始按照用户提交时的原样返回电子邮件地址。验证方和签发方指南会持续跟踪当前协议约定。

Email Verification API 仍是一项实验性提案。目前最适合将其作为渐进增强功能使用，同时由 WICG 继续收集网站、服务提供商和用户的反馈。

原文链接：https://www.infoq.com/news/2026/10/chrome-email-verification/