Chrome测试邮箱验证API免验证码回填隐私引争议

Google 已为 Email Verification API 开启 Chrome Origin Trial，桌面版 Chrome 150 起可参与测试。该提案由 WICG 推动，目标是在不发送验证邮件的情况下，由浏览器确认用户确实拥有所填写的电子邮件地址；Gmail 是首个参与的邮箱服务商。

这套机制试图替代一次性验证码和魔法链接。用户提交邮箱后，浏览器会在后台通过三方模型获取签名令牌：网站作为验证方，邮箱服务商作为签发方，浏览器负责中转。如果用户已登录邮箱服务，令牌会自动填入表单，网站服务器再在提交时完成校验。Google 表示，签发方不会知道具体是哪一个网站发起了验证请求，从而减少跨站关联。

前端接入相对简单，邮箱输入框需要增加 autocomplete 提示，并加入携带会话绑定 nonce 的隐藏字段；服务器端则必须使用服务商密钥验证令牌签名。Resend 的 Phil Nash 已发布流程指南、npm 软件包和 Next.js 示例，帮助开发者处理令牌解析与校验。

支持者认为，该方案能消除注册时离开页面、打开收件箱、复制验证码再返回的繁琐过程。开发者反馈称，跳转邮箱是注册流程中最糟糕的上下文切换之一，甚至曾因此放弃几十次乃至数百次注册；验证邮件被拦截、进入垃圾箱或延迟送达的问题，也可能随之减少。

不过，社区对隐私和复杂度存在明显分歧。批评者认为，邮箱服务商不知道请求来自哪个网站并非实际功能，反而可能限制依赖不同邮箱别名进行识别的开发者；例如 name+site@example.com 这类地址若无法由服务商证明归属，仍需退回传统验证流程。还有观点认为，网站完成验证后依旧可能发送欢迎邮件和营销提醒，因此隐私提升有限，并担心新协议会增加小型开发者的负担，逐渐把身份能力集中到浏览器中，类似 FedCM 或密码管理器的发展路径。

未登录 Chrome 中 Gmail 的用户仍会使用传统确认邮件，现有的语法、MX 和 SMTP 检查服务也可覆盖 API 暂不支持的地址。测试团队还需注意后续兼容性变化：Chrome 154 已加入 Android 与第三方 Origin Trial，将 Sec-Fetch-Dest 的签发值改为 email-verification；Chrome 156 起，电子邮件地址会按用户提交时的原样返回。该 API 目前仍属实验性提案，更适合以渐进增强方式部署，并继续根据网站、邮箱服务商和用户反馈调整协议。