Waarom een VPN-uitgang en de taal van je browser niet overeenkomen

Open de ontwikkelaarstools, laad de pagina en lees de verzoekheaders voordat je iets over de VPN concludeert. Je vindt meestal een Accept-Language-regel die om een bepaalde set talen vraagt, en die regel komt uit je browserinstellingen, niet uit je uitgangsadres. Een Franstalige op een uitgang in Tokio stuurt nog steeds Frans, en een site die in het Frans antwoordt, antwoordt op de header. De tunnel lekt niet alleen omdat de pagina in een bekende taal aankwam.

Lees eerst de header

Open in een desktopbrowser het paneel Netwerk, herlaad, klik op het documentverzoek en kijk onder de verzoekheaders. Vanuit een terminal zie je hetzelfde zonder browser, en je kunt de waarde overschrijven om het gedrag van de site te testen:

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

Nu staat de inhoud op schijf, dus de vergelijking gaat over de pagina en niet over een header die misschien nooit wordt verzonden. Kijk naar het lang-attribuut van de html-tag en naar de zichtbare tekst, want Content-Language is optioneel en veel servers laten het weg. Een site die op dezelfde URL de hele pagina van Engels naar Frans omzet, kan er in een vergelijking van alleen headers dus onveranderd uitzien. Als de taal van het document de header volgt terwijl de uitgang gelijk blijft, was de header de beslissende invoer en heeft de VPN niets met die observatie te maken.

Gebruik voor deze test een tweede browserprofiel in plaats van de taalkeuze van de site zelf. Een keuze schrijft meestal een cookie, wat een andere invoer is, en uiteindelijk meet je de cookie in plaats van de header.

Wat de q-waarden betekenen, en wat niet

RFC 9110 paragraaf 12.5.4 definieert Accept-Language als een lijst van geprefereerde natuurlijke talen voor het antwoord. Elke vermelding kan een gewicht van 0 tot 1 dragen, een bereik zonder gewicht heeft gewicht 1, en een gewicht van 0 markeert een taal als niet acceptabel. Dat is een voorkeursvolgorde en niets meer.

De waarde is geen locatierapport, geen betrouwbaarheidsscore en geen identiteit. Een server mag deze negeren, de enige vertaling die hij heeft serveren, of een landgebaseerde omleiding laten winnen. Inhoudsonderhandeling is de keuze van de server, en de header is een invoer voor die keuze, geen opdracht.

Dit is het deel dat mensen missen wanneer ze een gelokaliseerde pagina als locatietest behandelen. De header geeft aan welke talen iemand liever leest, en een voorkeur kan overal heen reizen.

Drie invoerwaarden bepalen welke taal je echt krijgt

Isoleer ze een voor een, want van buitenaf zie je niet welke heeft gewonnen:

• De header. Test met een tweede profiel dat op een andere talenlijst is ingesteld, en kijk of de pagina verandert terwijl al het andere gelijk blijft.
• Een opgeslagen keuze. Test in een privévenster zonder cookies, of wis de opslag van de site. Accountinstellingen en items in localStorage kunnen een taal maandenlang vastzetten.
• Een URL of omleiding. Test door het expliciete taalpad op te vragen, zoals /fr/, en door de statuscodes van een op het bronadres gebaseerde omleiding te volgen.

Voer de drie tests in die volgorde uit en noteer welke het resultaat heeft verschoven. Eén paginalading die van taal verandert nadat je de VPN aanzet, is zwak bewijs, want zowel een omleiding als een gecachte cookie kan die indruk wekken.

Wat de VPN verandert, en wat niet

De tunnel verandert het bronadres dat een server ziet, en daarmee alles wat de server uit IP-geolocatie afleidt. Hij herschrijft de taalvoorkeuren van de browser niet, wist geen opgeslagen instelling en verandert de URL die je hebt getypt niet. Die invoerwaarden blijven precies waar ze waren, dus een pagina kan zijn oude taal behouden nadat de uitgang verschuift.

Geolocatie voegt zijn eigen ruis toe. Adresdatabases spreken elkaar tegen, en een uitgang die in het ene land is geregistreerd, kan aan een ander land worden toegewezen, waardoor een landgebaseerde omleiding om redenen die niets met je browser te maken hebben verkeerd lijkt.

Een snelle controle scheidt ze: vraag de pagina opnieuw op, noteer het adres dat je presenteert, en vergelijk daarna de antwoordtaal met je headerlijst. Als de taal bij je lijst past en niet bij het uitgangsland, was de header de beslissende invoer en valt er aan de tunnel niets te repareren.

Wat een gelokaliseerde pagina bewijst, en wat niet

Er is hier een echt privacypunt, en het is kleiner dan wat mensen gewoonlijk aanvoeren. Een volledige lijst met taalvoorkeuren is een invoer voor vingerafdrukken en kan iets onthullen over wie je bent of wat je leest. Dat is een echte onthulling van voorkeur, en het is niet hetzelfde als bewijzen dat verkeer de tunnel heeft verlaten.

Een gelokaliseerde pagina is geen lekindicator. Als je echt op een lek wilt testen, controleer dan het uitgangsadres dat de site ziet, het resolverpad dat voor naamopzoekingen wordt gebruikt en de kandidaten die een WebRTC-stack blootlegt. Die tests beantwoorden de vraag die de taal van de pagina niet kan beantwoorden.

De volgende keer dat een site je land lijkt te kennen, open dan eerst de verzoekheaders. Als de antwoordtaal bij de lijst van je browser past, is er niets gelekt, en de laag waar je naar moet kijken is degene voor je.