InfoQ

Chrome Opens Trial for the Email Verification API: Letting Sites Verify Without Sending Emails

6.9内容质量
Chrome Opens Trial for the Email Verification API: Letting Sites Verify Without Sending Emails

TL;DR · AI 摘要

Chrome Opens Trial for the Email Verification API: Letting Sites Verify Without Sending Emails - InfoQ InfoQ Homepage Ne...

核心要点

  • 主题聚焦：Chrome Opens Trial for the Email Verification AP
  • 来源：InfoQ，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#前端#后端#安全
打开原文

Chrome启动电子邮件验证API试验：让网站无需发送邮件即可验证 - InfoQ

InfoQ 首页 News Chrome启动电子邮件验证API试验：让网站无需发送邮件即可验证

Web开发

从令牌到功能：为AI辅助工程构建成本归因架构（10月29日网络研讨会）

Chrome启动电子邮件验证API试验：让网站无需发送邮件即可验证

2026年10月28日 2分钟阅读

作者：

  • Daniel Curtis

#### 关注我们

Youtube

232K关注者

Linkedin

26K关注者

Instagram

新

RSS

19K读者

X

57.1k关注者

Facebook

21K点赞

Bluesky

收听这篇文章 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

谷歌已为电子邮件验证API（WICG提案）启动Chrome原产地试验，该提案允许浏览器在不发送任何消息的情况下确认访客拥有其输入的电子邮件地址。该试验从Chrome 150桌面版开始，Gmail作为首个参与提供商加入。

这一方案取代了常见的一次性验证码或魔法链接。目前用户输入电子邮件后，需要前往收件箱复制验证码再返回，这种上下文切换往往会导致用户流失。该提案采用三方模型，浏览器位于网站（"验证方"）和邮箱提供商（"签发方"）之间。如果用户已登录提供商，浏览器会静默获取签名令牌并将其填入表单，服务器在提交时验证该令牌。谷歌指出签发方永远不会知道哪个网站发起了请求。

对于开发者而言，前端实现相对直接。电子邮件字段需要自动完成功能提示，以及携带会话绑定随机数的隐藏输入：

code
<input id="email" name="email" type="email" autocomplete="email">
<input type="hidden" name="token" nonce={nonce} autocomplete="email-verification-token">

更复杂的工作在服务器端，需要将令牌签名与提供商的密钥进行比对。Resend的Phil Nash编写了该流程的详细指南，发布了npm包和Next.js示例来处理解析和验证。

在Hacker News上，有开发者表示"在注册过程中跳转到收件箱简直是史上最糟糕的上下文切换"，并指出电子邮件验证导致他们"损失了数十甚至数百个未完成的注册"。另一位开发者指出验证邮件经常被拦截或归类为垃圾邮件，延迟消息和丢失消息之间没有明显区别，因此移除验证邮件是真正的改进。

有评论者质疑隐私声明的合理性：

让所有能正常运作的东西变得复杂。没有任何优势。"用户隐私得到增强，因为签发方无法通过浏览器中介知道是哪个网站发起的请求。"如今每个网页应用在验证后都会发送欢迎邮件、引导邮件和提醒邮件。（没有用户隐私增强）所以我们得到一个解决不了任何问题但让一切变得更复杂的流程。（而复杂性长期来看有利于大公司，损害小公司）未验证但感觉像谷歌的草案，正在关闭网络。

另一个观点将发行者对请求站点的“功能缺陷”视为一种“功能缺陷”而非特性。依赖于按接收者地址（如 [email protected]）的开发人员指出，该流程在提供商无法验证这些别名时仍会强制回退。其他人则将其与FedCM进行类比，将身份原语折叠到浏览器中，就像密码管理器曾经做的那样。

在Chrome之外且已登录Gmail账户的情况下，网站会退回到经典的确认邮件，而现有的语法、MX和SMTP检查服务仍能覆盖该API无法处理的地址。

正在测试的团队应跟踪重大变更。Chrome十月更新在154版本中增加了Android和第三方来源试验，将Sec-Fetch-Dest发行值重命名为email-verification，并从156版本开始原样返回用户提交的电子邮件。验证者和发行者指南跟踪当前的契约。

电子邮件验证API仍然是一个实验性提案，目前最佳用法是作为渐进增强功能，同时WICG从网站、提供商和用户处收集反馈。

作者部分主容器

关于作者

章节标题

每个作者的主容器

#### Daniel Curtis

显示更多

显示更少

#### 本内容属于Web开发主题

##### 相关主题：

  • 开发
  • Web开发
  • JavaScript
  • TypeScript
  • Chrome
  • Google
  • 电子邮件
  • 相关编辑内容
  • 相关赞助商
  • 相关赞助商 2026年12月15-16日。探讨资深从业者如何在生产环境中运行代理、评估、模型服务和AI辅助工程，包括哪些失败了以及发生了什么变化。立即注册。

InfoQ新闻通讯

每周二发送上周InfoQ内容的摘要。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。