A recent investigation into AliExpress is a useful reminder that online tracking is not limited to cookies or visible consent banners. The marketplace was found running a silent Web Audio routine that could help identify a visitor’s device. It did not record through the microphone. Instead, it generated an inaudible signal and measured small, repeatable differences in the way the browser and device processed it. That is a form of browser fingerprinting: a way of recognising a device by combining technical characteristics rather than dropping a conventional cookie.
For UK and US leaders, the practical lesson is not “ban every fraud-control tool”. Fingerprinting can serve legitimate functions such as fraud prevention and bot detection. The issue is whether the technology is necessary, proportionate, transparent and governed. Covert collection that people cannot reasonably see or control is exactly the kind of tracking risk that privacy teams should be able to find, assess and explain.
What the AliExpress finding showed
The reporting began with an unexpected symptom. A user with multipoint Bluetooth headphones found that music from their phone stopped playing when an AliExpress tab was open on their PC; closing the tab restored normal behaviour. The technical analysis linked this to Web Audio graphs which remained connected to audio output at zero gain. In other words, the process was silent, but it could still keep the system audio path active.
Independent reporting describes the site processing a fixed waveform and examining the resulting numerical values. Those values can vary slightly according to the browser, operating system, CPU behaviour, audio hardware and drivers. On their own, such readings are limited. Combined with other signals, however, they can add to a device or browser identifier. The investigation and follow-up reporting also describe collection associated with canvas rendering, WebGL, display settings, WebRTC and user interactions. Malwarebytes’ report provides a useful technical summary; the original finding was also raised with Brave’s community.
This is not an allegation that AliExpress was listening through a customer’s microphone, and it should not be described that way. The concern is different: the output-side behaviour could derive a repeatable device signal without the user hearing anything or encountering a cookie prompt. Nor is this a regulator’s enforcement finding. It is a reported technical discovery, which means compliance teams should distinguish the evidence of the implementation from any conclusion about its legal purpose or lawfulness.
Why audio can contribute to a browser fingerprint
A browser fingerprint is a collection of device and browser details that, when combined, can make a returning visitor recognisable. The ICO’s guidance gives familiar examples: device configuration, JavaScript objects, HTTP headers, clocks, installed fonts, plugins and APIs. Audio processing is another potential input because devices and software can produce subtly different results from the same Web Audio operation.
That matters because a fingerprint can work when a person has deleted cookies or rejected a non-essential cookie banner. It can also be combined with IP address, account, purchase or interaction data. The ICO says that device fingerprinting falls within PECR where it stores information, or accesses information stored, on a person’s device; if personal data is involved, UK GDPR applies as well. This is not a cookie loophole. It is a separate tracking design that needs its own legal and technical assessment.
For marketers and product teams, the key question is not whether the code is first-party or third-party. The ICO says the relevant questions are who is responsible for the access or storage and what purpose it serves. A retailer using a supplier’s script remains responsible for understanding what it collects, where it sends data and whether it is necessary. That is the same governance point behind our WordPress cookie compliance guide: a tracker inventory must cover scripts and APIs, not just named cookies.
What Brave says it does — and the limit of that mitigation
Brave says its default Shields protections randomise browser features that can be used for fingerprinting, including audio-related outputs. Its approach, which it calls “farbling”, is designed so that a site sees a consistent value during one browser session, but a different site sees a different value and the value changes after the browser restarts. Brave also says it blocks the specific AliExpress script families identified in the investigation. That is a practical browser-level mitigation for people using the browser with Shields enabled.
Brave’s own Shields documentation says fingerprint randomisation is on by default, while its technical explanation of farbling describes per-site, per-session values for Web Audio and other semi-identifying browser features. Those claims should be read precisely: randomisation aims to make broad, web-scale tracking harder; it is not a guarantee that a determined actor cannot identify a particular person, and protections can be disabled for a site.
Businesses should therefore treat browser protections as a useful additional control, not as permission to avoid privacy engineering. They help users reduce exposure; they do not answer the organisation’s obligation to know what its own site code does. If an anti-fraud provider says it needs fingerprinting, ask for a documented explanation of the data points, purpose, retention, recipients, geographic transfers, false-positive impact and alternatives. Then test the implementation rather than accepting a vendor label.
A practical checklist for marketing, compliance and security teams
- Inventory browser-side code. Include JavaScript tags, SDKs, Web Audio, canvas, WebGL, WebRTC and tag-manager containers — not only cookies.
- Trace each data flow. Record what the script reads or derives, the endpoint it sends data to, every recipient and the retention period.
- Separate fraud controls from advertising. A genuine fraud-prevention purpose does not automatically justify unrelated profiling, analytics or retargeting.
- Assess PECR and data-protection requirements. The ICO’s guidance makes clear that the analysis turns on access or storage on terminal equipment and the purpose of the activity. Document the reasoning, including any consent or exception relied on.
- Make the explanation usable. Privacy notices and consent journeys should describe fingerprinting in plain language, not bury it under “device information”.
- Test the user impact. Look for side effects such as the Bluetooth issue in this report, and test whether blocking a script breaks checkout, authentication or accessibility.
For staff who commission marketing technology or manage customer data, the training objective is simple: recognise that hidden technical collection is still a compliance decision. Our data protection training matrix can help employers map that responsibility across marketing, product and technical teams; for the wider legal context, see our explainer on ICO cookie-consent changes.
The takeaway
The AliExpress report is a vivid example of why cookie banners are not a complete picture of online tracking. Silent Web Audio processing may not be microphone surveillance, but it can still supply a device-identification signal that users would struggle to spot. Browser protections such as Brave’s can reduce that exposure. For organisations, the more durable response is governance: map the code, verify the purpose, test the effect, document the legal basis and explain the processing clearly enough that a customer can understand it.
