AliExpress and the Silent Audio Fingerprint: What the Browser Was Really Doing

A pair of Bluetooth headphones exposed a privacy mechanism that ordinarily operates without a visible user-facing signal.

In August 2026, a developer using the name laserphile noticed that multipoint headphones would not hand audio from a computer back to a phone while an AliExpress tab remained open. Closing the tab restored the handoff. Muting the tab, browser, or operating-system mixer did not. There was no video playing, no audible sound, and no ordinary media indicator to explain why the computer continued to hold the headset’s audio channel.

The investigation traced the behavior to JavaScript delivered from Alibaba infrastructure. Two scripts, identified in the original investigation as collina.js and fireyejs.js, created live Web Audio processing graphs. Those graphs generated synthetic signals, analyzed the results, and connected to the computer’s audio destination through a GainNode set to zero. The browser therefore produced silence for the listener while still maintaining an active audio-processing path at the operating-system level. That path was enough to interfere with Bluetooth multipoint switching.

The public evidence supports calling the behavior Web Audio fingerprinting. It does not show that AliExpress activated the microphone, recorded conversations, or sent audible or ultrasonic beacons into the room. It also does not, by itself, reveal every server-side use of the collected result. The defensible conclusion is narrower and still serious: AliExpress ran device-profiling code that extracted characteristics from the browser’s audio implementation without an obvious user-facing signal, and the implementation’s hardware side effect made the hidden processing observable.

The episode is a useful window into the tracking system described in The Sovereign Dossier, Part 1. Cookies are only one identifier in a much larger identity graph. When a stable cookie disappears, companies can correlate weaker signals—IP history, device properties, rendering behavior, login events, and browser fingerprints—to recognize a returning device. Silent audio processing is one more source of those signals.

Silence Is Not the Same as Inactivity

The phrase “silent audio” invites the wrong mental model. AliExpress was not reported to be playing a recording at a frequency humans could not hear. The scripts generated a mathematical waveform inside the browser and passed it through the browser’s digital signal-processing pipeline. A volume control at the end of that pipeline reduced the output to zero.

The distinction resembles a running engine in neutral. The wheels are not moving, but the engine, transmission, and control systems are still operating. A zero-valued GainNode controls what reaches the listener; it does not necessarily tear down the upstream graph or release the system’s audio session. The AliExpress page kept enough of the live pipeline active that the computer continued to claim the Bluetooth audio route.

The Web Audio API was built for legitimate, sophisticated audio applications. Browser-based synthesizers, games, conferencing tools, music production software, accessibility systems, and interactive visualizations all need more than a simple play button. Web Audio gives developers a graph of modular processing nodes:

• An OscillatorNode creates a deterministic waveform such as a sine, triangle, or sawtooth wave.
• A DynamicsCompressorNode applies nonlinear gain calculations across many audio samples.
• An AnalyserNode exposes time-domain or frequency-domain data.
• A GainNode multiplies the signal amplitude, including by zero.
• An AudioContext coordinates the graph and, when connected to its destination, can interact with the live audio-output path.
• An OfflineAudioContext renders the same kind of graph into memory without sending it to physical audio hardware.

Most demonstrations of audio fingerprinting use OfflineAudioContext because it can render a fixed buffer quickly and quietly without occupying an output device. The reported AliExpress implementation used live contexts connected to the destination instead. The live design explains the Bluetooth symptom. The headset did not hear a sound and decide to remain attached; the host system continued presenting an active media path, so the headset never received the condition it needed to yield to the other paired device.

Muting failed for the same reason. A browser tab mute or operating-system volume slider generally changes the final audible output. It does not guarantee that a page’s audio graph has been suspended or that the underlying audio session has closed. The incident converted a hidden software operation into a physical diagnostic signal: the headphones revealed that the browser was still doing audio work after every visible control said “silent.”

How Audio Becomes a Device Signal

Audio fingerprinting does not identify a person by recognizing a song or voice. It challenges a browser with the same synthetic input and measures how that browser computes the output.

A simplified routine creates an oscillator, routes it through one or more processing nodes, renders a buffer, and reads back floating-point sample values. The input parameters are fixed. The output can still vary slightly across browser engines, operating systems, CPU architectures, compiler choices, resampling paths, and digital signal-processing implementations. The Web Audio specification’s privacy section explicitly acknowledges that an oscillator and dynamics compressor can contribute entropy to a client fingerprint because of normally inaudible differences in processing architecture, resampling, rounding, compiler configuration, and CPU design.

The mechanism can be represented as a short pipeline:

fixed waveform
    -> browser audio nodes
    -> floating-point sample buffer
    -> selected values or summary statistics
    -> compact fingerprint component

The fingerprint component does not need to be globally unique. A tracking system gains strength by combining it with other observations. Screen dimensions may place a device in one large group. Time zone, language, CPU-core count, graphics output, font measurements, and audio output each narrow the group further. A login or purchase can then anchor the composite device profile to an account.

That is why claims that an audio hash is a permanent serial number overstate the evidence. Browser fingerprints are probabilistic. Software updates, driver changes, browser defenses, hardware replacement, and ordinary configuration changes can alter individual components. Conversely, a matching audio result may be shared by many devices with the same environment. The commercial value comes from correlation: several imperfect attributes can collectively produce a high-confidence match.

The technique is also stateless from the user’s perspective. A cookie stores an identifier in the browser. A fingerprinting script derives attributes again when the page loads. Clearing site data removes the cookie but does not change the machine’s graphics stack, audio implementation, processor family, screen geometry, or behavioral patterns. Private-browsing mode limits local persistence and isolates some state; it cannot automatically make the underlying device indistinguishable from every other device.

The W3C does not describe this as an imaginary edge case. Its specification recognizes sample rate, output channel count, timing, latency, and processed audio output as possible fingerprinting surfaces. Browser vendors face an uncomfortable engineering constraint: the more precisely an application can observe and control the media system, the more information a hostile or commercially aggressive script can extract from that same precision.

What the AliExpress Evidence Establishes—and What It Does Not

The strongest evidence in this incident is technical and reproducible. The Bluetooth failure began when the AliExpress page was open and ended when it closed. Instrumentation exposed two live audio contexts. The associated scripts built signal-processing graphs with zero gain at the destination. The scripts also collected broader browser and device telemetry consistent with an anti-abuse or risk-scoring system. Multiple technical write-ups documented and reconstructed the essential graph and its reported effect, including the detailed Web Audio reconstruction cited in the supplied research.

Several more expansive claims require restraint.

First, the scripts did not need microphone permission. Generating a waveform and reading the browser’s computed result is different from calling getUserMedia() to capture a microphone. Modern browsers place microphone access behind a permission prompt and visible indicators. The reported graph operated on internally generated data and therefore bypassed those microphone-specific controls because it was not using the microphone.

Second, this was not ultrasonic cross-device tracking. Ultrasonic tracking systems embed inaudible beacons in television, radio, or web audio and use a microphone-equipped application to detect them. The detected beacon can link devices that occupied the same physical environment. Web Audio fingerprinting instead measures computation within one device. Both involve “inaudible audio,” but their data flows and permission requirements are different.

Third, the observed client-side code does not prove every downstream use. Fingerprinting is widely used in fraud prevention, bot detection, account security, advertising, and identity resolution. Large commerce platforms have legitimate reasons to distinguish a customer’s browser from credential-stuffing infrastructure, scripted inventory abuse, payment fraud, and automated review manipulation. A composite device profile can expose a session whose claimed identity conflicts with its technical environment.

Legitimate anti-fraud goals do not resolve the governance problem. A control can be operationally useful and still be excessively opaque, over-collected, retained too long, reused for unrelated purposes, or shared beyond the context in which it was gathered. The public evidence shows a fingerprinting-capable telemetry system. Without authoritative disclosure from AliExpress about purpose, retention, sharing, and user controls, claims about a specific permanent consumer identifier or a particular data-broker transfer remain unproven.

Fourth, the live AudioContext does not prove an attempt to bypass a specific browser defense. It may have been an engineering choice, a compatibility requirement, inherited vendor code, or an oversight. The Bluetooth interference demonstrates the architectural consequence, not the developer’s private intent.

This evidentiary discipline is important because privacy reporting loses force when an observable mechanism gets inflated into an unsupported story about microphones, conversations, or universal individual identification. The documented behavior already deserves scrutiny. It extracted device characteristics invisibly enough that a hardware malfunction, rather than a browser disclosure, alerted the user.

From a Browser Fingerprint to the Data-Broker Identity Graph

Our data-broker series describes identity resolution as a graph rather than a single dossier row. The nodes are identifiers: hashed email addresses, mobile advertising IDs, household addresses, account IDs, cookie IDs, IP addresses, and device fingerprints. The edges are observed associations: two identifiers appeared in the same authenticated session, repeatedly used the same residential network, or converged around the same location and schedule.

Audio fingerprinting fits into the graph as a device-level feature. It may help answer questions such as:

• Does this supposedly new browser resemble a device seen in earlier sessions?
• Are several accounts operating through the same technical environment?
• Did a user clear cookies but return with the same broader device profile?
• Does the browser look like ordinary consumer hardware or an automated environment?

One audio result cannot reliably answer those questions alone. A risk or identity engine can compare it with Canvas rendering, WebGL output, time zone, locale, device memory, logical processor count, network characteristics, and interaction patterns. When an authenticated customer signs in, the platform gains a high-confidence edge between the account and the composite fingerprint. Later anonymous activity can be compared against that anchored profile.

The same architecture supports both security and surveillance. Fraud teams can detect account takeover or mass automation. Marketing and analytics systems can recognize a device after cookies are deleted. Identity-resolution vendors can enrich an existing household graph. Government or commercial purchasers can acquire datasets whose collection conditions are far removed from the eventual use. Part 2 of The Sovereign Dossier examines how commercially available information moves into surveillance, breach, and regulatory systems after collection.

The AliExpress case does not establish that its audio-derived data entered a third-party broker’s inventory. It illustrates the upstream collection layer that makes the larger ecosystem possible. Device telemetry becomes durable surveillance infrastructure when organizations retain it, connect it to known identities, exchange it across business units or vendors, and reuse it outside the immediate transaction-risk purpose.

That lifecycle creates the governance questions AliExpress should answer:

• What exact fields did collina.js and fireyejs.js derive and transmit?
• Which purposes were attached to each field: fraud prevention, account security, analytics, advertising, or another use?
• Was the audio result stored as raw samples, a summary, a hash, or a score?
• How long was it retained, and what event caused deletion?
• Was it linked to an authenticated account, household, payment instrument, or advertising identifier?
• Which Alibaba entities, service providers, or third parties could receive it?
• Could a user access, correct, delete, or object to the resulting device profile?

Those questions move the debate beyond whether a website “played a sound.” The core issue is whether a platform may silently turn the technical properties of a visitor’s machine into an identity feature without a meaningful explanation or control.

Practical Defenses Without Pretending You Can Become Invisible

No single setting eliminates browser fingerprinting. The practical goal is to reduce stable entropy, constrain unnecessary script execution, separate contexts, and avoid feeding every service the same identity anchors.

Use a browser with active anti-fingerprinting defenses. Brave describes its approach as farbling: small, deterministic changes are applied to fingerprintable outputs using seeds scoped to a site and browsing session. A site receives consistent values within the context needed for compatibility, while another site or later session receives different values. Firefox’s Resist Fingerprinting mode takes a standardization-oriented approach across multiple browser surfaces. Stronger modes can break sites, so users should expect occasional compatibility tradeoffs.

Block known tracking and anti-abuse scripts selectively. A reputable content blocker can stop a known fingerprinting payload before it executes. Blocklists are reactive: scripts can move, change names, or arrive through first-party domains. Aggressive blocking can also trip fraud controls or break checkout and login flows. If a purchase requires temporarily relaxing a rule, use the smallest site-specific exception and remove it afterward.

Separate high-trust activity from casual browsing. A dedicated browser profile for shopping, finance, or other identity-bound activity limits cross-context correlation. Separate profiles do not change the underlying hardware, IP address, or every fingerprintable property, but they reduce shared cookies, extensions, history, and login state. Container tabs can provide lighter separation for state; a distinct browser profile creates a clearer operational boundary.

Keep the browser current. Anti-fingerprinting behavior, permission controls, script-blocking lists, and API mitigations evolve. An old browser preserves known fingerprinting surfaces and known vulnerabilities at the same time. Privacy hardening is not a reason to remain on an unpatched release.

Do not randomize every setting manually. An unusual user agent, rare extension combination, custom font set, extreme window geometry, and heavily modified browser can make a device more distinctive. Effective anti-fingerprinting systems coordinate outputs so that many users resemble one another or so that values change coherently. A pile of unrelated tweaks can produce a uniquely recognizable configuration.

Use network-level controls as an additional layer, not a complete answer. DNS filtering can block known tracking hosts, while a virtual private network can conceal the residential IP address from the destination. Neither prevents first-party JavaScript from querying browser APIs. A VPN changes one graph node; it does not erase the rest of the fingerprint.

Exercise deletion and opt-out rights where they apply. Deleting data after collection cannot stop a page from executing code today, but it can reduce the retained identity graph that makes future correlation valuable. California’s Delete Request and Opt-out Platform and other jurisdiction-specific mechanisms are covered in Part 3 of The Sovereign Dossier, along with DNS filtering, email aliases, identity separation, and periodic exposure reviews.

For organizations deploying device intelligence, the control standard should be equally concrete. Collect the minimum attributes necessary for a defined fraud decision. Keep security telemetry out of advertising workflows. Document the lawful basis and notice. Bound retention. Restrict access. Test whether a less invasive signal produces comparable detection value. Give privacy and security teams visibility into third-party anti-abuse JavaScript instead of treating vendor payloads as an opaque exception to normal software governance.

The Headphones Were the Transparency Control

Browser fingerprinting persists because most of its inputs look harmless in isolation. Audio sample values, screen size, GPU output, processor count, language, and time zone are ordinary implementation details. Correlation turns them into an identity system.

The AliExpress incident made that system legible through a mistake or side effect. A live, zero-volume audio graph held a Bluetooth route open, and the user’s headphones contradicted the browser’s lack of any visible media-playback indicator. The resulting investigation exposed a broader truth: permission prompts protect access to sensitive devices such as microphones, but many identity-relevant measurements come from APIs that websites can call without asking because those APIs are required for normal web functionality.

The correct response is neither panic nor resignation. AliExpress was not shown listening to rooms through visitors’ microphones. It was shown running silent audio-processing code consistent with device fingerprinting, embedded in a larger telemetry operation, with no meaningful user-facing explanation. That is a narrower claim than the viral version and a more useful one.

Cookies made tracking visible enough to regulate and delete. Fingerprinting shifts identification into computation, where the identifier can be derived again after local storage is cleared. Defending against that model requires browsers that deliberately limit or randomize fingerprintable outputs, users who separate and constrain browsing contexts, and organizations that govern device intelligence as personal-data infrastructure rather than harmless technical exhaust.

The headphones did what the page did not: they disclosed that the system was active.