AliExpress caught using silent audio to fingerprint shoppers' devices

A developer testing the AliExpress homepage could not get his multipoint Bluetooth headphones to switch back to his phone. The headphones stayed locked to the laptop, and the AliExpress tab kept them there until he closed it. The culprit was not a faulty headset. Two obfuscated scripts on the page construct a hidden Web Audio graph to fingerprint the device, and the way Web Audio talks to the operating system is the side effect that surfaced the trick.

WebAudio fingerprinting is a known browser tracking technique. A page plays an inaudible signal through a chain of audio nodes, measures how the browser and the underlying audio hardware distort it, and hashes the result into a device identifier. Modern browsers have largely neutralized the signal. Firefox engineer Tom Ritter ran internal telemetry and found that 99.24% of Firefox users collapse to three values, a result he attributes to CPU FMA (fused multiply-add) and NEON (ARM's SIMD instruction set) differences. The follow-up bugs 2036977 and 2040494 are collapsing the buckets further. The fingerprint, on its own, is mostly noise.

The privacy cost is paid somewhere else. Connecting the Web Audio graph to AudioContext.destination puts the AudioContext into a running state and registers the page as an active audio consumer with the operating system. The OS keeps the audio path warm. On Linux and Windows desktops with a multipoint Bluetooth stack, that warm path blocks the headphones from handing off to another device. Firefox bug 1863193 tracks the symptom.

The scripts live under Alibaba's /AWSC/ anti-abuse path: [collina.js](https://assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js) and [fireyejs.js](https://assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js). The original investigator instrumented them and traced the graph: a sawtooth oscillator feeding an AnalyserNode, then a ScriptProcessorNode, then a GainNode set to zero, then AudioContext.destination. No <audio> or <video> element. No play() call. No Media Session metadata. The browser's tab mute control and the OS audio indicator have nothing to act on, so the user sees nothing and the headphones stay locked.

Ritter extracted the WebAudio portion into a standalone test page and computed two distinct sha256 outputs: 9a388c0dd04cfdc54314f9d961c7e2d247b972067e28d1cea76bd6060cf1392e and 16d3191880ce01f726015ec6a1f9a072a81ebd04bf489098d4685d1d1c0b2711. Two browsers, two audio graphs, two hashes. The hash is the fingerprint.

The audio graph is the smallest data point by entropy. The same scripts run a much wider probe set: canvas toDataURL, WebGL renderer and extensions and shader precision, screen and viewport geometry, device pixel ratio, hardware concurrency, device memory, plugin inventory, supported audio and video formats, WebRTC behavior, performance timing, mouse and touch and focus and scroll events, device motion, device orientation, and an automation-detection routine. The result is serialized, encrypted, and exfiltrated to Alibaba telemetry through fetch() and sendBeacon(). The audio side is what holds the hardware open.

Whether the fingerprint's downstream use is fraud defense, bot detection, or ad targeting is not visible from the client. Alibaba has not commented on the record. The legal framing is more concrete. Under the European Union's ePrivacy Directive, Article 5(3), and the European Data Protection Board's guidance on tracking technologies, fingerprinting that reads device characteristics counts as access to terminal equipment and requires prior consent, regardless of whether the operator labels the practice as fraud prevention. The consent record and the exposure belong to the site that loaded the script, not the vendor that wrote it.

For users, the immediate fix is narrow. uBlock Origin filter rules for the two script families stop the behavior on new page loads. They do not tear down an existing AudioContext. Open tabs have to be closed. The Register, Ghacks, and TechSpot have all picked the story up.

The class of bug is larger than AliExpress. Any third-party script that connects to AudioContext.destination, holds a wake lock, polls sensors, keeps a WebSocket open, or runs requestAnimationFrame on a hidden tab can hold hardware resources in ways no synthetic monitor and most real-user-monitoring setups will see. WebAudio is the loudest example so far because the symptom hits a consumer device the user is already holding. The next vendor to ship the same pattern will not get a developer to blog about it. The browser vendors will.