An AliExpress page measured the browser with WebAudio

On August 20, a developer writing as m-c-tech documented a failure involving an AliExpress tab and Bluetooth multipoint. His headphones were connected to both a Windows PC and a phone. Loading the marketplace in Firefox or Chrome stopped audio from the phone; closing the tab brought it back. Muting the tab, the browser, or Windows audio did not help.¹

Browser instrumentation exposed two active AudioContext objects created by obfuscated scripts served from AliExpress's assets.aliexpress-media.com domain, under AWSC paths. Their graphs generated and analyzed audio before sending it through a GainNode set to zero. Nothing audible reached the headphones, the scripts never opened the microphone, and no signal crossed the room. The contexts kept the PC audio path active during the multipoint failure; blocking them removed the problem in the test.¹

Those scripts collected several other browser characteristics associated with fingerprinting. The client code establishes that measurements were made and transmitted. It cannot show how long a server retains them, whether they feed an anti-fraud decision, or whether Alibaba links a person across properties. The original researcher drew the same boundary around his findings.¹

Zero gain stops output after the measurement

WebAudio lets a page synthesize, route, and inspect sound through a graph of processing nodes. In the captured graph, a sawtooth OscillatorNode fed an AnalyserNode and a ScriptProcessorNode. A zeroed GainNode sat near the end, followed by AudioContext.destination.¹

By that stage, earlier nodes had already produced numerical samples. Differences in browser engines, audio implementations, and math libraries can shift the output slightly. Code can turn those samples into a compact value and combine it with less exotic browser signals.² ³

The ordering also accounts for the visible Bluetooth symptom. System mute controls had no useful output left to silence, but the running context still held the computer's audio path. In the researcher's test, blocking the two script files with a local uBlock Origin rule removed the contexts and restored normal multipoint behavior.¹ The test covered his own machines and headphones; it did not estimate how often the fault occurs across operating systems or hardware.

Firefox collapses most results into three values

The surrounding collection reached far beyond audio. It queried canvas and WebGL output, screen dimensions, pixel density, codecs, and hardware characteristics. Interaction data covered focus and scrolling as well as mouse and touch events. Checks associated with automated browsers appeared in the same code.¹ WebAudio supplied one coordinate in that larger fingerprint.

Firefox engineer Tom Ritter examined the distribution of the WebAudio result in his own browser data. A mitigation that landed in Firefox 118 moved audio calculations to a standardized math library, reducing machine-specific variation. In Ritter's sample, 99.24% of users produced one of only three values. Another 0.76% failed or returned zero, with a long tail of 48 users outside those common outputs.² ³

For protected Firefox users, that distribution leaves the value with little identifying power on its own. A rare result may still flag an unusual environment, while a common result can contribute a small amount of information to a composite fingerprint. Neither outcome turns the audio value into a unique device ID.

A collection of weak attributes may separate browsers even when no single attribute does. Server-side behavior remains the missing part of the evidence. Fraud prevention, abuse detection, and commercial tracking are all possible uses of a fingerprinting stack; the observed JavaScript does not select among them.¹

Ultrasonic tracking has a physical channel

Calling this output “inaudible” does not make it an ultrasonic cross-device beacon. In the captured AliExpress graphs, audio stayed inside the PC and zero gain prevented playback. The code did not request microphone input.¹

Ultrasonic cross-device tracking uses a different route. A television or a speaker controlled by a web page emits a coded tone above normal human hearing. A second device, commonly a phone running an app with microphone access, detects that tone and reports proximity. Privacy researchers mapped this ecosystem and its linking risks in a 2017 peer-reviewed study.⁵

The US Federal Trade Commission confronted one version of that architecture in 2016. It warned twelve app developers whose products contained the Silverpush SDK, which could listen for audio beacons embedded in television advertising even while an app ran in the background. The FTC also recorded Silverpush's statement that its beacons were not then operating in US television programming.⁶ That case required an acoustic emitter and a listening device. Neither component appeared in the AliExpress observation.

Browser defenses target the signal upstream

Firefox makes the calculation less variable. Brave's published approach adds session- and site-scoped randomization to high-entropy APIs, including WebAudio, so a stable machine does not return a stable value that can be linked freely across contexts.⁴ These protections trade some precision and compatibility for lower fingerprinting value, with implementation choices that differ by browser.

Denying microphone access helps against a receiver listening for ultrasonic beacons. It does nothing to a zero-gain WebAudio graph that never asks for that permission. In the original test, narrow uBlock Origin filters blocked only the collina.js and fireyejs.js script families. Existing tabs had to be closed because blocking a file does not shut down an AudioContext that is already running; the researcher also warned that the filters may trigger extra CAPTCHAs or login and payment problems.¹ Current browsers with native anti-fingerprinting measures can reduce this signal without making the rest of a composite fingerprint disappear.

That channel-by-channel distinction is also useful in a minimum viable privacy setup. Ultrasonic beacons reach a receiver through its microphone. The AliExpress measurement took place entirely inside the tab's WebAudio implementation.

Sources

1. AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting · m-c-tech / laserphile · https://blog.laserphile.com/2026/08/aliexpress-webpage-keeping-multipoint.html · Aug. 20, 2026
2. webaudio fingerprinting on alibaba · Tom Ritter · https://ritter.vg/blog-webaudio_alibaba.html · Aug. 20, 2026

Show 4 more sourcesHide sources

3. Use FDLIBM in WebAudio to reduce fingerprinting · Mozilla Bugzilla · https://bugzilla.mozilla.org/show_bug.cgi?id=1358149 · change shipped in Firefox 118
4. Fingerprinting Protections · Brave Browser Wiki · https://github.com/brave/brave-browser/wiki/Fingerprinting-Protections/a400aea46678d76e25f5f325e224f65ff3e958a6 · official documentation
5. On the Privacy and Security of the Ultrasound Ecosystem · Proceedings on Privacy Enhancing Technologies · https://petsymposium.org/popets/2017/popets-2017-0018.pdf · 2017
6. FTC Issues Warning Letters to App Developers Using ‘Silverpush’ Code · Federal Trade Commission · https://www.ftc.gov/news-events/news/press-releases/2016/03/ftc-issues-warning-letters-app-developers-using-silverpush-code · Mar. 17, 2016

— Newsroom