如何读取浏览器指纹信号

BotBrowser 支持在声明浏览器和配置文件输入后，重复执行经过授权的自有页面检查，并采集范围受限的浏览器可见字段；但它不能解释所有差异成因、识别个人，也不能预测服务的私有判断。有效的指纹复核应先区分信号分组，再核对执行上下文，最后确定由谁继续调查。

TL;DR

• 将 Canvas、WebGL、navigator、屏幕、音频、字体、时区和函数行为视为不同观察项。
• 分组摘要变化能缩小差异范围，但不能确定原因或个人身份。
• 每次比较都保留浏览器构建版本、操作系统、来源、权限、页面或 worker 上下文以及检查名称。
• 公开实现只能说明它自身检查了什么，不代表浏览器标准或第三方判定。

Contents

• 先区分信号分组
• 窄化解读行为检查
• 保留比较上下文
• 明确结论边界
• Practical conclusion

先区分信号分组

如果每条观察都与产生它的 API 或行为保持关联，浏览器指纹问题就更容易排查。Canvas 渲染、WebGL 参数、navigator 属性、屏幕指标、音频输出、字体、时区和函数行为都有不同的输入和失败模式。把它们合成一个标签，会隐藏究竟是哪种表面发生了变化。

一个公开实现展示了这种分组方式：其固定版本源码分别组装 Canvas、WebGL、屏幕、时区、音频、字体、navigator 和部分函数行为检查的摘要。这只是该实现自身处理结果的示例，不是浏览器指纹的完整清单；摘要变化也无法证明唯一成因。

BotBrowser 指纹文档介绍产品控制和配置文件一致性。本文额外说明如何按信号分组归类差异、保留比较上下文，并安排后续排查，而不是把某个检测器视为网站决策的权威。

基础术语可先阅读什么是浏览器指纹。需要可重复的证据流程时，再参考如何验证浏览器指纹，两篇文章提供了本方法所需的前置背景。

如果 Canvas 摘要改变而 navigator 字段保持稳定，应分别保留这两条事实，而不是笼统汇报“指纹变了”。前者能告诉下一位排查者从哪里开始；后者丢失了有用边界。相关内容还包括跨 realm 的浏览器 API 完整性和保护隐私的浏览器验证。

窄化解读行为检查

部分检测器会检查 JavaScript 函数如何呈现自身。公开示例包括比较 Function.prototype.toString() 输出、枚举自有属性描述符，以及检查调用或经 Proxy 包装的函数是否产生预期错误。这些测试编码的是某个实现的预期，并非覆盖所有浏览器 realm 的完整符合性套件。

检查失败只支持有限结论：在某个上下文中，一项受测行为不同于检测器预期。它无法说明差异来自浏览器更新、扩展、埋点、包装器还是测试 fixture。检查通过也只覆盖受测路径。应把检查名称和 API 与结果放在一起，方便他人复现同一个问题。

不要把单个“lie”标记说成浏览器在欺骗的证据。应说明具体行为、检查上下文，以及比较发生在 window 还是 worker。可参考 MDN 的 Function.prototype.toString() 文档和属性描述符文档。

保留比较上下文

比较数值前，先记录可能影响结果的条件。至少保留浏览器构建版本、操作系统、来源、权限状态、配置文件生命周期和执行上下文。如果检查同时运行于页面和 worker，应分别标记记录。上下文不一致可能看起来像浏览器回归，即使浏览器二进制没有变化。

每次比较只更改一个已声明输入。如果浏览器和配置文件同时变化，结果无法把差异归因于其中任何一个。为了可重复的产品检查，应使用同一自有页面和 fixture，记录第一个变化字段，并保留定义预期行为的检测器源码版本。

诊断过程同样要最小化数据。只保留路由问题所需的字段，不要把它们与账号标识、无关浏览历史或跨站数据拼接。W3C 隐私原则提供了更广泛的数据最小化依据。即使一个浏览器可见值不能直接指向个人，也可能具有敏感性。

将差异交给合适的负责人

根据第一个变化的观察项决定后续检查方向，不要直接套用统一严重性：

首个变化的观察项	首要复核方	下一步比较内容
Canvas 或 WebGL 摘要	渲染负责人	浏览器版本、图形后端、操作系统及确切绘图输入或参数
navigator 或屏幕字段	浏览器上下文负责人	权限、模拟设置、配置文件配置及页面或 worker 上下文
函数字符串或描述符检查	JavaScript 集成负责人	包装器、埋点顺序、自有键及受检函数
音频、字体或时区字段	环境负责人	已安装字体、音频路径、系统语言和配置文件生命周期
多个分组同时改变	测试负责人	修改代码前核对来源、fixture 版本、浏览器、配置文件和运行时间

这张表只用于分流，不是诊断结论。它把第一个问题交给最可能验证输入的团队。经过授权的 BotBrowser 受控上下文可以重复浏览器观察，但重复本身仍不能揭示第三方的私有评分规则。

建立范围受限的观察记录

使用一个简短记录，把观察结果和限制放在一起。以下是 schema 示例，并非实际运行输出：

{
  "fixture": "owned-signal-review-v1",
  "browserBuild": "declared build",
  "os": "declared OS",
  "origin": "https://app.example.test",
  "context": "page",
  "profileLifecycle": "fresh",
  "checkSourceRevision": "pinned source commit",
  "changedGroup": "webgl",
  "checkName": "parameter summary",
  "outcome": "changed",
  "interpretation": "review rendering inputs before changing profile settings"
}

示例中使用自有的合成来源，只在私有测试记录中替换它。如果变化分组标签已经足够，就不要保存原始 Canvas 输出、完整音频样本、账号数据或无关信号。如果检测器没有公开源码版本或执行上下文，应标注为未知，而不是猜测。

经过授权的 BotBrowser 运行可以重复声明的页面，并为版本比较保留这些范围受限字段。它无法证明信号无害、从浏览器值推断个人身份，也不能保证外部服务接受。交接记录时应把这条限制与数据放在一起。

明确结论边界

浏览器表面检查只回答实际执行路径上的问题。它不会揭示网站的完整风险模型，后者还可能包括网络信誉、账号历史、请求时序、服务端状态和应用规则。因此，一致性结果不能被描述为对 WAF 的预测，也不是匿名保证。

在隐私分析中，W3C 隐私原则强调目的限定与数据最小化。在工程实践中边界也很直接：比较已声明的 fixture，报告观察到的字段，并写明未知部分。如果主张依赖某项服务的决定，应通过经过授权的集成测试获取证据，而不是从浏览器检测器外推。

交接记录的最小标题应包含 browserBuild、os、origin、context、changedGroup 和 testedOn: 2026-10-29。将记录关联到同一份 W3C 隐私原则引用和确切页面 fixture。这些具体字段便于审计后续比较，同时无需保留原始信号值。

执行受控比较。

先写下一个明确指出单个字段和单个上下文的问题。“同一 Profile 下更新浏览器后，WebGL 参数摘要是否变化？”可以验证。“这个浏览器指纹是否一致？”则混合了许多表面，也没有定义比较边界。问题范围明确后，相关字段得到解释时就能停止。

对自有测试页面按以下顺序操作：

1. 记录页面 origin、浏览器构建版本、操作系统、Profile 生命周期、权限状态，以及代码是在 window 还是 worker 中运行。
2. 在声明的基线上下文中，运行两次未更改的页面。如果所选字段在两次运行间变化，应先调查 fixture 的稳定性，再比较浏览器构建版本。
3. 只更改问题中指定的变量，例如浏览器构建版本。保持 origin、Profile 生命周期、权限和页面 bundle 不变。
4. 比较第一个变化的字段及其来源路径。记录准确的属性名或检查名称，不要复制整份指纹报告。
5. 比较后重跑基线。值回到原状有助于区分输入变化和无关上下文漂移，但仍不能单独证明原因。

经授权的 BotBrowser 上下文可以使用声明的 Profile 输入重复运行页面自有 fixture，并保留范围受限的记录。Fixture 负责人仍需选择页面、定义可安全保留的字段，并判断观察到的差异是否影响应用。浏览器自动化提供可重复的执行上下文，但不会提供产品风险策略。

诊断常见不匹配。

结果不同后，先判断测试条件是否相同。navigator 属性缺失或变化，可能源于权限状态不同、模拟设置、从页面移到 worker，或 Profile 发生变化。Canvas 或 WebGL 差异可能由渲染输入或 backend 变化引起。函数行为检查可能受 instrumentation 顺序影响，也可能因为检查运行前安装了 wrapper。这些都只是待验证的假设，不能仅从输出推断为原因。

字段缺失时。

检查代码是否请求了该字段、其前置条件是否可用，以及页面是否获准使用相关能力。然后检查呈现路径：某些诊断页面会省略其认为不可用、置信度低或不在当前视图内的值。“报告中没有”与“浏览器不支持”是不同结果。

页面与 worker 不一致时。

确认两个上下文收到的是同一页面 bundle，并且 worker 已成功创建。为每个值标注上下文。不要把一个 Profile 的页面结果与另一个 Profile 的 worker 结果合并。如果测试有意在两个上下文读取同一属性，就分别记录两行，先比较输入，再判断差异是否为浏览器缺陷。

只有函数检查发生变化时。

检查函数如何加载，以及应用 wrapper 或测试 instrumentation 是否在检查运行前替换了它。公开的 Function.prototype.toString() 参考描述的是标准 API 表面，而检测器可能还编码了特定原生函数应有外观的假设。比较具体函数及其 own-property keys；笼统的“lie”标签不足以定位集成改动。

多个分组同时变化时。

更改代码前先回看运行记录头。检查浏览器构建版本、OS 镜像、locale、Profile 生命周期、权限状态或 origin 是否同时变化。恢复基线，每次改变一个输入。如果在受控运行中多个分组仍一起移动，就把这种关系记录为观察，而不是某个分组导致其他分组变化的证明。

准备有用的事件交接。

支持交接应让下一位负责人无需拿到完整浏览历史就能复现首次分歧。包括 fixture 标识符、运行时间戳、浏览器构建版本、OS、Profile 标签、origin 类别、上下文、变化分组、准确检查名称和第一个不同字段。如果预期行为来自检测器实现，还要包含源码修订版本。除非另有授权调查确实需要，否则排除 cookies、账号标识符、无关 URL、原始 Canvas 输出和完整音频样本。

后续动作应针对证据。渲染负责人可以在不同构建版本下比较同一绘制输入；上下文负责人可以在固定设置下重跑权限或 worker 检查；JavaScript 集成负责人可以比较应用 instrumentation 前后的函数；测试负责人可以确认 fixture 和 origin 没有漂移。“调查指纹”不是可执行的交接，因为它既没有指出第一个变化字段，也没有给出下一个受控比较。

如果记录要分享给应用团队之外的人，应删除内部主机名及任何可关联到用户或账号的值。保留足够上下文以解释结果，但不要把诊断包变成可复用的 Profile 标识符。数据最小化是记录设计的属性，不代表某个字段必然无害。

避免误导性比较。

以下捷径会产生一个数字，却得不出可靠结论：

• 比较不同 origin 的运行可能同时改变权限、存储、feature policy 和应用代码。
• 比较持久 Profile 与新 Profile 可能改变权限授予、缓存资源、service workers 和应用状态。
• 不标注上下文就比较页面与 worker 结果，会混合不同的执行环境。
• 比较原始 Canvas 或 audio 输出，可能保留超过问题所需的身份识别细节。
• 把 digest 变化当作身份变化，是将摘要函数与个人属性混为一谈。
• 把行为检查通过当作完整一致性，会把小测试扩展到它实际覆盖路径之外。

用这些例子检查比较设计，而不是据此推断某个条件导致了结果。如果测试无法保持某个变量不变，就把该限制写在观察旁边，不要归因于单一原因。

区分兼容性与隐私问题。

兼容性关注自有应用能否在指定条件下使用声明的浏览器能力。隐私关注收集或保留观察是否必要且合乎比例。某字段可能有助调试，却不适合日常分析。应分开作决定：先定义兼容性检查，再确定是否需要保存其输出、保存多久以及由谁负责。

版本检查中，短期记录可能足以确认必需字段存在且 fallback 可用。聚合产品监控应保留计数或粗粒度结果类别，而不是原始值。面向用户的隐私声明应描述应用实际收集的数据；浏览器检测器不能替代对服务器日志、分析配置或账号关联的审查。

W3C 隐私原则为目的限制和数据最小化提供框架，但不会认证某个具体测试设计。应用负责人仍须核实 fixture 输出了什么、记录流向何处，以及是否附加了无关标识符。

审查基于源码的检测器。

如果审查固定到某个修订版本，开源检测器可以解释特定结果为何出现。文中引用的实现把 Canvas、WebGL、屏幕、时区、audio、fonts、navigator 和选定的函数检查分成不同输出。其函数检查代码包含字符串化、属性描述符、预期错误和 Proxy 行为等情形。这些细节解释了检测器设计，但不能证明所有浏览器表现相同，也不能证明服务使用了相同检查。

审查源码相关主张时，应在同一 commit 检查 collector 入口和具体检查文件。记录组装了哪个输出字段、什么条件可能令其缺失，以及失败用例实际比较的内容。页面之后若发生变化，应先使用本文固定到 commit 的链接，重新审查主张。默认分支移动可能改变检查，而不改变早先观察的含义。

不要把源码文件当作运行测量来引用。源码审查可以确认测试已实现，但不能证明某次浏览器运行通过或失败。运行证据应来自带日期的记录，其中包含真实命令或页面、输出、浏览器构建版本、操作系统和 Profile 上下文。本文没有声称发生过这样的运行。

判断证据是否充分。

当测试问题明确、比较上下文已记录、首个变化字段可复现，且下一步针对该字段时，观察结果足以支持范围受限的工程决策。只有分数、未标注截图或没有基线的大型报告，则不够充分。此时应缩小问题范围，并在更改浏览器设置或产品代码前重跑受控比较。

决定也可以是“不改动”。如果差异来自预期的 OS 渲染输入，且自有应用运行正常，就记录兼容性条件，不要为了让检测器输出一致而修改无关 Profile 字段。如果差异阻碍了应用需求，就保留最小复现，并交给浏览器表面或集成层负责人。

不要把稳定等同于隐私，也不要把变化等同于缺陷。有些 API 本就会变化，有些受策略控制，有些仅在声明的环境内稳定。正确结论取决于应用需求和确切的可观察路径，而不是对输出一致性的泛化偏好。

Sources

• W3C 隐私原则
• MDN：Function.prototype.toString()
• MDN：Object.getOwnPropertyDescriptor()
• 公开信号分组实现，固定版本 creep.ts
• 公开函数行为检查，固定版本 lies/index.ts
• BotBrowser 指纹文档

Next reading

当同一属性需要从多个执行上下文读取时，请阅读跨 realm 的浏览器 API 完整性。当诊断记录需要缩短保留范围时，请阅读保护隐私的浏览器验证。

Cloudflare 的公开 Bot Score 证据指南说明，服务评分必须与浏览器可见信号分组分开，因为二者都不是针对个人的结论。

Practical conclusion

先找到第一个变化的信号分组，保留浏览器和执行上下文，再一次比较一个已声明输入。范围受限的观察可以引导有效排查，但不能确认个人身份或预测第三方的私有决定。