Chrome推邮箱验证新API：免复制验证码，隐私争议未停

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 应用在验证后不会给你发欢迎邮件、入门邮件或提醒邮件？（用户隐私并没有得到增强）

他的结论是，这套新流程什么毛病都没解决，反倒让一切更复杂。（从长远来看，复杂性帮的是大公司，坑的是小公司）

还有人评价：尚待证实，但感觉像一份要把 Web 带向封闭的 Google 草案。

另一些评论者认为，签发方查不到请求来自哪个网站算不上什么功能，反而是“功能性缺陷”。有开发者依赖每个接收方各用不同地址，比如使用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 则继续收集网站、服务提供商和用户的反馈。