Private Verification Tokens：Chrome 正在探索什么，以及 BotBrowser 当前如何处理
了解 Chrome 提议中的 Private Verification Tokens（PVT）、隐私浏览场景中的信任信号，以及 BotBrowser 当前为何不启用。
先说结论
Private Verification Tokens（PVT）是 Chrome 公开讨论中的一项隐私浏览提议。它设想让网站在普通浏览期间获得一个受限的信任凭证，并在之后的隐私浏览请求中收到一个不暴露浏览历史的窄范围信号。这个想法仍处于提议和实验阶段，不是已经交付的通用 Web 能力。
截至本文撰写时，Chrome Platform Status 将 PVT 标记为 proposed、尚未发布。Firefox 和 Safari/WebKit 目前没有公开的同类 signal 记录。BotBrowser 当前不启用 PVT，也不会伪造、导入或预置 PVT token。理解这几个事实，比把一个状态页上的名称当成现成能力更重要。
PVT 要解决什么问题？
隐私浏览的目标是减少长期状态和跨会话关联。一个全新的私密上下文通常没有普通配置文件中的 Cookie、站点存储或登录状态，因此网站很难区分以下两种情况：用户刚刚打开了一个干净的私密窗口，或者客户端确实没有任何可复用的站点状态。
在这两种情况下，网站都可能要求额外验证。对用户而言，这会造成不必要的摩擦；对网站而言，完全忽略这类请求又可能放大误判。PVT 提议探索一个更窄的中间点：浏览器可以携带“这个浏览器曾经从该站点获得过有效信任信号”的证明，但不把普通浏览会话本身交给网站。
这里的“信任”不是身份声明，也不是用户认证。它不应回答用户是谁、访问过哪些页面，或 token 是在哪一次会话中产生的。公开设计强调的是最小化信号：只回答一个注册站点是否可以收到一个有效、受限的凭证。
概念流程
下面的图示只表达公开提议中的概念关系，不代表已经发布的浏览器行为或 BotBrowser 的实现。普通浏览和隐私浏览之间由浏览器管理一条受限的凭证边界，网站只能看到设计允许的结果。
PVT 是提议、实验，还是已发布功能？
这些词不能互换。公开 explainer 把 PVT 描述为早期设计草案，并说明它尚未获准在 Chrome 中交付。Chrome Platform Status 当前记录的状态是 proposed、not released；其中的里程碑字段指向 Chrome 154 到 165，其他公开报道将这段范围描述为实验路径。注册方式、审查结果、浏览器支持和最终行为都可能改变。
因此，开发者不应把 PVT 当作稳定、普遍可用的浏览器契约。一个站点即使在某个实验版本中观察到相关行为，也不能据此假定所有 Chrome 用户、所有操作系统或所有隐私上下文都会得到相同结果。版本、注册资格和部署阶段都需要单独记录。
Chrome Platform Status 目前也没有记录来自 Firefox 或 Safari/WebKit 的同类 signal。这只是当前公开记录的范围，不是对未来浏览器路线的预测。跨浏览器方案仍需要以各自的公开文档和实际版本测试为准。
对隐私浏览意味着什么？
PVT 关注的是一个真实的产品张力：隐私浏览不应因为缺少长期 Cookie 就自动被当成异常，但减少误判也不应重新建立一个持久身份通道。一个设计良好的信号至少要回答以下问题：
- 普通浏览上下文中有哪些信息可以传到隐私上下文？
- 不同的用户身份、配置文件和私密窗口会不会意外共享结果？
- 网站能否把信号与其他数据组合成长期标识符？
- 信号只对注册站点有效，还是会扩展为跨站点机制？
- 用户和运营者是否能理解信号何时存在、何时缺失？
这些问题不能只通过一个请求头或一个 API 名称回答。需要在浏览器版本、操作系统、普通配置文件、私密上下文和多窗口组合之间进行一致性测试。对于隐私功能，缺失 signal、拒绝 signal 和浏览器尚未支持 signal 都是不同结果，日志应当区分它们。
BotBrowser 当前如何处理
当前 BotBrowser 构建版本不启用 PVT。BotBrowser 不会伪造、导入或预置 PVT token，也不会把一个尚未稳定的提议信号包装成产品保证。
这是基于当前公开状态的明确产品选择。PVT 的规范、注册流程、跨浏览器情况和隐私边界仍在变化；在这些条件稳定之前，保持行为不变更容易让用户理解和验证。BotBrowser 的普通配置文件、私密上下文和其他浏览器信号继续按照现有版本与发布说明工作。
未来是否重新评估，需要重新检查隐私属性、配置文件隔离、跨上下文行为和公开兼容性报告。届时也应以新的发布说明为准，而不是依据这篇文章推断功能已经开启。
运营者现在可以怎么测试？
如果你的应用同时服务普通浏览和隐私浏览用户，可以把下面的场景分开记录：
- 已有站点状态的普通配置文件。
- 没有站点状态的新普通配置文件。
- 从普通配置文件进入的全新隐私上下文。
- 两个必须彼此隔离的独立隐私上下文。
每次测试记录浏览器版本、操作系统、配置文件状态、上下文类型、站点是否已注册以及实际可观察结果。不要因为状态页出现 PVT 名称，就推断当前版本已经支持；也不要把一次请求的结果延伸为所有用户的行为。
应用层可以把 PVT 当作潜在的未来输入，而不是今天的依赖。验证流程、隐私提示、备用路径和错误处理仍应在没有 PVT 的情况下正常工作。这样，即使提议延期、变更或只在部分浏览器中出现，用户体验也不会依赖一个尚未稳定的信号。
常见问题
PVT 是一种登录凭证吗？
不是。公开设计将它限定为面向注册站点的窄范围信号，不应替代登录、授权或用户身份验证。它的目标是帮助站点判断是否存在先前的受限信任信号，而不是证明某个具体的人。
PVT 会让隐私浏览变成普通浏览吗？
提议的目标恰恰是保留隐私上下文的边界。实际能否达到这一点，取决于最终规范、浏览器实现和站点使用方式，因此不能把草案当作保证。
BotBrowser 什么时候会启用？
目前没有启用计划或产品承诺。请以未来 BotBrowser 发布说明和兼容性报告为准。