AliExpress WebAudio fingerprinting is why your Bluetooth multipoint headphones stopped handing off to your phone. A developer writeup traced the failure to two scripts, collina.js and fireyejs.js, that AliExpress pages load and run with no visible player and no tab-audio indicator. Each script builds a zero-gain audio graph wired straight into your system’s audio destination. And your browser processes that graph even when the tab is muted. Users hear crackle and random volume shifts, and iOS VoiceOver users get hit too. Blocking the two scripts with uBlock Origin on desktop restored normal switching, per the writeup.
That paragraph is the whole story. The rest is why it works, why no permission prompt stops it. And what it means if you build or maintain websites for a living.
The Symptom You’d Blame on iOS
Multipoint is the Bluetooth feature that lets one pair of headphones stay connected to two devices and follow whichever one starts playing. When it breaks, you notice fast: you start a video on your phone and the headphones refuse to let go of the laptop.
The writeup’s author went through exactly this and first wrote it off as standard iOS weirdness, which is the reasonable read. Random crackle and unexplained volume changes sound like driver problems, not like something a shopping site is doing to you. The break in the case was noticing the failure followed one specific site, not one specific device. That is the debugging habit worth stealing: when behavior tracks a context instead of the hardware, stop blaming the hardware.
I care about this angle more than the privacy angle, honestly.
The discipline of chasing a small ignorable anomaly is the same muscle that finds a broken automation in a client pipeline before the client notices. Most people would have rebooted the headphones and moved on.
What collina.js and fireyejs.js Actually Do
The Web Audio API lets a page synthesize and process sound in JavaScript. Fingerprinting vendors have used it for years. And Fingerprint.com’s own explainer describes why it works so well: the API’s internal processing chain varies slightly across hardware and software stacks. So the same mathematically generated signal comes out measurably different on your machine than on mine. Feed a known signal in, measure what comes back, hash the result. And you have an identifier that survives cookie clears because nothing was stored.
The source is generated by formula, so it is also stable across visits.
AliExpress’s scripts take that technique and run it constantly.
They build an audio graph at zero gain, which should mean silence. And connect it to the system destination, which is your actual audio output. The browser dutifully processes the graph regardless, and it does so even when you mute the tab. There is no player on the page and no speaker icon to click. One detail missing from every writeup so far: nobody has publicly attributed collina.js or fireyejs.js to a specific vendor or library. So you cannot yet tell which other sites run the same code.
Why It Kills Multipoint Switching
Multipoint handoff is driven by audio activity. The headphones hold two connections and switch to whichever device is actively producing sound.
A fingerprinting graph that never stops running tells your headphones that audio is permanently playing.
They stay locked to the connection running it and never yield to your phone, as from their side there is no silence to react to.
The crackle and the volume jumps are the graph’s constant activity leaking into the audible path instead of staying theoretical.
Your headphones are not malfunctioning. They are correctly reporting a signal that a script is generating for reasons that have nothing to do with you listening to anything.
The Permission Question Everyone Asked and Nobody Answered
The highest-engagement comment in the Hacker News discussion is a direct question: “Are you not required to grant an explicit permission for it to access audio?”
Here is the answer, and it is the part no ranking page bothers to give.
The web’s permission model gates audio input, not audio output.
Microphone and camera access go through getUserMedia prompts since they read your environment.
The Web Audio API was designed for synthesis and playback, so it was never given a gate at all. A zero-gain graph exploit sits precisely in that blind spot: it touches your audio pipeline. But from the browser’s perspective it is just a page making sounds. And pages have always been allowed to make sounds.
Consent banners do not save you either. A cookie banner governs cookies and tracking scripts it knows about. An audio graph created as a side effect of a page script runs before, after. And entirely outside that logic.
Commenters in the same thread pointed to eBay’s WebSocket port scanner and Reddit’s DRM and JIT abuse as the same pattern: scripts probing your machine beyond any remit the site owner would describe out loud.
You Ship What Your Scripts Ship
This is where it stops being an AliExpress story and becomes your story. Client sites carry third-party scripts from tag managers, analytics stacks, chat widgets. And ad vendors, and almost none of them are code anyone on the deploying team has read. They are inherited, not chosen.
If one of them spins up an AudioContext tomorrow, the site owner will find out from a customer’s bug report, same as everyone else.
The audit is cheap and you should run it this week. Load the page, open DevTools, and inventory every script the Network tab pulls in on a cold load. Search your bundle and your tags for AudioContext usage. If a script creates one and connects it to the destination while the page has no player anywhere on it, you have a question for a vendor.
And you want to ask it before a client’s customer finds it for you.
One adjacent note for the automation crowd: the popular AliExpress scraping guides promise to simulate realistic browser fingerprints. And none of the ones ranking right now mention the audio check at all. If you are building scraping or agentic browsing workflows, silent side-channel checks like this are exactly the kind of thing that fails your run with no error message.
The Fix Works on Desktop and Stops There
On desktop, the remedy is uBlock Origin blocking requests to collina.js and fireyejs.js. And the writeup reports headphone switching went back to normal afterward. That is the entire verified fix.
Here is the honest gap: the reported symptoms came through iOS and VoiceOver. And no coverage I can find addresses Safari content blockers, iOS, or the AliExpress app.
I am not going to invent an iOS workaround that has not been documented. Until one exists, the mobile answer is that you do not have a good one.
And that is worth saying plainly.
Browsers process silent audio with no indicator and no permission, and pages you trust run code you never approved. Block what you can, and audit what you ship.
