一个开发者打开AliExpress的网页,戴着的蓝牙耳机突然没声音了——手机那头的音乐停了,耳机被切到了电脑这一端。关掉网页,声音又回来了。反复试了几次,规律稳定得不像巧合。
这个叫Matthew Callaghan的研究者用的是支持多点连接的蓝牙耳机,可以同时接受手机和电脑两个设备的音频。按理说网页静音标签页不该抢占耳机通道,但AliExpress的页面偏偏做到了。他顺着这条线往下挖,扒出了两个高度混淆的脚本——collina.js和fireyejs.js。
一段“听不见”的音频,是怎么把你出卖的
这两个脚本干的事,说穿了不复杂。它们用浏览器自带的Web Audio API造出一个锯齿波振荡器,让这段声音经过一个分析节点,再经过增益归零处理,最后送进系统音频输出。增益归零意味着用户什么都听不到,但浏览器依然要把这段音频完整跑一遍——处理过程会用到系统底层的数学库,而不同操作系统、不同CPU的数学库在浮点运算上存在细微差异,这些差异被分析节点读出来,拼成一份接近唯一的“声音指纹”。
这正是耳机被打断的原因:网页在后台持续占用系统音频通道,哪怕你什么都听不到,系统层面这段音频是“真实在播放”的。
这不是麦克风窃听,AliExpress也没申请麦克风权限。整套流程从生成到分析都发生在浏览器内部,不涉及采集环境声音,更不是让设备互相“对暗号”。
别跟超声波追踪搞混了
“inaudible sounds”这个说法很容易让人联想到几年前FTC警告过的SilverPush式技术——那种技术是让电视广告里嵌入人耳听不到的超声波信标,手机App在后台用麦克风侦测,借此把电视观看行为和手机使用行为串联起来,是真正的跨设备追踪。
AliExpress这次的手法和那个完全是两回事。它更像是给浏览器做一次“体检”,量的是设备本身的运算特征,而不是窃听环境里发生了什么。把两者混为一谈,容易把关注点从“网站在偷偷给你打标签”跑偏到“有人在监听我说话”,反而模糊了真正该问的问题。
而且这项技术早就过时了。Firefox从118版本起统一了自己的音频数学库,不再依赖操作系统自带的实现,一名Firefox工程师透露,这一改动之后约99.24%的Firefox用户只会落入三种硬件分组里,音频指纹的区分度几乎归零。Chrome同样自带一致的音频处理库,对这个方法天然免疫。Brave更直接,默认就会随机化音频输出,并且专门拦截了这两个脚本。Safari是否有效防护,苹果没有正面回应。
一篇2021年的学术研究可以佐证这项技术的“成色”:研究者在2093名用户样本里,只测出95种不同的音频指纹,而且同一台设备的指纹还不够稳定。单独拿这个信号来识别用户,效果其实很弱。
十几种信号里,浏览器只堵住了一条
真正值得留意的是,音频指纹只是Callaghan发现的一个信号,AliExpress的脚本同时还在收集Canvas渲染、WebGL参数、屏幕与视口尺寸、CPU并发数、设备内存、已安装插件、支持的音视频格式、WebRTC行为、性能计时、鼠标触摸滚动轨迹、设备方向、以及是否命中自动化特征这一长串信号。音频这一项之所以能露馅,纯属它意外撞上了一个物理副作用——耳机被打断——才被人注意到,其余信号大多没有这种“可感知”的破绽,悄无声息地跑着。
- 结论.浏览器厂商能对付的,是那些留下了可测量副作用或已经被公开研究过的信号,像音频指纹这种;真正难防的,是Canvas、WebGL、行为轨迹这类几乎没有性能代价、也不容易被用户察觉的组合拳。
设备指纹本身不是新鲜事,Fingerprint、Sift、DataDome这类反欺诈供应商的产品文档里,音频信号一直被列为标准检测项之一,电商平台用它防机器人、防盗号,某种程度上算是行业惯例。真正的问题不在于用不用指纹,而在于藏得多深、说得多少。AliExpress把脚本文件名混淆到看不出用途,把静音处理伪装成正常音频播放,这已经不是“反欺诈”该有的克制,而更像是刻意规避用户察觉。
截至目前,阿里巴巴没有对这份报告做任何实质性回应,是否持久化保存这些指纹、是否在阿里系各个平台之间共享、有没有超出反欺诈范围用于精准营销,统统没有答案。这些问题恰恰是FTC多年前处理SilverPush类案件时反复强调的重点:哈希化不等于匿名化,弱信号一旦和其他强信号拼在一起,照样能拼出一个持久、可追踪的身份。
普通用户能做的有限——用Firefox或Brave能挡掉这一条音频信号,用uBlock Origin之类的拦截规则或许能屏蔽部分脚本,但代价是电商网站可能因此把你判定为高风险设备,弹出更多验证码。清Cookie在这种指纹面前基本无效,因为它靠的从来不是本地存储,而是设备本身的物理和运算特征。这才是这次事件真正让人不舒服的地方:抓个现行不难,难的是搞清楚抓到之后,数据到底流去了哪里。