AliExpress 首页静默运行 WebAudio 指纹识别：零音量音频图如何抢走你的蓝牙耳机

2026 年 8 月 20 日，一篇逆向分析文章在 Hacker News 上引发热议（891 分、292 条评论）：一位开发者发现，打开 AliExpress 首页后，页面上会静默创建两个隐藏的 WebAudio 音频上下文，把一个「零音量」的音频图接到系统音频输出上——这本来是阿里巴巴风控体系做浏览器指纹采集的手段，却意外导致他的双设备蓝牙耳机（multipoint）无法从电脑切回手机。更讽刺的是：标签页静音、浏览器静音、系统静音全部无效，因为页面上根本没有任何可静音的媒体元素。

这件事对中文开发者有双重价值：一方面它是「大型电商反滥用体系如何做无声指纹采集」的罕见实锤（涉及阿里自研的 AWSC 前端风控脚本）；另一方面它暴露了 Web Audio API 权限模型的盲区——不需要任何用户授权就能让浏览器持续占用系统音频路径。这篇文章还原作者的完整取证过程、拆解音频指纹的原理，再讨论它对 Web 隐私与安全设计的启示。

一、现象：一个打开即复现的蓝牙 Bug

作者（博主 m-c-tech）使用的耳机支持 multipoint 蓝牙音频，同时连接 PC 与手机：PC 播放时优先，PC 空闲时手机出声。这个机制平时工作正常，直到——只要在 Firefox/Chrome 里打开 AliExpress 首页，手机上正在播放的音乐就会立刻中断。

• 关闭 AliExpress 标签页：立即恢复；
• 静音标签页 / Firefox / Windows：完全无效；
• 页面上没有任何可见的视频、音乐或媒体元素：无 <audio>、无 <video>、无 MediaSession 元数据、无媒体请求。

这不是常规的自动播放视频——常规媒体会被浏览器标签页静音机制拦下来。作者由此怀疑问题出在 Web Audio API，于是对页面做了插桩取证。

二、取证：拦截 AudioContext，抓到两个「幽灵」上下文

作者在加载页面前，先包装了 AudioContext 构造函数与 AudioNode.prototype.connect()，记录任何音频处理上下文的创建与连接行为：

const OriginalAudioContext = window.AudioContext;
window.AudioContext = class extends OriginalAudioContext {
  constructor(...args) {
    super(...args);
    console.log("AudioContext created", {
      state: this.state,
      stack: new Error().stack,   // 记录创建者调用栈
    });
  }
};
// 再包装 AudioNode.prototype.connect()，观察谁连到了 destination

结果：AliExpress 首页空闲挂起几秒后，创建了两个 AudioContext，都进入 running 状态，且都向 AudioContext.destination 接了节点。与此同时：零个媒体元素、零次 play() 调用、无 Media Session、无任何可闻声音。

构造函数调用栈指向了两个脚本（都挂在 assets.aliexpress-media.com/g/AWSC/ 目录下，属于阿里巴巴浏览器安全与反滥用工具链）：

两个脚本都经过重度混淆（heavily obfuscated），但残留的标识符足以让 AI 辅助分析还原出音频代码的意图。

三、原理：零音量振荡器为什么能「抢走」音频路径

两个脚本构建的 WebAudio 图基本一致：

Sawtooth oscillator（锯齿波振荡器）
    → AnalyserNode（分析器）
      → ScriptProcessorNode（脚本处理节点）
        → GainNode 设为 0（零增益）
          → AudioContext.destination（系统音频输出）

工作原理拆开看：

• 振荡器生成已知波形，作为「探测信号」；
• AnalyserNode 测量波形经过浏览器音频实现之后的频域结果——不同浏览器版本、操作系统、音频库、硬件声卡对同一信号的处理存在微小差异，这就是指纹来源；
• GainNode 增益为 0，用户理论上听不到声音；
• 但图仍然连到了系统音频目的地，浏览器因此认为页面正在进行实时音频处理，会持续激活音频路径。

关键点在于：这与自动播放视频完全不同。没有媒体元素，浏览器的标签页静音控件无从下手；对页面而言，它只是在做「实时音频处理」，属于合法行为。作者的环境里，这种持续激活足以让 Firefox/Windows 保持 PC 的蓝牙音频通道，阻止 multipoint 耳机干净地切回手机。

四、不止音频：这是一套完整的浏览器指纹

音频探测只是这两个脚本的一小块。对打包代码的检查发现，它们还采集：

结果会序列化并加密，通过 fetch() / sendBeacon() 上报到阿里巴巴的遥测服务。单靠音频指纹不足以唯一标识设备，但叠加 Canvas、WebGL、硬件参数、交互时序后，就能构成高区分度的设备标识，或者作为欺诈/机器人检测评分的一项输入。

五、动机：为什么 AliExpress 要这么干

作者的分析很克制：AliExpress 有充分的业务理由区分「正常购物者」与「自动化客户端」——账号接管、虚假账户、爬虫、自动下单、支付欺诈、刷评论、薅新客优惠等。而 Cookie 不可靠（可被清除、复制、替换），一个由多个独立浏览器测量拼成的指纹更难被一致地伪造。交互数据还能辅助判断浏览器背后是人还是自动化程序。

作者的立场：「我不希望一个购物首页静默动用我的图形、音频、WebRTC、硬件与运动传感器 API 来追踪我的行为——尤其它还以『挡住我音乐』这种讨厌的方式表现出来。也许如果不是 AliExpress 挡住我的音乐，我根本不会去查这个站到底在干什么。」

六、屏蔽方法（uBlock Origin 规则）与注意事项

作者测试了用 uBlock Origin 屏蔽这两个脚本族：屏蔽后首页正常渲染，控制组抓不到任何 AudioContext 与音频连接。规则如下：

! 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，作者建议遇到正常登录/付款被拒时临时禁用这两条规则。

七、行业对照：凡无需授权的 API，都可能被改造成测量仪器

音频指纹并非 AliExpress 首创，它是一整套「无声测量」技术里的一员。这个方向最早被系统性记录，是普林斯顿 Englehardt 与 Narayanayya 的 Online Tracking: A 1-million-site Measurement Study（2016），以及后来的 AmIUnique、FingerprintJS 数据库——它们把 Canvas、WebGL、AudioContext 列为高熵信号。常规做法是用 OfflineAudioContext + DynamicsCompressorNode 渲染出一段哈希，本案的特别之处是把图接到真实 destination 并长期 running，于是副作用溢出到了系统音频硬件。

同一思路的更极端变体在 HN 讨论里被反复提起：

• eBay 的 WebSocket 端口扫描：通过 WebSocket 探测本机开放端口，做内网/本地服务指纹；
• Reddit 滥用 DRM / JIT 内省：借受版权保护内容的解密路径或 JIT 行为差异来测量环境；
• 它们的共同点：不需要任何权限弹窗，只是「借」了某个本就合法的 API，把它变成测量仪器。

八、浏览器如何反击：farbling 与信号归一化

站在 2026 年回看，这条猫鼠游戏的天平正在向「平台级归一化」倾斜。各厂商不再依赖用户去点权限弹窗，而是直接对高熵信号动手脚（DataDome 称之为「指纹识别时代的终结」）：

一个常见误解值得点破：VPN 防不了指纹。指纹来自本地 JS API 的返回值（声卡、驱动、字体渲染），与网络路由无关；想降噪得靠上面这些浏览器自身的能力，或用 EFF 的 Cover Your Tracks 先测自己的「可识别度」。

九、独立观点：真正的病根是「能力型」而非「意图型」权限模型

我的看法比「加个权限弹窗」更悲观一点。给 WebAudio 加一个类似摄像头/麦克风的授权弹窗，大概率只是表演性合规：电商页面确实要播视频声音，用户几乎一定会点允许，而「顺带做指纹」的动机并不会因此消失——弹窗挡不住「借合法能力做测量」的本质。这正是 HN 里有人马上指出的那句。

所以可持续的防线不在「授权」，而在信号归一化：让每个浏览器实例的音频/Canvas/WebGL 输出趋同（Brave 的 farbling、Firefox 的 RFP、Safari 的噪声注入）。当用户群体里的信号方差被压下去，单点的区分度就丧失了——这是用「对抗识别」替代「请求许可」，方向是对的。

但本案里最值得工程团队警惕的，其实是副作用越界：指纹采集代码占住了音频路径，进而改变了外部蓝牙硬件的行为。这把「隐私问题」升级成了「功能干扰」——用户不是被「偷偷识别」，而是被「真实影响」。这类「无感运行时副作用」恰恰是风控脚本最难被审计的地方：代码重度混淆、常驻首页、与业务诉求绑定。给团队的三条护栏：

• 测量性代码只在风控判定必需的时机与页面启用，不要在首页常驻；
• 任何「激活系统资源路径」的行为都应视为用户可见事件，至少要有可观测、可关闭的开关；
• 风控与隐私/体验之间设明确护栏，副作用超出业务边界时要有熔断。

这个案例最好的注脚来自 HN 讨论中的一句调侃：「对某些人这是 Bug，对另一些人这是功能。」当「静默采集」成为默认，用户只能靠第三方过滤规则自保——这不是健康的 Web 生态该有的样子。而把希望寄托在「平台级归一化」上，才算是把责任放回到了该放的地方。

结语

一个「耳机切不回手机」的小烦恼，牵出了一套完整的无授权设备指纹体系。技术层面，零增益音频图是 WebAudio 能力被改造为测量工具的教科书案例；产业层面，它提醒所有做风控/反滥用的团队：隐蔽性与副作用之间没有免费午餐。对普通用户，至少现在有了一条可用的 uBlock 规则；对开发者，这是一个值得写进「Web 权限模型漏洞」清单的真实案例；对平台，farbling 与归一化正在成为新的默认——只是来得有点晚。

信息来源

• laserphile 博客原文：AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting（2026-08-20）
• Hacker News 讨论：AliExpress runs silent WebAudio fingerprinting that breaks Bluetooth multipoint（891 分 / 292 条评论）
• 背景：Englehardt & Narayanan, Online Tracking: A 1-million-site Measurement Study（2016，WebAudio/Canvas/WebGL 指纹的系统性记录）
• 对照：Brave / Firefox resistFingerprinting / Safari iOS 26 Advanced Fingerprinting Protection 的音频信号归一化机制；EFF Cover Your Tracks
• 讨论中提及的对照案例：eBay WebSocket 端口扫描、Reddit 滥用 DRM/JIT 内省（HN 评论引用）

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。