AliExpress Didn't Beam Ultrasonic Sound at Shoppers. What It Actually Did Is Harder to Block

The viral version of this story is wrong. AliExpress was not blasting sound above the range of human hearing at shoppers' devices. The truth is stranger and, for defenders, less convenient: the site ran a sawtooth wave through the Web Audio API with the gain turned to zero and measured how your particular machine deformed the signal. Nothing had to be heard, not by you, not by any microphone, for the fingerprint to work.

That distinction matters more than the headlines suggest, because the defenses for these two techniques barely overlap. So let's untangle them, then walk through how to actually catch this on a live page.

A Bluetooth glitch gave the whole thing away

In August 2026, developer Matt Callaghan noticed something odd. His multipoint Bluetooth headphones would stop switching between his PC and his phone whenever an AliExpress tab was open, in Firefox or in Chrome. Closing the tab fixed it instantly. He could reproduce it reliably, and being a developer, he went digging.

What he found were two "extremely obfuscated" audio scripts sitting inside Alibaba's browser security and anti-abuse tooling. The scripts built a WebAudio graph with three moving parts: a sawtooth oscillator to generate a waveform, an analyser node to measure what came out the other side of the browser's audio implementation, and code to read the resulting frequency data. The gain was set to zero, so nothing was audible. But the graph stayed connected to the system audio output and kept processing, which is why it sat on the Bluetooth audio path and jammed his headphone switching.

Two details deserve more attention than they got. First, muting the tab did nothing, because the browser's tab-mute control acts on media elements and there was no media element here. Second, the scripts were not recording anyone through a microphone. They generated a signal internally and measured the small, repeatable differences in how each browser and device handled it. Those differences are shaped by the processor, sound hardware, drivers, operating system, and browser implementation. No cookies required.

Two techniques got mashed into one headline

Most coverage filed this under "inaudible audio tracking," which lumps together two very different animals. If you defend against the wrong one, your controls miss entirely.

Ultrasonic cross-device beaconing (the old trick)

This is the SilverPush-era technique that made headlines years ago. One device, say a TV or a web page, emits audio at frequencies above human hearing. A second device, usually a phone with an app carrying the right SDK, hears it through the microphone. That links the two devices for ad attribution. It needs a speaker on one end, a microphone on the other, and two separate devices. It is creepy, and it is also mostly a solved problem: microphone permissions, SDK audits, and blocker filter lists cover a lot of it.

Web Audio API fingerprinting (what AliExpress actually ran)

This is a rendering benchmark disguised as audio playback. The waveform is not a message to another device. It is an excuse to exercise your audio stack. Feed an identical sawtooth into millions of browsers and tiny implementation differences in floating point math, resampling, and driver behavior come out the other side. Those differences are stable per machine, which makes them a fingerprint.

The sound was never the point. Your audio pipeline was the point.

Why the distinction is the whole ballgame

Mic permissions do nothing here. Ultrasonic filter lists do nothing here. Countermeasures have to happen inside the Web Audio API itself, either by injecting noise into the outputs or by collapsing users into shared buckets so the fingerprint stops being unique. That is a browser-vendor-level fix, not a user-setting-level fix, which is exactly why the browser you pick matters so much (more on that below).

The audio signal was one input in a much bigger harvest

Focusing on the audio piece alone undersells what Callaghan found. The same scripts collected canvas rendering data, WebGL output, display settings, hardware configuration, WebRTC behavior, and user interactions. He documented code probing screen dimensions, device memory, browser plugins, and mouse events, plus signs that Alibaba encrypted the bundle and shipped it to its telemetry services. His summary: "a fairly comprehensive browser and device fingerprint."

Note where this code lived: inside security and anti-abuse tooling. That is the gray zone, and it is the part of this story that will outlast the news cycle. Device fingerprinting genuinely is standard practice for fraud prevention, bot detection, and risk scoring, because it still works after cookies get wiped. But the same pipeline that stops carding bots also tracks ordinary shoppers who never agreed to anything. We have made the same point about third-party code before: the integrations running inside your product are an attack surface in their own right, whether that code is an OAuth-connected SaaS app or an obfuscated script on a checkout page.

How to catch Web Audio fingerprinting yourself

Here is the part the news writeups skipped. You can look for this today, with tools you already have.

The five-minute DevTools check

Open the suspect page, let it settle, then check two things. In Chromium browsers, chrome://media-internals shows active audio streams; a silent shopping page holding an audio stream open is a red flag. Second, open the Performance Monitor in DevTools and watch for steady audio rendering activity on an otherwise idle tab. Audio that never reaches your ears still burns cycles, and cycles show up.

Instrument the API before the page does

The reliable way to confirm fingerprinting is to wrap the audio entry points and log who calls them. Paste this into the console, or better, run it as a userscript at document-start so it loads before the page's own scripts:

(() => {
  for (const name of ['AudioContext', 'webkitAudioContext', 'OfflineAudioContext']) {
    const Real = window[name];
    if (!Real) continue;
    window[name] = function (...args) {
      const ctx = new Real(...args);
      for (const m of ['createOscillator', 'createGain', 'createAnalyser', 'createDynamicsCompressor']) {
        const orig = ctx[m].bind(ctx);
        ctx[m] = (...a) => {
          console.log(`[audio-fp] ${name}.${m}`, new Error().stack);
          return orig(...a);
        };
      }
      return ctx;
    };
  }
  // The classic pattern to flag: oscillator + analyser on a page with no audio features,
  // or any OfflineAudioContext use on a page that never plays sound.
})();

An oscillator feeding an analyser with gain pinned at zero, on a page with no player, no notifications, no sound of any kind, is fingerprinting until proven otherwise. OfflineAudioContext on such a page is even louder as a signal, because its only real job is rendering audio nobody will hear. On the network side, watch for encrypted POST beacons fired shortly after page load; you usually cannot read the payload, but the timing correlation with the audio calls is its own tell.

For measurement at scale, the research community has done this for years: crawlers built on OpenWPM visit sites with instrumented browsers, and classifiers like FP-Inspector sort fingerprinting scripts from benign ones by their API call patterns. If you run your own site, the same discipline applies to what you ship. Audit the third-party scripts on your pages, and treat it as a repeating job rather than a one-time review, because script contents change silently. That is the same argument behind continuous exposure monitoring instead of point-in-time scans, and the detection work itself borrows the mindset from detection engineering against obfuscated supply-chain payloads: assume the interesting code is hidden, instrument the behavior, ignore the packaging.

The browser-by-browser defense matrix

This is where the story gets practical, because the vendors responded very differently.

Firefox's data is worth quoting precisely. Per Ritter, 99.24% of Firefox users fall into one of three WebAudio fingerprinting buckets, with the vast majority in bucket one (x86/x64 CPUs lacking FMA instructions) or bucket two (x64 CPUs with FMA). A fingerprint shared by a third of the user base is not a fingerprint. For the remaining 0.76%, the script failed entirely. That is how you neutralize a technique without an arms race: you do not block the call, you make the answer useless.

Brave said it has protected users from audio fingerprinting for six years by injecting random data into browser outputs, so every site sees a different fingerprint that resets across sessions. It posted on X on August 22, 2026 that it blocks the AliExpress scripts outright for all users, and said it has extended similar protections to GPU fingerprinting.

Chrome and Safari are the uncomfortable middle. "Probably have defenses" is doing a lot of work in that sentence, and nobody confirmed specifics. If you shop in Chrome, I would assume the signal gets through and act accordingly. For browsers without built-in defenses, content blockers like uBlock Origin can stop the scripts, but with a real tradeoff: parts of AliExpress that depend on the same code for security or fraud checks may break. Malwarebytes' advice is the sane baseline regardless of browser: run content blockers and anti-tracking extensions, keep the browser updated, and do your shopping in a separate browser or profile where you are not signed into anything else.

"But fraud prevention needs this" is half right

The pushback I hear from practitioners: every large platform fingerprints, bots are expensive, and risk scoring is how checkout stays online. All true. Fingerprinting is genuinely useful against fraud precisely because it survives cookie deletion.

But none of that justifies how this was built. The scripts were extremely obfuscated. The gain was set to zero so nothing would ever appear in a volume mixer. There was no disclosure and no consent flow, and because the fingerprinting sits inside the anti-abuse stack, blocking it risks breaking the very checkout protections a cautious user would want. That coupling is a choice, and a convenient one: accept the tracking or lose the security. Heise read the episode as part of a pattern of harmless-seeming background processes repurposed for tracking, pointing to an EFF analysis of advertising SDKs forwarding location data by default and to findings that Chinese camera components in British Royal Navy drones transmitted status signals home. Whether or not you buy the comparison, the tell here is the same. Security tooling that is only security tooling does not need to hide.

If your team is on the building side of this, the mirror-image question is worth asking: the AliExpress scripts shipped their harvest to telemetry endpoints, and your own third-party scripts and APIs deserve that same scrutiny from the inside. If you want the auth and object-level checks in this article run against a live app, start with Axeploit's API security checker.

Key takeaways

• AliExpress did not use ultrasonic beaconing. It ran a zero-gain sawtooth through the Web Audio API and measured how your audio stack bent it, a fingerprinting technique that mic permissions and ultrasonic filters cannot touch.
• The audio signal was one input in a broader bundle (canvas, WebGL, hardware, WebRTC, mouse events), encrypted and sent to Alibaba's telemetry services from inside its anti-abuse code.
• Detection is doable today: check chrome://media-internals for phantom audio streams, instrument AudioContext and OfflineAudioContext before page scripts run, and treat an oscillator plus analyser at zero gain on a silent page as fingerprinting until proven otherwise.
• Firefox collapses the signal into shared buckets (99.24% of users fall into just three), Brave randomizes outputs and blocks these scripts outright, and Chrome and Safari users should assume exposure until someone confirms otherwise.
• Fraud prevention is a real use case, but obfuscation plus zero gain plus no consent is a design decision, not a technical necessity.