It started not with privacy, but with a hardware malfunction. A person has a headset with multi-point: simultaneously connected to the computer and the phone, the sound goes from whichever device it came from. A tab opens on the AliExpress homepage — and the phone stops sound. Not immediately: the page needs to linger for a few seconds. You close the tab — the sound on the phone returns. There isn’t a single player, not a single video on the page.
The analysis was published on August 20, 2026 in the m-c-tech blog, and reproduces in Firefox and Chrome on Windows. Below is the same chain of reasoning, but written so you can repeat it in your console in five minutes.
Step 1. Catch the context that shouldn’t be there
The only way to create sound from JavaScript is to build a WebAudio graph, and it always starts with the AudioContext constructor. So the constructor can be overridden with your own and see who calls it:
const OriginalAudioContext = window.AudioContext;
window.AudioContext = class extends OriginalAudioContext {
constructor(...args) {
super(...args);
console.log("AudioContext created", {
state: this.state,
stack: new Error().stack
});
}
};
You need to insert this before the page loads — for example, via a user script with @run-at document-start. The same trick applies to AudioNode.prototype.connect() to see which nodes connect to what.
Result: there are two contexts on the page, both in running state, both pulling a stack to scripts from the same CDN:
https://assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
https://assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js
AWSC is a family of Alibaba anti-fraud scripts, and the version 1.140.0 appears in trackers lists independently: in AdGuard’s bug tracker there is a closed ticket №199162 for aliexpress.com, where AWSC/uab/1.140.0/collina.js appears in this role.
Multi-point — a mode where a Bluetooth headset maintains two active connections and switches playback between them. The decision about who is currently “the boss” is made not by the headphones, but by the OS → A2DP profile chain. As soon as one side opens an audio stream, the other side steps into the background.
Step 2. Five nodes leading to silence
The graph turned out to be short and perfectly canonical for a sound fingerprint: sine-wave oscillator → AnalyserNode → ScriptProcessorNode → GainNode with gain.value = 0 → AudioContext.destination.
The logic is this: the oscillator outputs a known waveform, it passes through the browser’s audio stack implementation on the hardware, and the analyser captures the spectrum at the output. Tiny variations in floating-point rounding yield a stable value that can be used as a device fingerprint. The zero gain is needed so the user doesn’t hear anything.
The audio fingerprint in this set is not unique. From the analysis, the scripts also suppress drawing canvases and toDataURL(), WebGL data — the renderer, extensions, shader precision — screen size and viewport, devicePixelRatio, hardwareConcurrency and deviceMemory, the list of plugins, supported audio and video formats, WebRTC behavior, performance timings, mouse, touch, focus and scroll events, accelerometer and gyroscope readings, and other signs used to usually detect automation. All of this gets sent to Alibaba’s servers in encrypted form.
Remember the purpose: collina.js and fireyejs.js are anti-fraud and anti-bot, not advertising trackers. For such SDKs, device identification is a direct function, not a side effect. This doesn’t negate questions, but explains why the code is there.
Why zero on the gain doesn’t save the headphones
Here’s where the most interesting part hides. The classic sound fingerprint is captured through OfflineAudioContext — it renders the buffer faster than real time and never reaches the sound card. In this case there is no effect on the hardware.
But collina.js builds a normal AudioContext and connects the chain to destination. For the operating system, this means: the tab wants to play sound — we open the audio device. Zero volume doesn’t affect this solution at all, because it’s applied inside the graph, not at the driver level. Then the same multi-point logic triggers: the stream from the computer is open, so the phone gracefully steps aside.
The indicator “sound is playing in the tab” does not light up in this situation. Practical consequence: by the browser UI, you cannot distinguish a page that silently uses your sound card from a normal page. The only reliable sign is the behavior of the hardware.
In discussions on Hacker News, people reported similar observations: hearing-aid users describe how different sites and apps momentarily switch the device to Bluetooth streaming and mute ambient sound; another user linked occasional Bluetooth mouse stalls on a MacBook to the American Express login page. These are comments, not measurements, and cannot be treated as facts — but they point the direction: the side effect is not unique to a single store.
The fingerprint that weighs almost nothing
The story could have gone toward “WebAudio — a new canvas, get ready to defend yourself.” It didn’t, and that’s good: the next day Tom Ritter from Mozilla published telemetry on this very fingerprint.
Numbers: 99.24% of users fall into one of three values, another 0.76% — failed collection, returned zero. The entire long tail — 23 other values belonging to 48 users. The three dominant values correspond to three classes of processors: x86 and x64 without FMA, x64 with FMA3, ARM with NEON. Firefox’s WebAudio values have been constant since version 118, released on September 26, 2023; Chrome implemented similar measures even earlier. Ritter’s conclusion: the audio fingerprint is “almost useless.”
Separate two things. Entropy leakage via WebAudio in modern browsers is closed and barely affects device differentiation. But the ability of a page to silently grab a sound device and keep a Bluetooth channel is not gone — and it costs battery and disrupts headset behavior, regardless of the stated purpose.
What can be done today
The author of the analysis closed the issue with two uBlock Origin rules — after them hidden contexts are not created:
||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
A simple test: open the page with ad blockers enabled, let it sit for half a minute, and check whether the phone sound disappeared. Note the risk: for anti-fraud scripts, blocking may result in order denial or extra Captcha — keep the rule disabled by default.
A second path, without modifying filters, is Firefox: Settings → Privacy & Security → Permissions → Autoplay, default value “Block audio,” and allow exceptions for sites you trust. A radical option privacy.resistFingerprinting disables the Web Audio API entirely (Mozilla bug 1708593), but breaks many normal pages and, at the same time, makes your profile noticeable by other signs.
What you should definitely not do is “mute” the problem at the system level: lower volume, disconnect headphones from the computer, manually change device priority. The audio stream remains open, the headset battery keeps draining, and the root cause stays in place.
Separately note that there is no universal solution here and there will not be one until browsers start treating “connection to destination” as an event worthy of an indicator. This is exactly what Ritter writes: the interesting thing is not the technique, but its invisibility.
Related analyses on the forum: 12 bits per second from the neighboring worker — about how an seemingly innocuous timer turns into a leak channel, and Your subdomains are already in the public log — about passive data collection that requires absolutely nothing to do.
Sources
- m-c-tech. AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting, 20.08.2026
- Tom Ritter (Mozilla). WebAudio fingerprinting on Alibaba
- Discussion on Hacker News
- AdguardFilters, issue #199162 — aliexpress.com
- Bugzilla 1708593 — Disable Web Audio when privacy.resistFingerprinting is enabled
- MDN: Firefox 118 release notes
Do you have multipoint working predictably at all? It would be interesting to collect a list of sites, after opening which the headset “sticks” to the computer — if you find one, attach the interceptor AudioContext from the first step and show the stack.


