By ByteBot
A developer debugging their Bluetooth headphones this week traced an unexpected culprit: the AliExpress homepage. Open it in a tab, and the site silently launches two WebAudio graphs that keep a ghost audio stream active in your browser. Your multipoint headphones read that stream as active audio from your laptop and refuse to switch to your phone. The post hit the top of Hacker News with 830+ points. The root cause is browser fingerprinting — and the Bluetooth disruption is entirely unintentional collateral damage.
What Was Found
The discovery came from a technical post published today by a developer who goes by “laserphile.” After noticing that opening AliExpress in any tab broke their multipoint headphone switching, they dug into the page’s JavaScript. What they found were two AudioContext instances created on page load by obfuscated Alibaba scripts: collina.js and fireyejs.js, both part of Alibaba’s AWSC (web security/client) module.
The scripts are heavily obfuscated — standard static analysis tools can’t touch them. The researcher used AI-assisted deobfuscation to decode what the audio code was doing: create an OscillatorNode, route it through a DynamicsCompressorNode, read the floating-point output into a buffer, then connect everything through a GainNode set to exactly 0.0 before hitting AudioContext.destination. Silent — but very much running.
Why Your Headphones Stop Switching
This is where it gets technically interesting. Bluetooth multipoint headphones maintain two simultaneous A2DP connections and switch active audio based on which device the OS reports as “outputting audio.” The key word is outputting — not playing audibly, but actively streaming.
When AliExpress connects its zero-gain AudioContext to the destination, the OS-level audio stack (Windows WASAPI, macOS CoreAudio) registers the browser as an active audio output device. From the headphone’s perspective, your laptop is streaming. So when you hit play on your phone, the headphones don’t switch — they see two competing “active” sources and the laptop wins because it got there first.
Browser mute does nothing here. The AudioContext is still running; you’ve just lowered the system volume on top of it. The only fix is closing the tab. Affected devices reported in the HN thread (800+ comments) include Sony WH-1000XM-series, Bose QuietComfort, Jabra Evolve2, and — more concerning — some hearing aids that responded to the silent stream by reducing ambient sound processing.
What WebAudio Fingerprinting Actually Does
The purpose of the scripts is device identification without cookies. The WebAudio API was designed for audio synthesis and processing, but it has a fingerprinting-useful property: floating-point audio sample values differ slightly between devices based on CPU floating-point unit behavior, audio driver stack, and OS audio subsystem version. An OscillatorNode processed through a DynamicsCompressor produces a slightly different number on a Dell XPS running Windows than on a MacBook Pro running macOS. Run that check on every visit, hash the output, and you have a stable device identifier that survives incognito mode, cookie clearing, and VPN use.
This technique has been documented since 2013. The W3C WebAudio Working Group has had open issues about it since 2017. AliExpress is not doing anything unusual — bot detection vendors, analytics platforms, and much of the Chinese e-commerce ecosystem (Temu and Shein use the same AWSC module) run similar code. The Bluetooth disruption is what made it visible.
Browser Protection in 2026
Chrome has nothing. Google killed Privacy Sandbox in April 2025 without shipping a single fingerprinting-specific mitigation, and the gap has only widened. If you’re on Chrome, WebAudio fingerprinting runs unimpeded on every site that uses it.
Firefox users with privacy.resistFingerprinting enabled get randomized audio output values, which breaks the fingerprint — but the AudioContext stays running, so Bluetooth disruption persists. Safari handles this best: Intelligent Tracking Prevention closes AudioContexts after roughly 30 seconds of page inactivity, and Safari’s WebAudio implementation adds random noise to output. Brave’s “farbling” randomizes audio API outputs across the board. Neither fully solves the Bluetooth problem, but both make the fingerprint useless.
What Developers Must Do
If you write WebAudio code, there’s a rule you may not be following: suspend the AudioContext when you’re not actively rendering audio.
// This keeps a ghost stream running and breaks Bluetooth multipoint:
const ctx = new AudioContext();
gain.connect(ctx.destination); // OS registers "active audio"
// Correct: suspend when idle
const ctx = new AudioContext();
await ctx.suspend(); // frees the audio stream
// When you actually need to play:
await ctx.resume();An AudioContext connected to destination — even through a gain of 0 — registers as active audio in the OS. That means any user with multipoint Bluetooth headphones will have switching broken as long as your page is open. The AliExpress case is the first time this became visible at scale. It won’t be the last. Mozilla is tracking improvements to WebAudio privacy protections, and browser vendors will move faster now that there’s a concrete, user-visible symptom attached to the problem.
For users right now: uBlock Origin in medium mode blocks the AWSC scripts. Default filter lists don’t cover inline scripts. Closing the AliExpress tab is the immediate fix. Chrome users are otherwise on their own until Google decides fingerprinting defenses are worth building.
