The AliExpress homepage took the audio channel, and your app takes the support ticket

The mechanism generalises, which is why it should bother anyone shipping sound in a browser. A sawtooth oscillator feeding an analyser, then a script processor, then a gain node pinned to zero, still terminates at the system audio destination ^[6], and the destination is what the browser then has to keep processing ^[7]. Zero gain means nothing audible. A live destination means the tab counts as a producer. Callaghan's description of the page's view of itself is the useful one: "As far as the page is concerned, it is performing live audio processing" ^[9]. Multipoint headphones then behave as designed and give the channel to the device that is producing.

The detail that turns this from trivia into a support problem is the delay. The audio only went after the page had sat idle for several seconds ^[4], which is the state of a tab someone opened, glanced at, and left behind a window. By then the causal link is invisible to the user. Their music stops, and whatever app is on screen is what they blame.

Then the controls. Tab mute, browser mute and Windows mute all did nothing, and only closing the tab restored playback ^[2]. Callaghan's account of why is the sentence to keep: "There is no media element for the browser's normal tab mute control to stop" ^[8]. The mute affordance users have been trained on for a decade is bound to media elements, and a page can hold the audio destination without ever creating one ^[5]. Nothing in a first-line support script reaches that.

Diagnosis is the second bill. Callaghan checked for audio and video elements, play() calls, Media Session metadata, media requests and framed content, found none, and watched the playback state read none throughout ^[3]. He got the answer only by wrapping the AudioContext constructor and the connect method, at which point two running contexts appeared, both wired to the destination ^[5]. That is not a tier-one procedure, and it is not visible in your telemetry either, because the code is served from another company's domain into another company's page ^[10].

What was bought with that audio focus is the awkward part. Tom Ritter of Firefox, writing the same day, says Firefox made its WebAudio output constant in version 118 in September 2023 ^[15], that 99.24% of users now return one of three values, and that 0.76% return zero because the measurement fails ^[16]. The three values map to processor families: x86 and x64 without fused multiply-add, x64 with it, and ARM using NEON ^[17]. His verdict is that WebAudio fingerprinting is nearly useless ^[19]. The exception is a tail of 23 further values held by 48 users worldwide ^[18], about two people per value ^[1], and the two published shares already sum to 100, so those 48 do not appear in the split at all ^[2].

One browser has therefore flattened this signal to a processor-family check for more than 99% of its users ^[16], while the graph that reads it keeps running on a commerce homepage and holding a destination no user-facing mute can release ^[7][8]. The Register, which reported Callaghan's findings on Monday, says it has asked Alibaba to comment ^[13]. Callaghan is careful about the other half of the question: he cannot see what AliExpress does with the data once it reaches its servers ^[12].