跨表面浏览器隐私：让同一上下文保持一致

隐私发生在多个表面之间

浏览器隐私经常被描述成一组彼此独立的开关。页面读取渲染结果，请求携带浏览器元数据，脚本观察显示偏好。更重要的问题不是某一项观察是否奇怪，而是这些本应描述同一个浏览上下文的观察，在用户切换页面、站点、标签页和嵌入内容时是否仍然相互吻合。

这就是跨表面问题。网站可以把页面可见的信息和服务器可见的信息组合起来。嵌入资源可以看到来自嵌入页面的请求，第一方脚本也可以观察产生该请求的浏览器环境。当同一个服务出现在多个不相关的网站上时，它就有机会比较这些观察结果。

服务不一定需要稳定的账号标识符。渲染特征、显示关系、语言偏好和请求元数据的组合，可能足以支持概率性的关联。结果未必是一个人的姓名，也可能只是置信度、记住的浏览器群组，或之后请求更多信息的依据。

防御性的目标应当清晰而有限：让一个 profile 在其预期的 BrowserContext 内保持公开行为一致，减少不必要的暴露，并让剩余暴露变得可理解。一致性不等于匿名，也不能决定网站是否有权收集数据。后两个问题仍然需要设置、同意、政策和适用法律来处理。

跨站收集如何拼接起来

收集通常不依赖一次特别显眼的读取，而是由容易忽略的日常页面活动拼接而成。

嵌入图片、字体、分析脚本、广告组件或测量库，都可能向地址栏所显示站点之外的服务发出请求。页面完成加载前，请求就可能携带浏览器层面的元数据。嵌入代码还可能观察当前环境的概括性属性。当同一服务出现在多个不相关的网站上时，它就可以比较这些观察。

第一方收集也可能在同一家公司内部形成类似效果。一个人访问商店、支持门户和文档站点，而它们共享测量代码。即使品牌不同，共享基础设施也可能把事件连接起来。登录会让连接更容易，但并不是每一种关联都需要登录。

因此，隐私控制应当在切换过程中评估。一个 profile 在单个页面上看起来一致，但嵌入框架加载后公开身份发生变化，这仍然没有解决核心问题。一个上下文在文档中表达一种语言偏好，在请求中表达另一种偏好，也会留下可被记录的关系。

渲染是公开观察，不是秘密

图形表面有价值，是因为它们描述计算结果，而不只是设置面板中的偏好。WebGL 和 WebGPU 可以通过支持能力和生成输出，透露渲染路径的特征。页面还可以在不同上下文中比较相关图形工作的行为。单个观察可能较为粗略，但与其他信号结合后，仍可能参与关联。

隐私风险并不是网站知道某人拥有哪一块显卡，而是渲染结果可能成为持久的浏览器身份组成部分。不同站点、标签页或框架之间的图形行为发生变化，同样会提供关联线索。声称的显示环境与实际渲染行为不相称，也会成为收集服务可以记录的关系。

因此，阻止图形表面并不是唯一的防御选择。阻止可以减少可见信息，但也可能改变页面行为，并形成少见的配置。更好的隐私审查会问：允许的结果是否和上下文其他部分协调，用户是否知道图形能力可以被观察，网站是否有正当理由使用这些信息。

显示关系携带上下文

屏幕尺寸和设备像素比不只是排版细节。它们之间的关系会影响页面渲染、媒体查询结果以及网站对可用显示区域的判断。窗口大小、视口大小、缩放和像素密度，都会在用户移动窗口或连接显示器时变化。有些变化正常且可见，有些变化则暴露 profile 与主机环境之间的不一致。

隐私关注点在于组合关系。声称一种设备，却以另一种比例渲染的显示身份可能显得突兀。新标签页中的关系与周围上下文不同，也可能成为关联提示。网页无需特殊权限，就能通过布局行为观察这段关系的一部分。

防御性配置应尊重真实的用户动作。用户调整窗口时，不应被困在虚假的屏幕状态中。同时，隔离的 BrowserContext 也不应静默继承与所选 profile 冲突的主机显示假设。实用的边界是先决定哪些显示行为属于该上下文，再让相关表面在上下文活动期间保持协调。

语言偏好不止代表语言

语言设置帮助网站选择内容，也可能成为地区和行为线索。浏览器可以向页面代码暴露偏好语言，请求层也可以把语言偏好传给服务器。网站可能把这些偏好与页面语言、选定的地区、时间相关设置或连接地区进行比较。

没有单独一项语言偏好可以识别一个人。风险来自意外组合，或来自不同表面之间的变化。页面显示一种地区，请求却声明另一种地区。嵌入资源收到的偏好与顶层页面不同。一个 profile 在不同站点之间保持稳定，却在创建新的 BrowserContext 后改变。每个不一致都可能让收集服务更容易分开本想共享上下文的会话，或连接本想隔离的会话。

注重隐私的配置把语言当成上下文决定，而不是装饰性的标签。选择的语言应当符合用户预期的内容和地区，也应当一致地应用到页面可见和请求可见的部分。用户应能主动改变语言，并清楚知道这可能改变内容，也可能改变服务观察到的浏览器关系。

User Agent Client Hints 属于请求边界

User Agent Client Hints 向服务器提供结构化的浏览器和平台元数据。服务器会用这些信息进行选择性的内容协商。从隐私角度看，它们仍然是可观察的请求表面。服务器可以把请求元数据与页面中的浏览器身份、渲染行为和显示设置所暗示的平台进行比较。

关键在于不同请求类型和不同上下文之间的一致性。顶层导航、嵌入资源和后续请求如果属于同一个 BrowserContext，就不应意外描述互相冲突的浏览器身份。同一个 profile 也不应向服务器表达一种浏览器家族，却向页面表达另一种。单独修改 User Agent 文本无法修复其他表面的不一致。

Client Hints 也说明了实际隐私边界。一些请求元数据在用户看到页面前就已经被服务器观察到。公开验证页面可以展示它收到的内容，却无法告诉用户服务会保存多久、是否会共享，或另一家公司是否获得副本。技术一致性可以减少意外关联，但不能替代服务的隐私声明或用户是否同意的决定。

一个 profile，一个预期的 BrowserContext

profile 是浏览器上下文如何呈现自己的选择集合。BrowserContext 是页面、请求、存储和权限应当共享受控会话的运行边界。两者的关系很重要。在无关上下文之间重复使用同一 profile，可能建立有意的连接。把不同 profile 的设置混在一个上下文中，则可能形成意外连接或不可能的组合。

防御性工作流应先命名边界：哪些页面和请求属于一起，哪些存储必须留在边界内，以及什么时候需要新上下文。为这个目的加载一个 profile，在活动会话中不要随意改变与身份有关的设置，除非改变本身就是明确计划的一部分。把显示、渲染、语言和请求决定放在一起管理，这样每一处改变都能与其他表面一起复核。

这不要求公开实现细节，而要求有可执行的流程。profile 应被当作带生命周期的隐私配置：为一个目的选择，在预期上下文中使用，验证公开行为，再按照组织的保留政策停用或轮换。浏览器可以帮助保持协调，却不能替用户决定政策。

公开检查可以展示什么

面向用户的验证页面可以回答一个范围有限但很有用的问题：这个浏览器上下文此刻公开了什么？页面可以展示图形样本，报告布局如何响应当前显示设置，显示页面采用的语言，并展示服务器收到的请求元数据。在新标签页或相关上下文中重复检查，还可以发现意外变化。

最好的验证是有同意前提的比较。使用自己控制的页面或信誉良好的公开服务，阅读隐私声明；如果简单的浏览器检查已经足够，就不要提交账号资料。先在同一上下文中比较有意改变前后的结果，只有当目的是确认隔离时才比较独立上下文。记录应保持在有助于排查的粒度，不要保存超出必要范围的识别信息。

公开检查应被当作观察，而不是认证。它可以展示某个页面及其服务器在当时能够观察到的表面之间是否协调，却无法检查远程服务的私有数据库，无法推断全部数据共享关系，也无法证明另一个站点会作出相同决定。它同样无法保证 profile 适合每一台实体设备或每一种网络条件。检查结果只是特定场景下的证据。

浏览器检查之外的部分

许多隐私问题在服务器侧会转化为政策问题。网站可能保留请求日志，把事件连接到账号，与处理方共享数据，或将数据用于页面上看不到的目的。本地浏览器检查无法验证这些做法。用户需要阅读服务声明、使用同意控制，并在适用时提出访问或删除请求。

网络隐私也比浏览器身份更广。保持 profile 协调不会隐藏 IP 地址，不会改变代理服务商的可信度，也不会阻止用户登录后被识别。存储和权限同样重要。Cookie、本地存储、登录状态和设备访问，即使在渲染与显示观察协调时，也可能建立连接。

最后，隐私有人的边界。浏览器不应用来破坏访问控制、隐藏被禁止的活动，或让人误以为观察已经不可能。更有用的承诺是让用户认可的浏览上下文可预测，减少意外的跨上下文连接，并让公开行为更容易检查。

一次务实的隐私复核

复核 profile 和 BrowserContext 时，可以提出以下问题：

• 目的： 哪些页面和请求属于这个上下文，为什么要把它们放在一起？
• 表面协调： 渲染行为、显示关系、语言偏好和请求元数据，是否描述同一个选定上下文？
• 变化处理： 窗口、显示、语言或连接改变时，变化是否符合预期并有记录？
• 隔离： 新上下文是否从预期的存储和权限开始，而不是意外继承状态？
• 证据： 用户控制的或信誉良好的公开页面，能否在不收集多余个人信息的情况下确认可见行为？
• 治理： 组织是否为收到的观察结果制定了保留、同意和删除政策？

这些问题比固定清单更耐用，因为浏览器能力和网站做法都会改变。它们也能让复核聚焦于隐私结果，而不是复现网站的收集逻辑。

上下文何时应当改变

保持一致不应成为把所有活动放进一个永久会话的理由。当用途、权限、账号或数据敏感度改变时，上下文也应改变。研究会话、个人账号和管理工作流，即使使用同一台工作站，也可能需要独立边界。分离可以限制可被连接的历史，并让事后复核更清楚。

变化应当是有意的。按照本地保留政策关闭或隔离之前的会话，为新边界启动预期 profile，并在敏感工作开始前验证公开行为。不要意外把保存的登录状态、语言偏好、显示假设或权限带入新边界。继承部分状态的新上下文，可能比已经明确的旧上下文更难理解。

同样的原则适用于服务改变页面或请求行为的情况。新的嵌入组件可能创建过去复核时不存在的收集路径。浏览器更新也可能改变渲染输出或请求元数据的协商方式。在重要变化后重新复核上下文，记录复核的目的和日期，并在不再需要时删除这些记录。这样可以形成可负责的隐私实践，而不必保存个人浏览的详细历史。

更平静的浏览器隐私模型

跨表面隐私既是协调问题，也是治理问题。渲染输出、屏幕和像素关系、语言偏好以及 User Agent Client Hints，本身都可能是普通的浏览器行为。当它们不一致，或组合后具有异常辨识度时，尤其跨站出现时，就可能成为持久的关联信号。

让一个 profile 在一个 BrowserContext 内保持协调，可以减少公开表面之间的意外连接，但不能替代同意、谨慎的存储、可信服务和明确的保留规则。公开验证能确认某个页面及其服务器在特定场景下观察到什么，隐私声明和组织控制则处理之后发生什么。

相关内容可阅读什么是浏览器指纹、Client Hints 指纹、WebGL 指纹、WebGPU 指纹和屏幕与窗口指纹。需要公开验证流程时，可访问验证中心。