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 <video> 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:

const OriginalAudioContext = window.AudioContext;

window.AudioContext = class extends OriginalAudioContext {

    constructor(...args) {

        super(...args);

        console.log("AudioContext created", {

            state: this.state,

            stack: new Error().stack

        });

    }

};

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:

https://assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js

https://assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

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:

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.

Edit - There seems to be a firefox bug ticket open for the issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1863193#c9  

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:

• 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. 

Edit - tomrittervg, a firefox developer, has done a further dive into what is being fingerprinted with the WebAudio: https://ritter.vg/blog-webaudio_alibaba.html

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:

! AliExpress AWSC fingerprinting scripts

||assets.aliexpress-media.com/g/AWSC/uab/*/collina.js$script,domain=aliexpress.com

||assets.aliexpress-media.com/g/AWSC/fireyejs/*/fireyejs.js$script,domain=aliexpress.com

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.

Edit - There have been some great discussions on Hacker News that are worth checking out: https://news.ycombinator.com/item?id=49372583

Bluetooth DMX controller update

After a couple of queries from people interested in this project i have decided to post an update to what we have been working on. We have produced a production prototype of the Bluetooth DMX controller to bring it a step closer to being ready for a small run production sample. I also threw together a very basic Android application using MITs application inventor, this let us test the first prototype as well as show off the proof of concept to friends.

The hardware

There were a couple of design iterations building up to the construction of the first production prototype. The production prototype boards are based around an Arduino mini controller and a Roving Networks RN-42 SMD bluetooth module.

The component list in full:

• Arduino mini
• RN-42 SMD bluetooth module
• MAX485 RS-485 serial interface
• 5V TO-220 regulator
• 3.3V TO-220 regulator
• 3 * 10µF electrolytic capacitors
• 2.5mm barrel jack power connector

You can see the component layout in this early design revision. from the right most side we have the XLR connector, the 8 pin MAX485 IC, the 5v regulator with capacitor above, socket layout for the arduino mini, surface mount pad layout for the RN-42 bluetooth module, 3.3v regulator, two capacitors and the 2.5mm barrel jack power connector. Note that all the thru-hole components are on the non copper side and the bluetooth SMD module is soldered straight onto the copper side of the printed circuit board.

The following is the layout of the first unit built, it has the power components all to the right hand side of the board to simplify the track layout, and have both power and DMX connectors coming out the one end.

For production the design is transferred to a Kinsten positive photo resist board by covering the bare circuit board with the printed design (printed on transparency paper) and exposing it to UV light, in our case using a specially designed UV flruo lightbox. After exposure the baord is still sensitive to light so it must be quickly developed in the Kinsten developer solution. Finally it is ready to etch, I did this using Ferric chloride and an old electric stove in an open area (the fumes can be quite noxious). Last two steps are to give the etched board a coat of circuit board lacquer to prevent the copper oxidising in the air and drilling out the holes for components.

You can just see 4 identical circuits laid out on the large circuit board on the table.

The first constructed prototype.

The current hardware plan is to make a small production run of units with 3d printed cases. We will give these units out to friends so we can get some feedback on what could be changed.

The Android software

The Android software is currently very basic, being able to only address 5 DMX channels via sliders on the touch screen. I built this quickly using the MIT app inventor, a very useful tool for quickly and easily making android applications.
I set up the first 2 channels to be able to strobe between 0 and the selected value on the slider (maximum 255).

I plan on re-writing the application from scratch and will be working to add the ability to assign a group of DMX channels to individual devices (like multi colour LED lights or moving heads). This will allow for a simple and intuitive interface for any screen size.
Following that I will work on enabling the ability to pre-set scenes and animations to be enabled on cue or run on a pre-set timeline.This will bring the functionality of the control software to be on par or better than low end dedicated DMX lighting desks.

Stay tuned.
Matt

Bluetooth DMX512 controller

DMX512 (Digital MultipleX) is a standard for digital communication networks that are commonly used to control stage lighting and effects. It was originally intended as a standardized method for controlling light dimmers, which, prior to DMX512, had employed various incompatible proprietary protocols. It soon became the primary method for linking controllers to dimmers and special effects devices such as fog machines and intelligent lights. DMX has also expanded to uses in non-theatrical interior and architectural lighting, at scales ranging from strings of Christmas lights to electronic billboards.

- Wikipedia

The need for a DMX lighting controller came about after I bought my first piece of lighting equipment, a DUNE 3 colour laser projector. This unit has automatic show functions and a sound reactive function, but it isn't enough, I wanted to be able to control the functions of my laser. 
After doing a bit of research into current products available on the market, I found they were either based on a physical lighting desk (expensive hardware), or propriety software systems based on a computer communicating with a usb DMX controller (expensive software/hardware).  In my research I also came across an Arduino software library capable of driving DMX signals, the hardware side of things is very simple, it is based around an RS485 serial communication IC with some supporting circuitry. 

The use of an Arduino microcontroller means that any manner of control could be used, anything from push buttons, to variable resistors, to accelerometer or the idea I had, which was to connect via Bluetooth to my phone. Okay, so it isn't a particularly new idea, but so far I cannot find anyone who has tried doing this open source. I want to be able to drop all of my gear down at an event, plug the power in, and immediately be able to control everything via a wireless connection from my phone. DMX512 supports daisy chaining devices along the same DMX bus, this removes the hassle of wiring back to central location, this plus wireless control should mean a very quick and pain free set up.



This is at the breadboard stage, I have a power supply in the background there supplying 3.3v to the Arduino and Bluetooth module.


I was testing out the functionality with my RGB LED strobe.


 I have changed to a different Arduino module here. The prototype board seen holds the two voltage regulators, a MAX485 chip and all the wiring to go between the Bluetooth and Arduino.


This is how the first prototype looks. My next two steps with the hardware is to design a custom PCB and a 3D printed case to hold everything together a bit more securely.
Looking at the software side of things and it is non existent, the phone and Arduino are currently just communicating via a Bluetooth serial terminal, the DMX library on the Arduino interprets commands and applies them to the DMX bus. The mobile device software side will be something relatively simple and allow for basic control of the DMX channels with possibly some programmable functions.


Just to share, this is my road case of stage equipment, it includes an RGB LED strobe, Dune red, green and cyan laser projector, and a Dune 400 smoke machine.