Silent AliExpress Audio Code Froze Headphones and Exposed Fingerprints

A developer’s multipoint Bluetooth headphones stopped handing audio back to his phone whenever the AliExpress homepage stayed open. Closing the tab fixed it at once. Muting the tab, the browser or the OS did nothing. The cause was two silent Web Audio graphs running from Alibaba security scripts that form part of a broad device fingerprint.

The glitch turned an invisible anti-abuse technique into something a user could feel. Researcher Matthew Callaghan, writing as laserphile, published the full technical write-up of the discovery on 20 August 2026 after instrumenting the page.

What began as a personal annoyance became a clear map of how a shopping homepage can keep a system audio pipeline busy without any visible player. The same work also showed how that pipeline activity fits inside a much larger set of browser and device measurements.

Headphones That Refused to Switch

Callaghan’s headphones support multipoint connections, so they stay paired to both a PC and a phone. The PC normally takes priority. Phone audio resumes when the computer is quiet. Opening AliExpress in Firefox or Chrome broke that handoff after a few idle seconds.

“Shortly after loading the AliExpress homepage, audio from my phone would stop playing,” he wrote. “Closing the AliExpress tab fixes it immediately. Muting the tab/Firefox/Windows does not help, and there is no visible video, music, or other media playing on the page.”

He first hunted conventional media elements, play() calls and Media Session metadata. Nothing appeared. The delay before the failure pointed him at the Web Audio API instead.

Multipoint designs treat the computer as the active endpoint whenever its audio stack looks busy. A live Web Audio graph counts as busy even when every sample is silent. That is why the phone never regained the link while the tab stayed open, and why ordinary mute controls never restored it.

Two Obfuscated Scripts Keep the Audio Path Alive

By wrapping the AudioContext constructor and connect() calls he caught two contexts entering the running state and wiring nodes to AudioContext.destination. Stack traces named the sources:

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

Both sit under Alibaba’s AWSC anti-abuse directory. Each built the same processing chain: a sawtooth oscillator feeding an AnalyserNode, then a ScriptProcessorNode, then a GainNode fixed at zero, then the destination.

The chain itself is simple when laid out step by step:

1. A sawtooth oscillator generates a known waveform.
2. An AnalyserNode measures what the browser’s audio stack returns.
3. A ScriptProcessorNode continues the live processing path.
4. A GainNode fixed at zero keeps the result inaudible.
5. A final connection to the destination forces the system pipeline to stay active.

The oscillator produces a known waveform. The analyser measures what the browser’s audio stack returns. Gain at zero keeps it inaudible. The destination connection still forces the browser to process the live graph and keeps the system audio pipeline active. That is what held the Bluetooth path open on Callaghan’s machine. No media element existed for the tab mute control to silence.

This is very different from an autoplaying video. There is no media element for the browser’s normal tab mute control to stop. As far as the page is concerned, it is performing live audio processing.

Matthew Callaghan, laserphile blog

Because the graph never touches a media element, browser chrome that only watches for video or audio tags has nothing to latch onto. The page can claim it is only doing measurement work while the operating system still treats the output path as occupied.

The Rest of the Fingerprint Stack

Audio was only one measurement. Callaghan’s inspection of the bundles showed the scripts also collected a long list of signals, serialised and encrypted them, then sent the package to Alibaba telemetry via fetch() or sendBeacon(). He called the result “a fairly comprehensive browser and device fingerprint.”

Small differences in CPU floating-point behaviour, OS audio libraries, drivers and browser implementations once made pure audio fingerprints highly identifying. Combined with the other signals they still help build a stable profile that survives cookie clearing.

Each category answers a different question about the client. Rendering probes expose GPU and driver details. Hardware fields sketch memory and display layout. Media tests reveal codec support. Timing and input streams capture how a real user moves. Environment checks look for automation. Taken together they form a package that is harder to reset than a single cookie jar.

Serialisation and encryption happen before the data leaves the page. The browser still initiates the transfer through ordinary fetch() or sendBeacon() calls, so the collection path looks like routine telemetry even though the payload is rich.

Why the Audio Piece Is Already Weak

Firefox engineer Tom Ritter examined the same WebAudio code and concluded the vector has little remaining power in modern browsers. Firefox made its audio math constant starting in version 118 three years earlier as part of fingerprinting protections. Telemetry showed 99.24 percent of users fall into one of three buckets that largely track CPU architecture (x86 without FMA, x64 with FMA, ARM NEON). A long tail of rare outliers still exists, but the bulk of the entropy is gone.

Ritter wrote that Chrome ships its own libraries too and that Safari is likely similar. “But at the end of the day, WebAudio fingerprinting is nearly useless,” he said in his Firefox engineer’s breakdown of remaining entropy. The technique may linger as leftover code or a minor input to a larger risk score. Its presence on a major shopping homepage still surprised many because the side effect was so concrete.

Crowd reaction on X treated the Bluetooth freeze as the moment an invisible practice became tangible. Posts framed it as more invasive than cookies precisely because mute buttons and system volume offered no control, and because the same scripts quietly gathered canvas, WebGL and interaction data at the same time.

The remaining value, if any, sits in combination with the wider stack rather than in the oscillator alone. A weak audio reading can still nudge a risk score when canvas, WebGL and input timing already agree. That is a thinner role than the historical one pure audio fingerprints once held.

What Brave and Other Browsers Already Do

Brave posted a high-engagement thread on 22 August stating it had blocked the responsible scripts by default and had protected against audio fingerprinting for more than six years. The company randomises certain outputs so sites receive inconsistent fingerprints that also reset across sessions.

In Brave’s thread explaining the silent-sound method the browser wrote: “Alibaba’s AliExpress was caught using users’ audio systems to track them. AliExpress wasn’t recording users but instead playing a silent sound and measuring how users’ specific devices processed it in order to fingerprint them. But don’t worry because Brave stops this.”

Firefox users already benefit from the constant math libraries and the broader set of Firefox fingerprinting protection features. Chrome’s own audio libraries blunt the pure audio signal. The remaining risk sits in the multi-signal combination and in any browser that still leaks stable values.

Randomisation and constant math attack the problem from opposite directions. One makes the answer change so often that it stops being a stable ID. The other makes many machines give the same answer so the ID loses discriminating power. Either approach drains value from a silent oscillator even if the script still runs.

Blocks Users Can Apply Right Now

Callaghan published narrow uBlock Origin filters that stop the two script families on aliexpress.com without breaking ordinary browsing of the homepage or product pages:

• ||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

Existing tabs must be closed after adding the rules because an already-created AudioContext stays alive. He noted the scripts appear tied to anti-fraud systems, so blocking them could increase CAPTCHAs or cause friction at login or checkout. So far ordinary shopping continued to work for him.

Other content blockers can target the same paths. Switching to a browser with built-in randomisation or constant implementations reduces the value of the entire stack. The trade-off is real: platforms use these measurements to fight bots, account takeovers, coupon abuse and payment fraud when cookies are unreliable. Users who block them may face more friction while gaining privacy and, in this case, working headphones again.

The practical sequence is short. Add the filters, close every AliExpress tab that might already hold a live context, then reopen the site and test multipoint handoff again. If checkout later grows stricter, the same rules can be relaxed for a single session without abandoning the rest of the block list.

How a Shopping Tab Seized System Audio

The side effect followed directly from how browsers and operating systems share a single audio path. Once a page connects a running AudioContext to the destination, the stack has live work to do. Multipoint headphones read that activity as proof the computer still needs the link.

Mute controls never reached the graph because they act on media elements and output levels, not on processing nodes held at zero gain. Closing the tab destroyed the contexts and released the path at once. That contrast is what made the discovery easy to confirm without deep tooling on a second machine.

The same mechanism explains why the failure appeared only after a few idle seconds. Contexts must start, nodes must connect, and the pipeline must settle before the OS treats the endpoint as busy. Callaghan’s delay matched that startup window rather than a media playlist or a delayed ad script.

In short, the page never needed to play a sound the user could hear. It only needed to keep the graph alive. The headphones then enforced a priority rule that ordinary shoppers never see until something goes wrong.

What the Timeline of the Episode Shows

The public record of the case is short and concrete when the dated moments are placed in order:

1. 20 August 2026 – Callaghan published the full technical write-up after instrumenting the homepage.
2. 22 August 2026 – Brave posted its thread stating default blocks and long-standing audio fingerprinting protections.
3. 25 August 2026 – AliExpress and Alibaba still had offered no public explanation of purpose, retention or cross-service use.

Those three markers frame the gap between a reproducible client-side finding and an unanswered institutional question. The scripts, the endpoints and the signal list were visible in the browser. Server-side retention and reuse were not.

The episode therefore splits into two layers. One layer is mechanical and already documented: two AWSC scripts, a zero-gain graph, a multipoint handoff that fails. The other layer is policy and remains opaque: how long any derived profile lasts and which services may read it.

What AliExpress Has Not Said

As of 25 August 2026 AliExpress and Alibaba have not publicly explained the purpose, retention period or cross-service use of the data. Callaghan could not see server-side behaviour from the browser. The client code proves extensive measurements are collected and transmitted. Whether the result becomes a persistent device ID, a short-lived risk score, or both remains unconfirmed.

The episode leaves the classic tension intact. Large platforms keep adding signals that are hard to spoof. Browser makers keep collapsing the most identifying ones. A silent technique still managed to seize a system audio path strongly enough to alter external hardware behaviour, and that side effect is what finally made the practice visible to ordinary users.

Without a vendor statement, outside observers can only weigh the client evidence. The bundles run from an anti-abuse directory, they encrypt a broad signal package, and they ship it by fetch() or sendBeacon(). Those facts support an anti-fraud reading, yet they do not fix the retention period or the scope of reuse across services.

Callaghan’s closing observation still stands: a shopping homepage that quietly exercises graphics, audio, WebRTC, hardware and motion APIs without notice produces both a privacy cost and, sometimes, a practical one.