In a better world browsers would protect their users against shit like this.
More sneaky spyware bullshit causing problems as a side effect of its primary nefariousness
Honestly, this doesn’t sound like spyware. More like absurd optimization. Here’s why: Audio devices often go to sleep (to save battery) and can take a second or two to wake up. That’s enough time that the end user will miss the first second or two of audio.
By keeping the audio outputting something (even if it’s just silence), they can guarantee that their little (often hilariously terrible) product videos will play the way they expect (which is loud and startling, of course!).
This is just one of those stupid tricks that’s bad for energy use but good for ignorant users who might complain that the first second of every AliExpress video is silent 🤷
The reason why I believe this to be the case is because there’s really nothing unique or interesting to be learned from an audio output loop that’s literally sending zeros through itself. If you wanted to use that to fingerprint a user, you wouldn’t need to keep it active. You could pass a single zero (silence) through and be done.
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().
Not sure you need all this to play audio.
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.
The gaining happens after retrieval of the results it seems: so it’s just silent for the end user. And perhaps they do both fingerprinting, and ensure audio devices remain awake.
If that’s actually their problem, they could easily just play a small amount of silence before a video’s content. They don’t need to be constantly tying up an audio stream.
