Indice dei Contenuti
- La divisione fondamentale: livello di rete vs livello del browser
- Cosa nasconde una VPN in un contesto browser
- Cosa una VPN non tocca: la superficie del fingerprint
- WebRTC: la perdita IP che bypassa il tuo tunnel
- DNS: il secondo vettore di perdita
- Quale VPN completa meglio il rafforzamento del browser
- ProtonVPN: scelta pragmatica, limitazioni oneste
- Costruire lo stack completo
La divisione fondamentale: livello di rete vs livello del browser
La maggior parte del marketing VPN confonde due superfici di minaccia distinte come se fossero una sola. Non lo sono.
Il livello di rete è ciò che una VPN affronta: quale indirizzo IP vedono i server di destinazione, se il tuo ISP può osservare le destinazioni del traffico, se un osservatore di rete passivo può leggere i payload non crittografati. Una VPN competente risolve adeguatamente tutti questi aspetti.
Il livello del browser è ortogonale: riguarda ciò che JavaScript in esecuzione nella pagina può estrarre sul tuo dispositivo tramite le API del browser — output di rendering del canvas, stringhe del renderer WebGL, temporizzazione AudioContext, enumerazione dei font installati, dimensioni dello schermo, concorrenza hardware, memoria del dispositivo, navigator.userAgent e molte altre decine di segnali. Una VPN non ha alcun effetto su nessuno di questi. Il browser li riporta direttamente; il routing del tunnel è irrilevante.
Comprendere questa divisione è il prerequisito per costruire una privacy efficace. Confonderli porta all'errore comune di pensare che un abbonamento VPN costituisca una postura di privacy completa. Gestisce un livello. L'altro richiede strumenti separati.
Il nostro stato dell'arte del fingerprinting del browser 2026 copre la tassonomia completa dei vettori di fingerprinting e delle misurazioni di entropia. Questo articolo si concentra sull'intersezione: cosa aggiunge (e non aggiunge) una VPN a uno stack di privacy del browser e quale VPN è più adatta a completare la resistenza attiva al fingerprint.
Cosa nasconde una VPN in un contesto browser
Quando instradi il traffico del browser attraverso una VPN, tre cose cambiano concretamente:
1. Il tuo indirizzo IP al server di destinazione. I server HTTP registrano l'IP di connessione. Senza una VPN, questo è il tuo vero IP pubblico — un IP residenziale legato al tuo account ISP, o un IP di un operatore mobile con precisione di localizzazione approssimativa. Con una VPN, il server vede un IP di nodo di uscita VPN condiviso utilizzato da potenzialmente migliaia di utenti simultanei. Questo riduce la geolocalizzazione basata su IP al livello della città al massimo ed elimina la correlazione diretta con l'ISP.
2. Il tuo indirizzo IP al resolver DNS. Se la tua VPN instrada il DNS all'interno del tunnel (tutti e tre i provider recensiti qui lo fanno correttamente), il tuo vero IP non è visibile al resolver. Per la maggior parte degli utenti il cui DNS si risolve contro il resolver predefinito del loro ISP, questo rimuove un punto dati significativo. Nota: se il browser esegue DNS-over-HTTPS (DoH) verso un resolver esterno al di fuori del tunnel, il resolver vede ancora il tuo vero IP. Configura DoH tramite il resolver della tua VPN o disabilitalo per lasciare che il resolver del sistema operativo (all'interno del tunnel) lo gestisca.
3. Destinazioni del traffico dal tuo ISP. Il tuo ISP può vedere che stai inviando traffico crittografato a un server VPN. Non può vedere quali siti stai visitando, quanto tempo trascorri su di essi o la suddivisione del volume per destinazione. Per il brokeraggio dei dati a livello di ISP — una vera minaccia negli Stati Uniti sotto le attuali regole FCC — una VPN è una mitigazione legittima.
Queste sono protezioni significative. Non sono protezioni contro il fingerprint.
Cosa una VPN non tocca: la superficie del fingerprint
La superficie del fingerprint è l'insieme di attributi che JavaScript può estrarre dalle API del browser senza permessi elevati. Una descrizione dettagliata è disponibile nella nostra guida al fingerprinting. I segnali ad alta entropia che dominano il fingerprinting nel mondo reale sono:
Hash di rendering del canvas. Il browser disegna un canvas nascosto con una stringa e un'immagine specificate, quindi legge l'array di pixel. Le variazioni nella pipeline GPU, nel renderer dei font, nella modalità AA e nella versione del driver producono un hash coerente per dispositivo. Il routing VPN non influisce sull'hardware GPU, sul rendering dei font o sul comportamento del driver. L'hash del canvas è identico con o senza VPN attiva.
Stringhe del renderer e del vendor WebGL. gl.getParameter(gl.RENDERER) restituisce una stringa che identifica il modello della tua GPU e la versione del driver. Su Chrome/Chromium, questo di solito non è offuscato. Su Firefox, può essere sovrascritto. VPN: nessun effetto.
Fingerprint AudioContext. Viene creato un nodo oscillatore, elaborato attraverso un nodo di guadagno, e i valori in virgola mobile accumulati vengono hashati. La variazione deriva dalle differenze nell'hardware di elaborazione audio e nell'implementazione del driver. Nessun routing di rete coinvolto.
Geometria dello schermo e rapporto pixel del dispositivo. window.screen.width, window.screen.height, window.devicePixelRatio. Questi dipendono dal tuo monitor e dalle impostazioni di visualizzazione. Un monitor 4K con 2x DPR riporta valori coerenti indipendentemente dal percorso di rete.
Campi del Navigator. navigator.hardwareConcurrency (numero di core CPU), navigator.deviceMemory (bucket RAM), navigator.platform, navigator.language. Questi sono proprietà hardware e del sistema operativo.
Enumerazione dei font. Il probing dei font basato su CSS (misurando le dimensioni del testo reso con font specifici) o l'approccio più vecchio document.fonts può rilevare quali font sono installati. Il tuo set di font è una funzione del tuo sistema operativo, dei pacchetti linguistici e delle applicazioni installate. Non è una proprietà di rete.
L'entropia combinata di questi segnali è abbastanza alta da rendere la maggior parte delle sessioni del browser nel mondo reale unicamente identificabili attraverso sessioni VPN, modalità incognito e persino cambiamenti di indirizzo IP. Un'analisi EFF del 2025 ha rilevato che canvas + WebGL + AudioContext da soli hanno prodotto >18 bit di entropia in un pannello di 50.000 sessioni — più che sufficiente per re-identificare la maggior parte dei browser nel tempo.
WebRTC: la perdita IP che bypassa il tuo tunnel
WebRTC (Web Real-Time Communication) è l'API del browser che alimenta le videochiamate nel browser, il trasferimento di file P2P e i giochi in tempo reale. Il suo meccanismo ICE (Interactive Connectivity Establishment) funziona raccogliendo tutte le interfacce di rete disponibili per trovare il percorso di connessione ottimale. Questo include l'interfaccia virtuale della tua VPN ma anche il tuo IP LAN e, in modo critico, il tuo vero IP pubblico tramite riflessione STUN.
Il comportamento che costituisce una perdita di privacy: una pagina con una connessione peer WebRTC attiva può raccogliere candidati ICE che contengono il tuo vero indirizzo IP. Questo avviene all'interno del sandbox JavaScript, senza permessi elevati, anche con una VPN attiva. La richiesta STUN viene instradata al di fuori del tunnel VPN attraverso lo stack di rete del sistema operativo.
La portata pratica di questa perdita è contestata. Richiede una connessione peer attiva, il che significa che la pagina attaccante ha bisogno di una funzionalità WebRTC legittima o di uno script di fingerprinting JavaScript che crea specificamente una connessione peer per scopi di sorveglianza. Quest'ultimo esiste. La nostra guida al rilevamento delle perdite di rete include una procedura per testare se la tua specifica combinazione browser/VPN è vulnerabile.
Opzioni di mitigazione classificate per efficacia:
- Mullvad Browser: disabilita WebRTC per impostazione predefinita. Superficie di attacco zero.
- Firefox (con
media.peerconnection.enabled = false): disabilita WebRTC globalmente. Interrompe i siti di videochiamata a meno che non venga temporaneamente riabilitato. - Firefox (con
media.peerconnection.ice.default_address_only = true): limita ICE a una singola interfaccia, tipicamente la VPN. Consente a WebRTC di funzionare impedendo l'enumerazione multi-interfaccia. - Chrome con un'estensione (politica WebRTC di uBlock Origin, o estensioni dedicate alla prevenzione delle perdite WebRTC): restrizione basata su politica. L'efficacia varia in base all'estensione e alla versione di Chrome.
- Chrome senza modifiche: vulnerabile. Il flag
--force-webrtc-ip-handling-policy=disable_non_proxied_udpesiste ma richiede il riavvio del processo e la configurazione da riga di comando.
DNS: il secondo vettore di perdita
Anche con una VPN attiva, il DNS può perdere il tuo vero IP se la configurazione è errata. I tre modi di fallimento:
1. Bypass del DNS di sistema. Alcuni client VPN non riescono a reindirizzare tutto il traffico DNS attraverso il tunnel su configurazioni specifiche del sistema operativo. Le richieste DNS del browser raggiungono il resolver di sistema, che può essere quello del tuo ISP o un resolver pubblico come 8.8.8.8, dal tuo vero IP. Test: esegui tcpdump -n port 53 mentre navighi con la VPN connessa. Qualsiasi pacchetto che mostra la tua interfaccia reale come sorgente è una perdita.
2. DNS-over-HTTPS al di fuori del tunnel. I browser con DoH abilitato (il "Trusted Recursive Resolver" di Firefox, il "Secure DNS" di Chrome) bypassano il resolver del sistema operativo e inviano query DoH direttamente a Cloudflare (1.1.1.1) o Google (8.8.8.8). Se l'IP del provider DoH non è instradato attraverso il tunnel VPN, queste query partono dal tuo vero IP. Il DNS-over-tunnel della VPN è aggirato.
3. Fallback IPv6. Se la tua rete ha connettività IPv6 e la VPN fornisce solo tunneling IPv4, le richieste DNS IPv6 e le connessioni dirette possono bypassare completamente il tunnel. ProtonVPN, Mullvad e IVPN supportano tutti il tunneling IPv6 sui loro client attuali, ma il comportamento del kill switch IPv6 varia in base al sistema operativo e alla versione del client.
Per eliminare le perdite DNS: disabilita DoH nel browser (lascia che il resolver della VPN lo gestisca), verifica che il tuo client VPN abbia la protezione dalle perdite IPv6 abilitata e verifica con un test del resolver controllato come descritto nella nostra guida al rilevamento delle perdite di rete.
Quale VPN completa meglio il rafforzamento del browser
Non tutte le VPN sono uguali in quanto bene si integrano con uno stack di privacy del browser. I fattori di differenziazione per questo caso d'uso specifico:
Qualità del resolver DNS. La VPN gestisce un resolver senza log e non filtrante? Mullvad gestisce la propria infrastruttura DNS con blocco dei contenuti opzionale; il resolver stesso non registra. Il resolver di ProtonVPN si integra con la sua funzione di blocco malware/tracker Netshield, con la nota che il DNS è elaborato attraverso l'infrastruttura di Proton. Il resolver di IVPN è simile a quello di Mullvad con livelli di blocco opzionali.
Gestione WebRTC. La VPN stessa non può influenzare direttamente il comportamento WebRTC del browser — è una configurazione lato browser. Tuttavia, Mullvad fornisce il Mullvad Browser come prodotto complementare progettato specificamente per eliminare le perdite a livello di browser che una VPN non può affrontare. Questo rende la combinazione rete Mullvad + Mullvad Browser lo stack più coerente architettonicamente disponibile.
Affidabilità del kill switch. Un tunnel VPN interrotto che si riconnette in 5 secondi produce una finestra durante la quale il tuo vero IP è esposto nelle richieste HTTP. Un kill switch a livello di sistema operativo con una configurazione predefinita attiva (modello di Mullvad) chiude questa lacuna.
Protezione dalle perdite IPv6. Tutti e tre i provider supportano il tunneling IPv6. Il client di Mullvad applica per impostazione predefinita il solo tunneling IPv6. ProtonVPN richiede di verificare questo nelle impostazioni del client.
ProtonVPN: scelta pragmatica, limitazioni oneste
Nel panorama VPN rilevante per la privacy del browser, ProtonVPN è una raccomandazione ragionevole con specifici compromessi dichiarati chiaramente.
Cosa fa bene per la privacy del browser: DNS-in-tunnel affidabile su tutte le piattaforme. Blocco tracker e malware a livello DNS Netshield (opzionale). Una vasta flotta di server (oltre 9.200 server) con buona copertura geografica per la diversità dei nodi di uscita. Il livello gratuito senza limite di larghezza di banda lo rende accessibile per gli utenti che testano la loro configurazione prima di impegnarsi in un abbonamento.
Cosa non fornisce: Resistenza al fingerprint a livello di browser — questo non è una critica specifica a Proton, nessuna VPN lo fornisce. Nessun browser complementare rinforzato nell'ecosistema Proton. L'anonimato dei pagamenti è più debole rispetto a Mullvad o IVPN (solo Bitcoin mediato da BitPay, niente Monero, niente contanti).
Dove si inserisce: Utenti che desiderano una base di privacy a livello di rete affidabile, in particolare quelli che già utilizzano l'ecosistema Proton (ProtonMail, ProtonDrive), e che gestiscono la privacy del browser separatamente tramite scelta e configurazione del browser. La giurisdizione svizzera, l'audit dell'infrastruttura Cure53 (aprile 2025) e il piano gratuito lo rendono un punto di ingresso a basso attrito.
Divulgazione: il link sottostante è un link affiliato. Guadagniamo una commissione se ti abboni tramite esso, senza alcun costo aggiuntivo per te. Raccomandiamo solo strumenti che raccomanderemmo senza questo accordo.
Prova ProtonVPN → ProtonVPN (piano gratuito disponibile — nessun limite di larghezza di banda)
Costruire lo stack completo
Una configurazione di privacy che affronta sia il livello di rete che il livello del browser richiede la combinazione di strumenti. Una configurazione pratica per un utente tecnicamente consapevole nel 2026:
Livello di rete: ProtonVPN (pragmatico, punto di ingresso gratuito) o Mullvad (architettura più forte se l'anonimato dei pagamenti è importante). Kill switch attivo. DNS-in-tunnel verificato. Protezione dalle perdite IPv6 abilitata.
Livello del browser:
- Mullvad Browser per la navigazione generale — rumore del canvas, letterboxing, WebRTC disabilitato, set di font coerente. Non richiede Mullvad VPN.
- Firefox con
media.peerconnection.ice.default_address_only = trueper i siti che richiedono WebRTC. Conferma che DoH instradi tramite il resolver della tua VPN o disabilitalo. - Tor Browser per sessioni in cui l'anonimato IP è importante oltre ciò che una VPN fornisce.
Verifica:
- Dopo aver configurato la tua VPN e il browser, controlla con un test di perdita DNS esterno che le query provengano dall'IP della VPN.
- Apri una pagina di test WebRTC e conferma che nessun IP locale/reale appaia nei candidati ICE.
- Esegui il nostro strumento di test del fingerprint del browser prima e dopo le modifiche di configurazione per verificare che l'iniezione di rumore del canvas sia attiva e misurare la tua riduzione di entropia.
- Verifica che la connettività IPv6 sia instradata, non nativa.
Il livello di rete e il livello del browser sono complementari, non sostituti. Una VPN senza rafforzamento del browser lascia la superficie del fingerprint ad alta entropia completamente esposta. Il rafforzamento del browser senza una VPN rivela ancora il tuo vero IP nei log dei server. Lo stack necessita di entrambi, configurati correttamente e verificati.
Per la tassonomia completa del fingerprint e l'analisi dell'entropia, vedi Stato dell'arte del fingerprinting del browser 2026. Per la configurazione lato browser, il confronto dei browser per la privacy copre Tor, Mullvad Browser, Brave e LibreWolf contro una matrice di modelli di minaccia comuni.
