AliExpress's Silent WebAudio Fingerprinting: How a Broken Bluetooth Headphone Exposed a Hidden Tracking System
A security researcher wasn't hunting for a privacy scandal. He just wanted his headphones to work.
His multipoint Bluetooth headset — the kind that stays paired to both a PC and a phone at once — kept refusing to hand audio playback back to his phone whenever he had an AliExpress tab open. Muting the tab did nothing. Muting the browser did nothing. Muting Windows itself did nothing. The only fix was closing the tab.
That's not normal browser behavior. That's the kind of anomaly a SOC analyst learns to never ignore, and in this case, chasing it down led straight into one of the more inventive device-fingerprinting techniques to surface in 2026: a completely silent, invisible audio-processing pipeline running on AliExpress's homepage, long before a user ever logs in or checks out.
Table of Contents
- What Actually Happened
- How WebAudio Fingerprinting Works
- The Scripts Behind It: collina.js and fireyejs.js
- Why This Broke Bluetooth Headphones
- It's Not Just Audio: The Full Fingerprint
- How to Detect It Yourself
- Detection & Prevention Techniques
- Expert Tips
- Related Reading
- FAQ
- Conclusion
What Actually Happened
Researcher Matt Callaghan, who writes under the handle Laserphile, documented the issue in a blog post published on August 20, 2026. He noticed that opening AliExpress's homepage in Firefox or Chrome would abruptly cut off audio playing from his phone through his multipoint headphones — with zero visible cause on the page. No video element. No audio player. No calls to HTMLMediaElement.play(). The Media Session API reported no active playback at all.
The behavior only kicked in after the page had been idle for several seconds, which is itself a telling detail. It's the kind of delay you'd expect from a fingerprinting script waiting to avoid interfering with page load metrics, not from a legitimate media feature.
To dig deeper, Callaghan overrode the native AudioContext constructor and AudioNode.connect() method in the browser console to intercept and log every call made against the Web Audio API. That instrumentation caught two separate AudioContext instances spinning up and moving into a running state — both wired to the system's audio destination, both completely silent.
How WebAudio Fingerprinting Works
WebAudio fingerprinting isn't new — researchers have documented it since the early 2010s — but it's less well known than canvas or WebGL fingerprinting because it produces no visual artifact for a user to notice. Here's the underlying idea in plain terms.
Every browser processes audio signals using floating-point math running on top of the device's actual CPU, audio drivers, and OS-level audio stack. When you feed a browser a known waveform and ask it to process that waveform through a chain of digital signal processing nodes, the output isn't always bit-for-bit identical across machines. Tiny differences in hardware, compiler optimizations, audio libraries, and OS versions produce measurably different output values.
Capture that output with enough precision, and you have a fingerprint — one that doesn't depend on cookies, doesn't require permissions, and survives incognito mode and cache clearing.
In the AliExpress case, the graph pattern reverse-engineered by Callaghan looked like this:
- A sawtooth oscillator node generates a known waveform.
- The signal passes through an analyzer node and a script processor node, which read the resulting values.
- The signal then passes through a gain node set to zero before reaching the audio destination.
That final gain-to-zero step is the important part. It makes the entire process inaudible to the user, but the browser still treats the graph as live, active audio because it's technically still connected to the destination node and being processed in real time.
The Scripts Behind It: collina.js and fireyejs.js
Stack traces pointed Callaghan to two heavily obfuscated JavaScript files, collina.js and fireyejs.js, both served from an AWSC (Alibaba Wireless Security Component) path on Alibaba's own asset infrastructure. AWSC is associated with Alibaba's anti-fraud and bot-detection tooling — the kind of risk-scoring layer large e-commerce platforms run to catch fake accounts, credential stuffing, scraping, and automated purchasing abuse.
That context matters for how you read this story. This isn't spyware bolted on by a rogue ad network. It's homegrown anti-abuse tooling from the platform operator itself, deployed unconditionally on the general shopping homepage — well before login, well before checkout, and with zero visible disclosure to the visitor.
Why This Broke Bluetooth Headphones
This is the part that makes the story genuinely interesting from an incident-response and root-cause-analysis standpoint. A muted <video> element is a media element the browser knows is silenced; the OS and Bluetooth stack can safely treat it as inactive. But a WebAudio graph connected to the destination node — even with gain at zero — isn't muted media. As far as the browser and operating system are concerned, it's live audio processing.
On the researcher's system, that was apparently enough for Firefox and Windows to keep the Bluetooth audio path locked to the PC, preventing his multipoint headset from switching cleanly back to his phone. It's an unintended physical-world side effect of a purely software tracking technique — and it's the only reason this got caught at all.
A Mozilla engineer, Tom Ritter, independently corroborated the finding and added useful context: Firefox made WebAudio output deliberately constant starting with Firefox 118 (released September 2023) as part of its first round of fingerprinting protections. According to telemetry he cited, over 99% of Firefox users now land in one of three common output values tied to broad CPU architecture (x86/x64 without FMA instructions, x64 with FMA, and ARM/NEON). A long tail of roughly 48 users worldwide still produce enough unique values to be individually identifiable through this vector alone — a good reminder that fingerprinting defenses reduce the attack surface, they don't eliminate it for everyone.
It's Not Just Audio: The Full Fingerprint
WebAudio fingerprinting was just one signal in a much larger collection pipeline. The same scripts were found probing:
- Canvas rendering output
- WebGL renderer and GPU details
- Screen and viewport dimensions
- Hardware concurrency (CPU core count)
- Device memory
- Installed browser plugins
- WebRTC behavior (useful for detecting local/VPN IP leakage)
- Mouse and touch event patterns
- Device motion signals
- Browser automation / headless indicators
Results are serialized, encrypted, and shipped to Alibaba telemetry endpoints using fetch() and sendBeacon() — both of which are designed specifically to survive page navigation and tab closure, so the data reliably reaches its destination even if the user leaves quickly.
How to Detect It Yourself
.webp "DevTools Console Script to Detect WebAudio Fingerprinting")
If you want to verify this kind of behavior on any site — not just AliExpress — this is roughly the approach Callaghan used, and it's a solid technique to keep in your own browser-side investigation toolkit.
// Paste into DevTools console before loading the target page
const origConnect = AudioNode.prototype.connect;
AudioNode.prototype.connect = function(...args) {
console.trace('AudioNode.connect() called', this);
return origConnect.apply(this, args);
};
const OrigAudioContext = window.AudioContext || window.webkitAudioContext;
window.AudioContext = function(...args) {
console.trace('AudioContext instantiated');
return new OrigAudioContext(...args);
};
What it does: overrides the native AudioContext constructor and AudioNode.connect() method so every call logs a full stack trace to the console.
When to use it: before navigating to or reloading a page you suspect is running hidden audio-based fingerprinting — the override has to be in place before the page's own scripts execute.
Expected output: if the site is building a hidden WebAudio graph, you'll see AudioContext instantiated and multiple connect() calls in the console with stack traces pointing to the responsible script file — exactly how collina.js and fireyejs.js were identified in this case.
Detection & Prevention Techniques
.webp "DevTools Console Script to Detect WebAudio Fingerprinting")
For end users:
- Use a browser with built-in fingerprinting resistance. Firefox normalizes WebAudio output as of version 118+; Brave randomizes audio fingerprint output per-site by default and has publicly stated it blocks the AliExpress scripts involved.
- Block the specific scripts with a content-blocking extension. A uBlock Origin custom filter targeting the
collina.jsandfireyejs.jspaths on Alibaba's asset domain stops the hidden AudioContext instances from spawning and restores normal Bluetooth switching. - Expect trade-offs. Since these scripts likely feed AliExpress's fraud-scoring pipeline, blocking them may trigger additional CAPTCHA challenges during checkout or login.
For SOC teams and blue teamers monitoring egress traffic:
- Watch for repeated
sendBeacon()/fetch()POST traffic to third-party analytics or risk-scoring subdomains shortly after page load with no corresponding user-initiated action — this pattern is common to fingerprinting-as-a-service and anti-fraud SDKs alike. - If you manage browser policy at the enterprise level, evaluate whether WebAudio API access should be restricted via extension policy or CSP on managed endpoints handling sensitive sessions.
- Treat "unexplained hardware side effects" (odd Bluetooth behavior, GPU fan spin-up, battery drain) as legitimate triage signals — they occasionally expose background scripts that pure network monitoring misses.
Expert Tips
- Don't assume fingerprinting is limited to canvas and WebGL. WebAudio, WebRTC, and even the Battery Status API have all been used as fingerprinting vectors historically — the attack surface is broader than most awareness training covers.
- When a physical device behaves strangely after visiting a specific site, treat it as an investigative lead, not a hardware fault, before you replace or reset anything.
- Overriding native browser APIs from DevTools (as shown above) is a fast, zero-install way to audit any site's client-side behavior without needing specialized tooling.
Related Cybersecurity Topics You Should Explore
- ToxNetV2: The Linux Botnet That Asks AI Before It Attacks
- Tata Nexarc Account Takeover Bug: All It Took Was a Phone Number
- Zscaler Client Connector Flaw Lets Hackers Run Code Remotely
- 91 Spring CVEs Impact 209,000+ Components — Critical RCE Flaw Found
- SynkLoader Malware Fakes Windows Lock Screen to Steal Passwords
- SysScan Scam: Fake Microsoft Alert Tricks Users Into Deleting AV
- 768 Leaked AWS Keys Still Have Full Admin Access in 2026
- Enable Maximum Windows Logging for SOC & Ransomware Detection
- OpenBin.ai & OpenAPK.ai Review: Free AI Reverse Engineering Tool
- Grok Zero-Click Hack Steals Your Chats — No Click Needed
- head Command in Linux: Fast Log Triage for SOC Analysts
- Elementor Pro Bug Lets Hackers Upload PHP — No Login Needed
FAQ
Is AliExpress recording my microphone audio?
No. The technique never captures real audio input. It generates a synthetic waveform internally and measures how the browser's audio stack processes it — no microphone access or permission is involved.
Why did this only affect Bluetooth headphones and not regular speakers?
Standard speakers don't have a "switching" behavior between devices. Multipoint Bluetooth headsets specifically monitor which paired device has an active audio session, so a phantom "live" WebAudio graph on the PC was enough to make the headset lock onto the computer.
Does this work in Incognito or Private Browsing mode?
Yes. WebAudio fingerprinting doesn't rely on cookies or local storage, so private browsing modes don't block it by default. Browser-level fingerprinting resistance (like Firefox's or Brave's) is what actually mitigates it.
Is this illegal or does it violate privacy regulations?
That depends on jurisdiction and how the resulting data is used. Under frameworks like GDPR, fingerprinting used for tracking generally requires disclosure and, in many cases, consent — running it unconditionally on a homepage with no visible notice is the kind of implementation privacy regulators have scrutinized in other cases.
Can I confirm whether a site is doing this without coding knowledge?
Partially — install uBlock Origin, enable its default filter lists, and watch for blocked requests to third-party analytics domains in its dashboard when you visit the site. For a definitive answer, the DevTools console method above is the reliable route.
Does AliExpress deny this is happening?
At the time of these reports, AliExpress had not issued a detailed public response addressing the specific findings; the site has been asked to comment by multiple outlets covering the story.
Conclusion
The most interesting part of this story isn't really the fingerprinting technique itself — WebAudio-based tracking has existed for years. It's that it took a hardware side effect, on one researcher's specific headphone model, to expose a tracking mechanism that was otherwise engineered to be completely invisible.
That's worth sitting with. Modern fingerprinting is built to leave no trace a normal user would ever notice — no visual glitch, no permission prompt, no performance hit worth mentioning. The defense isn't paranoia; it's using tooling that resists fingerprinting by default, and treating unexplained device behavior as a signal worth investigating rather than dismissing.
If you found this breakdown useful, share it with your team, and drop a comment with any similar client-side tracking behavior you've caught in the wild — cases like this are exactly how the community builds better detection filters for everyone.