Silent Audio Probes: One Developer's Accidental Discovery of Browser Fingerprinting

When Your Hardware Betrays the Code

Matthew Callaghan noticed the problem by accident. His multipoint Bluetooth headphones, configured to stream from his phone unless his PC produced sound, kept switching away from phone audio every time he visited a particular shopping site. The interruption was consistent: load the page, lose the phone audio. Close the tab, regain it. No audible sound played from the browser, yet something was triggering the headphone's audio-source priority logic.

At DailyTechWire, we've tracked the evolution of browser fingerprinting techniques across Asia and beyond for years. Most implementations rely on canvas rendering, font enumeration, or timezone data. What Callaghan uncovered sits in a different category entirely: a method that commandeers the WebAudio API to generate signals outside human hearing range, then measures how each browser renders those signals. The result is a unique identifier stable enough to track users across sessions, even when cookies are cleared.

The Mechanics of Inaudible Fingerprinting

The technique hinges on subtle variations in how browsers and underlying audio stacks process digital waveforms. When Callaghan examined the page's JavaScript, he found two heavily obfuscated scripts working in tandem. Together, they instantiated an oscillator within the WebAudio context and generated sawtooth waves, a waveform characterized by a linear rise followed by a sharp drop. Sawtooth waves are ubiquitous in digital synthesis, but here they served a different purpose: producing a test signal that each browser would render with microscopic differences.

Those differences stem from floating-point arithmetic, hardware acceleration paths, and codec implementations that vary by operating system, chipset, and browser version. The scripts captured the resulting audio graph, extracted numerical features, and hashed them into a fingerprint. Because the oscillator operated at frequencies or amplitudes users couldn't hear, the entire process ran invisibly, save for the side effect that tipped Callaghan off.

WebAudio fingerprinting isn't new. Academic papers documented its feasibility as early as the mid-2010s, and privacy researchers have cataloged deployments on analytics platforms and ad-tech vendors. What makes this instance noteworthy is the scale: AliExpress handles hundreds of millions of visitors monthly, and the technique was embedded directly in the homepage rather than delegated to a third-party tag. That integration suggests a deliberate engineering decision, not an inherited library.

Why Marketplaces Turn to Fingerprinting

E-commerce platforms face a familiar tension. On one side, regulators in the European Union, California, and parts of Asia have tightened rules around persistent identifiers. Cookie banners proliferate, and users increasingly delete cookies or browse in private modes. On the other, fraud prevention, dynamic pricing, and recommendation engines all depend on recognizing repeat visitors. Browser fingerprinting offers a way to bridge that gap without relying on storage mechanisms users can inspect or clear.

The trade-off is opacity. Unlike a cookie, which a user can view and delete through browser settings, a fingerprint exists only as a hash computed on the server side. There's no standardized disclosure, no consent dialog that explains what data the oscillator collected. From a user-rights perspective, that's precisely the problem: the technique operates in a compliance gray zone, leveraging APIs designed for legitimate audio playback to extract identifying information.

Asia's e-commerce giants have been particularly aggressive in deploying anti-fraud and user-tracking infrastructure. Alibaba's ecosystem, which includes AliExpress, competes with Shopee, Lazada, and JD.com in markets where mobile dominates and users frequently switch devices. Maintaining session continuity and detecting account abuse at that scale demands robust identification methods. Audio fingerprinting, combined with device graphs built from IP addresses, user agents, and behavioral signals, can fill gaps that cookie-based tracking leaves open.

The Broader Fingerprinting Landscape

Audio fingerprinting sits within a larger taxonomy of techniques. Canvas fingerprinting renders hidden graphics and measures pixel output. Font enumeration probes which typefaces are installed. WebGL fingerprinting queries the graphics stack. Battery API, screen resolution, installed plugins, and even haptic feedback capabilities have all been weaponized for identification. Each method exploits the fact that browsers expose rich APIs to enable functionality, and those same APIs leak information about the underlying system.

Privacy-focused browsers have responded with countermeasures. Tor Browser and Brave add noise to canvas outputs, limit font enumeration, and block or permission-gate APIs like WebAudio. Firefox has introduced resist-fingerprinting modes that normalize many exposed values. Safari restricts access to device sensors. Yet each mitigation risks breaking legitimate use cases, and the arms race continues: as browsers harden one surface, trackers shift to another.

The regulatory picture remains fragmented. Europe's GDPR and ePrivacy Directive theoretically require consent for any processing of personal data, and fingerprints derived from device characteristics arguably qualify. Enforcement has been inconsistent, however, and technical detection is difficult. Data protection authorities lack the engineering resources to audit obfuscated JavaScript at scale, and many commercial fingerprinting vendors operate through intermediaries or offshore entities that complicate jurisdiction.

What Developers and Users Should Watch

For developers building or auditing web properties, the lesson is straightforward: scrutinize third-party scripts and any code that touches device APIs without a clear functional need. Obfuscation is a red flag. If a script instantiates an AudioContext but never plays audible sound, ask why. If it queries canvas, WebGL, or font APIs in ways that don't map to visible UI, investigate further.

Users have fewer tools. Browser extensions like uBlock Origin can block known fingerprinting scripts, and privacy modes reduce some surface area, but no single setting neutralizes every technique. The most effective defense remains using browsers with built-in anti-fingerprinting measures and keeping software updated so that vendors can patch newly discovered vectors.

Callaghan's discovery underscores a recurring theme in web privacy: the gap between what's technically possible and what's ethically or legally acceptable often goes unexamined until someone stumbles on a side effect. His headphones weren't supposed to react to silent oscillators, but multipoint Bluetooth prioritizes any active audio source, and the browser's audio stack treated the fingerprinting script as legitimate playback. That collision of intent and implementation made the invisible visible.

The incident also highlights how fingerprinting techniques age. WebAudio fingerprinting was cutting-edge research a decade ago; today it's considered legacy, supplanted by more sophisticated methods that combine dozens of signals. Yet legacy doesn't mean obsolete. If a technique still yields stable identifiers and most users remain unaware, there's little incentive for trackers to retire it.

As privacy regulations mature and browser vendors tighten defaults, the economics of fingerprinting may shift. Until then, the web remains a space where visiting a shopping page can mean surrendering a biometric-like identifier, extracted through invisible sound and calculated in milliseconds. Whether that trade-off is acceptable depends on whom you ask, but the technical capability is no longer in doubt.