AliExpress Runs Two Silent Audio Graphs on Its Homepage. They Are Loud Enough to Break Bluetooth Headphones.
On August 20 a developer writing at blog.laserphile.com published the answer to a problem I would have given up on: his multipoint Bluetooth headphones stopped switching audio back to his phone whenever an AliExpress tab was open in Firefox or Chrome. Closing the tab fixed it instantly. Muting the tab, muting the browser, and muting Windows all did nothing.
There was no video on the page. No audio element. No play() call. navigator.mediaSession.playbackState sat at none the whole time.
He found it by wrapping the AudioContext constructor and logging the stack trace on every construction. The AliExpress homepage was quietly creating two of them.
What the graph actually does
Both AudioContexts entered the running state and both connected nodes all the way through to AudioContext.destination. The stack traces pointed at two scripts under Alibaba's AWSC directory: collina.js and fireyejs.js, both heavily obfuscated, both part of what looks like Alibaba's browser security and anti-abuse tooling.
The graph each one builds looks like this:
OscillatorNode (sawtooth)
-> AnalyserNode
-> ScriptProcessorNode
-> GainNode (gain = 0)
-> AudioContext.destination
That is an audio fingerprint. You generate a known waveform, push it through the browser's audio stack, and read the frequency data back out of the analyser. Small differences in browser build, operating system, audio library, and hardware produce slightly different numbers from an identical input signal. On its own it does not identify anyone. Combined with canvas, WebGL, hardware concurrency, and timing data, it becomes a useful component of a device fingerprint.
The gain node is set to zero, so nothing is audible. That is the point of it. But the graph is still connected to the system audio destination, and connecting to the destination is what makes the browser actively process the graph. The page is doing live audio work, continuously, at zero volume.
Why muting does not help
This is the detail I keep turning over.
Tab mute in Firefox and Chrome is built around media elements. It is a control over playback. There is no <audio> element here to mute, no media session to pause, nothing that the browser's own audio UI models as "content that is playing." From the browser's point of view, the page is not playing media. It is performing audio processing, which is a different thing, and the mute button was never designed to stop it.
On the author's setup, that was enough to keep the PC's Bluetooth audio path alive, which is what prevented the multipoint headphones from handing back to the phone.
I want to be careful about the causal claim here, because the author is too. He observed the correlation on his own hardware and confirmed that blocking the two scripts made the AudioContexts and the destination connections disappear. Whether the exact mechanism is Firefox, Windows, the Bluetooth stack, or some interaction between them is not something a browser-side investigation can settle. What is proven is the client behavior: two running audio graphs, connected to the destination, on a shopping homepage, with no visible indication.
The part that should bother you as a builder
The fingerprinting itself is not surprising. AliExpress has account takeovers, scraping, automated purchasing, payment fraud, review manipulation, and coupon abuse to deal with. Cookies are weak for that because they can be cleared and copied. A fingerprint assembled from many independent measurements is harder to forge consistently. If you have ever run a marketplace, you understand exactly why this code exists.
What should bother you is the shape of the failure. This is a third-party script, doing something reasonable, that produced a physical side effect on hardware the site does not own, that is invisible in every tool a site operator normally looks at.
Ask yourself what would have shown up in your own dashboards. Not an error. Not a console warning. Not a Sentry event. Not a Lighthouse regression, since none of this blocks paint. Not a support ticket either, because the user's headphones are misbehaving and the user blames the headphones. The author only investigated because the symptom was annoying enough and he happened to have the skills to instrument AudioContext.
If you embed a bot-detection vendor, a fraud-scoring SDK, an analytics bundle, or a session replay tool, you have shipped code you cannot read into the browsers of everyone who visits you. The obfuscation is not incidental; these vendors obfuscate deliberately, because being readable would make them easier to defeat. That is a defensible engineering choice and it also means you have no realistic path to auditing what you deployed.
What I would actually do
For a site you run, three things, in rough order of effort:
Enumerate what you have shipped. Open your own site in a clean profile and list every third-party origin that loads a script. Most people find at least one they do not remember adding, usually attached to a marketing tool or an A/B testing product someone trialled and never removed. Removing dead vendors is the highest-value hour available here.
Check whether your vendors touch WebAudio. The instrumentation the author used is about ten lines. Wrap window.AudioContext, log the constructor stack, and also wrap AudioNode.prototype.connect so you can see what reaches the destination. Run it against your own homepage. If a vendor is doing this and you did not know, that is worth a conversation with them at renewal.
Decide where the script is allowed to run. The strongest criticism in the original post is not that fingerprinting happens, it is that it happens on the general shopping homepage, before any sensitive action. There is a real difference between running a fraud check at checkout and running it on every visitor who lands from a search result. If you have a fraud vendor, ask whether you can scope it to login, checkout, and account changes rather than sitewide.
As a user, the author published two narrow uBlock Origin filter rules that block only those two script families and only on AliExpress. They work, though he notes the obvious risk: these are anti-fraud scripts, so blocking them may earn you extra CAPTCHAs or trouble at checkout, and existing tabs need closing because blocking a script does not tear down an AudioContext it already created.
Where this argument is weakest
I am extrapolating from one person's hardware to a general lesson, which is exactly the move I complain about when other people make it. The Bluetooth interaction may well be specific to a particular headset, a particular Windows audio stack, and a particular Firefox build. Plenty of sites run WebAudio fingerprinting without anyone's headphones misbehaving.
The lesson survives the caveat, though, because the lesson is not "WebAudio breaks Bluetooth." It is that a third-party script can hold a resource in a way your monitoring does not model, and the only reason anyone found this one is that the side effect happened to be irritating. The silent ones are still running.
Author
Lukas
@lukcombinator