AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting - 我的飛鳥集
AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting
·· reads0
AI TranslationEnglishEnglish
Key Insights
A user discovered that the AliExpress homepage silently creates two hidden WebAudio contexts via obfuscated Alibaba security scripts (collina.js and fireyejs.js). These scripts build a zero-gain audio graph connected to the system audio destination, which interferes with Bluetooth multipoint headphone switching, preventing audio from playing on a connected phone. The scripts are part of a comprehensive browser fingerprinting system, measuring audio, canvas, WebGL, hardware, and interaction data. The user provides uBlock Origin filter rules to block these scripts, noting potential side effects like extra CAPTCHAs. The issue stems from the audio graph keeping the PC's audio path active, which tab muting cannot stop. The user blocks the scripts to prevent this privacy-invasive tracking and the hardware side effect.
AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio fingerprinting
Recently I ran into a strange problem with my Bluetooth headphones. They support multipoint Bluetooth audio, so they can be connected to my PC and phone at the same time. Normally the PC takes priority playing audio, with my phone being able to play audio when nothing is playing on the PC.
Usually I listen to music on my phone but with notifications or Youtube playing through the PC, this works reliably until I open an AliExpress page in Firefox or Chrome (other browsers untested).
Shortly after loading the AliExpress homepage, audio from my phone would stop playing. Closing the AliExpress tab fixes it immediately. Muting the tab/Firefox/Windows does not help, and there is no visible video, music, or other media playing on the page.
This seemed suspicious enough to investigate.
Looking for hidden media
My first thought was an autoplaying product video or advertisement, so I checked for the usual suspects:
<audio> and <audio> elements
calls to HTMLMediaElement.play()
active Media Session metadata
media requests
embedded frames containing media
None of these showed anything useful. There were no audio or video elements, no media playback calls, and navigator.mediaSession.playbackState remained none.
A clue was that the problem did not begin immediately. It appeared after the page had been sitting idle for several seconds. I instrumented the page before loading it and watched the Web Audio API instead of only looking for conventional media elements.
The basic idea was to wrap the AudioContext constructor and record whenever a page created an audio-processing context:
I also wrapped AudioNode.prototype.connect() so I could see whether anything was connected to the context's audio destination.
That finally found it, two hidden audio contexts!
During an idle capture of the AliExpress homepage, the page created two AudioContext objects. Both entered the running state and both connected nodes to AudioContext.destination.
At the same time there were still:
zero <audio> or <video> elements
zero media play() calls
no active Media Session
no audible sound
The constructor stack traces pointed to two scripts:
The first context was created by collina.js, while the second came from fireyejs.js. Both sit under an AWSC directory and appear to be part of Alibaba's browser security and anti-abuse tooling.
The scripts are extremely obfuscated, but enough names and operations survive for AI to work out what the audio code is doing.
What the audio code does
Both scripts build a WebAudio graph resembling this:
TEXT
Both scripts build a WebAudio graph resembling this:
Sawtooth oscillator
-> AnalyserNode
-> ScriptProcessorNode
-> GainNode set to zero
-> AudioContext.destination
The oscillator generates a known waveform. The analyser measures the result after it has passed through the browser's audio implementation, and the script reads frequency data from it.
The gain is set to zero, so the user should not hear anything. However, the graph is still connected to the system audio destination. Connecting it to the destination causes the browser to actively process the graph, even though the final volume is zero.
This is very different from an autoplaying video. There is no media element for the browser's normal tab mute control to stop. As far as the page is concerned, it is performing live audio processing.
In my case, that appears to have been enough for Firefox or Windows to keep the Bluetooth audio path active, preventing my multipoint headphones from switching cleanly back to the phone.
The WebAudio test is not the only measurement in these scripts. Inspection of the bundles found code that queries or measures:
canvas rendering and toDataURL()
WebGL renderer information, extensions, and shader precision
audio oscillator and analyser output
screen and viewport dimensions
device pixel ratio
hardware concurrency and device memory
installed browser plugins
supported audio and video formats
WebRTC behaviour
browser performance timing
mouse, touch, focus, and scroll events
device motion and orientation
properties commonly associated with browser automation
There is also code for serialising and encrypting results, making requests to Alibaba telemetry services, and sending data with fetch() or sendBeacon().
This is a fairly comprehensive browser and device fingerprint.
Audio fingerprinting works because small differences in browser versions, operating systems, audio libraries, and hardware can produce slightly different results from the same generated signal. It is not necessarily enough to uniquely identify a device by itself, but it becomes much more useful when combined with canvas, WebGL, hardware, timing, and interaction data.
I cannot see what AliExpress does with the resulting data after it reaches their servers. It may be used as a persistent device identifier, but it could also be one input into a fraud or bot-detection score.
Why AliExpress would want this
AliExpress has plenty of reasons to distinguish normal shoppers from automated or suspicious clients as well as tracking users browsing habits. The site has to deal with account takeovers, fake accounts, scraping, automated purchasing, payment fraud, review manipulation, and abuse of coupons or new-customer promotions. They also, like most large businesses, make use of large datasets of user behaviour to better market products and services.
Cookies are not especially reliable for this purpose because they can be cleared, copied, or replaced. A fingerprint made from many independent browser measurements is harder to manipulate consistently.
Interaction data can also help determine whether a browser is controlled by a person or automation. From AliExpress's perspective, this could reduce fraud and allow trusted customers through without showing a CAPTCHA every few pages. Not that Aliexpress shies away from their AI generated CAPTCHAs.
Personally I do not want a shopping homepage silently exercising my graphics, audio, WebRTC, hardware, and motion APIs, etc, to track my behaviours, especially if it has such an annoying effect as blocking my music. Perhaps if AliExpress wasn't blocking my music I never would've looked into what the site was doing.
Blocking it with uBlock Origin
I tested blocking the two identified script families. With both requests blocked, the AliExpress homepage continued to render and no AudioContext objects or destination connections appeared during the control capture.
In Firefox, I use the official uBlock Origin extension by Raymond Hill. To block the scripts open the uBlock dashboard, select My filters, and add:
Click Apply changes, close any existing AliExpress tabs, and open the site again. Existing tabs need to be closed because blocking a script does not shut down an audio context that it has already created.
These rules are deliberately narrow. They block only the two observed script families and only when requested by AliExpress. I would not be surprised if this stops working in the future, I'll cross that bridge when it comes to it.
Because these scripts appear to be connected with anti-fraud systems, blocking them may cause extra CAPTCHAs or problems during login or checkout. So far the homepage and ordinary product browsing still work, but I would temporarily disable the rules if AliExpress refuses a legitimate login or payment.
Why I am blocking it
The anti-fraud use case is understandable, but this implementation has real world problems.
It runs on the general shopping homepage before I perform a sensitive action. It collects a broad set of device and behavioural measurements, the implementation is deliberately difficult to inspect, and there is no visible indication that the page has started a live audio-processing graph.
It also produced a very real hardware side effect. A silent fingerprinting test was able to interfere with Bluetooth multipoint switching, while the browser's mute control did nothing!
If a hidden analytics or security feature can take ownership of an audio path strongly enough to change how external hardware behaves, blocking it seems like a reasonable trade-off.
I also cannot prove how long AliExpress stores the fingerprint or whether it is used across other Alibaba properties. The client code proves that extensive fingerprint-like measurements are collected and transmitted, but server-side retention and identity linkage are not visible from the browser. Can you really trust anyone on the internet to have your best interests at heart?
TL;DR
The AliExpress homepage silently creates two running WebAudio graphs from heavily obfuscated Alibaba security scripts. The graphs generate and analyse a waveform as part of a much larger browser fingerprint, then connect through a zero-gain node to the system audio destination preventing the user from hearing anything.
On my setup, this appears to keep the PC's Bluetooth audio path active and prevents multipoint headphones from switching back to a phone. Muting the tab does not fix it because there is no conventional media element to mute.
Blocking collina.js and fireyejs.js with the two uBlock Origin rules above prevented the hidden audio contexts from being created and means I can happily listen to my music without being interrupted while browsing AliExpress.
Recently I ran into a strange problem with my Bluetooth headphones. They support multipoint Bluetooth audio, so they can be connected to my PC and phone at the same time. Normally the PC takes priority playing audio, with my phone being able to play audio when nothing is playing on the PC.
Usually I listen to music on my phone but with notifications or Youtube playing through the PC, this works reliably until I open an AliExpress page in Firefox or Chrome (other browsers untested).
Shortly after loading the AliExpress homepage, audio from my phone would stop playing. Closing the AliExpress tab fixes it immediately. Muting the tab/Firefox/Windows does not help, and there is no visible video, music, or other media playing on the page.
This seemed suspicious enough to investigate.
Looking for hidden media
My first thought was an autoplaying product video or advertisement, so I checked for the usual suspects:
None of these showed anything useful. There were no audio or video elements, no media playback calls, and navigator.mediaSession.playbackState remained none.
A clue was that the problem did not begin immediately. It appeared after the page had been sitting idle for several seconds. I instrumented the page before loading it and watched the Web Audio API instead of only looking for conventional media elements.
The basic idea was to wrap the AudioContext constructor and record whenever a page created an audio-processing context:
I also wrapped AudioNode.prototype.connect() so I could see whether anything was connected to the context's audio destination.
That finally found it, two hidden audio contexts!
During an idle capture of the AliExpress homepage, the page created two AudioContext objects. Both entered the running state and both connected nodes to AudioContext.destination.
At the same time there were still:
The constructor stack traces pointed to two scripts:
The first context was created by collina.js, while the second came from fireyejs.js. Both sit under an AWSC directory and appear to be part of Alibaba's browser security and anti-abuse tooling.
The scripts are extremely obfuscated, but enough names and operations survive for AI to work out what the audio code is doing.
What the audio code does
Both scripts build a WebAudio graph resembling this:
The oscillator generates a known waveform. The analyser measures the result after it has passed through the browser's audio implementation, and the script reads frequency data from it.
The gain is set to zero, so the user should not hear anything. However, the graph is still connected to the system audio destination. Connecting it to the destination causes the browser to actively process the graph, even though the final volume is zero.
This is very different from an autoplaying video. There is no media element for the browser's normal tab mute control to stop. As far as the page is concerned, it is performing live audio processing.
In my case, that appears to have been enough for Firefox or Windows to keep the Bluetooth audio path active, preventing my multipoint headphones from switching cleanly back to the phone.
This looks like fingerprinting
The WebAudio test is not the only measurement in these scripts. Inspection of the bundles found code that queries or measures:
There is also code for serialising and encrypting results, making requests to Alibaba telemetry services, and sending data with fetch() or sendBeacon().
This is a fairly comprehensive browser and device fingerprint.
Audio fingerprinting works because small differences in browser versions, operating systems, audio libraries, and hardware can produce slightly different results from the same generated signal. It is not necessarily enough to uniquely identify a device by itself, but it becomes much more useful when combined with canvas, WebGL, hardware, timing, and interaction data.
I cannot see what AliExpress does with the resulting data after it reaches their servers. It may be used as a persistent device identifier, but it could also be one input into a fraud or bot-detection score.
Why AliExpress would want this
AliExpress has plenty of reasons to distinguish normal shoppers from automated or suspicious clients as well as tracking users browsing habits. The site has to deal with account takeovers, fake accounts, scraping, automated purchasing, payment fraud, review manipulation, and abuse of coupons or new-customer promotions. They also, like most large businesses, make use of large datasets of user behaviour to better market products and services.
Cookies are not especially reliable for this purpose because they can be cleared, copied, or replaced. A fingerprint made from many independent browser measurements is harder to manipulate consistently.
Interaction data can also help determine whether a browser is controlled by a person or automation. From AliExpress's perspective, this could reduce fraud and allow trusted customers through without showing a CAPTCHA every few pages. Not that Aliexpress shies away from their AI generated CAPTCHAs.
Personally I do not want a shopping homepage silently exercising my graphics, audio, WebRTC, hardware, and motion APIs, etc, to track my behaviours, especially if it has such an annoying effect as blocking my music. Perhaps if AliExpress wasn't blocking my music I never would've looked into what the site was doing.
Blocking it with uBlock Origin
I tested blocking the two identified script families. With both requests blocked, the AliExpress homepage continued to render and no AudioContext objects or destination connections appeared during the control capture.
In Firefox, I use the official uBlock Origin extension by Raymond Hill. To block the scripts open the uBlock dashboard, select My filters, and add:
Click Apply changes, close any existing AliExpress tabs, and open the site again. Existing tabs need to be closed because blocking a script does not shut down an audio context that it has already created.
These rules are deliberately narrow. They block only the two observed script families and only when requested by AliExpress. I would not be surprised if this stops working in the future, I'll cross that bridge when it comes to it.
Because these scripts appear to be connected with anti-fraud systems, blocking them may cause extra CAPTCHAs or problems during login or checkout. So far the homepage and ordinary product browsing still work, but I would temporarily disable the rules if AliExpress refuses a legitimate login or payment.
Why I am blocking it
The anti-fraud use case is understandable, but this implementation has real world problems.
It runs on the general shopping homepage before I perform a sensitive action. It collects a broad set of device and behavioural measurements, the implementation is deliberately difficult to inspect, and there is no visible indication that the page has started a live audio-processing graph.
It also produced a very real hardware side effect. A silent fingerprinting test was able to interfere with Bluetooth multipoint switching, while the browser's mute control did nothing!
If a hidden analytics or security feature can take ownership of an audio path strongly enough to change how external hardware behaves, blocking it seems like a reasonable trade-off.
I also cannot prove how long AliExpress stores the fingerprint or whether it is used across other Alibaba properties. The client code proves that extensive fingerprint-like measurements are collected and transmitted, but server-side retention and identity linkage are not visible from the browser. Can you really trust anyone on the internet to have your best interests at heart?
TL;DR
The AliExpress homepage silently creates two running WebAudio graphs from heavily obfuscated Alibaba security scripts. The graphs generate and analyse a waveform as part of a much larger browser fingerprint, then connect through a zero-gain node to the system audio destination preventing the user from hearing anything.
On my setup, this appears to keep the PC's Bluetooth audio path active and prevents multipoint headphones from switching back to a phone. Muting the tab does not fix it because there is no conventional media element to mute.
Blocking collina.js and fireyejs.js with the two uBlock Origin rules above prevented the hidden audio contexts from being created and means I can happily listen to my music without being interrupted while browsing AliExpress.
Copyright
: AliExpress webpage keeping multipoint Bluetooth headphones active with WebAudio