Hvorfor en VPN-udgang og din browsers sprog ikke stemmer overens
Accept-Language beder om et svarsprog; VPN’en ændrer kildeadressen. Når et websted ser lokaliseret ud, afgør tre input, hvilken der vandt.
Åbn udviklerværktøjerne, indlæs siden, og læs anmodningsheadere, før du konkluderer noget om VPN’en. Du finder normalt en Accept-Language-linje, der beder om et bestemt sæt sprog, og den linje kommer fra dine browserindstillinger, ikke fra din udgangsadresse. En fransktalende på en udgang i Tokyo sender stadig fransk, og et websted, der svarer på fransk, svarer headeren. Tunnelen lækker ikke, bare fordi siden ankom på et velkendt sprog.
Læs headeren først
I en desktopbrowser åbner du panelet Netværk, genindlæser, klikker på dokumentanmodningen og kigger under anmodningsheadere. Fra en terminal kan du se det samme uden en browser, og du kan tilsidesætte værdien for at teste webstedets adfærd:
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 ligger brødteksten på disken, så sammenligningen handler om siden og ikke om en header, der måske aldrig sendes. Se på lang-attributtet på html-taggen og på den synlige tekst, fordi Content-Language er valgfri, og mange servere udelader den. Et websted, der skifter hele siden fra engelsk til fransk på den samme URL, kan derfor se uændret ud i en sammenligning, der kun ser på headere. Hvis dokumentets sprog følger headeren, mens udgangen står fast, var headeren det afgørende input, og VPN’en er irrelevant for den observation.
Brug en anden browserprofil i stedet for webstedets egen sprogvælger til denne test. En vælger skriver normalt en cookie, som er et andet input, og du ender med at måle cookien i stedet for headeren.
Hvad q-værdierne betyder, og hvad de ikke betyder
RFC 9110 afsnit 12.5.4 definerer Accept-Language som en liste over foretrukne naturlige sprog til svaret. Hver post kan bære en vægt fra 0 til 1, et interval uden vægt har vægt 1, og en vægt på 0 markerer et sprog som ikke acceptabelt. Det er en præferencerækkefølge og intet mere.
Værdien er ikke en placeringsrapport, ikke en tillidsscore og ikke en identitet. En server er fri til at ignorere den, til at levere den eneste oversættelse, den har, eller til at lade en landebaseret omdirigering vinde. Indholdsforhandling er serverens valg, og headeren er et input til det valg, ikke en kommando.
Det er den del, folk overser, når de behandler en lokaliseret side som en placeringstest. Headeren angiver, hvilke sprog personen foretrækker at læse, og en præference kan rejse hvor som helst.
Tre input afgør, hvilket sprog du faktisk får
Isolér dem én ad gangen, for udefra kan du ikke se, hvilken der vandt:
- Headeren. Test med en anden profil, der er sat op til en anden sprogliste, og se, om siden ændrer sig, mens alt andet holdes konstant.
- Et gemt valg. Test i et privat vindue uden cookies, eller ryd webstedets lager. Kontoindstillinger og poster i localStorage kan låse et sprog i månedsvis.
- En URL eller omdirigering. Test ved at anmode om den eksplicitte sprogsti, for eksempel
/fr/, og ved at følge statuskoderne for en omdirigering baseret på kildeadressen.
Kør de tre tests i den rækkefølge, og skriv ned, hvilken der flyttede resultatet. En enkelt sideindlæsning, der skifter sprog, efter du har aktiveret VPN’en, er svag evidens, fordi både en omdirigering og en cachet cookie kan skabe det indtryk.
Hvad VPN’en ændrer, og hvad den ikke ændrer
Tunnelen ændrer den kildeadresse, en server ser, og dermed alt, hvad serveren udleder af IP-geolokation. Den omskriver ikke browserens sprogpræferencer, sletter ikke en gemt indstilling og ændrer ikke den URL, du indtastede. De input bliver præcis, hvor de var, så en side kan beholde sit gamle sprog, efter udgangen flytter sig.
Geolokation tilføjer sin egen støj. Adressedatabaser er uenige med hinanden, og en udgang registreret i ét land kan blive knyttet til et andet, hvilket får en landebaseret omdirigering til at se forkert ud af grunde, der intet har med din browser at gøre.
En hurtig gennemgang adskiller dem: anmod om siden på ny, notér den adresse, du fremviser, og sammenlign derefter svarsproget med din headerliste. Hvis sproget matcher din liste snarere end udgangslandet, var headeren det afgørende input, og der er intet at rette i tunnelen.
Hvad en lokaliseret side beviser, og hvad den ikke beviser
Der er en reel pointe om privatliv her, og den er mindre end den, folk normalt fremfører. En komplet liste over sprogpræferencer er et input til fingeraftryk og kan afsløre noget om, hvem du er, eller hvad du læser. Det er en ægte afsløring af præference, og det er ikke det samme som at bevise, at trafik er undsluppet tunnelen.
En lokaliseret side er ikke en lækageindikator. Hvis du faktisk vil teste for lækage, så tjek den udgangsadresse, webstedet ser, den resolvervej, der bruges til navneopslag, og de kandidater, en WebRTC-stak afslører. De tests besvarer det spørgsmål, som sidens sprog ikke kan.
Næste gang et websted ser ud til at kende dit land, så åbn anmodningsheadere først. Hvis svarsproget matcher din browsers liste, lækkede intet, og det lag, du skal kigge på, er det, der ligger foran dig.