CSIPE

Published

- 20 min read

AliExpress Used Silent Audio to Read a Browser Fingerprint

Browser Privacy Device Fingerprinting Web Tracking Privacy

Books by the author

Compare all 5

As an Amazon Associate I earn from qualifying purchases. Buying through these links costs you nothing extra and helps pay for the blog.

A developer opened AliExpress, and his Bluetooth headphones stopped switching cleanly between his computer and phone. The shopping page made no sound. It showed no playing video. Closing the tab fixed the headphones immediately.

That small annoyance exposed a quieter privacy problem. Code on the AliExpress homepage had created two audio-processing systems inside the browser, generated a known signal, measured the result, and turned the final volume down to zero. The measurement sat beside details about graphics, hardware, screen size, browser behaviour, and other device traits.

This was fingerprinting. A site can combine many ordinary details into a label that helps it recognise a browser even after cookies have been cleared. The audio result was one piece of that label. It did not require microphone permission, because the page was generating and analysing its own signal rather than listening to the room.

The distinction matters. Claims that AliExpress was secretly recording conversations go beyond the evidence. Claims that nothing happened because nobody heard a sound ignore the code, the measurements, and the data path the developer found. The useful lesson sits between those two mistakes: browser APIs can disclose identifying characteristics without asking for the permissions people associate with surveillance.

What the headphones revealed on 20 August

The discovery began with a repeatable physical symptom. In a 20 August 2026 technical account, the developer writing as laserphile described how an AliExpress tab kept multipoint Bluetooth headphones attached to the computer’s audio path. Music from the phone stopped. Muting the tab, Firefox, or Windows did not help, while closing the tab did.

He first checked the obvious routes. The page had no audio or video element responsible for playback, no conventional media call, and no active media-session indicator. The delay offered a clue: the problem started several seconds after the homepage had loaded. He then instrumented the browser’s Web Audio API and recorded when the page created an AudioContext, the container in which browser code can generate, route, inspect, and process sound.

Two contexts appeared. Both reached a running state, and both connected processing nodes to the browser’s audio destination. The call stacks led to two obfuscated JavaScript files named collina.js and fireyejs.js, served from an Alibaba media domain under an AWSC path. The developer described them as appearing to belong to browser-security and anti-abuse tooling, a cautious description that fits the available evidence better than assigning a confirmed business purpose.

The audio graph had a recognisable shape. A sawtooth oscillator created a fixed waveform. An analyser read the processed result. A script-processing node handled values, while a gain node set the volume to zero before the graph reached the destination. The browser still did the work. Silence came from the final volume setting, not from an absence of audio processing.

That explains the headphone behaviour. A browser can hold an active audio route because a page is processing a graph, even when the user hears nothing. A tab mute control aimed at ordinary playback may leave the underlying calculation alive. The privacy mechanism became visible only because it collided with a piece of hardware outside the browser.

The developer then inspected the surrounding scripts. He reported checks involving canvas rendering, graphics hardware, screen and viewport dimensions, processor concurrency, device memory, browser plugins, supported formats, WebRTC behaviour, performance timing, interaction events, motion sensors, and signs of browser automation. He also found code for serialising results and sending data to Alibaba telemetry services. Malwarebytes independently reviewed the public finding on 24 August and described the same combination of silent Web Audio processing with canvas, WebGL, display, hardware, WebRTC, and interaction signals.

Several limits belong beside those facts. The public analysis did not establish how AliExpress used the result after receipt. A device score can support fraud detection, bot detection, account protection, marketing, or several purposes at once. The code’s broad measurements and hidden operation create a privacy concern regardless, but purpose should not be invented where the server-side decision remains unseen.

There is also no evidence in the finding that AliExpress captured microphone input. The Web Audio API can process microphone streams when a user grants access, but the observed graph generated its own waveform. The W3C’s Web Audio specification separates audio synthesis and processing from live input obtained through getUserMedia. The reported AliExpress path used the first capability. No room audio was needed.

That narrower account is still serious. The page ran the measurement on a general shopping homepage before a login or payment, according to the developer. He blocked the two script families and found that ordinary browsing still worked during his test. The result suggests that the fingerprint was useful to AliExpress, while the page itself did not need it merely to display products.

How a silent waveform becomes identifying data

A fingerprint starts with variation. Give two computers the same mathematical audio graph and their final numbers may differ slightly because of the browser, operating system, processor instructions, audio implementation, or hardware. The page does not need a melody. A known input and a stable way to inspect the output are enough.

Think of striking the same tuning fork in several rooms. The note is fixed, but the walls, furniture, and microphone colour the measurement. A browser audio test uses software and hardware as the room. It records the tiny differences left after a standard signal travels through that environment.

One result rarely names a person. Thousands or millions of machines may return the same audio value. The identifying power grows when the site joins it with other characteristics: a particular screen size, graphics renderer, language set, time zone, browser build, device-memory estimate, and pattern of supported features. Each field reduces the crowd.

Brave uses the term “semi-identifiers” for these pieces. Its technical explanation of fingerprinting defences shows how a site combines common traits into a much rarer browser profile. Plenty of people use Linux. Plenty prefer French. Far fewer share that operating system, language, hardware shape, window size, and every other measured trait at the same time.

A cookie takes the direct route. The site writes an identifier into browser storage and reads it later. Clearing that storage removes the label, at least until the site sets another. A fingerprint rebuilds a label from the browser’s exposed characteristics. The rebuilt value can remain similar after cookie deletion because the computer, software, and settings have not changed.

That does not make fingerprints magical or permanent. Browser updates alter outputs. Hardware changes. Privacy defences add noise or reduce detail. A user can move between networks, profiles, and devices. Sites also change their collection code. A fingerprint works as a probability and correlation tool, not as a serial number burned into the motherboard.

The AliExpress scripts appear to have understood that. The audio measurement sat inside a larger collection. If one field grouped almost every browser into a few buckets, another field could separate them. If a privacy browser distorted one result, interaction timing or graphics data might still contribute. The strength came from the bundle.

The mechanism also explains why a VPN does little here. A VPN changes the network address visible to the destination and hides traffic from the local internet provider. It does not automatically change the browser’s graphics renderer, screen dimensions, processor behaviour, fonts, or Web Audio output. A site can see a new address attached to a familiar browser shape.

Private browsing has a similar edge. It is useful for separating local history and short-lived storage from an ordinary session. Fingerprinting reads characteristics exposed during the private session itself. A private window can therefore present fewer old cookies while still presenting a recognisable combination of device details. Privacy modes help, but they do not promise a blank machine.

The right defensive goal is to make correlation less dependable. That may mean blocking known scripts, exposing fewer stable details, changing values between sites or sessions, and separating activities that should not be joined. No single switch guarantees anonymity. Several well-chosen boundaries raise the cost of connecting one visit to another.

The Firefox result cuts the audio claim down to size

The loudest version of this story says the waveform uniquely identified every device. A Firefox engineer tested that assumption and found a much weaker result for current Firefox users. That correction improves the story because it shows which layer still matters.

On 20 August, Firefox engineer Tom Ritter extracted the AliExpress Web Audio test and compared it with telemetry from Firefox’s fingerprinting work. He wrote that Firefox had made most Web Audio outputs constant in Firefox 118, released three years earlier. In the survey he described, 99.24 percent of users fell into three output values, while the collection failed for the remaining 0.76 percent.

Three huge groups make a poor unique identifier. Ritter traced the difference mainly to processor instruction families: x86 or x64 without fused multiply-add, x64 with it, and ARM processors using NEON instructions. Firefox had already collapsed some of those buckets and had work recorded for the remaining difference. For the overwhelming majority of the sampled Firefox population, the audio field revealed a broad processor class rather than a unique machine.

A long tail remained. Ritter reported 23 other values among 48 users and noted that unusual hardware, faulty memory, processor behaviour, or uncommon architectures could explain them. Those users could stand out sharply inside that one measurement. Privacy protection often works unevenly: the common machine joins a crowd, while the unusual setup remains exposed.

The correction changes the scale of the audio component. It does not erase the fingerprinting system. The laserphile analysis found many other signals, and Ritter explicitly warned that browser fingerprinting remains effective against many users. A low-value audio field can still add one bit of information to a larger score. It can also expose that a visitor belongs to an uncommon group.

This is why “audio fingerprint” should not be read as “audio serial number.” The page asked the browser a question. Firefox had deliberately arranged for almost everybody to give one of a few answers. Other browsers have their own defences, and results can vary by version and platform. An article that treats all visitors as uniquely identified by this waveform skips the browser’s work.

The headset symptom also proves more than the output value alone. Whatever identifying strength the measurement had, the scripts created running audio contexts and connected them to the destination. That implementation affected a real device. The code crossed from an invisible score into the user’s physical experience, which is why anyone noticed it.

A better privacy assessment asks two questions. First, how much identifying information did each API expose in the tested browser? Second, what could the collector infer after joining every field? Answering only the first can miss the bundle. Answering only the second can turn a weak component into a sensational claim.

The current evidence supports a firm but measured conclusion. AliExpress code performed browser and device measurements consistent with fingerprinting, including a silent Web Audio test. Firefox had already reduced that audio test to a coarse signal for nearly all measured users. The broader set of measurements remains the real concern.

Fraud control does not excuse an invisible identity layer

Large shopping platforms have real abuse problems. Stolen accounts, automated scraping, payment fraud, fake reviews, coupon abuse, and bot-driven purchases cost money and hurt customers. A device-risk score can help a platform decide when to request another check instead of challenging every visitor.

That purpose creates a legitimate design problem rather than a blank cheque. A service should collect data tied to a defined risk, at the point where the risk appears, and keep it for a stated period. Running a broad device probe on the public homepage reaches people who have not logged in, entered payment details, or attempted a sensitive action.

The timing matters. A strong anti-fraud check before a purchase may protect both buyer and seller. The same check on every product view can build a browsing identifier long before fraud is possible. The technical mechanism may be identical, while necessity changes with context.

Transparency matters as well. People understand that a shop sees the pages they request. Few expect a silent audio graph to inspect how their browser and processor handle a waveform. Consent banners usually focus on cookies, yet fingerprinting can operate through APIs and telemetry that do not look like storage to the visitor.

A banner cannot repair every hidden collection practice. “Accept all” offers little choice when essential shopping and broad measurement arrive together. Useful transparency names the purpose, categories of signal, retention period, recipients, and consequence of refusal. It also gives the customer a route that does not require reverse-engineering obfuscated JavaScript.

The code design deserves scrutiny because obfuscation and encryption make outside inspection harder. Obfuscation can protect anti-fraud logic from attackers who want to imitate trusted devices. It can also conceal collection from customers and auditors. Both facts can coexist. The answer is accountable review, documented data boundaries, and independent testing rather than publishing every detection rule.

Purpose separation is the key control. Data gathered to stop payment fraud should not quietly become a durable marketing identifier. A platform can enforce that separation through distinct services, access controls, retention schedules, and audit records. A policy sentence helps only when the architecture makes repurposing visible and difficult.

Collection should also become more specific as the risk increases. A public product page might need rate limits and coarse bot signals. Login can justify checks tied to account takeover. Checkout can justify payment-risk controls. Each stage should have its own minimum data set. Collecting the maximum everywhere is convenient engineering, but it transfers the privacy cost to every visitor.

The AliExpress case offers no public view of those server-side boundaries as of 25 August 2026. The developer could see measurements and outbound telemetry, but not retention, access, or downstream use. AliExpress or Alibaba could narrow the concern by publishing the exact purpose of collina.js and fireyejs.js, the fields sent, how long they remain linkable, and whether advertising systems can receive them.

Silence leaves the broadest technically plausible uses in play. That uncertainty is avoidable. A company asking a browser detailed questions about its user should be able to explain why each answer is needed.

What the finding means for anonymity work

A journalist can clear cookies before contacting a source and still carry a familiar browser shape into the new session. An activist can change networks while keeping the same uncommon laptop, display, language, fonts, and browser configuration. A whistleblower can use a VPN and remain linkable through application-layer signals gathered after the encrypted tunnel ends.

Those examples do not mean a fingerprint automatically reveals a legal name. Correlation comes first. A tracker sees that the browser visiting one page resembles the browser that visited another. Identity can arrive later through a login, purchase, email link, delivery address, or any session where the person volunteers a name.

This sequence is the danger. An anonymous session needs only one later connection to a named session for the two histories to become candidates for joining. The more unusual and stable the browser, the cheaper that comparison becomes. A tracker does not need courtroom certainty to target an advert, raise a fraud score, or send a lead to another system.

The unusual setup can hurt twice. Privacy-conscious users often install uncommon extensions, change many hidden settings, add distinctive fonts, and run a rare operating system. Each choice may block one tracker while making the whole configuration easier to distinguish. A defence that makes you the only person in the room can trade one leak for another.

Crowds protect better than cleverness. A widely used privacy browser with standard settings gives many people similar answers. Tor Browser follows this principle most strictly by trying to make users resemble one another, though changing its defaults can reduce that benefit. Mainstream browsers increasingly add their own fingerprinting defences, but they make different trade-offs between compatibility and uniformity.

Brave takes another route for some APIs. Its published design adds small, deterministic changes to canvas and Web Audio values, using a seed tied to the site and session. The same site receives a stable answer during that session, while another site or later session receives a different one. This “farbling” aims to break cross-site correlation without making ordinary features unusable.

Firefox reduces exposed variation and blocks or limits known and suspected fingerprinting behaviour. Ritter’s audio measurements show the practical result for one API: almost everyone moved into a few large groups. Neither approach makes tracking impossible. Both attack the stability that fingerprinting needs.

The Anonymity Playbook treats correlation as a boundary problem. A network identity, browser identity, account identity, and payment identity should not meet by accident. Browser fingerprinting matters because it can bridge two of those compartments without leaving an obvious cookie behind.

Operational separation therefore needs more than a new tab. Use a separate browser profile for work that should not join ordinary shopping or social accounts. For higher stakes, use a separate browser built for uniformity, and avoid customising it. Keep named accounts, personal email, delivery addresses, and payment sessions out of that environment.

A separate profile is a modest boundary, not a perfect one. Profiles on the same machine may still expose similar hardware and network traits. A site can compare them probabilistically. The benefit is that storage, logins, extensions, and routine history no longer cross automatically. That removes several strong links even when weaker similarities remain.

Threat model decides how far to go. Someone who wants fewer shopping adverts can use built-in tracking protection and a content blocker. A reporter protecting a source should use a hardened, standardised browser environment and disciplined identity separation. A person facing a capable state adversary needs device, network, behavioural, and account separation designed together. One browser setting cannot carry that burden.

What to do without turning browsing into a second job

Most readers do not need to inspect JavaScript bundles or maintain a private blocklist. Browser vendors and well-maintained blockers can do more useful work at scale. The goal is to choose a small set of controls that reduce stable signals and prevent unrelated activities from sharing one container.

  1. Update the browser before changing obscure settings. Firefox’s Web Audio result improved because engineers changed the browser implementation. An old browser keeps old privacy weaknesses as well as old security bugs. Install the current stable release and restart it so the new code is actually running.

  2. Turn on the browser’s built-in fingerprinting and tracking protection. Use the strongest standard mode that keeps the sites you need working. If one page breaks, make a site-specific exception rather than disabling protection everywhere. Broad exceptions recreate the original problem quietly.

  3. Use a reputable content blocker. The original researcher used the official uBlock Origin extension to block the two observed AliExpress script families and reported that ordinary homepage browsing still worked. Narrow rules can age quickly, so prefer maintained lists and extension updates over copying a filter once and forgetting it.

  4. Separate shopping from sensitive work. Put shopping, delivery accounts, and payment sessions in one browser profile. Keep research, source contact, organising, or other sensitive browsing in another environment. Do not sign into personal email from the sensitive profile just because a link is convenient.

  5. Keep the sensitive browser ordinary. Resist the temptation to install a dozen niche extensions or tune every hidden preference. A standard privacy configuration gives you a larger crowd and fewer maintenance surprises. Test any change against a fingerprinting tool before treating it as an improvement.

  6. Use a VPN for the problem it solves. A VPN hides your destination traffic from the local network and changes the public network address seen by a site. It does not wipe application-layer characteristics. Pair it with browser controls when correlation matters.

  7. Close a suspicious tab, then verify the symptom. In this case, closing AliExpress immediately released the headphone path. Closing a tab also ends its active page code and short-lived contexts. If hardware remains engaged, quit the browser and inspect operating-system microphone and audio indicators before assuming the cause.

  8. Test, do not guess. The EFF’s Cover Your Tracks project shows how trackers see a browser and whether its configuration appears distinctive. Run a test before and after a major privacy change. A result is a clue about exposure, not a certificate of anonymity.

People who administer browsers for a team can make these controls less fragile. Set an update policy, approve a short extension list, enable tracking protection by default, and provide separate managed profiles for risky research. Record exceptions with an owner and expiry date. A permanent global exception should be rare.

Developers should inspect third-party anti-fraud and analytics libraries with the same discipline they apply to payment code. Map every browser API touched, every field sent, every destination, and every retention rule. Test the site with collection disabled. If the user-facing function still works, justify why the measurement belongs on that page.

Security teams can watch the network boundary. Content-security policy and destination allowlists will not stop first-party code from collecting data, but they can restrict where scripts load from and where results are sent. Build-time dependency review catches known libraries. Runtime observation catches code that changes after deployment.

The practical standard is simple: browser measurement should be proportionate to the action in front of the user. Browsing a product page should not silently create the same device dossier needed to defend a high-risk payment. If the business disagrees, it owes visitors a clear explanation and a real choice.

The sound was silent, the boundary was not

The AliExpress finding is memorable because a privacy mechanism tripped over a pair of headphones. Invisible code held open a visible device path. The developer followed that symptom into two scripts, two running audio contexts, a fixed waveform, and a much larger set of browser measurements.

The clean account avoids drama. AliExpress was not shown recording a room. Its code generated and measured an inaudible signal. Firefox had already made that audio value weak for nearly all users in one survey. Other characteristics around the audio test could still contribute to a useful browser and device profile.

That final bundle is the point. Privacy can leak through ordinary capabilities that were built for games, graphics, media, responsive layouts, and fraud control. Permission prompts cover some dangerous actions, while many identifying measurements remain available because websites rely on them. Browser makers respond by blocking scripts, reducing variation, or changing answers between contexts.

Users should answer with boundaries of their own. Keep the browser current. Use built-in protection and a maintained blocker. Separate named shopping from sensitive work. Choose a standard privacy configuration over a handcrafted fingerprint. Treat a VPN as one layer rather than a disguise for the whole device.

The headphone glitch will be fixed or the scripts will change. The design lesson will last longer: if two activities should not be connected, do not let one browser profile introduce them.

If you want calm, practical security and privacy analysis without a daily alarm bell, join the newsletter. It is one email per month.

Sources