Varför en VPN-utgång och webbläsarens språk inte stämmer överens

Accept-Language ber om ett svarspråk; VPN:en ändrar källadressen. När en webbplats ser lokaliserad ut avgör tre indata vilken som vann.

Öppna utvecklarverktygen, ladda sidan och läs begäranshuvudena innan du drar någon slutsats om VPN:en. Du hittar vanligtvis en Accept-Language-rad som ber om en viss uppsättning språk, och den raden kommer från webbläsarens inställningar, inte från din utgångsadress. En fransktalande på en utgång i Tokyo skickar fortfarande franska, och en webbplats som svarar på franska svarar på huvudet. Tunneln läcker inte bara för att sidan kom på ett bekant språk.

Läs huvudet först

I en stationär webbläsare öppnar du panelen Nätverk, laddar om, klickar på dokumentbegäran och tittar under begäranshuvudena. Från en terminal ser du samma sak utan webbläsare, och du kan skriva över värdet för att testa webbplatsens beteende:

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ödtexten på disken, så jämförelsen handlar om sidan och inte om ett huvud som kanske aldrig skickas. Titta på lang-attributet i html-taggen och på den synliga texten, eftersom Content-Language är valfritt och många servrar utelämnar det. En webbplats som byter hela sidan från engelska till franska på samma URL kan därför se oförändrad ut i en jämförelse av bara huvuden. Om dokumentets språk följer huvudet medan utgången står stilla var huvudet det avgörande indata och VPN:en har inget med den observationen att göra.

Använd en andra webbläsarprofil i stället för webbplatsens egen språkväljare för det här testet. En väljare skriver vanligtvis en kaka, vilket är ett annat indata, och du mäter till slut kakan i stället för huvudet.

Vad q-värdena betyder, och vad de inte betyder

RFC 9110 avsnitt 12.5.4 definierar Accept-Language som en lista över föredragna naturliga språk för svaret. Varje post kan bära en vikt från 0 till 1, ett intervall utan vikt har vikten 1, och en vikt på 0 markerar ett språk som oacceptabelt. Det är en preferensordning och inget mer.

Värdet är inte en platsrapport, inte en tillförlitlighetspoäng och inte en identitet. En server får ignorera det, leverera den enda översättning den har eller låta en landsbaserad omdirigering vinna. Innehållsförhandling är serverns val, och huvudet är ett indata till det valet, inte ett kommando.

Det är detta folk missar när de behandlar en lokaliserad sida som ett platstest. Huvudet anger vilka språk personen föredrar att läsa, och en preferens kan resa vart som helst.

Tre indata avgör vilket språk du faktiskt får

Isolera dem en i taget, för utifrån ser du inte vilken som vann:

  • Huvudet. Testa med en andra profil som är inställd på en annan språklista och se om sidan ändras medan allt annat hålls konstant.
  • Ett sparat val. Testa i ett privat fönster utan kakor, eller rensa webbplatsens lagring. Kontoinställningar och poster i localStorage kan låsa ett språk i månader.
  • En URL eller omdirigering. Testa genom att begära den uttryckliga språksökvägen, till exempel /fr/, och genom att följa statuskoderna för en omdirigering som bygger på källadressen.

Kör de tre testerna i den ordningen och skriv ned vilket som flyttade resultatet. En enda sidladdning som byter språk efter att du slagit på VPN:en är svagt bevis, eftersom både en omdirigering och en cachad kaka kan skapa det intrycket.

Vad VPN:en ändrar och vad den inte ändrar

Tunneln ändrar källadressen som en server ser, och med den allt som servern härleder från IP-geolokalisering. Den skriver inte om webbläsarens språkpreferenser, raderar inte en sparad inställning och ändrar inte URL:en du skrev in. Dessa indata stannar exakt där de var, så en sida kan behålla sitt gamla språk efter att utgången flyttats.

Geolokalisering tillför sitt eget brus. Adressdatabaser är oense med varandra, och en utgång registrerad i ett land kan mappas till ett annat, vilket får en landsbaserad omdirigering att se fel ut av skäl som inte har något med din webbläsare att göra.

En snabb kontroll skiljer dem: begär sidan på nytt, notera adressen du presenterar och jämför sedan svarspråket med din huvudlista. Om språket matchar din lista och inte utgångslandet var huvudet det avgörande indata och det finns inget att åtgärda i tunneln.

Vad en lokaliserad sida bevisar och vad den inte bevisar

Här finns en verklig integritetspunkt, och den är mindre än den folk vanligtvis tar upp. En fullständig lista över språkpreferenser är ett indata för fingeravtryck och kan avslöja något om vem du är eller vad du läser. Det är ett genuint avslöjande av preferens, och det är inte samma sak som att bevisa att trafik slapp ut ur tunneln.

En lokaliserad sida är ingen läckageindikator. Om du verkligen vill testa för läckage, kontrollera utgångsadressen som webbplatsen ser, resolvervägen som används för namnsökningar och de kandidater som en WebRTC-stack avslöjar. Dessa test svarar på frågan som sidans språk inte kan svara på.

Nästa gång en webbplats verkar känna till ditt land, öppna begäranshuvudena först. Om svarspråket matchar listan i din webbläsare läckte ingenting, och lagret du bör titta på är det framför dig.

Relaterade artiklar