Private Verification Tokens：Chrome 正在探索什么，以及 BotBrowser 当前如何处理

隐私浏览可能让回访用户看起来像新客户端。Private Verification Tokens（PVT）是针对该问题的站点范围提议，并非已发布能力；BotBrowser 当前不会启用 PVT，也无法让网站信任一次隐私访问。

要点速览

• PVT 仍是提议，不是普遍可用的浏览器功能。
• 该设计希望把受限的信任结果带入隐私上下文，而不暴露浏览历史。
• BotBrowser 当前不会启用、伪造、导入或预置 PVT token。
• 应分别测试普通与隐私浏览流程，不要让生产决策依赖 PVT。

目录

• 观看视频
• 先说结论
• PVT 要解决什么问题？
• 概念流程
• PVT 是提议、实验，还是已发布功能？
• 对隐私浏览意味着什么？
• 运营者现在可以怎么测试？
• 实践结论

观看视频

这段英文视频对照平台记录解读 Private Verification Tokens 提议：Chrome Platform Status 将其列为已提议、未发布。随后本地实验页面在 Ubuntu（Chrome 154）和 Windows（Chrome 155）的稳定版 Chrome 控制台中，询问浏览器自己是否有包含 “verification” 的 feature-policy 条目，并用隐私上下文读回页面打印隐私上下文当前能看到什么。两台主机各运行一次，都打印出 0 个匹配项和没有 PVT 接口，这并不说明任何其他版本或站点。测试不涉及 BotBrowser 配置文件。音轨为英文。

连接策略提案属于另一条浏览器边界：Connection Allowlists：Chrome 发布与适用边界说明为什么不能把带日期的公告、ChromeStatus 快照和 WICG 草案合并成一个支持结论。

先说结论

Private Verification Tokens（PVT）是 Chrome 公开讨论中的一项隐私浏览提议。它设想让网站在普通浏览期间获得一个受限的信任凭证，并在之后的隐私浏览请求中收到一个不暴露浏览历史的窄范围信号。这个想法仍处于提议和实验阶段，不是已经交付的通用 Web 能力。在受控测试中，BotBrowser 可以让同一配置文件的指纹表面在普通会话和私密会话之间保持一致；但它无法让网站接受私密访问者。

目前，Chrome Platform Status 将 PVT 标记为 proposed、尚未发布。BotBrowser 当前不启用 PVT，也不会伪造、导入或预置 PVT token。理解这些事实，比把一个状态页上的名称当成现成能力更重要。

有关相邻的隐私边界，可对照无痕模式检测和浏览器指纹验证。这些是浏览器和网站各自的决策，不是 PVT 已经发布的证据。

PVT 要解决什么问题？

公开方案使用 Sec-Private-Verification-Token 描述这一受限请求信号。

隐私浏览的目标是减少长期状态和跨会话关联。一个全新的私密上下文通常没有普通配置文件中的 Cookie、站点存储或登录状态，因此网站很难区分以下两种情况：用户刚刚打开了一个干净的私密窗口，或者客户端确实没有任何可复用的站点状态。关于私密窗口会限制哪些本地记录、谁仍然能看到活动，请参阅无痕浏览能做什么，不能做什么，其中也说明了哪些内容会随会话关闭。

在这两种情况下，网站都可能要求额外验证。对用户而言，这会造成不必要的摩擦；对网站而言，完全忽略这类请求又可能放大误判。PVT 提议探索一个更窄的中间点：浏览器可以携带“这个浏览器曾经从该站点获得过有效信任信号”的证明，但不把普通浏览会话本身交给网站。关于私密窗口为何不会改变浏览器指纹，请参阅为什么无痕模式无法防御指纹追踪，其中逐步对比了普通会话与私密会话。

这里的“信任”不是身份声明，也不是用户认证。它不应回答用户是谁、访问过哪些页面，或 token 是在哪一次会话中产生的。公开设计强调的是最小化信号：只回答一个注册站点是否可以收到一个有效、受限的凭证。

概念流程

下面的图示只表达公开提议中的概念关系，不代表已经发布的浏览器行为或 BotBrowser 的实现。普通浏览和隐私浏览之间由浏览器管理一条受限的凭证边界，网站只能看到设计允许的结果。

PVT 是提议、实验，还是已发布功能？

这些词不能互换。公开 explainer 把 PVT 描述为早期设计草案，并说明它尚未获准在 Chrome 中交付。Chrome Platform Status 当前记录的状态是 proposed、not released；其中的里程碑字段指向 Chrome 154 到 165，其他公开报道将这段范围描述为实验路径。注册方式、审查结果、浏览器支持和最终行为都可能改变。若想把一项提议追溯到有边界的浏览器证据，请参阅从浏览器规范到实现状态，其中包含一份状态工作表。

因此，开发者不应把 PVT 当作稳定、普遍可用的浏览器契约。一个站点即使在某个实验版本中观察到相关行为，也不能据此假定所有 Chrome 用户、所有操作系统或所有隐私上下文都会得到相同结果。版本、注册资格和部署阶段都需要单独记录。

对隐私浏览意味着什么？

评估范围应区分 eTLD+1 站点边界与配置文件身份。

PVT 关注的是一个真实的产品张力：隐私浏览不应因为缺少长期 Cookie 就自动被当成异常，但减少误判也不应重新建立一个持久身份通道。一个设计良好的信号至少要回答以下问题：

• 普通浏览上下文中有哪些信息可以传到隐私上下文？
• 不同的用户身份、配置文件和私密窗口会不会意外共享结果？
• 网站能否把信号与其他数据组合成长期标识符？
• 信号只对注册站点有效，还是会扩展为跨站点机制？
• 用户和运营者是否能理解信号何时存在、何时缺失？

这些问题不能只通过一个请求头或一个 API 名称回答。需要在浏览器版本、操作系统、普通配置文件、私密上下文和多窗口组合之间进行一致性测试。对于隐私功能，缺失 signal、拒绝 signal 和浏览器尚未支持 signal 都是不同结果，日志应当区分它们。

BotBrowser 当前如何处理

BotBrowser 会让同一配置文件在普通会话和隐身会话中保持指纹表面、存储配额数值和存储 API 行为一致，因此团队在评估 PVT 时可以对比普通上下文与私密上下文的状态。限制同样明确：当前 BotBrowser 构建版本不会启用、伪造、导入或预置 PVT token，无法在 Chrome 发布之前让 PVT 可用，也无法控制网站是否接受或信任私密访客。

这是基于当前公开状态的明确产品选择。PVT 的规范、注册流程、跨浏览器情况和隐私边界仍在变化；在这些条件稳定之前，保持行为不变更容易让用户理解和验证。BotBrowser 的普通配置文件、私密上下文和其他浏览器信号继续按照现有版本与发布说明工作。

未来是否重新评估，需要重新检查隐私属性、配置文件隔离、跨上下文行为和公开兼容性报告。届时也应以新的发布说明为准，而不是依据这篇文章推断功能已经开启。

运营者现在可以怎么测试？

将 Sec-Private-Verification-Token 视为提议中的协议标记，不要当作当前可用接口。

如果你的应用同时服务普通浏览和隐私浏览用户，可以把下面的场景分开记录：

1. 已有站点状态的普通配置文件。
2. 没有站点状态的新普通配置文件。
3. 从普通配置文件进入的全新隐私上下文。
4. 两个必须彼此隔离的独立隐私上下文。

每次测试记录浏览器版本、操作系统、配置文件状态、上下文类型、站点是否已注册以及实际可观察结果。不要因为状态页出现 PVT 名称，就推断当前版本已经支持；也不要把一次请求的结果延伸为所有用户的行为。

应用层可以把 PVT 当作潜在的未来输入，而不是今天的依赖。验证流程、隐私提示、备用路径和错误处理仍应在没有 PVT 的情况下正常工作。这样，即使提议延期、变更或只在部分浏览器中出现，用户体验也不会依赖一个尚未稳定的信号。

常见问题

PVT 是一种登录凭证吗？

不是。公开设计将它限定为面向注册站点的窄范围信号，不应替代登录、授权或用户身份验证。它的目标是帮助站点判断是否存在先前的受限信任信号，而不是证明某个具体的人。

PVT 会让隐私浏览变成普通浏览吗？

提议的目标恰恰是保留隐私上下文的边界。实际能否达到这一点，取决于最终规范、浏览器实现和站点使用方式，因此不能把草案当作保证。

BotBrowser 什么时候会启用？

目前没有启用计划或产品承诺。请以未来 BotBrowser 发布说明和兼容性报告为准。

来源

• Private Verification Tokens explainer
• Chrome Platform Status: Private Verification Tokens
• BotBrowser 无痕模式文档
• PPC Land：Chrome 测试向网站表明无痕访客为真人的单比特信号

实践结论

应把 PVT 视为提议，而非生产依赖。确保隐私浏览流程在没有该 token 时仍可使用；只有官方文档和发布说明确认变化后，才重新评估这项能力。