Come estrarre la mappa di rilevamento del sito: troviamo da soli gli script fingerprint

```html

Il 20 agosto 2026, lo sviluppatore Matt Callaghan (blog laserphile) ha pubblicato un'analisi di un strano bug: le sue cuffie Bluetooth con multipoint smettevano di passare dal computer al telefono. Ogni volta che era aperta la scheda di AliExpress. Non ha indovinato — ha strumentato le API del browser e ha guardato cosa succedeva all'interno della pagina. Si è scoperto che due script offuscati dello stack anti-frode di Alibaba sollevavano un contesto audio e tracciavano l'impronta del dispositivo attraverso un suono che nessuno sente.

Questa è un'illustrazione perfetta di ciò che quasi nessuno fa prima di configurare i profili o avviare un parser: non legge lo stack di rilevamento della piattaforma, ma lo indovina. Di seguito è riportato un metodo pratico su come creare una mappa di rilevamento di un sito specifico con le proprie mani, in un'ora, senza fare reverse engineering dell'offuscamento e senza servizi a pagamento.

Perché creare una mappa di rilevamento

Un ciclo tipico appare così: gli account vengono bannati — giriamo le impostazioni del browser anti-detect a caso — cambiamo proxy — di nuovo bannati. Tra "bannati" e "impostazioni" non ci sono dati: non è chiaro cosa legga esattamente la piattaforma e a quale livello venga catturato.

La mappa di rilevamento colma questo divario. È un elenco: quale vendor di protezione è in uso, quali script lo implementano, quali API toccano e dove va a finire il risultato. Diventa quindi chiaro dove si trova davvero il collo di bottiglia — nell'IP, nell'impronta di rete o nel layer hardware del browser. È ugualmente utile per tre pubblici:

• Multi-accounting — capire quale segnale unisce i profili. Gli IP sono diversi, ma lo stack audio, il renderer WebGL e hardwareConcurrency sono spesso identici per tutta la farm.
• Scraping — capire se vale la pena avviare il browser o se il compito può essere risolto da un client HTTP con un'impronta TLS corretta.
• Privacy — vedere cosa raccoglie esattamente il negozio o il servizio sul tuo dispositivo oltre ai cookie.

Passo 1. Determinare il vendor di protezione tramite rete

La prima cosa da fare è aprire DevTools nella scheda Network, caricare la pagina e controllare le intestazioni e i cookie del primo documento. I segni distintivi sono noti e stabili:

• CF-RAY nelle intestazioni della risposta e cookie cf_clearance — Cloudflare.
• Cookie _abck e script con la funzione bmak — Akamai Bot Manager.
• Variabili e cookie con il prefisso _px — PerimeterX (HUMAN).
• Cookie datadome e un JS separato dal dominio del vendor — DataDome.
• Un 429 vuoto senza corpo della risposta — firma caratteristica di Kasada.

Se non hai voglia di farlo manualmente, ci sono rilevatori aperti come microlinkhq/is-antibot (30+ provider) e estensioni del browser per rilevatori su 26+ vendor. Forniscono una risposta rapida iniziale, ma non rispondono alla domanda principale: cosa viene effettivamente misurato nel tuo browser. Per questo bisogna andare oltre.

Passo 2. Estrarre l'elenco degli script sospetti

Filtra la rete per tipo JS e annota tutto ciò che viene caricato non dal dominio principale o si trova in directory di servizio. Nel caso di AliExpress, si trattava di due file con percorsi chiaramente di servizio:

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

Segni di uno script anti-frode: codice offuscato, versione nel percorso, sottodominio separato per la statica, assenza di qualsiasi connessione con la parte visiva della pagina. Non è necessario aprire e leggere l'offuscamento — nel passo successivo lo script parlerà da solo.

Passo 3. Strumentare l'API di fingerprinting

Questo è il nucleo del metodo ed è esattamente ciò che ha fatto Callaghan: ha avvolto il costruttore AudioContext e AudioNode.prototype.connect(), dopo di che ha visto due contesti audio attivi sulla pagina, dove non c'era alcun elemento multimediale e nessuna chiamata a play().

La logica è semplice: si sostituisce il metodo di interesse con il proprio wrapper, che registra la chiamata con lo stack e passa il controllo all'originale. Lo stack delle chiamate mostra quale script ha effettivamente chiamato l'API. È più comodo inserire un tale snippet attraverso DevTools Sources → Snippets o tramite un'estensione che esegue codice all'inizio del documento — è importante farlo prima che lo script anti-frode venga caricato.

Un insieme minimo di trappole che copre la maggior parte dei segnali:

1. HTMLCanvasElement.prototype.toDataURL e getImageData — impronta del canvas.
2. WebGLRenderingContext.prototype.getParameter — modello della scheda video e driver, precisione degli shader.
3. AudioContext / OfflineAudioContext e AudioNode.prototype.connect — impronta audio.
4. Getter navigator.hardwareConcurrency, navigator.deviceMemory, navigator.plugins, navigator.webdriver.
5. RTCPeerConnection — WebRTC e indirizzi locali.
6. screen.width/height, devicePixelRatio, Intl.DateTimeFormat().resolvedOptions() — schermo e fuso orario.
7. navigator.mediaDevices.enumerateDevices — elenco di dispositivi audio e video.

Alla fine dell'esecuzione avrai un elenco: quali di queste API sono state effettivamente chiamate, quante volte e da chi. Nel caso analizzato, gli script di Alibaba toccavano il canvas e toDataURL, il renderer WebGL e la precisione degli shader, audio tramite oscillatore e analizzatore, dimensioni dello schermo e devicePixelRatio, hardwareConcurrency e deviceMemory, plugin, supporto per codec, WebRTC, tempistiche delle prestazioni, schemi di movimento del mouse e tocchi, sensori di movimento del dispositivo e indicatori di automazione.

Cosa facevano esattamente con il grafo audio

È utile capire come appare la misurazione, per riconoscerla in altri luoghi. Il grafo era il seguente: oscillatore a dente di sega → AnalyserNode → ScriptProcessorNode, che legge il risultato dell'analisi → GainNode con guadagno zero → destination. Non c'è suono, il volume non conta — semplicemente non esiste. Ma la connessione a destination, secondo la formulazione dell'autore, costringe il browser a elaborare attivamente il grafo, anche se il volume finale è zero. È proprio il percorso audio attivo che ha mantenuto aperto il percorso Bluetooth, rompendo il passaggio multipoint delle cuffie.

Le differenze nel trattamento di questo segnale dipendono dal processore, dall'hardware audio, dal sistema operativo, dal browser e dai driver — da qui l'identificatore stabile, che sopravvive al cambio di IP e alla pulizia dei cookie. Un'analisi dettagliata di questo layer e la configurazione dei profili per esso — nell'articolo sulla protezione contro l'Audio Context Fingerprinting.

Passo 4. Catturare l'invio del risultato

Raccogliere senza inviare è privo di senso, quindi il passo successivo è trovare dove va a finire l'impronta raccolta. Filtra la rete per XHR/Fetch e guarda separatamente le richieste di tipo ping — queste sono generate da navigator.sendBeacon, che gli script di telemetria amano usare, perché sopravvive all'uscita dalla pagina.

È praticamente sempre utile avvolgere ulteriormente fetch, XMLHttpRequest.prototype.send e navigator.sendBeacon — in questo modo vedrai il corpo della richiesta prima che parta. Preparati al fatto che il contenuto sarà serializzato e crittografato: nel caso di AliExpress, i dati venivano crittografati prima di essere inviati alla telemetria di Alibaba. Ma anche così ottieni due fatti: l'indirizzo del destinatario e il momento dell'invio rispetto alle tue azioni.

Se il sito funziona non solo nel browser, ma anche tramite un'app mobile o un client separato, la stessa questione viene risolta a livello di traffico, non di DOM — la metodologia di intercettazione e analisi è descritta nell'analisi dell'audit del traffico tramite mitmproxy.

Passo 5. Confrontare la mappa con il proprio profilo

Ora hai un elenco di segnali che la piattaforma legge realmente. Resta da verificare cosa restituisce il tuo profilo di lavoro per questi segnali. L'ordine è il seguente: prendi i valori in un browser normale, poi in ciascun profilo anti-detect e confrontali.

Due cose sono importanti contemporaneamente: i valori devono differire tra i profili e essere stabili all'interno di un singolo profilo tra le sessioni. Un profilo il cui impronta salta ad ogni avvio appare per l'anti-frode non meno sospetto di dieci profili con impronte identiche.

Controlla separatamente che la sostituzione esista effettivamente nel layer necessario. Qui è indicativa la dispersione tra i browser: Firefox dalla versione 118 restituisce un output costante di WebAudio, e secondo i dati analizzati il 99,24% degli utenti si riduce a tre valori; Brave inserisce dati casuali e dal 22 agosto 2026 blocca specificamente questi script di AliExpress, ricordando che la protezione contro l'audio-fingerprinting è attiva di default da oltre sei anni; Safari introduce errori nei buffer audio; Chrome non ha protezioni aggressive.

Insidie

• Lo script ha già avuto effetto. Il blocco del file non elimina un contesto audio già creato — l'autore sottolinea esplicitamente che le schede aperte devono essere chiuse. Lo stesso vale per la tua strumentazione: se il wrapper è stato inserito dopo lo script, non vedrai nulla.
• Il blocco rompe la funzionalità. Lo stack anti-frode spesso risponde anche a cose legittime — autorizzazioni, pagamenti, protezione anti-bot contro abusi reali. Creare una mappa di rilevamento e rimuovere script sono compiti diversi; il secondo rompe il sito.
• Non c'è una sola versione di rilevamento. Lo stack può variare in base alla geolocalizzazione, al tipo di dispositivo e al gruppo A/B. Ha senso creare la mappa dall'IP e dal dispositivo da cui lavori realmente, altrimenti stai descrivendo una configurazione altrui.
• La strumentazione stessa viene rilevata. I metodi nativi ridefiniti perdono un corretto toString, e un debugger collegato lascia tracce. Per l'intelligence questo non è critico, ma non confondere un profilo di intelligence con uno operativo — le tecniche di mascheramento dell'automazione sono state analizzate nella guida su mascheramento del browser headless.

Quale proxy serve per il risultato

La principale conclusione pratica da una tale mappa è quasi sempre una: l'IP è solo il primo layer, e viene controllato prima di tutti gli altri. Se l'anti-frode vede già l'indirizzo di hosting nella fase di richiesta, non si arriverà mai al grafo audio e al canvas — riceverai una sfida o un output vuoto e riparerai la cosa sbagliata.

Quindi la logica di scelta è questa. Per le piattaforme con uno stack serio (Akamai, DataDome, PerimeterX, sviluppi propri a livello di Alibaba) la base sono proxy residenziali — indirizzi di veri provider, che non vengono filtrati al primo controllo. Per le app mobili e le piattaforme dove il pubblico principale utilizza smartphone, i proxy mobili si avvicinano di più al profilo naturale: il CGNAT dell'operatore rende l'indirizzo necessariamente condiviso tra molti utenti reali.

E viceversa: se la mappa ha mostrato che la piattaforma si limita a intestazioni e cookie, e non c'è un pesante fingerprinting JS, — una farm di browser è superflua, il compito può essere risolto con un normale client HTTP e indirizzi di data center.

Conclusione

Il caso delle cuffie è prezioso non tanto per il fatto stesso dell'audio-fingerprinting — di cui si sa da anni. È prezioso il metodo: la persona non ha creduto alle congetture, ma ha avvolto due metodi delle API del browser e in una sera ha ottenuto un elenco completo di ciò che viene raccolto da lui e l'indirizzo a cui va. La stessa tecnica richiede un'ora su qualsiasi piattaforma con cui lavori e sostituisce mesi di tentativi di impostazioni a caso. Crea una mappa di rilevamento prima di riparare i ban — altrimenti c'è il rischio di spendere il budget per proxy dove il problema era in un identico renderer WebGL su tutti i profili.