AliExpress Wasn’t Playing Audio. It Was Measuring Your Browser.
An AliExpress page did not need to play music, show a video or request microphone access to take control of a computer’s audio path.
Two heavily obfuscated scripts on the shopping site’s homepage created live WebAudio processing graphs, generated a known waveform, measured the result and fed the output into a much larger browser and device fingerprint. The final gain was set to zero, so the process was silent. It was not inactive.
The behaviour became visible only because it caused an external hardware symptom. A developer using multipoint Bluetooth headphones found that audio from a phone stopped when an AliExpress tab had been open for several seconds. Closing the tab immediately restored switching. Muting the tab, browser or Windows did not.
That side effect matters beyond one pair of headphones. It exposed a browser-control gap: a page could maintain a live audio-processing path without an audible signal, a media element or a useful indication to the user. The same code also shows how anti-fraud and bot-detection systems can collect enough browser characteristics to become privacy-sensitive identity infrastructure.
A Bluetooth fault revealed the hidden processing
The original investigation began with an ordinary troubleshooting problem. Multipoint headphones were connected to a PC and phone. The PC normally took priority only while it was producing audio, allowing playback to return to the phone when the computer was quiet.
Opening AliExpress changed that behaviour. The researcher first checked for hidden audio and video elements, calls to the normal media playback function, active media-session metadata, media requests and embedded frames. None explained the result.
The clue appeared after instrumenting the browser’s Web Audio API. During an idle capture of the AliExpress homepage, the page created two AudioContext objects. Both entered the running state, and both connected nodes to AudioContext.destination, the browser’s route to the system audio output.
The stack traces led to two JavaScript bundles hosted on AliExpress infrastructure: collina.js and fireyejs.js. Both were located under an AWSC path associated with Alibaba’s browser-security and anti-abuse tooling.
What the WebAudio graph measured
Each script constructed a graph with the same essential shape: a sawtooth oscillator fed an analyser and a script-processing node, then passed through a gain node set to zero before reaching the audio destination.
The oscillator supplied a predictable input. The analyser measured how the browser and underlying system processed that input. Small differences can reflect the browser version, operating system, CPU instruction set, audio implementation, drivers and hardware. The resulting value is not necessarily a unique identifier on its own, but it can add another dimension to a composite fingerprint.
Zero gain prevented audible output. It did not prevent the graph from running. Because the graph remained connected to the destination, the browser continued processing it. On the researcher’s setup, that was enough for Firefox or Windows to keep the PC’s Bluetooth audio path active and stop the headphones switching cleanly back to the phone.
This distinction explains why the tab mute control did nothing. Browser mute controls are designed around sound a user can hear, not every computation performed through an audio API. There was no conventional player to pause and no audible stream to suppress.
Audio was only one component of the fingerprint
The two bundles did considerably more than test audio processing. The original analysis found code that queried or measured canvas rendering, WebGL renderer data and shader precision, screen and viewport dimensions, device-pixel ratio, processor concurrency, device memory, installed plugins, supported media formats, WebRTC behaviour and browser performance timing.
The scripts also examined mouse, touch, focus and scroll activity, device motion and orientation, and properties commonly associated with automated browsers. Code for serialising and encrypting results, then sending data to Alibaba telemetry services with fetch() or sendBeacon(), was present as well.
Together, those signals can help a platform decide whether a session resembles a returning device, an automated scraper, an account-takeover attempt or a shopper abusing coupons and promotions. Such controls can reduce fraud and unnecessary challenges. They can also recognise a browser after cookies have been cleared and collect far more device information than a shopper reasonably expects from a retail homepage.
The client-side evidence proves that broad fingerprint-like measurements were collected and transmitted. It does not reveal Alibaba’s server-side purpose, retention period or linking rules. The public analysis cannot establish whether the fingerprint becomes a persistent identifier, feeds only a short-lived risk score, or is correlated across other Alibaba properties. It also does not show microphone capture or eavesdropping.
Firefox sharply reduces this specific audio signal
Independent analysis by Firefox engineer Tom Ritter adds an important limit to the finding. Firefox 118 introduced changes intended to make WebAudio output far more constant as part of the browser’s fingerprinting protection.
Mozilla telemetry examined by Ritter placed 99.24 per cent of users into only three output values. The remaining main differences corresponded largely to processor instruction classes: x86 or x64 without fused multiply-add instructions, x64 with those instructions, and ARM processors using NEON. Another 0.76 per cent produced no collected value.
That makes AliExpress’s WebAudio result nearly useless as a standalone identifier for most Firefox users. It does not make the broader fingerprint harmless. A three-way processor clue can still contribute to a profile when it is combined with canvas, WebGL, display, hardware, timing and interaction signals. Privacy protection is therefore a composition problem, not a verdict on one API.
The security use case does not remove the transparency problem
AliExpress has legitimate reasons to distinguish human shoppers from automated or hostile sessions. A global marketplace must contend with account theft, payment fraud, review manipulation, scraping, automated purchasing, fake accounts and promotion abuse.
The problem is not that anti-abuse systems measure risk. It is that ordinary user controls and browser indicators did not describe what this system was doing. The code ran on the general shopping homepage, exercised several high-entropy browser surfaces and kept a live system-audio path open without producing sound. Its real-world effect was stronger than its visibility.
That is a poor control boundary. If a webpage can claim enough of an audio resource to alter Bluetooth behaviour, browsers should expose that state clearly. A mute control that leaves the responsible graph running is technically consistent with today’s API model but misleading from a user’s perspective.
What users and defenders can do
- Close the tab to release the context. In the reported setup, closing AliExpress ended the Bluetooth interference immediately. Blocking a script after it has run may not shut down an existing audio context.
- Use browser fingerprinting protections. Firefox’s resistance substantially reduces this specific WebAudio signal. Brave said its browser blocks the identified scripts and has long applied audio-fingerprinting defences.
- Apply narrow content-blocking rules carefully. The original researcher blocked the two observed script families with uBlock Origin and no longer saw the audio contexts during the control test. Because the bundles appear connected to anti-fraud checks, blocking them may cause additional CAPTCHAs or problems during sign-in and payment.
- Separate sensitive browsing contexts. Organisations that permit consumer marketplaces on managed endpoints can use separate browser profiles, isolation services or restricted browsing environments to reduce the value of cross-session fingerprinting.
- Monitor unexpected API use. Browser-security teams and researchers can instrument
AudioContextcreation and destination connections when analysing sites that should not need audio. The same review should include canvas, WebGL, WebRTC, motion and automation-detection surfaces.
Browser vendors have a larger design question to answer. Live audio processing that touches the system destination should have a visible, understandable state even when final gain is zero. Privacy controls also need to consider combinations of individually weak signals, because a composite fingerprint can remain valuable after one component has been normalised.
What Alibaba still needs to explain
The public client-side evidence leaves several consequential questions unanswered: whether the measurements are retained as a stable device identifier, how long the data remains associated with a session or account, whether it is shared across Alibaba services, which actions trigger collection, and what notice or user control applies.
A narrow anti-fraud explanation may ultimately account for the code. It would not erase the lesson. A silent browser feature became observable because hardware outside the browser reacted to it. That is a warning for any security or analytics system whose reach exceeds the controls users can see.
Sources and further reading
- Original technical investigation: AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting
- Tom Ritter: WebAudio fingerprinting on Alibaba and Firefox’s protections
- Mozilla Bugzilla: audio power request on AliExpress pages
- TechSpot: AliExpress silently running audio to fingerprint a device
- Cybernews: AliExpress and Alibaba audio-system tracking report
