An August 2026 investigation found AliExpress creating live Web Audio graphs that generated and measured a silent signal while broader scripts sampled graphics, hardware and interaction data. The Bluetooth disruption made the behavior visible, but the sharper lesson is that audio is only one component of a larger fingerprint—and, in Firefox, one of the weaker components.
Table of Contents
On August 20, 2026, a developer writing as m-c-tech documented a peculiar AliExpress behavior: opening the marketplace in Firefox or Chrome could stop music from a phone from reaching multipoint Bluetooth headphones, even though the AliExpress tab contained no visible player and produced no audible sound. Instrumenting the Web Audio API exposed two running AudioContext objects traced to collina.js and fireyejs.js; both connected processing nodes to the audio destination while the final gain was set to zero.
That is the verified core of the story. The stronger claim—that AliExpress can uniquely identify a person from the “sound” of a PC—is too broad. The scripts do collect an audio-derived signal, and they also inspect canvas, WebGL, hardware and behavioral properties associated with browser fingerprinting. Yet Firefox has spent years reducing Web Audio variability, and a Mozilla engineer says almost all measured Firefox users fell into only a few audio-output buckets.
The consequential discovery is therefore not a secret ultrasonic ID. It is that a routine shopping page can run a silent measurement stack whose side effects escape the browser UI. The Bluetooth failure made an otherwise invisible anti-abuse or tracking mechanism observable. That distinction matters for users, browser makers and regulators because it separates what the client code proves from what remains unknown about server-side identity linkage.
The Bluetooth failure exposed the signal
The original investigation began with a product-reliability symptom, not a privacy audit. The developer used headphones paired to both a PC and phone. Normally, the headset could return to phone audio when the computer was quiet. After AliExpress loaded, that handoff stopped; closing the tab restored it. Muting the tab, Firefox or Windows did not. The developer then ruled out ordinary <audio> and <video> elements, HTMLMediaElement.play() calls and an active Media Session before instrumenting AudioContext creation and node connections.
That observation has an important historical corroboration. Mozilla Bug 1863193 was opened against Firefox 119 after a user found that AliExpress pages on Windows 11 could keep an audio power request active. Mozilla’s later profiling showed AliExpress creating Web Audio nodes; an oscillator remained running, and Firefox continued processing it even when its output was no longer consumed. The bug remained open and was updated again in August 2026.
The chronology matters. The Mozilla report predates the August 2026 investigation by years, so it provides independent evidence that AliExpress Web Audio activity had already created operating-system-level side effects. It does not prove that the exact same script versions or node graph persisted unchanged across that period. It does show that the current discovery fits an older technical pattern rather than appearing from nowhere.
So the Bluetooth effect is not merely a viral anecdote created this week. AliExpress has previously triggered persistent Web Audio activity visible to Firefox engineers. The 2026 write-up connected that behavior to a broader fingerprint-like script bundle and to a specific multipoint failure on one user’s setup. The scope should stay that precise: the available evidence does not establish that every headset, operating system or browser will react the same way.
The investigative value of the failure is larger than its prevalence. Browser fingerprinting is designed to be background activity. A headset that refuses to switch devices converts invisible processing into an external physical symptom. The privacy mechanism became detectable because it accidentally behaved like a hardware bug.
The audio graph did real work at zero volume
The Web Audio API is built around graphs. Sources such as oscillators feed processing nodes, which can feed an AudioContext destination. The W3C specification defines AudioDestinationNode as the final destination of an audio context, commonly an audio output device, while a GainNode multiplies each sample by its gain value. A gain of zero therefore produces silence at the output without implying that the upstream graph did no computation.
In the AliExpress capture, the reported graph resembled a sawtooth oscillator feeding an analyser and ScriptProcessorNode, then a zero-gain node and AudioContext.destination. The oscillator generated a known waveform; the analyser read data after browser-side processing. The user heard nothing because the final gain was zero, but the context was running and connected to the destination.
That explains the apparently contradictory symptom. Silence is not the same thing as inactivity. A tab-mute control can prevent a user from hearing output without necessarily destroying the JavaScript audio graph or suspending the context that created it. Mozilla’s older AliExpress bug explicitly noted that AudioContext.suspend() could stop the site’s audio-device use, which is different from simply lowering audible volume.
There is also an important correction to the phrase “it sends sound to your speakers.” The browser graph is connected to its destination, but the gain stage makes the final signal silent. The identifying information is read from generated and processed numerical audio data, not from a microphone recording of the room. No evidence reviewed for this article shows AliExpress using the microphone in this mechanism. The fingerprinting issue is computational and device-oriented, not eavesdropping.
The fingerprint is a bundle, not an acoustic serial number
Browser fingerprinting works by combining attributes that vary across browsers, operating systems and hardware. The original AliExpress inspection reported code touching canvas rendering, WebGL renderer properties and shader precision, screen dimensions, device pixel ratio, hardware concurrency, device memory, browser plugins, supported media formats, WebRTC behavior, timing information and interaction events in addition to audio output. It also found serialization and telemetry logic.
Audio can contribute because floating-point processing, browser implementations and CPU-specific code paths do not always produce bit-identical results. Fingerprint, a commercial device-identification company that publishes an open-source browser library, documents the same underlying technique: generate a deterministic waveform, process it through Web Audio, read numerical output and incorporate the result as one signal among many. Its own engineering write-up says audio adds only slightly to uniqueness while remaining useful for stability.
That is a more accurate model than “your CPU has a unique sound.” The audio result is one feature in a multidimensional classifier. A coarse signal that distinguishes a CPU family or rendering path can still help when combined with graphics properties, browser behavior and screen characteristics. Conversely, a supposedly distinctive audio hash is much less useful if a browser intentionally forces many users toward the same output.
Fingerprinting systems care about both uniqueness and stability. A highly unique value that changes every session is poor for recognition; a stable but common value can still narrow a population. Commercial fingerprinting research therefore evaluates signals in combination rather than treating one API result as a serial number. That logic is crucial here because the AliExpress bundle appears designed to accumulate weak and strong attributes into a more discriminating profile.
This bundle logic also explains why the AliExpress code can plausibly serve both fraud prevention and tracking without the client revealing the final server-side purpose. The browser can collect attributes and ship them to a risk system; the server can decide whether they contribute to a bot score, account-risk decision, device link or some other classification. The original investigator explicitly could not see retention rules or identity linkage after transmission. Client-side collection proves measurement, not the exact downstream identity policy.
Fraud prevention explains the incentive, not the opacity
AliExpress’s own privacy policy says the platform automatically collects browser type, device type, unique device identification numbers, operating system, software and hardware attributes, browsing patterns and other usage information. It also says personal data can be used to assess account security and transaction risks, including fraud detection, and separately for recommendations, personalization and tailored advertising.
Those disclosures make an anti-abuse motive credible. Large marketplaces face automated scraping, fake accounts, promotion abuse, payment fraud and account takeover. A fingerprint that survives cookie deletion can help a risk engine notice when the same environment reappears under a different session. The commercial fingerprinting industry openly markets multi-signal browser identification for similar anti-fraud use cases.
But purpose does not erase implementation choices. A security control can be legitimate and still be unnecessarily opaque or technically disruptive. In this case, the measurement ran on a shopping page, created live audio contexts, and on at least one documented setup interfered with Bluetooth multipoint behavior. AliExpress’s cookie notice says essential cookies support security and that analytics cookies can improve platform security, but the public documents reviewed here do not specifically describe the zero-gain Web Audio graph or name collina.js and fireyejs.js as an audio fingerprinting mechanism.
That gap is where the business issue sits. Fraud teams want signals that attackers cannot easily spoof; privacy teams want data collection that users can understand and control; product teams want features that do not seize resources or break peripherals. The more covert and low-level the signal, the more important proportionality becomes, because an anti-abuse technique can impose costs on every ordinary visitor before any risky transaction occurs.
Firefox has already crushed much of audio’s identifying power
The viral version of this story implies that tiny audio differences uniquely identify individual machines. Firefox’s own data undercuts that claim. Mozilla engineer Tom Ritter, writing after examining the Alibaba code, said Firefox made Web Audio output substantially more constant in Firefox 118 as part of anti-fingerprinting work. In an internal survey he cited, 99.24% of users fell into three measured values, while 0.76% produced a failed value of zero.
Mozilla traced the three major buckets to CPU-level implementation differences: x86 and x64 without fused multiply-add, x64 with FMA, and ARM using NEON. A later Mozilla bug changed the relevant Web Audio calculation so the FMA and non-FMA x86/x64 buckets could collapse together; Bug 2036977 was resolved as fixed for the Firefox 152 branch. A remaining architecture distinction had a separate follow-up.
That means Firefox turns this particular audio measurement from a supposed unique identifier into a low-entropy architecture signal for almost everyone. It is not zero information, and Ritter noted a small long tail of unusual outputs, but it is far less precise than the phrase “every CPU sounds different” suggests. Mozilla’s earlier AudioContext fingerprinting bug, fixed for Firefox 118, shows that this reduction was deliberate browser policy rather than an accident.
The long tail is worth retaining in the analysis. Ritter reported 23 other values among 48 survey users and described them as unfortunate because unusual machines can become more distinctive. That is a reminder that normalization protects the majority best; rare hardware, architectures or implementation anomalies can still stand out. Privacy defenses reduce entropy statistically rather than guaranteeing identical output on every possible computer.
Firefox also deploys broader fingerprinting defenses. Its support documentation describes protections for known and suspected fingerprinters and says it introduces random data when sites read back canvas images. Brave takes a different approach, documenting “farbling” and other fingerprinting defenses that modify or randomize semi-identifying API outputs; its Web Audio protection work specifically targeted AudioBuffer data. Browser vendors can reduce the value of a fingerprint without disabling useful APIs outright.
The hardware side effect turns privacy into product reliability
Fingerprinting debates often sound abstract because the harm is about linkability: whether visits can be correlated without a conventional identifier. The AliExpress incident adds a more immediate cost. A live, silent audio context can interact with operating-system audio behavior strongly enough to affect how a multipoint headset decides which connected device should dominate. The original developer’s phone audio stopped; Mozilla’s older bug recorded AliExpress keeping an audio-related power request active on Windows 11.
That changes who has an incentive to care. A privacy control that breaks headphones is also a performance and support problem. Users may blame Bluetooth firmware, Windows, Firefox or the headset vendor because the website gives no visible indication that an audio-processing graph is running. The debugging cost lands far away from the script that created the condition.
There is a wider engineering lesson here. Web APIs expose real device capabilities through abstractions. Graphics fingerprinting consumes GPU-facing data; WebRTC can expose network behavior; Web Audio can acquire and process an output path. If tracking or anti-abuse code uses those APIs continuously rather than briefly and locally, side effects can become observable in power usage, scheduling, device routing or accessibility behavior even when the data collection itself remains invisible.
The uBlock Origin issue opened around the 2026 report proposed narrow filters for the two AliExpress script families and said blocking them restored expected behavior in the reporter’s setup. That is useful evidence of causality for that environment, but it is not a universal prescription. Blocking security scripts can also change login, CAPTCHA or checkout behavior, a risk the original investigator acknowledged.
The strongest claim stops short of proving persistent identity
The available evidence supports several things strongly. AliExpress loaded scripts that created live Web Audio contexts. The scripts generated and analysed a waveform while suppressing audible output. The same bundles inspected many other browser and device properties. Data-handling code transmitted results to Alibaba-related telemetry endpoints, according to the original client-side analysis. And on the investigator’s setup, disabling the scripts removed both the audio contexts and the Bluetooth problem.
What it does not establish is equally important. No reviewed source shows the server-side database schema, retention period, identity-resolution rules or whether the audio output itself becomes a durable identifier tied to a named account. The original investigator explicitly said those server-side uses were not visible. There is also no public evidence here that AliExpress needs audio alone to recognize a returning browser, or that the Bluetooth side effect occurs on all hardware.
The “nearly invisible way of identifying you” description is therefore directionally right about browser fingerprinting but too certain about identity. A fingerprint can be probabilistic, coarse, session-scoped or one feature in a fraud score. Firefox’s audio normalization shows why the distinction matters: a three-bucket signal cannot uniquely identify millions of users by itself, yet it may still add classification value beside canvas, WebGL and other attributes.
There is also a difference between recognizing a browser and identifying a named person. A site can associate a device profile with an account after login, but the reviewed client-side evidence does not show whether AliExpress performs that linkage with this audio-derived value or how long any resulting profile persists. Its privacy policy confirms broad device and account-risk processing, not the server-side mechanics of this specific fingerprint.
The defensible thesis is broader and more troubling: the browser exposes enough semi-identifying surfaces that a site can assemble a useful device profile without asking for microphone access or relying on one cookie. The AliExpress case made that architecture visible because one of the chosen signals unexpectedly affected a physical peripheral.
Browsers, site operators and users have different levers
Browser makers have the strongest structural leverage because they define what websites can measure. Mozilla’s approach shows one path: make Web Audio outputs more uniform, sanitize graphics-related identifiers, randomize selected values and classify known or suspected fingerprinters. Brave’s published strategy combines blocking or modifying APIs with randomized outputs designed to frustrate cross-session or cross-site linking.
Site operators have a different obligation: minimize the signal set and lifecycle. A fraud check should justify why it needs each device surface, when it runs and when it releases resources. Mozilla’s AliExpress bug points to a concrete engineering improvement—suspending or releasing an AudioContext when it is no longer required—rather than leaving a graph running. A security system can also defer higher-cost measurements until a risk-sensitive action such as login, payment or promotion redemption instead of applying the same depth to ordinary browsing.
Users have the least precise controls. Closing the tab stopped the original reporter’s issue; blocking the two scripts also worked in that environment. Firefox users can enable stronger fingerprinting protections, and privacy-focused browsers can reduce the identifying value of some APIs. But script blocking is a blunt instrument and can interfere with anti-fraud flows. There is no single browser setting that simultaneously preserves every site feature, removes every fingerprinting surface and fixes every Bluetooth implementation quirk.
Regulators add a fourth lever. The European Data Protection Board’s final guidance says device fingerprinting falls within the technical scope of Article 5(3) of the ePrivacy Directive. The directive generally requires information and consent for storing or accessing information on terminal equipment unless a narrow necessity exception applies. UK ICO guidance published in 2026 likewise treats device fingerprinting and scripts as storage-and-access technologies governed by PECR. Whether a particular anti-fraud deployment qualifies for an exemption depends on purpose and necessity; the legal question cannot be answered from the JavaScript alone.
The next test is whether the invisible stack becomes accountable
The AliExpress case is persuasive because three layers line up: a user-visible hardware symptom, client-side instrumentation that identifies the responsible Web Audio contexts, and older Mozilla evidence that AliExpress could keep Firefox’s audio path active. The fingerprinting interpretation is strengthened by the same scripts’ collection of graphics, hardware and interaction signals and by AliExpress’s own policy disclosures about device, browser and security-risk data.
The audio component itself is not the most powerful part of that system, especially in Firefox. The real advantage comes from aggregation. When one signal becomes noisy or constant, a risk engine can lean more heavily on others. That is why browser vendors increasingly treat fingerprinting as an ecosystem problem rather than chasing one hash at a time.
The most useful next evidence would be concrete: AliExpress or Alibaba documenting the purpose and retention of the relevant measurements; an independent reproduction across operating systems and browser versions; browser telemetry showing whether the Bluetooth effect is widespread; and technical changes that release the audio destination without weakening legitimate fraud defenses. Without that evidence, claims about permanent cross-site identity should remain qualified.
The judgment for now is conditional but clear. The investigation convincingly exposes a broad, low-visibility device-measurement stack; it does not prove that a silent audio value uniquely identifies an individual. Firefox’s defenses show that one fingerprint surface can be made nearly useless. The unresolved policy question is whether websites will narrow such systems voluntarily—or whether browsers and regulators will have to make invisible measurement expensive enough that anti-fraud teams choose more proportionate designs.
Questions the AliExpress Web Audio case raises
The reported code creates and processes a Web Audio signal and connects the graph to AudioContext.destination, but the final gain is set to zero. That means the graph can remain active while producing no audible sound.
No evidence reviewed for this case shows microphone capture. The reported fingerprinting mechanism generates its own waveform in JavaScript and analyses browser-side processing; it does not require microphone permission.
Because muting audible output does not necessarily suspend or destroy a running AudioContext. Mozilla’s AliExpress bug notes that suspending the context can release audio-device use, which is a different operation from a volume mute.
Not reliably by itself. Mozilla reported that almost all Firefox users in one internal survey fell into only a few audio-output buckets, and it has continued collapsing those differences. Audio can still add information when combined with other fingerprinting signals.
The original analysis reported canvas, WebGL, screen, device-memory, hardware-concurrency, WebRTC, browser capability, timing and interaction measurements alongside Web Audio.
No. Firefox reduces or modifies several fingerprinting surfaces and has made this Web Audio signal much less distinctive, but browser fingerprinting remains a multi-signal problem. Firefox also offers protections against known and suspected fingerprinters.
Brave documents fingerprinting defenses that randomize or modify selected API outputs, and its Web Audio protection work specifically targets audio-buffer data. Those defenses reduce stability or linkability rather than removing every Web Audio capability.
The original investigator and a related uBlock Origin issue reported that narrowly blocking the two identified script families prevented the observed audio contexts in their tests. Blocking anti-abuse scripts can also create login, CAPTCHA or checkout problems, so the result is environment-dependent.
Not categorically. EDPB guidance says device fingerprinting falls within Article 5(3) of the ePrivacy Directive, which generally requires consent unless an applicable necessity exemption applies. The legality of a specific deployment depends on its purpose, implementation, national law and whether an exemption genuinely fits.
Author:
Jan Bielik
CEO & Founder of Webiano Digital & Marketing Agency
This article is an original analysis supported by the sources cited below
AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting
The original August 20, 2026 investigation documented the Bluetooth symptom, instrumented AliExpress’s Web Audio activity, identified the two scripts and described the broader device-measurement bundle.
webaudio fingerprinting on alibaba
Firefox engineer Tom Ritter analysed the Alibaba audio test, explained Firefox’s reduced Web Audio entropy and reported the major CPU-related output buckets.
Bug 1863193 — Audio power request prevents sleep on Windows 11 on Aliexpress pages
Mozilla’s bug tracker independently documented persistent AliExpress Web Audio processing and audio-device power behavior on Firefox.
Bug 1358149 — Address fingerprinting issues with AudioContext
Mozilla’s resolved Firefox 118 bug establishes the browser’s deliberate work to reduce AudioContext fingerprinting differences.
Bug 2036977 — Honor fp-contract=no to reduce fingerprinting in Web Audio
Mozilla’s 2026 fix traces a remaining audio fingerprint bucket to fused multiply-add behavior and records the change targeting Firefox 152.
Firefox’s protection against fingerprinting
Mozilla’s user documentation describes current fingerprinting protections, including protections against known and suspected fingerprinters and canvas readback noise.
The W3C Recommendation defines the Web Audio graph, AudioDestinationNode and GainNode behavior used to explain why a zero-gain graph can still perform processing.
Audio fingerprinting: What it is + how it works with Web API
Fingerprint’s engineering article provides a commercial implementation perspective on audio-derived browser signals, their limitations and their role within multi-signal identification.
Brave’s project documentation explains its strategy of modifying, blocking or randomizing semi-identifying browser API outputs.
Brave’s public engineering issue records its Web Audio fingerprinting defense for AudioBuffer data.
AliExpress’s policy describes automatic collection of device, browser, hardware and usage information and lists fraud prevention, personalization and advertising purposes.
AliExpress’s notice describes security and analytics functions and the platform’s use of cookies and related tracking technologies.
The uBlock Origin issue reproduces the reported multipoint symptom, identifies the same AliExpress script families and records narrow blocking rules tested by the reporter.
Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive
The European Data Protection Board’s final guidance confirms that device fingerprinting falls within the technical scope of Article 5(3) of the ePrivacy Directive.
Directive 2002/58/EC on privacy and electronic communications
The official EU legal text provides the consent and necessity framework for storing or accessing information on terminal equipment.
Final storage and access technologies guidance published
The UK Information Commissioner’s Office confirms that its 2026 guidance covers device fingerprinting and similar storage-and-access technologies under PECR and, where relevant, UK GDPR.
What are storage and access technologies?
The ICO’s detailed guidance explicitly includes device fingerprinting, scripts and tags among technologies subject to the UK storage-and-access rules.
| Citing this article? Brief excerpts are welcome. Please credit Webiano.digital, name the author where stated, and include a link to https://webiano.digital and to this original article. Full or substantial republication requires prior written permission. Read our Copyright and Content Use Policy. |
This article was prepared with the assistance of artificial intelligence tools. The content underwent expert human review, and Webiano Digital & Marketing Agency assumes editorial responsibility for its final version and publication.
