On a PC with AliExpress open, Bluetooth multipoint headphones failed to switch back to a smartphone. On August 20, 2026, independent developer laserphile investigated the issue and found that the homepage was running a silent WebAudio graph from two obfuscated scripts. When the tab was closed, the symptom disappeared; in an environment where the scripts in question were blocked, both the AudioContext and the Bluetooth symptom vanished.
What's being measured here is not microphone input. Nor is it a process that captures speaker output or room reverberation. It's a WebAudio implementation that reads, via FFT, a waveform generated internally by the browser—capturing microphone input would require separate getUserMedia permission.
What has now come together isn't simply the long-known existence of WebAudio fingerprinting, but material that traces a path from a physical side effect to a concrete implementation, a transmission route, and behavior previously reported in Firefox. The identifying power of the value itself and the design that bundles multiple signals to run invisibly need to be considered separately.
Two Silent Graphs Exposed by a Bluetooth Malfunction
What laserphile confirmed were two AudioContexts created by collina.js and fireyejs.js, both hosted under assets.aliexpress-media.com. Both were in the "running" state and connected to AudioContext.destination. The graph generally connected in this order: Sawtooth Oscillator → AnalyserNode → ScriptProcessorNode → GainNode (gain of 0) → destination.
The AnalyserNode is placed before the stage where gain becomes 0, reading the frequency components of the generated waveform. So there's no need for audible output. However, leaving the connection to destination in place can cause the browser and OS to keep the audio pathway open. The investigator's Bluetooth device may have treated the PC as actively playing audio, which appears to have prevented switching to the smartphone.
This symptom is not a step required to obtain the fingerprint value. It's a side effect that the silent implementation had on the OS and Bluetooth. Whether it reproduces across all operating systems, browsers, and headphones remains unconfirmed. Whether the cause lies in Firefox or Windows, and how much the Bluetooth stack or headphone firmware is involved, cannot be determined from this observation alone.
As of August 24, 2026, it has not been verified which regions, pages, or browsers the same scripts are being delivered to. The August 20 observation cannot be generalized to the current state of AliExpress as a whole.
In the code for fireyejs version 1.231.69, extracted and annotated by Tom Ritter, an AnalyserNode with an FFT size of 2048 retrieves 1,024 frequency bins on the first onaudioprocess call and converts them to a string. The original code never calls close() on the AudioContext. An implementation choice to leave the audio pathway open persisted invisibly to users.
Audio Alone Doesn't Make a Device ID
Differences in WebAudio output can be influenced by DSP implementation, resampling, and floating-point rounding. Compiler settings and CPU architecture can also change the values. The W3C Web Audio specification notes that differences normally imperceptible to the ear can constitute fingerprinting information. On the other hand, WebAudio alone tends only to distinguish browser and OS type to a limited degree.
A peer-reviewed paper from IMC 2022 measured seven fingerprinting methods 30 times each across 2,093 participants in 57 countries. The method that aggregated audio vectors produced 95 distinct clusters, 49 of which appeared in only a single person. The information content was 2.803 bits. Adding audio to Canvas alone—which yields 6.109 bits—brought the total to 6.699 bits, a 9.6% increase within the same sample.
This figure doesn't represent the proportion of all current users who can be uniquely identified. Even a weak signal, layered onto existing device attributes, can further narrow a candidate set. Unlike cookies, which store an identifier on the device itself, a method that combines multiple quasi-identifiers isn't rendered meaningless just because each individual value is weak.
Defenses have also progressed in Firefox. According to Ritter, Firefox 118 and later largely normalize WebAudio results, with 99.24% of telemetry falling into just three values. The remaining 0.76% is the value 0, representing collection failures; the three values correspond to CPU-class differences—non-FMA x86/x64, x64 FMA, and ARM NEON. On Firefox, it's difficult for audio values alone to strongly identify an individual device.
The Same Trace in a Two-Year-Old Bugzilla Report
Mozilla's Bugzilla contains a report that opening an AliExpress page in Firefox 119 leaves a power request active for the Windows audio device—even in silence—preventing sleep. The report predates this investigation by roughly two years, and as of August 24, 2026, its status remains NEW.
A Mozilla developer reviewed the WebAudio logs and stated that no use other than fingerprinting was apparent in the process. The AudioContext is said to be capable of being stopped via suspend(); the fact that audio processing continued even when the page produced no audible sound was itself the problem. Whether the exact same script version as the one found in this investigation was running cannot be confirmed from the public bug report alone.
WebAudio-based fingerprinting itself isn't a new technique—it was detected in real-world use in a large-scale web measurement study from 2016. The method observed on AliExpress wasn't the well-known type combining OfflineAudioContext with DynamicsCompressor, but a type using a real-time AudioContext and AnalyserNode's FFT.
laserphile notes that AI assisted in the initial analysis of the obfuscated code. As a result, the structure can only be asserted with certainty to the extent supported by Mozilla's logs, Ritter's extracted code, and the Web Audio specification. Even so, traces remain showing that the silent processing wasn't a one-off coincidence—it had been holding browser resources for some time.
Fraud Prevention and Tracking Draw on the Same Material
The same bundle also examines Canvas and WebGL, along with screen dimensions and device pixel ratio. CPU core count and memory capacity, along with plugin and codec information, are also targets. It further measures WebRTC and processing time, and logs mouse movement, touch input, and screen focus and scrolling. It even queries device orientation and motion, plus attributes specific to browser automation. Code was also confirmed that serializes and encrypts the results before sending them to Alibaba's telemetry service via fetch or sendBeacon.
AliExpress's privacy policy took effect on July 30, 2026. It discloses automatic collection of IP addresses, device type, and unique device identifiers. Browser and OS, software and hardware attributes, and browsing and interaction history are also covered. Stated purposes include account and transaction security and fraud prevention, alongside personalization, advertising, and research and analysis. The policy also names ALIBABA.COM CHINA LIMITED as a risk-management operator.
The policy text doesn't name "fingerprint," "WebAudio," or "Canvas" specifically. The AWSC and automation-detection code, along with the security and risk-management language in the policy, are consistent with a fraud-prevention purpose. However, this doesn't directly prove what the transmitted data is ultimately used for. Use in advertising tracking or as a persistent device ID remains unconfirmed. Cross-use within Alibaba, retention period, server-side matching, and linkage to individuals are also unknown.
France's CNIL classifies fingerprints derived from device configuration as trackers. Prior consent is generally required in principle, though exceptions can apply for authentication strictly necessary for a service the user requested, or for preventing fraudulent logins. How this case would be assessed in the EU and UK depends on the processing purpose and whether strict necessity applies. Beyond consent status, whether the data is kept isolated without secondary use also affects the judgment.
Even When Browsers Neutralize the Values, the Execution Stays Invisible
Firefox's normalization is a defense that suppresses the identifying power of audio output. Brave has also applied per-site, per-session farbling to Canvas and WebAudio since 2020. Within the same session, values remain stable for compatibility, but change if the site or session changes. Defenses that alter values make it harder to reuse a fingerprint.
However, neutralizing the values doesn't automatically erase the fact that a page called the WebAudio API, or that it held CPU and OS audio resources. Because muting a tab prevents sound from playing, users have little way of telling from the UI that two AudioContexts are running. The Bluetooth malfunction in this case is an instance where a physical side effect revealed execution that normally goes unseen.
Evaluating defenses can't rest solely on how much harder WebAudio values have become to identify. It also matters whether users can tell that the API was executed, and whether an unneeded AudioContext gets stopped and close()d. How narrowly the destination and purpose of the transmission are limited is likewise worth checking. As of August 24, 2026, no official response regarding this matter has been confirmed from AliExpress or Alibaba.
Before asking whether the Bluetooth symptom reproduces, it needs to be established which script version is running on which pages, what it transmits, and how long it persists. Browser defenses that lower the identifying power of values, and implementation fixes that reduce invisible execution, are separate matters requiring separate judgment.