AliExpress: fingerprinting tramite l’API Web Audio

Si apre un negozio online e all’improvviso la musica sullo smartphone si interrompe. Nel browser non è in riproduzione alcun video, non si sente nessuna pubblicità e neppure disattivare l’audio della scheda cambia qualcosa. Solo chiudendo la scheda di AliExpress le cuffie Bluetooth tornano a passare correttamente al telefono.

Quello che sembrava un problema di Bluetooth Multipoint ha condotto lo sviluppatore Matt Callaghan a due file JavaScript fortemente offuscati nella homepage di AliExpress. Entrambi creavano in background un grafo Web Audio che restava attivo. Il livello in uscita era zero, quindi non si sentiva nulla. Per browser, sistema operativo e cuffie, però, il percorso audio rimaneva attivo.

La scoperta è tecnicamente affascinante perché un effetto collaterale involontario dell’hardware ha rivelato una misurazione invisibile del browser. Dal punto di vista della sicurezza è ancora più interessante, perché Web Audio era solo un componente. Gli script controllavano anche Canvas, WebGL, schermo, hardware, formati multimediali supportati, WebRTC e interazioni dell’utente. Il risultato appare come un’impronta completa del browser e del dispositivo.

Il problema Bluetooth che non era un problema Bluetooth

Callaghan usa cuffie Multipoint collegate contemporaneamente al PC e allo smartphone. Normalmente ascolta musica dal telefono. Quando il PC riproduce davvero dell’audio, prende il controllo. Questo cambio di priorità ha iniziato a bloccarsi quando AliExpress era aperto in Firefox o Chrome. Non ha provato altri browser.

I sospetti abituali sono stati esclusi. Non c’erano elementi audio o video, chiamate a HTMLMediaElement.play(), Media Session attive o file multimediali riconoscibili nel traffico di rete. L’unica anomalia era che il disturbo iniziava alcuni secondi dopo il caricamento della pagina.

Callaghan ha quindi strumentato l’API Web Audio. Ha sostituito il costruttore di AudioContext con un wrapper, registrato i nuovi contesti audio e monitorato le connessioni tramite AudioNode.connect(). Sono comparsi due contesti attivi, le cui stack trace puntavano a questi script:

assets.aliexpress-media.com/g/AWSC/uab/1.140.0/collina.js
assets.aliexpress-media.com/g/AWSC/fireyejs/1.231.67/fireyejs.js

Entrambi si trovavano sotto un percorso AWSC e, per le loro funzioni, sembravano far parte di un’infrastruttura Alibaba dedicata alla sicurezza del browser e al rilevamento degli abusi. L’attribuzione è plausibile, ma i soli nomi dei file non la dimostrano in modo definitivo. Alibaba Cloud documenta però esplicitamente, per il proprio Anti-Bot Web SDK, un web collector utilizzato insieme a una valutazione lato server.

Il comportamento è stato circoscritto ulteriormente: dopo aver bloccato entrambe le famiglie di script, nella misurazione di controllo di Callaghan non sono stati creati né i contesti audio né i collegamenti all’uscita. La homepage e la normale ricerca dei prodotti hanno continuato a funzionare nel suo test.

Che cosa fa esattamente il grafo Web Audio

Web Audio non è una funzione nascosta di intercettazione, ma una potente interfaccia del browser per giochi, sintetizzatori, videoconferenze e altre applicazioni interattive. Invece di limitarsi a riprodurre un file audio, un sito può collegare singoli nodi di elaborazione formando un grafo.

In forma semplificata, gli script AliExpress analizzati costruivano questa catena:

OscillatorNode con onda a dente di sega
  -> AnalyserNode
  -> ScriptProcessorNode
  -> GainNode con guadagno 0
  -> AudioContext.destination

L’oscillatore genera un segnale noto. L’AnalyserNode mette a disposizione i dati dell’elaborazione e JavaScript legge i valori di frequenza. Il GainNode porta poi il livello a zero. Il segnale non è quindi udibile, ma il grafo resta collegato a AudioContext.destination e dunque all’uscita in tempo reale.

È proprio questo collegamento a spiegare l’effetto collaterale. Volume zero non significa elaborazione zero. Il browser continua a calcolare il grafo e, sul sistema Windows di Callaghan, questo è apparentemente bastato a mantenere attivo il percorso audio del PC. La commutazione automatica Multipoint ha quindi continuato a considerare il PC una sorgente attiva.

Per una misurazione puramente computazionale sarebbe stato più logico un OfflineAudioContext. Questo renderizza un grafo direttamente in un buffer di memoria senza inviarlo agli altoparlanti o al dispositivo audio del sistema. Nel grafo AliExpress, inoltre, l’oscillatore e l’analisi precedono l’uscita impostata a zero. Il collegamento con l’uscita live non offriva un vantaggio riconoscibile per i dati di frequenza già letti, ma provocava l’effetto visibile.

Mozilla aveva registrato lo stesso effetto già nel 2023

Nel 2026 le cuffie di Callaghan hanno fornito l’indizio che ha attirato l’attenzione pubblica. Tuttavia, Mozilla aveva già registrato l’effetto di base nel novembre 2023 come Bug 1863193. Il rapporto originale su Firefox 119 descriveva pagine AliExpress che, in Windows 11, causavano una richiesta permanente di alimentazione audio. powercfg /requests segnalava uno stream attivo anche se la scheda non mostrava alcuna riproduzione. Il computer non entrava più automaticamente in sospensione. Chiudendo la scheda, la richiesta scompariva.

Lo sviluppatore Mozilla Karl Tomlinson ha quindi attivato il logging di Web Audio. Il log mostrava due volte esattamente la catena descritta in seguito da Callaghan: OscillatorNode, AnalyserNode, ScriptProcessorNode, un GainNode silenziato e AudioDestinationNode. Tomlinson ha osservato un uso permanente simile del dispositivo in Chrome e ha annotato che AliExpress avrebbe potuto interromperlo con AudioContext.suspend().

È una conferma indipendente importante. L’effetto collaterale hardware non si basa soltanto sull’interpretazione di Callaghan di uno script offuscato. Anni prima, Mozilla aveva registrato direttamente nel browser il grafo attivo e il suo impatto sulla gestione energetica di Windows. Il bug è ancora aperto. Mostra anche una responsabilità condivisa: AliExpress avrebbe potuto sospendere il contesto dopo la misurazione, mentre il browser potrebbe scollegare prima dal dispositivo un grafo effettivamente muto e non più necessario.

Nessun microfono e nessun ultrasuono nella stanza

Qui è importante usare termini precisi. In questo test AliExpress non ha registrato il microfono né ascoltato suoni nell’ambiente. L’accesso al microfono passerebbe da getUserMedia() e richiederebbe l’autorizzazione dell’utente.

È altrettanto fuorviante immaginare che il negozio abbia emesso un segnale ultrasonico dagli altoparlanti per poi catturarlo fisicamente. La misurazione avveniva all’interno dell’elaborazione audio del browser. L’onda a dente di sega veniva calcolata, analizzata e portata a zero prima dell’uscita. L’effetto sulle cuffie nasceva perché il grafo virtuale restava comunque collegato all’uscita reale.

Perché calcoli identici possono produrre risultati diversi

L’elaborazione digitale dei segnali comprende molte operazioni in virgola mobile. Architettura della CPU, librerie matematiche, decisioni del compilatore, implementazione del browser e arrotondamenti possono generare piccole differenze. Lo standard Web Audio cita esplicitamente OscillatorNode, DynamicsCompressorNode, frequenza di campionamento, latenza e misure temporali come possibili superfici di fingerprinting. I browser dovrebbero quindi limitare tali differenze.

Un risultato Web Audio non è però un numero di serie magico dell’hardware. Più dispositivi possono restituire lo stesso valore e un browser può uniformare o modificare i risultati. La riconoscibilità aumenta solo quando il dato viene combinato con altre caratteristiche.

La tecnica è in uso almeno dal 2016

Il fingerprinting audio non è una nuova scoperta del 2026. Steven Englehardt e Arvind Narayanan hanno esaminato un milione di siti nello studio OpenWPM pubblicato all’ACM CCS nel 2016. Hanno trovato fingerprinting tramite AudioContext in tre script presenti complessivamente su 67 siti. Secondo la loro analisi manuale, due script utilizzavano davvero la tecnica in modo attivo.

Anche in quel caso un oscillatore generava un segnale noto che veniva elaborato, letto e trasformato in hash. Una delle varianti documentate conduceva il grafo attraverso un AnalyserNode, un ScriptProcessorNode e un GainNode muto fino all’uscita. La struttura è sorprendentemente simile al modello AliExpress. I ricercatori di Princeton sottolineavano già che non serve un microfono e che le tecniche di fingerprinting vengono solitamente combinate.

La novità del caso AliExpress non è quindi l’idea di base. È il ritrovamento concreto su uno dei maggiori marketplace online, l’ampia combinazione di altre caratteristiche e soprattutto il canale laterale che ha reso visibile la misurazione.

Il valore audio era solo un pezzo del puzzle

Nei bundle esaminati, Callaghan ha trovato richieste e misurazioni relative a molti altri attributi:

• rendering Canvas e toDataURL()
• renderer WebGL, estensioni e precisione degli shader
• dimensioni di schermo e viewport, oltre a Device Pixel Ratio
• hardwareConcurrency e deviceMemory
• plugin installati e formati multimediali supportati
• comportamento WebRTC e performance timing
• eventi di mouse, touch, focus e scorrimento
• movimento e orientamento del dispositivo
• proprietà che possono indicare automazione del browser o bot

Il codice conteneva inoltre routine per serializzare e cifrare i risultati e per trasmetterli tramite fetch() o sendBeacon(). Sul lato client è quindi dimostrato che una vasta quantità di dati adatti al fingerprinting può essere raccolta e inviata ai servizi Alibaba.

Non è dimostrato che cosa accada lato server. Dal browser non si possono conoscere né il periodo di conservazione né eventuali collegamenti successivi con account, ordini, altri servizi Alibaba o profili pubblicitari. Callaghan dichiara esplicitamente questo limite.

Nella propria informativa sulla privacy, AliExpress menziona dati di browser e sistema operativo, caratteristiche hardware e software, identificatori univoci del dispositivo, modelli di utilizzo e interazioni. Tra le finalità cita, oltre al funzionamento e alla personalizzazione, anche il rilevamento di frodi, riciclaggio e incidenti di sicurezza. L’informativa non rende trasparente l’implementazione tecnica osservata, ma mostra che dati estesi su dispositivo e utilizzo fanno parte del modello descritto.

Fingerprinting non significa automaticamente tracciamento pubblicitario

Le impronte del browser vengono usate in contesti molto diversi. Le reti pubblicitarie possono riconoscere un browser anche dopo la cancellazione dei cookie. Negozi online e servizi di pagamento impiegano segnali simili anche per valutazione del rischio, compromissione degli account, abuso di coupon, scraping, bot o acquisti automatizzati.

Le due finalità non si escludono. Lo stesso identificatore può servire contemporaneamente interessi di sicurezza e marketing. Tuttavia, il JavaScript trovato non dimostra una specifica campagna pubblicitaria cross-site. Affermare direttamente che “AliExpress traccia ogni utente su tutti i siti” va oltre le prove disponibili.

Per la valutazione di sicurezza, il caso resta comunque problematico:

• La misurazione iniziava già sulla homepage generale, non soltanto durante login o pagamento.
• Gli script erano fortemente offuscati e praticamente incomprensibili per gli utenti.
• La raccolta comprendeva molto più di un singolo segnale antibot.
• Il grafo audio attivo non era indicato in modo utile nell’interfaccia e non terminava silenziando la scheda.
• Una funzione in background interveniva così profondamente nel percorso audio locale da modificare il comportamento di hardware esterno.

Una comprensibile difesa dalle frodi non richiede necessariamente di pubblicare una guida all’implementazione. Richiede però minimizzazione dei dati, una finalità chiaramente delimitata e un’interfaccia il cui comportamento non contraddica le aspettative dell’utente. Una scheda silenziosa di un negozio non dovrebbe occupare un percorso audio in tempo reale.

Quanto era davvero univoca questa impronta audio?

Lo sviluppatore Firefox Tom Ritter ha estratto il calcolo Web Audio in questione e lo ha confrontato con dati di telemetria di Firefox. Il risultato ridimensiona notevolmente le rappresentazioni allarmistiche.

Da Firefox 118, Web Audio utilizza su tutte le piattaforme la libreria matematica FDLIBM per ridurre le differenze dipendenti dal sistema. Nell’analisi di Ritter, il 99,24% degli utenti ricadeva in soli tre valori. Per un ulteriore 0,76% il punto di misurazione falliva e restituiva zero. I tre grandi gruppi corrispondevano essenzialmente a classi di CPU: x86 o x64 senza FMA, x64 con FMA e ARM con NEON.

Per lo specifico metodo AliExpress, ciò significa che in Firefox il valore audio non era individuale per quasi tutti gli utenti esaminati. Indicava più una classe generale di processore che un singolo dispositivo. Rimaneva però una piccola coda lunga con altri valori, e proprio i valori rari possono rendere più riconoscibili i sistemi interessati.

Il fingerprinting lavora con combinazioni. Dimensioni dello schermo, fuso orario o classe di CPU sono spesso banali da soli. Canvas, WebGL, font, dati hardware, caratteristiche del browser, modelli di interazione e un login esistente possono insieme essere molto più discriminanti. Il valore Web Audio non deve quindi essere univoco per restare utile nel punteggio complessivo.

La protezione del browser è una corsa agli armamenti con effetti collaterali

I browser adottano strategie diverse. Firefox uniforma determinati calcoli e blocca servizi di fingerprinting noti. Da Firefox 145, protezioni più estese sono inizialmente attive in modalità privata e con la protezione antitracciamento avanzata impostata su Rigida. Mozilla stessa sottolinea che un’uniformazione più aggressiva può rompere funzioni legittime.

Brave modifica leggermente i risultati adatti al fingerprinting, come i valori Canvas e Web Audio. Questo cosiddetto Farbling resta stabile all’interno di una sessione e di un sito, ma dovrebbe produrre risultati differenti tra siti e sessioni. L’applicazione continua così a ricevere valori plausibili, ma può usarli con maggiore difficoltà come identificatore globale persistente.

WebKit limita in Safari varie superfici di fingerprinting, tra cui i font installati localmente e certe informazioni sul dispositivo. Per interfacce particolarmente rischiose, WebKit talvolta rinuncia del tutto all’implementazione finché non esiste una soluzione considerata sicura. Questo mostra il conflitto fondamentale: le stesse interfacce che consentono applicazioni web complesse ampliano anche la superficie di misurazione del browser.

Nessun browser normale può garantire che ogni forma di fingerprinting scompaia. Quando un attributo viene uniformato, i fornitori passano ad altri attributi o segnali comportamentali. E una combinazione particolarmente insolita di estensioni, font e protezioni manuali può, nel peggiore dei casi, rendere il browser ancora più raro.

Che cosa possono fare concretamente gli utenti

La base migliore è un browser aggiornato con protezione anti-fingerprinting attiva. In Firefox, il livello più avanzato richiede la protezione antitracciamento avanzata in modalità Rigida o una finestra privata. Brave abilita per impostazione predefinita Shields e la difesa dal fingerprinting. In Safari vanno usate le versioni aggiornate del sistema e del browser. Tor Browser e Mullvad Browser si spingono oltre per le sessioni sensibili: cercano di far apparire più utenti possibile nello stesso gruppo con un’impronta simile. Proprio lì non andrebbero aggiunte personalizzazioni o estensioni.

Le finestre private da sole non sono una risposta completa. Limitano lo stato memorizzato, ma non rendono automaticamente invisibili le caratteristiche di hardware e browser. Anche eliminare i cookie non reimposta un’impronta nello stesso modo in cui elimina un ID cookie.

Una VPN risolve un altro problema. Sostituisce l’indirizzo IP pubblico visibile e, a seconda dell’uso, protegge il trasporto fino al provider VPN. Non modifica però automaticamente Canvas, WebGL, calcoli audio, font o caratteristiche hardware. Una VPN può quindi essere utile, ma da sola non protegge dal fingerprinting del browser.

Bloccare in modo mirato i due script con uBlock Origin

Callaghan ha pubblicato due filtri volutamente specifici per uBlock Origin:

! 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

Dopo averli inseriti in I miei filtri, occorre chiudere le schede AliExpress già aperte. Bloccare successivamente uno script non termina un contesto audio che è già stato creato.

Queste regole sono un’istantanea. Percorsi, versioni e nomi possono cambiare. Poiché gli script appartengono probabilmente all’infrastruttura antibot e di valutazione del rischio, possono anche comparire CAPTCHA aggiuntivi o problemi con accesso e checkout. Chi non riesce a completare una transazione legittima può disattivare temporaneamente la regola soltanto per quell’operazione e poi chiudere nuovamente la scheda.

Bloccare l’intero host assets.aliexpress-media.com a livello DNS sarebbe molto più grossolano. Potrebbero trovarsi lì altre risorse del negozio. Una regola URL ristretta è quindi più controllabile di un blocco generale del dominio.

Disattivare completamente JavaScript è raramente pratico

Senza JavaScript questa misurazione non può funzionare. I negozi moderni diventano però quasi inutilizzabili. Una disattivazione globale crea inoltre uno stato insolito del browser e non sostituisce una corretta separazione di account, profili e attività sensibili.

Per ricerche particolarmente delicate può essere utile un browser separato e modificato il meno possibile. Questo limita il collegamento con il profilo quotidiano, ma non garantisce l’anonimato. Indirizzo IP, login, dati di pagamento e segnali lato server restano invariati.

La questione giuridica va oltre i cookie

In Europa, “senza cookie” non significa “senza consenso”. Le Linee guida definitive 2/2023 del Comitato europeo per la protezione dei dati interpretano volutamente l’ambito tecnico dell’articolo 5, paragrafo 3, della direttiva ePrivacy in modo più ampio dei cookie classici. Può essere rilevante anche l’accesso a informazioni memorizzate nel terminale o generate lì da software e hardware.

La liceità della concreta implementazione AliExpress in un singolo caso dipende, tra l’altro, dallo scopo effettivo, dalla necessità, dall’attuazione regionale delle norme ePrivacy, dalla trasparenza e dal trattamento successivo. La lotta alle frodi può essere una finalità legittima. Questo però non stabilisce automaticamente se ogni caratteristica raccolta sulla homepage sia necessaria per tale scopo o se occorra un consenso.

Questo articolo non sostituisce una valutazione legale. Sul piano tecnico, tuttavia, il caso mostra perché i banner dei cookie non rappresentano completamente la realtà dell’identificazione moderna. Un utente può rifiutare tutti i cookie di marketing visibili e venire comunque misurato da JavaScript first-party.

Base del test e limiti

Ho verificato l’analisi tecnica, le informazioni dei browser e le politiche pubblicamente disponibili l’ultima volta il 31 agosto 2026. La scoperta concreta su AliExpress si basa sul test documentato da Callaghan in Windows con Firefox e Chrome e sulla sua strumentazione dell’API Web Audio. A ciò si aggiungono il bug report indipendente di Mozilla, l’analisi di Ritter del metodo audio estratto, la ricerca OpenWPM e la documentazione primaria di W3C, Mozilla, Brave, WebKit, Alibaba Cloud, AliExpress ed EDPB.

Durante il mio controllo, i due URL versionati degli script indicati da Callaghan rispondevano ancora con HTTP 200 e il tipo application/javascript. Non ho tuttavia eseguito personalmente gli script su un account AliExpress controllato né riprodotto l’effetto Bluetooth con le mie cuffie. Altri sistemi operativi, browser, regioni, test A/B o versioni degli script modificate nel frattempo possono comportarsi diversamente. Archiviazione lato server, scoring, collegamento delle identità e utilizzo dei valori trasmessi non erano visibili e non costituiscono quindi osservazioni dirette di questo articolo.

La mia conclusione

Il caso non dimostra una sorveglianza ultrasonica segreta e nemmeno che un singolo valore audio identifichi in modo univoco ogni computer. Dimostra però molto bene quanto ampiamente i siti moderni possano usare il browser come strumento di misurazione senza che gli utenti vedano nulla.

La spiegazione antifrode è tecnicamente credibile. Un grande marketplace deve combattere bot, compromissioni di account, frodi nei pagamenti e abuso di coupon. Questo non giustifica automaticamente qualsiasi misurazione in ogni punto del percorso del cliente. Chi raccoglie già dalla homepage caratteristiche audio, grafiche, hardware, WebRTC e comportamentali deve rispondere a domande su necessità, trasparenza ed effetti collaterali.

Alla fine, non è stata una dashboard sulla privacy a rendere visibile la misurazione. È stato un paio di cuffie Bluetooth che si è rifiutato di fingere che il browser fosse silenzioso.

Alla prossima,
Joe