一位开发者最近发现了一个离奇的问题：他的蓝牙耳机支持多点连接（multipoint），同时连着电脑和手机。正常情况下电脑播放音频时优先，没有声音时手机可以正常出声。但只要在 Firefox 或 Chrome 里打开速卖通（AliExpress）首页，手机上的音乐就会立刻停止；关掉标签页，声音马上恢复。更诡异的是，静音标签页、静音浏览器甚至静音整个 Windows 都没用——页面上明明没有任何可见的视频、音乐或其他媒体在播放。
两个隐藏的 AudioContext
作者的调查路径很值得借鉴。他先排除了常规嫌疑：没有 audio/video 元素、没有 HTMLMediaElement.play() 调用、没有 Media Session 元数据、没有媒体请求、没有内嵌 frame。随后他换了一个思路——不再找”媒体元素”，而是包装 Web Audio API 的 AudioContext 构造函数和 AudioNode.connect()，观察页面是否在创建音频处理上下文。
结果在闲置数秒后的速卖通首页上，抓到了两个隐藏的 AudioContext：它们都进入 running 状态，都把节点连接到了 AudioContext.destination。调用栈指向两个高度混淆的脚本：assets.aliexpress-media.com 下的 collina.js 和 fireyejs.js，二者都属于阿里 AWSC（浏览器安全与反滥用）工具链。
零音量也能”占线”
这两个脚本构建的音频图是：锯齿波振荡器 → AnalyserNode → ScriptProcessorNode → 增益归零的 GainNode → destination。振荡器生成已知波形，AnalyserNode 读取经过浏览器音频实现后的频谱数据；增益设为零，用户听不到任何声音。但关键在于：图仍然连接着系统音频输出，浏览器必须持续处理这条音频管线。这与自动播放视频完全不同——没有媒体元素，标签页静音按钮根本管不到它。对 Firefox/Windows 来说，这就是一路”正在进行的实时音频”，足以让蓝牙音频通路保持激活，耳机无法干净地切回手机。
这是指纹追踪
反编译这两个包后还发现，它们同时在采集 canvas 渲染与 toDataURL、WebGL 渲染器/扩展/着色器精度、屏幕与视口尺寸、devicePixelRatio、硬件并发数与设备内存、浏览器插件、音视频格式支持、WebRTC 行为、性能计时、鼠标/触摸/焦点/滚动事件、设备运动与方向等大量特征，并加密序列化后通过 fetch/sendBeacon 发往阿里遥测服务。这是一套相当完整的浏览器与设备指纹。音频指纹的原理是：同一信号经过不同浏览器版本、操作系统、音频库和硬件后会产生细微差异，单独看不足以唯一定位设备，但和 canvas、WebGL、硬件、时序、交互数据叠加后就很有用了。
为什么速卖通要这么做
从反滥用角度看，速卖通要面对账号接管、假账号、爬虫、自动下单、支付欺诈、刷评和薅羊毛等问题；Cookie 可被清除、复制、替换，而由大量独立浏览器测量值组成的指纹更难被一致地伪造，交互数据还能区分真人和自动化脚本。但正如作者所言：我不希望一个购物首页静默地运行我的图形、音频、WebRTC、硬件和运动传感器 API 来追踪我的行为——尤其是它还会掐断我的音乐。
社区反响
这条帖子以 848 分登顶 24 小时热榜（280+ 评论）。讨论集中在隐私与反滥用工具的边界、WebAudio 指纹的可行性，以及浏览器指纹对抗手段（如 Firefox 的 RFP、随机化）能否覆盖这类”副作用”。也有评论指出，把音频图连到 destination 导致的蓝牙占线属于典型的”反滥用工具的意外副作用”——安全脚本为了采集数据，反而破坏了用户的正常体验。
一点思考
这个案例的讽刺之处在于：反欺诈脚本想证明”你是真人”，却通过抢占音频通道让真人的体验变得更糟。对普通用户来说，值得记住的教训是——网页能做的事远比”播放视频”多得多，静音按钮挡不住无声的音频处理；而对做 Web 安全的人来说，这是”采集数据时别打扰用户”的又一次生动提醒。
原文：AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting
HN 讨论：news.ycombinator.com/item?id=49372583