Silent browser APIs used for covert fingerprinting
AliExpress was discovered running WebAudio fingerprinting silently in the background, and the side effect was breaking users' Bluetooth multipoint connections because the API was triggering audio device initialization. This isn't theoretical privacy risk. It caused a real, reproducible hardware problem that users had to debug themselves.
The thread debate quickly landed on a concrete policy question: should audio playback APIs require explicit permission, like camera and microphone access already do? The current answer is no, and that's a gap that ad-tech and e-commerce platforms are exploiting. The concern isn't just AliExpress. Once one major retailer deploys a technique like this, others follow.
The deeper issue is that fingerprinting has moved well past cookies. Canvas, WebGL, WebAudio, font enumeration, and battery status APIs all leak identifying information with no user consent and no browser warning. Builders shipping web products should assume their users are being fingerprinted by third-party scripts on the same page, because they almost certainly are.
So what?
If you embed third-party scripts, analytics, or ad networks in your product, you are likely participating in fingerprinting your users whether you know it or not. Audit what you load. For founders building privacy-forward products, this is an opening: WebAudio permission gating and fingerprinting protection are coming, and getting ahead of that is a real differentiator.