A report about one shopping tab reached 551 points on Hacker News within hours because it exposes an awkward boundary in the web platform: a page can engage the computer's audio system without playing anything a person can hear, and the browser's mute button may not help. In this case, a researcher traced Bluetooth multipoint failures to two silent Web Audio graphs created on the AliExpress homepage. The finding is not proof that every headset or operating system will fail in the same way. It is evidence that fingerprinting code can have a physical side effect far outside the analytics pipeline that deployed it.
The investigation by the author of the Laserphile blog began with a repeatable nuisance. Their headphones were connected to a PC and a phone. Normally, PC audio took priority, while the phone could play when the PC was quiet. Opening AliExpress in Firefox or Chrome stopped audio from the phone after several seconds. Closing the tab restored it immediately. Muting the tab, the browser, or Windows did not.
That last detail is the important one. This was not an autoplay video with its volume set to zero. According to the researcher, the page contained no active audio or video element, made no media playback call, and exposed no active Media Session. The activity instead lived in Web Audio, the lower-level browser API used to build audio-processing graphs.
Two silent graphs, one occupied audio path
The researcher instrumented the page by wrapping the AudioContext constructor and watching nodes connect to its output destination. After the page sat idle, two contexts appeared. Both were running and both connected to the destination used for real-time audio output. Stack traces led to two obfuscated JavaScript bundles served from an AliExpress media domain: collina.js and fireyejs.js, under paths labelled AWSC.
Their audio pipelines reportedly followed the same basic shape: a sawtooth oscillator fed an analyser and a script-processing node, then passed through a gain node set to zero before reaching the destination. The analyser could inspect how the generated signal changed as it moved through the browser and system audio stack. The zero gain made the result inaudible, but it did not make the graph computationally inactive.
That distinction is built into the platform. The W3C Web Audio specification describes AudioContext as an audio graph routed to a real-time output device. It also notes that suspending a context can release resources, while closing one releases system audio resources altogether. A graph connected to the destination may therefore matter to the operating system even when its final samples have been reduced to silence.
On the researcher's Windows setup, the working explanation is that the running contexts kept the PC's Bluetooth audio route active. Multipoint headphones decide which connected source gets control, and a PC that appears to maintain an active audio session can prevent a phone from taking over. Closing the AliExpress tab destroyed that condition. Blocking the two scripts prevented the contexts from appearing during a control test and stopped the interruption.
This is a careful causal chain, not a universal compatibility finding. The report covers one hardware and software setup, with Firefox and Chrome tested and other browsers left untested. It does not establish which combinations of browser, operating system, Bluetooth stack, and headset firmware are affected. AliExpress also does not appear to have provided a public technical explanation in the material available for this report.
Why the code looks like fingerprinting
Audio fingerprinting does not listen through the microphone or record the room. It generates a known signal inside the browser, processes it, and measures the result. Small differences in browser versions, operating systems, processors, audio libraries, resampling, and numerical rounding can change the output. The measurement becomes one feature in a larger device profile.
The privacy issue is not speculative at the standards level. The Web Audio specification's security and privacy section says oscillator and compressor nodes can reveal entropy about a client, and that sample rate, timing, latency, processor architecture, and digital-signal-processing differences can contribute to fingerprinting. It instructs browser makers to mitigate the risk. The broader W3C guidance on browser fingerprinting defines the central problem: APIs that reveal stable or distinctive characteristics can let sites correlate activity without relying on a conventional account or cookie.
The AliExpress bundles went beyond audio, according to the researcher's inspection. The code measured or queried canvas rendering, WebGL information, screen and viewport dimensions, pixel ratio, processor concurrency, device memory, plug-ins, supported media formats, WebRTC behaviour, performance timing, interaction events, motion sensors, and signals associated with browser automation. The report also identified code for serialising and encrypting results and transmitting data through browser networking methods.
Together, those operations are consistent with a broad browser and device fingerprint. What cannot be determined from client-side code is how AliExpress interprets the data after receiving it. It could contribute to fraud and bot detection, account protection, abuse prevention, marketing attribution, persistent recognition, or some combination of those functions. The researcher explicitly could not establish retention periods or whether the fingerprint links activity across other Alibaba services. Those unknowns matter. Calling the code anti-abuse tooling describes its apparent context, not a verified account of every server-side use.
Large marketplaces do have legitimate reasons to separate people from automated clients. Scraping, account takeover, payment fraud, fake accounts, review manipulation, and promotion abuse all create pressure for signals that are harder to clear than cookies. A device risk score can also reduce the number of challenges shown to trusted shoppers. None of that removes the need to examine how much information is collected, when collection begins, and what the code does to a user's machine.
The mute button does not cover every audio API
The practical lesson for browser developers is bigger than this one site. People understand a speaker icon on a tab as evidence that a page is producing sound, and they understand mute as a way to stop it. Here, the reported graph was inaudible, presented no conventional media playback, and survived those familiar controls while still affecting the system's output path. The browser interface and the hardware state told different stories.
That gap creates at least three engineering questions. First, should a page receive clearer UI treatment when a running AudioContext connects to the destination, even if its audible output is zero? Second, should tab mute suspend or reroute Web Audio output strongly enough to release an otherwise active hardware path? Third, can browsers make fingerprinting measurements less stable without breaking music tools, games, accessibility software, and other legitimate low-latency applications?
There is no cost-free answer. A gain value of zero at one point in a graph does not prove the entire context is useless; applications may automate gain, analyse live data, or prepare sound for immediate playback. Automatically suspending a graph could break valid software. A persistent indicator might become visual noise on sites that use Web Audio responsibly. Meanwhile, reducing precision can weaken tracking signals but also compromise real audio work.
The Web Audio specification reflects that tension. It discusses adding jitter or quantising timing and latency values, and limiting sample-rate exposure, while noting that excessive latency damages usability and can create accessibility problems. Browser privacy defences therefore need to control identifying entropy without treating every synthesiser, conferencing tool, or audio editor as hostile.
A narrow workaround, with a trade-off
For people who can reproduce this exact AliExpress problem, the researcher published two narrowly scoped uBlock Origin filters:
||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
Those rules target the two observed script families only on AliExpress. Existing tabs must be closed because blocking a future request does not terminate an AudioContext that already exists. The workaround should not be treated as a universal privacy recipe. Script names and paths can change, and blocking security-related code could trigger extra verification or interfere with login, checkout, or payment. Anyone applying the filters should be prepared to disable them temporarily if a legitimate transaction fails.
For developers diagnosing a similar bug on another site, the more durable method is the one used in the investigation: inspect creation of AudioContext objects, record constructor stacks, watch node connections to the destination, and compare behaviour after blocking the responsible script. Looking only for media elements or network requests labelled audio will miss an entirely synthetic graph. Reproducing the result across browsers and output devices is also essential before attributing a Bluetooth failure to the page.
The next useful evidence would be independent reproduction across Windows, macOS, Linux, Android, and several multipoint headsets, followed by a response from AliExpress about the scripts' purpose, retention, and scope. Browser vendors can then determine whether an active-but-silent graph needs stronger disclosure or different mute semantics. Until that work exists, the measured claim remains specific but consequential: on at least one documented setup, hidden fingerprinting code did not merely identify the machine. It changed which machine the headphones would play.