AliExpress and Web Audio fingerprinting: why your Bluetooth cuts out, and what actually blocks it

Hello, this is Ryuta Hamamoto from TIMEWELL.

"When I open AliExpress, the music playing on my phone stops."

On August 20, 2026, an engineer published a write-up of chasing that symptom down.¹ Digging into it turned up device identification running through the Web Audio API — audio fingerprinting. A Firefox developer published a technical analysis the same day.²

Three things about this story get garbled in retelling, so let me clear them first.

One. This is not ultrasonic. "Tracking with sound" usually brings to mind inaudible ultrasonic beacons linking devices together. That is a different technique entirely.

Two. No microphone is involved. Only the output side is used. Nothing is listening to you. Confuse this point and you will aim your countermeasures in the wrong direction.

Three. No regulator cracked down on anything. An individual engineer chased a symptom and a browser developer analyzed it. There is no enforcement action or legal finding here.

With that said, the mechanism is genuinely interesting and the countermeasures are worth taking. Let me go through it.

The short version

• Symptom: opening an AliExpress tab stops phone audio on multipoint Bluetooth headphones. Muting the tab does not fix it
• Cause: a script that connects to the audio output destination with gain set to zero. Silent, but the audio path is held
• Purpose: device identification. Identical calculations produce slightly different floating-point results across CPUs and browsers, and that difference becomes a fingerprint
• No microphone. Output side only
• Canvas rendering, WebGL, screen size, device memory, plugins, WebRTC and performance timing were reportedly collected as well
• Firefox has handled this since version 118 (2023), making output constant so that 99.24% of users fall into one of three values
• Countermeasures are browser choice and script blocking, but closing the audio channel does not stop tracking overall

What happened

The symptom

Here is the setup the discoverer describes.¹

• Multipoint Bluetooth headphones connected to both a PC and a phone
• Music playing from the phone
• Open AliExpress in Firefox or Chrome on the PC, and the phone's music stops
• Close the AliExpress tab and it comes straight back
• Muting the tab does not help
• No visible media is playing on the page

"Multipoint" lets headphones connect to two devices at once and switch to whichever one is producing sound. Convenient, but the side judged to be "producing sound" wins — which is how this surfaced.

The diagnosis

Having confirmed there were no conventional media elements or playback calls, the author instrumented the AudioContext constructor to watch Web Audio API activity.¹

That revealed two AudioContext objects being created quietly, entering the running state, with nodes connected to the audio destination.

What was found

Two obfuscated scripts were responsible.¹

Script	Served from
collina.js	assets.aliexpress-media.com/g/AWSC/uab/1.140.0/
fireyejs.js	assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/

The audio graph they built is the heart of this.

Sawtooth oscillator → AnalyserNode → ScriptProcessorNode → GainNode (gain = 0) → AudioContext.destination

In plain terms:

1. A sawtooth oscillator generates a tone
2. An analyser node examines its frequency content
3. A script processor node processes the signal
4. A gain node sets the volume to zero
5. That gets connected to the audio output destination

Step 4 means nobody hears anything. But step 5 means that, as far as the OS is concerned, this application is producing audio.

That is what confused the Bluetooth switching. No sound, but the audio path is held. Muting the tab does not help because muting silences audible output; it does not release the path.

It was found because of the side effect — which is the interesting part. With non-multipoint headphones, nobody would likely have noticed.

Why sound can identify a device

This is the conceptual hurdle, so let me take it slowly.

Identical calculations, slightly different answers

Computers handle decimals as floating-point numbers, and those calculations always carry a small error.

The important part: how that error falls varies subtly by CPU and by browser implementation. Run the same audio processing and the low-order digits of the returned values differ.

Collect enough of those tiny differences and you can distinguish devices quite finely. No sound needs to be heard; running the audio processing internally and reading out the numbers is enough.

Why this instead of cookies

Cookies can be deleted, and browsers can refuse them. Fingerprinting builds an identifier out of the device's own characteristics, so there is nothing to delete. Private browsing generally yields the same values.

Valuable to the tracker, awkward for the tracked.

It was not only audio

The scripts reportedly gathered much more.¹

• Canvas rendering results (the same shape renders slightly differently across GPUs and drivers)
• WebGL information
• Screen dimensions
• Device memory
• Browser plugins
• WebRTC behaviour
• Performance timing

Fingerprinting gains its accuracy from combination, not from any single signal. Individually these are unremarkable; stack ten or twenty and you can pin down an individual with real confidence.

Keep that in mind when planning defences. Closing the audio channel leaves the rest open.

Firefox handled this three years ago

Tom Ritter, a Firefox developer, published his analysis the same day.² The gist:

Firefox 118 (2023) added fingerprinting protection that makes Web Audio output constant.

The result:

99.24% of users belong to one of three values

Almost everyone returns the same value. A fingerprint is only useful if values are spread out. Three buckets is not an identifier.

The three remaining buckets come from CPU architecture:

Bucket	Description
1	x86 / x64 without FMA
2	x64 with FMA3
3	ARM NEON

Differences in fused multiply-add implementations surface in the results. That is hardware-level and cannot be papered over. But three categories carry almost no identifying value.

Ritter concludes that Web Audio fingerprinting is nearly useless in privacy-focused browsers, while browser fingerprinting in general remains effective.

That framing is right. Not "use Firefox and you are untracked." Rather, "this particular technique does not work on Firefox."

Countermeasures

By position.

For individuals

1. Turn on fingerprinting protection

In Firefox, with fingerprinting protection active, Web Audio is constant as described. Check your enhanced tracking protection level under Privacy and Security.

Tor Browser goes further. Brave implements a comparable defence by slightly randomizing values.

2. Block the scripts with a content blocker

The discoverer added these uBlock Origin rules, which stopped AudioContext from being created at all.¹

||assets.aliexpress-media.com/g/AWSC/uab/*/collina.js$script,domain=aliexpress.com
||assets.aliexpress-media.com/g/AWSC/fireyejs/*/fireyejs.js$script,domain=aliexpress.com

Bluetooth behaviour returned to normal afterwards.

One caveat. The script paths contain version numbers, absorbed by the * wildcard. Change the path structure and the rules stop matching. As a durable fix, the browser-level defence above is more reliable.

3. If you only want the symptom gone

If tracking is not your concern but the music stopping is, closing the tab is the reliable move. Muting will not do it. Temporarily disabling multipoint on the headphones is another workaround.

For IT departments

The corporate question is different: how do you feel about work devices being uniquely identifiable on external sites?

1. Standardize the defence through browser policy

Do not leave this to individual settings. Enable fingerprinting protection through managed policy — Firefox Enterprise Policy, Chrome Group Policy or Cloud Management. "Please turn this on yourselves" is not an operating model.

2. Distribute extensions centrally

Push a content blocker through an allowlisted deployment rather than relying on individuals. A device where staff can install arbitrary extensions is its own risk.

3. Keep unnecessary sites off work devices

Blunt, but there is usually no business need to open a consumer marketplace on a work machine. URL filtering handles this most efficiently.

4. Be able to notice "audio device in use with no audio"

This case surfaced because of a side effect. Without one, nobody notices. Which means the ability to spot device anomalies — unexpected audio device occupation, unexplained CPU load — raises your odds of catching this class of thing.

5. Do not overreact

Worth stating. Fingerprinting is widely used, in advertising and in fraud prevention alike. At least one of the scripts named here appears to serve an anti-fraud purpose. Equating tracking with malice will lead you to bad decisions.

The problem is less the technique itself than it happening where users cannot see it, and in this case, producing a visible side effect.

Where Japanese law sits

For readers here, a note on the regulatory frame.

Japan's Telecommunications Business Act was amended in June 2022 to add external transmission rules, in force from June 16, 2023.³

Operators of telecommunications businesses (website operators, application providers and the like) must, before sending a program to a user's terminal that instructs external transmission, notify or publish the content of the user information to be transmitted, so that users can readily know it

The scope is not limited to cookies — it covers sending user information externally via tags and information-collection modules. Information obtained through fingerprinting sits within that thinking.

On scope, the Ministry of Internal Affairs and Communications says:³

Services that provide a "place" for shopping across multiple stores or buying from multiple sellers online, such as online shopping malls, fall under "telecommunications business" and also under "telecommunications services with a not-insignificant effect on users' interests," and therefore the external transmission rules apply

So services of this kind carry notification and publication duties toward users in Japan.

To be clear: I am not asserting that any particular operator breached this rule. Whether notification and publication are adequate requires reading each operator's published disclosures, and no administrative determination has been made.

What a user can do is actually read the "external transmission" disclosure. Many sites publish a list of externally transmitted information separately from the privacy policy. What gets sent should be written there.

What this case teaches

1. Invisible processing gets found through side effects

The trigger here was music stopping. Nobody detected a privacy violation; someone noticed an inconvenience.

Which means an implementation without side effects runs indefinitely without anyone noticing. That applies to client-side code generally.

2. Browser-side defences are actually working

A mitigation Firefox shipped three years ago covered this outright. Users were protected without doing anything.

Privacy protection features get discussed abstractly. A concrete technique met by a concrete defence is a useful data point.

3. One countermeasure is not enough

Close audio and canvas and WebGL remain. Fingerprinting is fought as a whole. Getting comfortable after plugging one hole is the real risk.

Wrapping up

• An AliExpress page ran a script that connects to the audio output with gain at zero. Silent, but it held the audio path and broke Bluetooth multipoint switching
• The purpose is device identification from tiny floating-point differences. No microphone
• This is not an ultrasonic beacon, and not a regulatory enforcement action
• Canvas, WebGL, screen size and device memory were reportedly collected too
• Firefox 118 (2023) already addressed it. 99.24% of users fall into three values, so it fails as a fingerprint
• For individuals: browser protection and script blocking. Blocking rules are fragile against path changes
• For organizations: standardize through policy rather than individual settings
• In Japan the external transmission rules (in force June 16, 2023) apply, and online shopping malls are in scope

We work on AI and security implementation day to day. What stayed with me here is that before the question of malice comes the question of whether users can see what is happening to them.

Setting the gain to zero was presumably reasoned as "inaudible, therefore harmless." In the user's actual environment, it caused a real problem. Worth holding onto when writing code that runs where nobody is looking.

---

Footnotes

1. laserphile, "AliExpress webpage keeping multipoint bluetooth headphones from playing phone audio" (August 20, 2026). https://blog.laserphile.com/2026/08/aliexpress-webpage-keeping-multipoint.html ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Tom Ritter, "WebAudio Fingerprinting and Alibaba" (August 20, 2026). https://ritter.vg/blog-webaudio_alibaba.html ↩ ↩²

3. Ministry of Internal Affairs and Communications, guidance on the external transmission rules. https://www.soumu.go.jp/main_sosiki/joho_tsusin/d_syohi/gaibusoushin_kiritsu.html ↩ ↩²