Warum ein VPN-Ausgang und die Browsersprache nicht übereinstimmen

Öffnen Sie die Entwicklertools, laden Sie die Seite, und lesen Sie die Anfrage-Header, bevor Sie irgendetwas über das VPN schließen. Meist finden Sie eine Accept-Language-Zeile, die eine bestimmte Sprachliste anfordert, und diese Zeile stammt aus Ihren Browsereinstellungen, nicht aus Ihrer Ausgangsadresse. Ein französischsprachiger Nutzer an einem Ausgang in Tokio sendet weiterhin Französisch, und eine Seite, die auf Französisch antwortet, antwortet dem Header. Der Tunnel leckt nicht, nur weil die Seite in einer vertrauten Sprache ankam.

Lesen Sie zuerst den Header

Öffnen Sie in einem Desktop-Browser den Netzwerkbereich, laden Sie neu, klicken Sie auf die Dokumentanfrage und schauen Sie unter den Anfrage-Headern nach. Im Terminal sehen Sie dasselbe ohne Browser, und Sie können den Wert überschreiben, um das Verhalten der Seite zu 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

Jetzt liegt der Inhalt auf der Festplatte, die Gegenüberstellung betrifft also die Seite und nicht einen Header, der vielleicht nie gesendet wird. Prüfen Sie das lang-Attribut des html-Tags und den sichtbaren Text, denn Content-Language ist optional und viele Server lassen sie weg. Eine Seite, die auf derselben URL die gesamte Seite von Englisch auf Französisch umstellt, kann in einem reinen Header-Vergleich daher unverändert wirken. Folgt die Dokumentsprache dem Header, während der Ausgang gleich bleibt, war der Header die entscheidende Eingabe, und das VPN ist für diese Beobachtung unerheblich.

Nutzen Sie für diesen Test ein zweites Browserprofil statt der Spracheneinstellung der Seite selbst. Eine Umschaltung schreibt meist ein Cookie, das eine andere Eingabe ist, und am Ende messen Sie das Cookie statt des Headers.

Was die q-Werte bedeuten und was nicht

RFC 9110 Abschnitt 12.5.4 definiert Accept-Language als Liste bevorzugter natürlicher Sprachen für die Antwort. Jeder Eintrag kann eine Gewichtung von 0 bis 1 tragen, ein Bereich ohne Gewichtung hat Gewicht 1, und eine Gewichtung von 0 kennzeichnet eine Sprache als nicht akzeptabel. Das ist eine Präferenzreihenfolge, mehr nicht.

Der Wert ist kein Standortbericht, kein Vertrauenswert und keine Identität. Ein Server darf ihn ignorieren, die einzige vorhandene Übersetzung ausliefern oder eine länderbasierte Umleitung gewinnen lassen. Content Negotiation ist die Wahl des Servers, und der Header ist eine Eingabe für diese Wahl, kein Befehl.

Diesen Punkt übersehen Leute, wenn sie eine lokalisierte Seite als Standorttest behandeln. Der Header nennt die Sprachen, die die Person bevorzugt liest, und eine Präferenz kann überallhin reisen.

Drei Eingaben entscheiden, welche Sprache Sie tatsächlich bekommen

Isolieren Sie sie nacheinander, denn von außen sehen Sie nicht, welche gewonnen hat:

• Der Header. Testen Sie mit einem zweiten Profil, das auf eine andere Sprachliste eingestellt ist, und beobachten Sie, wie sich die Seite ändert, während alles andere gleich bleibt.
• Eine gespeicherte Wahl. Testen Sie in einem privaten Fenster ohne Cookies oder löschen Sie den Speicher der Seite. Kontoeinstellungen und Einträge in localStorage können eine Sprache monatelang festhalten.
• Eine URL oder Umleitung. Testen Sie, indem Sie den ausdrücklichen Sprachpfad anfordern, etwa /fr/, und die Statuscodes einer Umleitung beobachten, die auf der Quelladresse beruht.

Führen Sie die drei Tests in dieser Reihenfolge aus und notieren Sie, welcher das Ergebnis bewegt hat. Ein einzelnes Laden der Seite, das die Sprache nach dem Einschalten des VPN ändert, ist schwache Evidenz, denn sowohl eine Umleitung als auch ein zwischengespeichertes Cookie können diesen Eindruck erzeugen.

Was das VPN ändert und was nicht

Der Tunnel ändert die Quelladresse, die ein Server sieht, und damit alles, was der Server aus der IP-Geolokalisierung ableitet. Er schreibt die Sprachpräferenzen des Browsers nicht um, löscht keine gespeicherte Einstellung und ändert nicht die von Ihnen eingegebene URL. Diese Eingaben bleiben genau, wo sie waren, daher kann eine Seite ihre alte Sprache behalten, nachdem sich der Ausgang verschiebt.

Die Geolokalisierung bringt ihr eigenes Rauschen mit. Adressdatenbanken widersprechen einander, und ein in einem Land registrierter Ausgang kann einem anderen zugeordnet werden, wodurch eine länderbasierte Umleitung aus Gründen falsch wirkt, die nichts mit Ihrem Browser zu tun haben.

Eine kurze Prüfung trennt sie: Fordern Sie die Seite frisch an, notieren Sie die Adresse, die Sie präsentieren, und vergleichen Sie dann die Antwortsprache mit Ihrer Header-Liste. Stimmt die Sprache mit Ihrer Liste statt mit dem Ausgangsland überein, war der Header die entscheidende Eingabe, und am Tunnel ist nichts zu reparieren.

Was eine lokalisierte Seite beweist und was nicht

Hier gibt es einen echten Datenschutzpunkt, und er ist kleiner als der, den Leute üblicherweise vorbringen. Eine vollständige Liste der Sprachpräferenzen ist eine Eingabe für Fingerprinting und kann etwas darüber verraten, wer Sie sind oder was Sie lesen. Das ist eine echte Offenlegung von Präferenz und nicht dasselbe wie der Beweis, dass Verkehr den Tunnel verlassen hat.

Eine lokalisierte Seite ist kein Leck-Indikator. Wenn Sie wirklich auf ein Leck testen wollen, prüfen Sie die Ausgangsadresse, die die Seite sieht, den Resolver-Pfad für Namensauflösungen und die Kandidaten, die ein WebRTC-Stack preisgibt. Diese Tests beantworten die Frage, die die Seitensprache nicht beantworten kann.

Wenn eine Seite das nächste Mal Ihr Land zu kennen scheint, öffnen Sie zuerst die Anfrage-Header. Stimmt die Antwortsprache mit der Liste Ihres Browsers überein, ist nichts geleakt, und die Ebene, die Sie sich ansehen sollten, ist die vor Ihnen.