AliExpress has been running hidden audio fingerprinting scripts on visitors, according to research covered by Ars Technica. Two obfuscated scripts on the site build silent WebAudio graphs, and the tiny imperfections in how your machine renders a test tone become a tracking identifier. Nothing plays out loud. You never grant permission. The scripts are still loading as of the latest checks.
How the trick works
The technique is AudioContext fingerprinting. A page creates an audio processing graph: a sawtooth oscillator feeding an analyser node, a script processor, then a gain node set to zero so the output stays inaudible, all connected to the AudioContext destination. The page then reads back what the audio stack did to the signal.
The output is never exactly what was put in. Floating-point math, compression, and resampling differ slightly depending on the OS audio libraries, the browser build, the CPU, and the hardware. Those differences are stable for a given machine, so the processed waveform hashes into a durable fingerprint. It’s the same idea as canvas fingerprinting, moved into the audio stack.
Independent analysis of the AliExpress pages found two scripts, collina.js and fireyejs.js, doing exactly this. Both are loaded from AliExpress’s asset servers, both create audio contexts that produce no sound, and neither is disclosed to the user. A researcher documented the oscillator-to-analyser chain in the code, which is how the technique was confirmed rather than just suspected.
Not quite new
Audio-based tracking has a decade of history. In 2016, researchers documented ultrasonic cross-device tracking, where ads embed beacons in the 18 to 22 kHz band and phone microphones pick them up, letting advertisers link your TV, laptop, and phone into one profile. SilverPush was the best-known commercial implementation, and the FTC sent warning letters to app developers using its SDK without disclosure in March 2016. European regulators later classified ultrasonic tracking as profiling under GDPR and the ePrivacy rules, which means it needs consent.
The AliExpress case is a cousin rather than a repeat. Instead of sounds traveling through the air between devices, the signal stays inside the browser’s audio pipeline. That makes it quieter, harder to notice, and dependent on browser architecture rather than microphone access. It also means the usual “apps shouldn’t have mic access” defense does nothing here.
Where browsers stand
Browser defenses are uneven. Firefox 118 started bundling its own math libraries in 2023, which removed much of the hardware-dependent entropy the fingerprint relies on. Chrome and Safari already ship their own audio stacks, so the technique generates less variation there. Brave takes the more aggressive route with farbling: it injects per-site random noise into WebAudio outputs so the fingerprint changes depending on who’s asking.
That leaves a gap. Chromium-based browsers without anti-fingerprinting patches, which is most of them, will produce stable audio hashes. If you run Chrome stock and visit a site running this code, your audio fingerprint is consistent across sessions and useful for tracking you.
What you can do
Blocking the two scripts kills the behavior. A uBlock Origin rule targeting collina.js and fireyejs.js on aliexpress.com stops the audio contexts from ever being created. Brave users get randomization by default, and Firefox users on recent versions are largely shielded. For everyone else, fingerprinting-resistant browsing means either an extension or a different browser.
The bigger problem
The awkward part for the industry is that AliExpress isn’t an obscure site, and the scripts shipped through its standard asset pipeline, apparently unnoticed for a long time. Fingerprinting code hides well because it looks like ordinary feature detection from the outside, and consent banners say nothing about it. Regulators have treated cross-device ultrasonic tracking as profiling; silent in-browser fingerprinting deserves the same scrutiny and mostly doesn’t get it.
Detection is the structural weakness. A page that renders a canvas or queries a font list at least touches APIs with visible side effects a debugger can spot. An audio graph with its gain node at zero produces no sound, no console warning, and no permission prompt, so the only way to catch it is to read the code. Researchers found this one because someone bothered to deobfuscate a 200 KB script file. Most users never will, and most privacy tooling watches cookies and network requests, not API calls that stay entirely on-device.
If you build web products, the takeaway is to audit what your third-party scripts actually instantiate. WebAudio, WebGL, and font enumeration all leak hardware signals, and a vendor SDK that quietly creates an AudioContext is quietly collecting fingerprints whether you intended it or not. That lands on your privacy policy, not the vendor’s.
Where this goes next
Expect more of it. Fingerprints survive cookie clearing, which makes them attractive to ad-tech firms under pressure from cookie deprecation and browser privacy walls. The counter-pressure exists too: Brave’s farbling model and Firefox’s library bundling show browsers can sand down hardware entropy without breaking real audio features. The open question is whether the dominant browser ships anything similar, since Google sells ads and sits in an awkward position as both platform owner and the party profiting from cross-site identity. Until that changes, defensive choices stay with users and with the sites willing to answer for what their scripts do.