Hvorfor en VPN-utgang og nettleserens språk ikke stemmer overens
Accept-Language ber om et svarspråk; VPN-en endrer kildeadressen. Når et nettsted ser lokalisert ut, avgjør tre innganger hvilken som vant.
Åpne utviklerverktøyene, last siden og les forespørselshodene før du konkluderer noe om VPN-en. Du finner vanligvis en Accept-Language-linje som ber om et bestemt sett språk, og den linjen kommer fra nettleserinnstillingene, ikke fra utgangsadressen din. En fransktalende på en utgang i Tokyo sender fortsatt fransk, og et nettsted som svarer på fransk, svarer headeren. Tunnelen lekker ikke bare fordi siden kom på et kjent språk.
Les headeren først
I en stasjonær nettleser åpner du Nettverk-panelet, laster på nytt, klikker på dokumentforespørselen og ser under forespørselshodene. Fra en terminal kan du se det samme uten nettleser, og du kan overstyre verdien for å teste nettstedets oppførsel:
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
Nå ligger brødteksten på disken, så sammenligningen handler om siden og ikke om en header som kanskje aldri sendes. Se på lang-attributtet til html-taggen og på den synlige teksten, fordi Content-Language er valgfritt og mange servere utelater det. Et nettsted som bytter hele siden fra engelsk til fransk på samme URL, kan derfor se uendret ut i en sammenligning av bare headere. Hvis dokumentets språk følger headeren mens utgangen står fast, var headeren den avgjørende inngangen, og VPN-en er irrelevant for den observasjonen.
Bruk en annen nettleserprofil i stedet for nettstedets egen språkvelger for denne testen. En velger skriver vanligvis en cookie, som er en annen inngang, og du ender opp med å måle cookien i stedet for headeren.
Hva q-verdiene betyr, og hva de ikke betyr
RFC 9110 avsnitt 12.5.4 definerer Accept-Language som en liste over foretrukne naturlige språk for svaret. Hver oppføring kan bære en vekt fra 0 til 1, et område uten vekt har vekt 1, og en vekt på 0 markerer et språk som ikke akseptabelt. Det er en preferanserekkefølge og ikke noe mer.
Verdien er ikke en posisjonsrapport, ikke en tillitsscore og ikke en identitet. En server står fritt til å ignorere den, til å levere den eneste oversettelsen den har, eller til å la en landbasert omdirigering vinne. Innholdsforhandling er serverens valg, og headeren er en inngang til det valget, ikke en kommando.
Det er dette folk går glipp av når de behandler en lokalisert side som en posisjonstest. Headeren sier hvilke språk personen foretrekker å lese, og en preferanse kan reise hvor som helst.
Tre innganger avgjør hvilket språk du faktisk får
Isoler dem én om gangen, for utenfra ser du ikke hvilken som vant:
- Headern. Test med en annen profil som er satt opp for en annen språkliste, og se om siden endrer seg mens alt annet holdes konstant.
- Et lagret valg. Test i et privat vindu uten cookies, eller tøm nettstedets lagring. Kontoinnstillinger og oppføringer i localStorage kan låse et språk i månedsvis.
- En URL eller omdirigering. Test ved å be om den eksplisitte språkstien, for eksempel
/fr/, og ved å følge statuskodene for en omdirigering basert på kildeadressen.
Kjør de tre testene i den rekkefølgen og skriv ned hvilken som flyttet resultatet. Én enkelt sideinnlasting som bytter språk etter at du slår på VPN-en, er svak evidens, fordi både en omdirigering og en bufret cookie kan skape det inntrykket.
Hva VPN-en endrer, og hva den ikke endrer
Tunnelen endrer kildeadressen en server ser, og med den alt serveren utleder fra IP-geolokasjon. Den skriver ikke om nettleserens språkpreferanser, sletter ikke en lagret innstilling og endrer ikke URL-en du skrev inn. Disse inngangene blir nøyaktig der de var, så en side kan beholde sitt gamle språk etter at utgangen flytter seg.
Geolokasjon tilfører sin egen støy. Adressedatabaser er uenige med hverandre, og en utgang registrert i ett land kan bli tilordnet et annet, noe som får en landbasert omdirigering til å se feil ut av grunner som ikke har noe med nettleseren din å gjøre.
En rask kontroll skiller dem: be om siden på nytt, noter adressen du presenterer, og sammenlign deretter svarspråket med headerlisten din. Hvis språket samsvarer med listen din og ikke med utgangslandet, var headeren den avgjørende inngangen, og det er ingenting å rette i tunnelen.
Hva en lokalisert side beviser, og hva den ikke beviser
Her er det et reelt personvernpoeng, og det er mindre enn det folk vanligvis tar opp. En fullstendig liste over språkpreferanser er en inngang for fingeravtrykk og kan avsløre noe om hvem du er eller hva du leser. Det er en ekte avsløring av preferanse, og det er ikke det samme som å bevise at trafikk slapp ut av tunnelen.
En lokalisert side er ikke en lekkasjeindikator. Hvis du virkelig vil teste for lekkasje, sjekk utgangsadressen nettstedet ser, resolverstien som brukes til navneoppslag, og kandidatene en WebRTC-stack avslører. Disse testene svarer på spørsmålet sidens språk ikke kan svare på.
Neste gang et nettsted ser ut til å kjenne landet ditt, åpne forespørselshodene først. Hvis svarspråket samsvarer med nettleserens liste, lakk ingenting, og laget du bør se på, er det som er foran deg.