AliExpress：通过 Web Audio API 进行浏览器指纹识别

打开一家网上商店，手机上的音乐突然静音。浏览器没有播放视频，也听不到广告，即使把标签页设为静音也毫无变化。只有关闭 AliExpress 标签页后，蓝牙耳机才会重新正确切回手机。

这个看似属于蓝牙 Multipoint 的故障，让开发者 Matt Callaghan 在 AliExpress 首页发现了两个高度混淆的 JavaScript 文件。它们都在后台创建一个持续运行的 Web Audio 图。输出电平为零，因此没有任何可听声音；但对浏览器、操作系统和耳机而言，音频路径仍然处于活动状态。

这项发现的技术意义在于，一个意外的硬件副作用暴露了不可见的浏览器测量。从安全角度看，它更值得关注，因为 Web Audio 只是其中一部分。脚本还检测 Canvas、WebGL、屏幕、硬件、受支持的媒体格式、WebRTC 和用户交互。最终结果看起来是一份广泛的浏览器与设备指纹。

一个并非蓝牙故障的蓝牙故障

Callaghan 使用同时连接 PC 和手机的 Multipoint 耳机。通常音乐来自手机；当 PC 真正播放音频时，耳机会切换到 PC。AliExpress 在 Firefox 或 Chrome 中打开后，这个优先级切换突然卡住。他没有测试其他浏览器。

常见原因均被排除。页面没有音频或视频元素，没有调用 HTMLMediaElement.play()，没有活动的 Media Session，网络流量中也没有可识别的媒体文件。唯一异常是干扰会在页面加载数秒后开始。

因此，Callaghan 对 Web Audio API 进行了插桩。他用包装器替换 AudioContext 构造函数，记录新建的音频上下文，并监控通过 AudioNode.connect() 建立的连接。结果出现了两个持续运行的上下文，其堆栈跟踪指向以下脚本：

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

两者都位于 AWSC 路径下。根据其功能，它们似乎属于 Alibaba 用于浏览器安全和滥用检测的基础设施。这个归属判断很合理，但仅凭文件名还无法最终证明。不过，Alibaba Cloud 的 Anti-Bot Web SDK 文档明确描述了一个与服务端评估配合使用的 Web Collector。

行为还可以进一步缩小：阻止这两组脚本后，Callaghan 的对照测量中既没有创建音频上下文，也没有建立到音频输出的连接。首页和普通商品搜索在他的测试中仍可正常使用。

Web Audio 图究竟做了什么

Web Audio 不是隐藏的窃听功能，而是浏览器为游戏、合成器、视频会议和其他交互应用提供的强大接口。网站不只是播放一个音频文件，还可以把各个处理节点连接成图。

被分析的 AliExpress 脚本大致建立了以下链路：

带锯齿波的 OscillatorNode
  -> AnalyserNode
  -> ScriptProcessorNode
  -> 增益为 0 的 GainNode
  -> AudioContext.destination

振荡器生成已知信号。AnalyserNode 提供处理后的测量数据，JavaScript 读取频率值。随后 GainNode 把电平设为零。信号因此不可听见，但图仍与 AudioContext.destination 相连，也就是仍连接实时输出。

这个连接正是副作用的原因。音量为零并不等于没有处理。浏览器继续计算该图，在 Callaghan 的 Windows 系统上，这似乎足以让 PC 音频路径保持活动。耳机的 Multipoint 自动切换因此仍把 PC 视为活动音源。

如果只是计算测量，OfflineAudioContext 会更合理。它把音频图直接渲染到内存缓冲区，不会发送到扬声器或系统音频设备。在 AliExpress 的图中，振荡器和分析节点也位于归零输出之前。连接实时输出对已经读取的频率数据没有明显额外价值，却造成了可见副作用。

Mozilla 早在 2023 年就记录了同一现象

2026 年，Callaghan 的耳机提供了引发公众关注的线索。但 Mozilla 早在 2023 年 11 月就把底层浏览器现象记录为 Bug 1863193。最初针对 Firefox 119 的报告称，AliExpress 页面会在 Windows 11 上触发持续的音频电源请求。即使标签页没有显示播放，powercfg /requests 仍报告活动音频流，导致计算机无法自动进入睡眠。关闭标签页后，请求才消失。

Mozilla 开发者 Karl Tomlinson 随后启用了 Web Audio 日志。日志两次显示了 Callaghan 后来描述的完全相同链路：OscillatorNode、AnalyserNode、ScriptProcessorNode、静音的 GainNode 和 AudioDestinationNode。Tomlinson 在 Chrome 中也观察到类似的持续设备占用，并指出 AliExpress 可以通过 AudioContext.suspend() 结束它。

这是重要的独立确认。硬件副作用并不只基于 Callaghan 对混淆脚本的解释。Mozilla 早在数年前就直接记录了运行中的图及其对 Windows 电源管理的影响。该错误目前仍未关闭。它也表明责任是双方的：AliExpress 本可在测量后挂起上下文，浏览器也可以更早让实际静音且不再需要的图脱离音频设备。

没有麦克风，也没有房间里的超声波

这里必须用词准确。在这项测试中，AliExpress 没有录制麦克风，也没有监听房间中的声音。麦克风访问会通过 getUserMedia() 进行，并需要用户授权。

认为商店通过扬声器发射超声波再物理接收回来，同样具有误导性。测量发生在浏览器的内部音频处理流程中。锯齿波被计算、分析，并在输出前归零。耳机副作用来自虚拟音频图仍然连接着真实输出。

为什么相同计算会产生不同结果

数字信号处理包含大量浮点运算。CPU 架构、数学库、编译器决策、浏览器实现和舍入行为都可能造成细微差异。Web Audio 标准明确把 OscillatorNode、DynamicsCompressorNode、采样率、延迟和时间测量列为潜在的指纹识别面。因此浏览器应限制这些差异。

但 Web Audio 结果不是神奇的硬件序列号。多个设备可能得到相同值，浏览器也可以统一或修改结果。只有与其他特征结合时，识别能力才会上升。

这项技术至少从 2016 年起就在使用

音频指纹并不是 2026 年的新发现。Steven Englehardt 和 Arvind Narayanan 为 2016 年发表于 ACM CCS 的 OpenWPM 研究检查了 100 万个网站。他们在总计 67 个网站上的三个脚本中发现了 AudioContext 指纹。经人工分析，其中两个脚本确实主动使用了该技术。

这些脚本同样由振荡器生成已知信号，再处理、读取并哈希。其中一个有记录的变体让音频图经由 AnalyserNode、ScriptProcessorNode 和静音 GainNode 到达输出，其结构与 AliExpress 模式惊人地接近。Princeton 研究人员当时已强调，此技术不需要麦克风，而且指纹技术通常会组合使用。

因此，AliExpress 案例的新意不在基本思路，而在于它出现在全球最大的在线市场之一，结合了大量其他特征，尤其还通过一个旁路效应暴露了测量。

音频值只是拼图的一块

Callaghan 在被检查的 bundle 中发现了对大量其他特征的查询和测量：

• Canvas 渲染和 toDataURL()
• WebGL 渲染器、扩展和着色器精度
• 屏幕与 viewport 尺寸以及 Device Pixel Ratio
• hardwareConcurrency 和 deviceMemory
• 已安装的浏览器插件和支持的媒体格式
• WebRTC 行为与性能计时
• 鼠标、触摸、焦点和滚动事件
• 设备运动与方向
• 可能表明浏览器自动化或机器人的属性

代码还包含序列化和加密结果的例程，并通过 fetch() 或 sendBeacon() 传输数据。因此在客户端可以确认，大量适合指纹识别的数据能够被收集并发送给 Alibaba 服务。

但服务端如何处理尚未得到证明。从浏览器无法得知保存期限，也无法看出数据之后是否会与账户、订单、其他 Alibaba 服务或广告档案关联。Callaghan 自己也明确指出了这一限制。

AliExpress 隐私政策提到浏览器与操作系统数据、软硬件特征、唯一设备标识符、使用模式和交互。所列目的除了运营和个性化，还包括发现欺诈、洗钱和安全事件。该政策没有让观察到的技术实现变得透明，但说明广泛的设备和使用数据属于其描述的数据模型。

指纹识别并不自动等于广告跟踪

浏览器指纹用于很多不同场景。广告网络可以借此在 Cookie 被删除后重新识别浏览器。网上商店和支付服务也使用类似信号进行风险评估，检测账户接管、优惠券滥用、抓取、机器人或自动购物。

这两种目的并不互斥。同一个设备标识符可以同时服务于安全和营销利益。但仅从发现的 JavaScript 无法证明某项具体的跨站广告活动。直接断言“AliExpress 在所有网站上追踪每个用户”超出了现有证据。

即便如此，从安全评估角度看，该案例仍有问题：

• 测量从普通首页就开始，而非只在登录或支付时进行。
• 脚本高度混淆，用户几乎无法理解。
• 数据收集远不止一个反机器人信号。
• 运行中的音频图没有在界面上得到有意义的提示，标签页静音也无法终止它。
• 后台功能深入影响本地音频路径，甚至改变了外部硬件的行为。

合理的反欺诈措施不一定需要公开实现指南，但必须满足数据最小化、明确限定用途，并让界面行为符合用户预期。一个无声的购物标签页不应占用实时音频路径。

这个音频指纹究竟有多独特？

Firefox 开发者 Tom Ritter 提取了相关 Web Audio 计算，并与 Firefox 遥测数据比较。结果大幅缓和了过度惊恐的说法。

自 Firefox 118 起，Web Audio 在所有平台使用 FDLIBM 数学库，以减少依赖系统的差异。在 Ritter 的分析中，99.24% 的用户只落在三个结果值上；另有 0.76% 的测量点失败并返回零。三个主要群体基本对应 CPU 类别：不带 FMA 的 x86 或 x64、带 FMA 的 x64，以及带 NEON 的 ARM。

对 AliExpress 的具体方法而言，这意味着在 Firefox 中，几乎所有被研究用户的音频值都不是个体唯一的。它更多暴露粗略的处理器类别，而非单个设备。不过，仍存在一条包含其他值的小型长尾，而稀有值反而可能让相应系统更突出。

指纹识别依靠组合。屏幕尺寸、时区或 CPU 类别单独看通常很普通，但 Canvas、WebGL、字体、硬件信息、浏览器特征、交互模式以及已有登录状态结合后，区分能力会强得多。因此 Web Audio 值不必唯一，也能在整体评分中发挥作用。

浏览器保护是一场带有副作用的军备竞赛

浏览器采取不同策略。Firefox 统一某些计算并阻止已知指纹服务。自 Firefox 145 起，更广泛的保护措施首先在隐私模式和严格的增强型跟踪保护中启用。Mozilla 自己也强调，过于激进的统一可能破坏合法功能。

Brave 会轻微改变 Canvas 和 Web Audio 等适合指纹识别的结果。所谓 Farbling 在同一会话和网站内保持稳定，但会在不同网站和会话间提供不同结果。应用仍能获得可信值，却更难把它作为长期全局标识符。

WebKit 在 Safari 中限制多种指纹面，例如本地安装字体和特定设备信息。对于风险特别高的接口，WebKit 有时会在没有安全方案前完全不实现。这体现了根本冲突：让复杂 Web 应用成为可能的接口，也扩大了浏览器的测量面。

没有普通浏览器能够保证所有指纹识别消失。当一个特征被统一后，提供方会转向其他特征或行为信号。而由扩展、字体和手动保护设置组成的极不寻常组合，在最坏情况下反而会让自己的浏览器更加罕见。

用户可以采取哪些具体措施

最合理的基础是使用已启用指纹保护的最新浏览器。Firefox 的进一步保护需要严格的增强型跟踪保护或隐私窗口。Brave 默认启用 Shields 和指纹防护。Safari 应使用最新操作系统和浏览器版本。Tor Browser 与 Mullvad Browser 对敏感会话做得更多：它们尽量让更多用户以相似指纹出现在同一群体中。因此恰恰不应在这些浏览器中加入个性化修改或额外扩展。

仅使用隐私窗口并不是完整答案。它会限制保存的状态，却不会自动隐藏硬件和浏览器特征。删除 Cookie 也不像删除 Cookie ID 那样重置指纹。

VPN 解决的是另一个问题。它替换可见的公网 IP，并视使用方式保护到 VPN 提供商的传输。但 VPN 不会自动改变 Canvas、WebGL、音频计算、字体或硬件特征。因此 VPN 可以有用，却不能单独防止浏览器指纹识别。

使用 uBlock Origin 精确阻止两个脚本

Callaghan 发布了两条刻意保持狭窄的 uBlock Origin 过滤规则：

! AliExpress AWSC fingerprinting scripts
||assets.aliexpress-media.com/g/AWSC/uab/*/collina.js$script,domain=aliexpress.com
||assets.aliexpress-media.com/g/AWSC/fireyejs/*/fireyejs.js$script,domain=aliexpress.com

把它们添加到我的过滤器后，必须关闭已经打开的 AliExpress 标签页。事后阻止脚本并不会结束它此前创建的音频上下文。

这些规则只是当前快照，路径、版本和文件名可能变化。由于脚本可能属于反机器人和风险基础设施，还可能出现额外 CAPTCHA 或登录、结账问题。若无法完成合法交易，可只在该过程中暂时停用规则，完成后再次关闭标签页。

在 DNS 层阻止整个 assets.aliexpress-media.com 主机会粗糙得多，因为那里还可能包含其他商店资源。狭窄的 URL 规则比笼统的域名封锁更可控。

完全关闭 JavaScript 通常并不实际

没有 JavaScript，这项测量无法运行，但现代商店也几乎无法使用。全局关闭还会制造不寻常的浏览器状态，并不能替代对账户、配置文件和敏感活动的合理隔离。

对于特别敏感的研究，可以使用一个单独且尽量少修改的浏览器。这样能减少与日常配置文件的关联，但不能保证匿名。IP 地址、登录、支付数据和服务端信号仍不受影响。

法律问题不只是 Cookie 问题

在欧洲，“无 Cookie”不等于“无需同意”。欧洲数据保护委员会最终版《指南 2/2023》刻意把 ePrivacy 指令第 5(3) 条的技术范围解释得比传统 Cookie 更广。访问存储在终端设备中的信息，或由终端软硬件生成的信息，也可能具有决定性意义。

具体 AliExpress 实现是否合法，取决于实际目的、必要性、各地区 ePrivacy 规则的落实、透明度和后续处理。反欺诈可以是合法目的，但这并不能自动回答首页上收集的每项属性是否都为该目的所必需，或是否需要同意。

本文不能替代法律审查。但从技术角度看，这个案例说明为何 Cookie 横幅无法完整反映现代识别技术。用户可能拒绝所有可见的营销 Cookie，仍被第一方 JavaScript 测量。

测试依据与局限

我最后一次核查技术分析、浏览器信息和公开政策是在 2026 年 8 月 31 日。具体 AliExpress 发现以 Callaghan 在 Windows 上使用 Firefox 和 Chrome 的记录测试及其 Web Audio API 插桩为基础，另有 Mozilla 的独立错误报告、Ritter 对提取音频方法的分析、OpenWPM 研究，以及 W3C、Mozilla、Brave、WebKit、Alibaba Cloud、AliExpress 和 EDPB 的原始文档。

Callaghan 指出的两个带版本脚本 URL 在我检查时仍返回 HTTP 200 和 application/javascript 内容类型。但我没有在受控 AliExpress 账户中亲自执行这些脚本，也没有用自己的耳机复现蓝牙副作用。其他操作系统、浏览器、地区、A/B 测试或后来修改的脚本版本可能表现不同。服务端存储、评分、身份关联以及上传值的用途不可见，因此不属于本文的直接结论。

我的结论

这个案例不能证明存在秘密超声波监控，也不能证明单个音频值可以唯一识别每台计算机。但它很好地证明了现代网站能够在用户毫无察觉的情况下，把浏览器广泛用作测量工具。

反欺诈解释在技术上可信。大型市场必须防御机器人、账户接管、支付欺诈和优惠券滥用。但这并不会自动使客户流程中每个阶段的每种测量都合理。从普通首页就收集音频、图形、硬件、WebRTC 和行为特征的一方，必须回答有关必要性、透明度和副作用的问题。

最终，让测量暴露的不是隐私控制面板，而是一副拒绝假装浏览器安静的蓝牙耳机。

下次再见，
Joe