简介

浏览器指纹保护有三种根本不同的架构。每种架构在浏览器技术栈的不同层级运行，而这个层级决定了它能控制什么、不能控制什么。

三种方法分别是：

浏览器扩展：在页面加载后注入脚本，覆盖 JavaScript 属性
JS 注入/隐身插件：通过 Puppeteer 或 Playwright 等自动化框架，在页面代码运行前修改浏览器环境
引擎级修改：直接修改浏览器内核的编译代码，在任何 JavaScript 上下文存在之前就改变指纹信号

这不仅仅是同一想法的不同实现，而是架构上的根本差异。这些差异在一致性、覆盖范围和长期可靠性方面都有实际影响。本文将详细分析每种方法，解释它们为什么产生不同的结果，并帮助你根据隐私需求选择正确的架构。

隐私影响

不完整或不一致的指纹保护可能比完全不保护更糟糕。当部分信号被修改而其他信号未被修改时，产生的指纹包含矛盾信息。一个声称运行在 Windows 上但 Canvas 输出却匹配 Linux 渲染特征的浏览器会更加独特，而不是更不独特。一个通过 Object.defineProperty 覆盖了 navigator.webdriver 属性的浏览器，可以通过属性描述符与原生实现不匹配来识别。

不完整的保护会创建一个独特的"隐私工具指纹"，通常比它试图修改的原始指纹更具辨识度。多个学术研究团队已经记录了这种效应：某些隐私扩展的用户比完全不采取任何措施的用户更容易被识别。

保护架构决定了你是否能实现真正的一致性，还是意外地创建了新的识别信号。理解这些架构差异对于做出正确选择至关重要。

技术背景

方法一：浏览器扩展

浏览器扩展通过 WebExtensions API 运行，提供在页面 JavaScript 上下文中执行的内容脚本。指纹保护扩展通常的工作方式：

注入一个在 document_start 运行的内容脚本
使用 Object.defineProperty 覆盖 navigator.hardwareConcurrency、navigator.platform 或 screen.width 等属性
包装 Canvas、WebGL 和 Audio API 以修改返回值
拦截 HTMLCanvasElement.prototype.toDataURL 等方法

扩展方法的弱点：

属性描述符不一致。 当扩展使用 Object.defineProperty 覆盖 navigator.hardwareConcurrency 时，属性描述符会改变。getter 变成了 JavaScript 函数而不是浏览器的原生 getter。这种不一致对页面上运行的任何代码都是可见的，是扩展方法的一个已知弱点。

原型链修改。 覆盖原型方法的扩展会在原型链上留下痕迹。被覆盖的方法可以被识别为非原生 JavaScript 函数，而不是浏览器内置代码。

新上下文隔离。 这是最根本的弱点。扩展可能不会将其覆盖注入到每个执行上下文中。iframe、Web Worker 和其他隔离上下文可以访问原始的、未修改的值。如果主框架中的覆盖值与新上下文中的原始值不同，不一致性就会显现。

无法控制渲染。 扩展无法修改 Canvas、WebGL 或 AudioContext 操作的实际像素输出。它们可以拦截读取输出的 API 调用（如 toDataURL 或 getImageData），但无法改变渲染引擎实际产生的内容。这意味着任何直接从原始渲染输出计算指纹的方法（而非通过 JavaScript API）将看到真实的设备值。

无法控制网络层。 扩展无法修改初始导航请求中发送的 HTTP 头。Client Hints 头如 Sec-CH-UA-Platform 在任何内容脚本执行之前就已发送。TLS 指纹（JA3/JA4）完全在扩展的控制范围之外。

方法二：JS 注入/隐身插件

隐身插件（如 puppeteer-extra-plugin-stealth）是扩展方法的进化。它们不依赖扩展 API，而是通过自动化框架在页面加载前注入 JavaScript。这给了它们更好的时机和更多的注入控制。

典型的隐身插件工作方式：

使用 page.evaluateOnNewDocument() 或 page.addInitScript() 在页面 JavaScript 运行前注入代码
覆盖 navigator.webdriver，删除框架特定对象，修补 navigator.plugins，修改其他可检测属性
修补 toString() 方法使覆盖的函数看起来像原生代码
尝试同时覆盖多个检测向量

相对扩展的改进：

更好的时机：代码在页面自身脚本之前运行，关闭了时序窗口
可以通过 evaluateOnNewDocument 修补所有新上下文，该方法对每个框架都生效
可以处理自动化特有的信号，如 navigator.webdriver 和框架绑定对象

仍然存在的弱点：

JavaScript 层的边界。 隐身插件完全在 JavaScript 层内操作。它们可以覆盖 JavaScript API 的返回值，但无法控制 JavaScript 层以下发生的事情。这造成了几个缺口：

Canvas 和 WebGL 渲染输出。 当网站在 Canvas 元素上绘图并读取像素数据时，实际渲染由浏览器引擎的图形管线执行，而不是由 JavaScript 执行。隐身插件可以拦截 toDataURL() 并返回修改后的数据，但无法改变渲染本身。实际像素输出仍然绑定到真实的 GPU 和驱动程序，导致拦截的 API 响应与底层渲染之间存在不一致。

音频指纹。 AudioContext 处理发生在浏览器的音频引擎中。隐身插件可以包装 AudioContext API，但实际的音频处理输出由浏览器引擎决定。与 Canvas 类似，真实的音频指纹会通过 JavaScript 拦截可能无法完全覆盖的路径泄露。

HTTP 和 TLS 层。 隐身插件无法修改 TLS 握手（JA3/JA4 指纹）、初始导航 HTTP 头或在 JavaScript 执行之前发送的 Client Hints。隐身插件可以覆盖 navigator.userAgentData，但无法改变已经随页面请求发送的 Sec-CH-UA-Platform 头。

跨信号一致性。 隐身插件独立修补各个信号。navigator.platform 覆盖、Canvas 拦截、WebGL 包装和字体列表修改是独立的补丁。确保所有这些内部一致（Canvas 输出匹配声称的 GPU 实际产生的结果）在 JavaScript 层面极其困难，因为插件无法访问渲染引擎的内部状态。

Worker 和 SharedWorker 上下文。 虽然 evaluateOnNewDocument 覆盖了 iframe，但 Web Worker 和 SharedWorker 创建的独立 JavaScript 上下文可能不会接收到注入的脚本，这取决于框架的实现。Service Worker 也是一个挑战，因为它们在页面加载之间持续存在。

方法三：引擎级修改

引擎级修改直接更改浏览器的编译代码。不是在 JavaScript API 调用发出后拦截它们，而是在浏览器引擎的 C++ 实现内部从源头设置值。这是 BotBrowser 的方法。

当加载指纹配置文件时，浏览器引擎的内部值在任何 JavaScript 上下文创建之前就已配置。当 JavaScript 代码调用 navigator.hardwareConcurrency 时，它通过浏览器引擎的正常代码路径返回配置文件的值，使用与原生浏览器相同的原生 getter。没有 JavaScript 覆盖，没有修改的属性描述符，没有改变的原型链。

引擎级控制的能力：

原生属性描述符。 每个被覆盖的属性都有原生 getter，因为它在浏览器引擎的 C++ 代码中实现。Object.getOwnPropertyDescriptor 返回的结果与原生浏览器完全相同。toString() 调用返回 [native code]。一致性检查找不到任何异常，因为确实不存在异常。

实际渲染控制。 Canvas、WebGL 和音频指纹不是在 API 级别拦截的。渲染引擎本身产生与加载的配置文件一致的输出。Canvas 操作的像素级输出、WebGL 渲染器和供应商字符串、AudioContext 处理结果都来自引擎的渲染管线，配置为匹配配置文件的设备特征。

网络层一致性。 HTTP 头（包括初始导航时发送的 Client Hints）匹配配置文件。User-Agent 头、Sec-CH-UA 头和其他请求头在网络栈级别设置，而不是事后修补。

统一的上下文覆盖。 每个 JavaScript 上下文，无论是主框架、iframe、Web Worker、SharedWorker 还是 Service Worker，都看到相同的值。没有可能遗漏上下文的注入步骤。值来自浏览器引擎本身。

无时序窗口。 在页面加载过程中不存在真实值可见的时刻。配置文件的值从浏览器进程启动时就已激活。

对比表

下表从关键保护维度比较三种方法。这是基于架构能力的技术对比，不涉及具体产品的评测。

保护维度	浏览器扩展	隐身插件	引擎级
navigator 属性	JS 覆盖（描述符可检测）	JS 覆盖（时机更好）	原生 C++ 值
Canvas 指纹	仅 API 拦截	仅 API 拦截	渲染输出受控
WebGL 指纹	仅 API 拦截	仅 API 拦截	渲染输出受控
音频指纹	仅 API 拦截	仅 API 拦截	处理输出受控
字体指纹	无法控制字体可用性	无法控制字体可用性	字体列表来自配置文件
HTTP 头	无法修改初始请求	部分（仅导航后）	在网络栈级别设置
Client Hints	无法控制	无法控制	按配置文件控制
TLS 指纹（JA3/JA4）	无法控制	无法控制	由引擎控制
iframe/Worker 上下文	可能遗漏新上下文	覆盖 iframe，可能遗漏 Worker	所有上下文统一
属性描述符检查	可检测（JS getter）	可检测（JS getter）	原生（无法区分）
原型链完整性	被修改	被修改	未修改
时序窗口	页面加载开始后	页面 JS 之前，引擎初始化之后	无（从进程启动即激活）
跨信号一致性	独立补丁	独立补丁	配置文件驱动，统一
性能开销	每页脚本注入	每页脚本注入	零运行时开销

BotBrowser 的引擎级方法

BotBrowser 在浏览器引擎级别实现指纹保护。以下是这种架构所带来的具体能力概述。

配置文件系统

每个指纹由从真实硬件上的真实浏览器会话中捕获的配置文件定义。配置文件包含完整的设备信号集：navigator 属性、屏幕尺寸、GPU 信息、字体列表、渲染特征、音频处理参数等。加载配置文件会同时配置所有这些信号，确保内部一致性。

# 加载从真实 Windows Chrome 会话捕获的配置文件
chrome --bot-profile="/opt/profiles/windows-chrome-134.enc" \
       --user-data-dir="$(mktemp -d)"

确定性噪声种子

对于需要可重复结果的研究和测试场景，BotBrowser 支持噪声种子来控制所有随机化的指纹信号：

chrome --bot-profile="/opt/profiles/profile.enc" \
       --bot-noise-seed=42

相同的配置文件和相同的种子在每次运行时都产生完全相同的 Canvas 哈希、WebGL 输出和音频指纹，无论宿主操作系统或硬件如何。这对于回归测试、CI/CD 管线和受控实验都很有价值。

每上下文独立指纹

BotBrowser 支持在单个浏览器进程中运行多个隔离身份。每个浏览器上下文可以有自己的指纹配置文件、代理和地理设置。

使用每上下文配置，单个浏览器实例可以运行 50 个独立身份。基准数据显示，与运行 50 个独立浏览器实例相比，这种方法实现了 29% 的内存节省和 57% 的进程数减少。

跨平台一致性

在 Linux 服务器上加载的 Windows 配置文件在每个信号上都产生 Windows 一致的输出：navigator 属性、字体列表、Canvas 渲染、WebGL 输出、HTTP 头和 Client Hints。宿主操作系统对外不可见。这在架构上对扩展或 JS 注入方法来说是不可能的，因为它们无法控制渲染引擎或网络栈。

性能

引擎级保护实际上没有运行时开销，因为没有每页 JavaScript 注入，没有 API 拦截，没有运行时修补。配置文件的值编译进浏览器的执行路径。

基准测试结果：

Speedometer 3.0：BotBrowser 得分 42.7，原生 Chrome 得分 42.8（差异 0.2%）
Canvas/WebGL/Navigator/Screen/Font API 延迟：0ms 额外延迟
无每页注入成本：与扩展和隐身插件不同，不需要在每个页面加载时注入和执行 JavaScript

集成示例

Playwright 集成

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/opt/botbrowser/chrome',
    args: [
      '--bot-profile=/opt/profiles/profile.enc',
    ],
    headless: true,
  });

  const context = await browser.newContext({ viewport: null });
  const page = await context.newPage();

  await page.goto('https://abrahamjuliot.github.io/creepjs/');

  // 所有指纹信号与加载的配置文件一致
  // 不需要隐身插件。不需要 evaluateOnNewDocument 补丁。
  // Canvas、WebGL、音频、字体、navigator - 全部在引擎级别控制。

  const fingerprint = await page.evaluate(() => ({
    platform: navigator.platform,
    hardwareConcurrency: navigator.hardwareConcurrency,
    webdriver: navigator.webdriver,
    // 属性描述符是原生的，不是 JS 覆盖
    descriptorType: typeof Object.getOwnPropertyDescriptor(
      Navigator.prototype, 'hardwareConcurrency'
    ).get,
  }));

  console.log(fingerprint);
  await browser.close();
})();

Puppeteer 集成

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/opt/botbrowser/chrome',
    args: [
      '--bot-profile=/opt/profiles/profile.enc',
      '--bot-disable-console-message',
    ],
    headless: true,
    defaultViewport: null, // 保持配置文件的屏幕尺寸
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');

  // 验证一致性：主框架和 iframe 返回相同值
  const consistency = await page.evaluate(() => {
    const iframe = document.createElement('iframe');
    iframe.srcdoc = '<html></html>';
    document.body.appendChild(iframe);

    return {
      mainPlatform: navigator.platform,
      iframePlatform: iframe.contentWindow.navigator.platform,
      match: navigator.platform === iframe.contentWindow.navigator.platform,
    };
  });

  console.log('跨上下文一致性:', consistency);
  // match: true（引擎级控制保证）

  await browser.close();
})();

生产配置

chrome \
  --bot-profile="/opt/profiles/windows-chrome-134.enc" \
  --proxy-server=socks5://user:pass@proxy.example.com:1080 \
  --bot-disable-debugger \
  --bot-disable-console-message \
  --bot-always-active \
  --bot-inject-random-history \
  --bot-port-protection \
  --user-data-dir="/data/session-1" \
  --headless

验证：如何测试你的保护效果

无论使用哪种方法，都应该验证保护的有效性。以下是关键检查项：

1. 属性描述符验证

const checks = await page.evaluate(() => {
  const props = [
    'hardwareConcurrency', 'deviceMemory', 'platform',
    'languages', 'webdriver'
  ];

  return props.map(prop => {
    const desc = Object.getOwnPropertyDescriptor(Navigator.prototype, prop);
    return {
      property: prop,
      hasNativeGetter: desc?.get?.toString().includes('[native code]') ?? 'no getter',
      value: navigator[prop],
    };
  });
});
console.log('属性描述符检查:', checks);
// 引擎级：全部显示 [native code]
// 扩展/隐身：显示 JavaScript 函数

2. 跨上下文一致性

const crossContext = await page.evaluate(() => {
  const iframe = document.createElement('iframe');
  iframe.style.display = 'none';
  document.body.appendChild(iframe);

  const signals = ['platform', 'hardwareConcurrency', 'deviceMemory', 'languages'];
  const results = {};

  for (const signal of signals) {
    const mainValue = JSON.stringify(navigator[signal]);
    const iframeValue = JSON.stringify(iframe.contentWindow.navigator[signal]);
    results[signal] = {
      main: mainValue,
      iframe: iframeValue,
      consistent: mainValue === iframeValue,
    };
  }

  document.body.removeChild(iframe);
  return results;
});
console.log('跨上下文检查:', crossContext);

3. 在线验证工具

访问以下站点检查是否有不一致的警告：

CreepJS - 包含谎言检测的全面指纹分析
BrowserLeaks - 单项信号测试（Canvas、WebGL、字体等）

常见问题

隐身插件能否达到与引擎级修改相同的效果？

不能。隐身插件在 JavaScript 层操作，无法控制渲染输出、网络级别头、TLS 指纹或覆盖值的属性描述符行为。这些是架构限制，不是可以通过更好的代码修复的实现差距。

使用 BotBrowser 后还需要隐身插件吗？

不需要。隐身插件与 BotBrowser 一起使用是多余的，而且可能引入自身的可检测痕迹（注入的 JavaScript 本身就可以被检测到）。BotBrowser 处理隐身插件所解决的所有信号，以及它们无法触及的信号。

声称可以随机化 Canvas 的浏览器扩展呢？

扩展级别的 Canvas 随机化拦截 toDataURL() 和 getImageData() API 调用并向输出添加噪声。这种方法有两个问题。第一，噪声不是应用于实际渲染的，因此底层像素输出保持不变，无论 API 拦截如何。第二，随机噪声产生的指纹在每次页面加载时都会变化，这本身就是一个识别信号。真实设备产生一致的 Canvas 输出。

引擎级修改会影响浏览器性能吗？

影响可以忽略不计。BotBrowser 的 Speedometer 3.0 得分为 42.7，原生 Chrome 为 42.8，差异仅为 0.2%。没有每页注入成本，没有运行时 API 拦截。配置文件的值是浏览器正常执行路径的一部分。

BotBrowser 如何处理新的指纹技术？

因为 BotBrowser 在引擎级别运行，从浏览器引擎读取值的新指纹向量（新 API、新渲染技术、新头类型）可以通过更新引擎代码来解决。这不同于扩展/插件方法，后者每个新向量都需要新的 JavaScript 补丁，而这些补丁可能有自己的可检测性问题。

可以将 BotBrowser 与 Selenium 一起使用吗？

BotBrowser 与 Playwright 和 Puppeteer 配合效果最佳，它们通过 CDP（Chrome DevTools Protocol）通信。Selenium 使用 WebDriver 协议，可能引入额外的自动化信号。如果使用 Selenium，BotBrowser 仍然在引擎级别控制指纹信号，但某些 Selenium 特有的痕迹可能不会被处理。

引擎级修改比隐身插件更难设置吗？

不是，设置实际上更简单。不需要安装隐身插件包、配置多个补丁选项并希望它们不冲突，你只需要将自动化框架指向 BotBrowser 可执行文件并指定一个配置文件。一个可执行文件，一个配置文件，完整的保护。

总结

指纹保护的架构决定了其有效性。浏览器扩展和隐身插件在 JavaScript API 层操作，这意味着它们只能拦截 API 调用，无法控制底层信号。引擎级修改从源头控制信号，在每个 API、每个上下文和浏览器栈的每个层级都产生一致、真实的输出。

BotBrowser 是开源的，可在 GitHub 上获取：https://github.com/botswin/BotBrowser

相关文章

对比

引擎级 vs API 级指纹保护：为什么架构选择至关重要