Skip to content

Build1 publisher3 min readPublished

A zero-gain oscillator held a PC's audio session and broke a Bluetooth handoff

Two obfuscated Alibaba anti-bot scripts on AliExpress built silent Web Audio graphs with no media element. Tab, browser and OS mute did nothing. Closing the tab worked.

The Engineer · Build desk

Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened

  • AliExpress loaded two obfuscated Alibaba security scripts that created silent Web Audio processing graphs and, on one user's Windows setup, prevented multipoint Bluetooth headphones from switching audio back to a phone, according to a technical analysis published August 20th.
  • The scripts generated and analyzed audio without an <audio> or <video> element, so muting the AliExpress tab, Firefox or Windows did not release the computer's audio connection. Closing the tab did.
  • The analysis comes from the operator of the laserphile blog, identified on the site as m-c-tech, and documents one configuration rather than a broad test across headphones, operating systems and browsers.
  • The underlying browser activity was captured by instrumenting the page's Web Audio interfaces and tracing the scripts that created each audio context.
  • The investigation began after a pair of multipoint headphones repeatedly stopped playing audio from a phone while an AliExpress page was open on a connected PC; the interruption appeared several seconds after the page loaded and ended immediately when the tab closed.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

A technical analysis published August 20th reports that AliExpress loaded two obfuscated Alibaba security scripts which built silent Web Audio processing graphs, and that on one user's Windows setup those graphs stopped multipoint Bluetooth headphones from switching audio back to a phone [1]. Because the scripts generated and analyzed audio without an `<audio>` or `<video>` element, muting the AliExpress tab, muting Firefox and muting Windows all failed to release the computer's audio connection; closing the tab released it immediately [2].

The route to the finding is worth the detail. According to the analysis, published by the operator of the laserphile blog, identified on the site as m-c-tech, the investigation started with a symptom rather than a suspicion: a pair of multipoint headphones repeatedly stopped playing phone audio while an AliExpress page was open on a connected PC, several seconds after page load, and recovered the moment the tab closed [3][5]. An initial inspection turned up no media elements, no playback calls, no active Media Session and no visible content that would explain it [6]. The author then wrapped the browser's `AudioContext` constructor and `AudioNode.connect()` to log audio activity [7]. The homepage was running two audio contexts, and stack traces pointed at Alibaba-hosted files named collina.js and fireyejs.js, both under an AWSC directory associated with Alibaba's browser security tooling [8].

The graph itself is the point. Per the analysis, both scripts built the same shape: a sawtooth oscillator into an analyzer and a script processor, then a gain node set to zero, then a connection to the system audio destination [11]. Zero gain makes the output inaudible, but the destination connection still makes the browser push the graph through the machine's audio path, and on this setup that was enough to hold the PC side of the multipoint link open [12]. The Web Audio specification treats the destination as the final audio output, and browser documentation notes it commonly maps to speakers or another physical output device, while a gain of zero effectively mutes the signal [13]. So the user had three mute controls, all operating on volume, against a process that was already silent; the only lever that worked was killing the page [17].

Autoplay policy does not catch this either. Browser autoplay protections cover Web Audio, but their behavior depends on settings, prior interaction and whether the audio counts as inaudible, and MDN's current guidance says muted or zero-volume media may be permitted automatically [14].

Alibaba Cloud's documentation describes AWSC JavaScript components as part of its no-interaction verification product, and its anti-bot documentation says browser-side collectors gather environmental characteristics, automation indicators and user behavior to separate humans from bots, injected across every page of a protected site [9]. An Alibaba developer article identifies fireye.js as part of an AWSC security system for anti-scraping, anti-abuse and human-versus-bot detection, and says calls within the script collect low-level hardware information and can consume significant processing resources [10]. The wider script inspection found code reading canvas output, WebGL properties, screen dimensions, hardware concurrency, device memory, supported media formats, WebRTC behavior, timing information and user interaction, plus code to encrypt and transmit results to Alibaba telemetry services [15]. Those measurements match established browser-fingerprinting techniques [16].

The honest caveat: this documents one configuration, not a test across headphones, operating systems and browsers [3].

What to watch: whether anyone reproduces the handoff failure on other headphone, OS and browser combinations; whether browser vendors stop treating a destination-connected zero-gain graph as an active audio session for the operating system's purposes; and whether the AWSC scripts keep the destination connection, which the analysis suggests is not needed to compute a fingerprint from the analyzer and script processor [11].

Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories