Perché l’uscita VPN e la lingua del browser non coincidono
Accept-Language chiede una lingua di risposta; la VPN cambia l’indirizzo di origine. Quando un sito sembra localizzato, tre ingressi decidono quale ha vinto.
Aprite gli strumenti per sviluppatori, caricate la pagina e leggete le intestazioni della richiesta prima di concludere qualcosa sulla VPN. Di solito trovate una riga Accept-Language che chiede un insieme preciso di lingue, e quella riga proviene dalle impostazioni del browser, non dall’indirizzo di uscita. Un francofono su un’uscita a Tokyo invia comunque francese, e un sito che risponde in francese risponde all’intestazione. Il tunnel non perde solo perché la pagina è arrivata in una lingua familiare.
Leggete prima l’intestazione
In un browser desktop aprite il pannello Rete, ricaricate, fate clic sulla richiesta del documento e guardate sotto le intestazioni della richiesta. Da un terminale vedete la stessa cosa senza browser, e potete sovrascrivere il valore per testare il comportamento del sito:
curl -sS -D /tmp/h1 -o /tmp/b1 https://example.com
curl -sS -D /tmp/h2 -o /tmp/b2 -H 'Accept-Language: fr,en;q=0.6' https://example.com
grep -o 'lang="[^"]*"' /tmp/b1 /tmp/b2
diff /tmp/b1 /tmp/b2 | head -40
Ora il corpo è su disco, quindi il confronto riguarda la pagina e non un’intestazione che forse non verrà mai inviata. Guardate l’attributo lang del tag html e il testo visibile, perché Content-Language è facoltativo e molti server lo omettono. Un sito che cambia l’intera pagina dall’inglese al francese sullo stesso URL può quindi sembrare invariato in un confronto solo sulle intestazioni. Se la lingua del documento segue l’intestazione mentre l’uscita resta fissa, l’intestazione era l’ingresso decisivo e la VPN non c’entra nulla con quell’osservazione.
Per questo test usate un secondo profilo del browser invece del selettore di lingua del sito. Un selettore di solito scrive un cookie, che è un altro ingresso, e finirete per misurare il cookie invece dell’intestazione.
Cosa significano i valori q, e cosa no
La RFC 9110, sezione 12.5.4, definisce Accept-Language come un elenco di lingue naturali preferite per la risposta. Ogni voce può portare un peso da 0 a 1, un intervallo senza peso ha peso 1 e un peso di 0 segna una lingua come non accettabile. È un ordine di preferenza, niente di più.
Il valore non è un rapporto di posizione, non è un punteggio di affidabilità e non è un’identità. Un server è libero di ignorarlo, di servire l’unica traduzione che ha o di lasciare vincere un reindirizzamento per paese. La negoziazione dei contenuti è una scelta del server, e l’intestazione è un ingresso di quella scelta, non un comando.
È la parte che le persone trascurano quando trattano una pagina localizzata come un test di posizione. L’intestazione dichiara quali lingue la persona preferisce leggere, e una preferenza può viaggiare ovunque.
Tre ingressi decidono la lingua che ricevete davvero
Isolateli uno alla volta, perché dall’esterno non vedete quale ha vinto:
- L’intestazione. Provate con un secondo profilo configurato per un altro elenco di lingue e osservate se la pagina cambia mentre tutto il resto resta invariato.
- Una scelta salvata. Provate in una finestra privata senza cookie, oppure cancellate l’archivio del sito. Le impostazioni dell’account e le voci di localStorage possono fissare una lingua per mesi.
- Un URL o un reindirizzamento. Provate chiedendo il percorso di lingua esplicito, per esempio
/fr/, e osservando i codici di stato di un reindirizzamento basato sull’indirizzo di origine.
Eseguite i tre test in quest’ordine e annotate quale ha spostato il risultato. Un solo caricamento di pagina che cambia lingua dopo aver attivato la VPN è una prova debole, perché sia un reindirizzamento sia un cookie in cache possono produrre quell’impressione.
Cosa cambia la VPN e cosa no
Il tunnel cambia l’indirizzo di origine che vede un server, e con esso tutto ciò che il server deduce dalla geolocalizzazione IP. Non riscrive le preferenze di lingua del browser, non cancella un’impostazione salvata e non cambia l’URL che avete digitato. Tali ingressi restano esattamente dove erano, quindi una pagina può mantenere la vecchia lingua dopo che l’uscita si è spostata.
La geolocalizzazione aggiunge il proprio rumore. I database degli indirizzi si contraddicono, e un’uscita registrata in un paese può essere mappata su un altro, il che fa sembrare sbagliato un reindirizzamento per paese per motivi che non hanno nulla a che fare con il vostro browser.
Un controllo rapido li separa: richiedete la pagina da capo, annotate l’indirizzo che presentate e poi confrontate la lingua della risposta con il vostro elenco di intestazioni. Se la lingua corrisponde al vostro elenco invece che al paese di uscita, l’intestazione era l’ingresso decisivo e non c’è nulla da correggere nel tunnel.
Cosa dimostra una pagina localizzata e cosa no
C’è un punto reale sulla privacy, ed è più piccolo di quello che le persone di solito avanzano. Un elenco completo delle preferenze linguistiche è un ingresso per il fingerprinting e può rivelare qualcosa su chi siete o su cosa leggete. È una divulgazione genuina di preferenza, e non è la stessa cosa del dimostrare che il traffico è uscito dal tunnel.
Una pagina localizzata non è un indicatore di fuga. Se volete davvero testare una fuga, controllate l’indirizzo di uscita che vede il sito, il percorso del resolver usato per le ricerche dei nomi e i candidati che uno stack WebRTC espone. Quei test rispondono alla domanda a cui la lingua della pagina non può rispondere.
La prossima volta che un sito sembra conoscere il vostro paese, aprite prima le intestazioni della richiesta. Se la lingua della risposta corrisponde all’elenco del vostro browser, non è trapelato nulla, e lo strato da guardare è quello che avete davanti.