zurück zur Übersicht Mehr Artikel

Sprach-Leak: Dein VPN ändert deine Browsersprache nicht

Wird geladen...

Du leitest deinen Verkehr durch Amsterdam, und Google begrüßt dich auf Niederländisch. Fast jeder VPN-Nutzer kennt das und tut es als seltsames VPN-Verhalten ab. Dabei ist es genau das Datenleck dieses Artikels, nur in umgekehrter Richtung.

Die Anfrage widersprach sich selbst. Die Pakete kamen von einer niederländischen IP-Adresse, die Header nannten dagegen deine tatsächlichen Lesesprachen: Accept-Language: en-US,en;q=0.9. Bei der Auswahl der Oberflächensprache vertraut Google der IP. Ein Betrugserkennungsscript beim Bezahlen führt denselben Vergleich andersherum aus: Es prüft, ob die Sprachen zur IP passen, und übernimmt das Ergebnis in deine Risikobewertung. Das Widget auf dieser Seite macht diesen Test jetzt mit deinem Browser.

Die Kurzfassung: Dein Browser nennt bei jeder Anfrage deine bevorzugten Sprachen in einem Header, den dein VPN wortwörtlich weiterleitet. Der Vergleich mit dem IP-Land ist sogar billiger als die Zeitzonenprüfung: Die Zeitzone braucht eine Zeile JavaScript, die Sprache steht schon in den Anfrage-Headern. Nur den Header oder nur JavaScript zu fälschen, macht aus einer Abweichung einen Widerspruch, der noch schlechter bewertet wird.

Accept-Language: ein Header bei jeder Anfrage

Wenn dein Browser etwas von einem Server anfordert, ob Seite, Bild oder Schrift, hängt er den HTTP-Header Accept-Language an. Damit können Server eine Sprache wählen, die du verstehst. Er entsteht aus der Sprachliste deiner Browsereinstellungen, die bei der Installation aus der Betriebssystemsprache übernommen wurde. Die Schreibweise q=0.9 gewichtet die Liste: Dieser Browser bevorzugt amerikanisches Englisch, allgemeines Englisch folgt knapp dahinter. Die vollständige Syntax erklärt die MDN-Seite zu Accept-Language.

Der Header steht schon in deiner allerersten Anfrage, bevor ein Script geladen oder ein Cookie gesetzt wurde. Der Server liest ihn zusammen mit der Quell-IP des Pakets:

Schon die erste Anfrage antwortet zweimal
1 Woher die Pakete kommen
Quell-IP 198.51.100.7 Geodatenbank Amsterdam, NL
2 Was in der Anfrage steht
GET /checkout HTTP/1.1
Host: shop.example
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...
Accept-Language: en-US,en;q=0.9  ◄ die eigene Sprachliste des Browsers
1 Die IP: Niederlande gegenüber 2 Der Header: jemand, der Englisch liest
Zwei Standortangaben in derselben Anfrage, verglichen, bevor auch nur eine Zeile JavaScript läuft.
Der Accept-Language-Header reist in jeder HTTP-Anfrage deines Browsers mit. Der Server liest ihn direkt neben der Quell-IP. Der Vergleich kostet daher praktisch nichts.

JavaScript bekommt dieselbe Information über navigator.language und die gesamte Liste über navigator.languages, ohne Berechtigungsdialog. Anders als bei der Uhr: Ein Script muss erst laufen und deine Zeitzone abfragen. Deine Sprache ist bereits da, bevor die Seite überhaupt Scripts ausführen kann.

Warum ein VPN deine Browsersprache nicht ändert

Ein VPN unternimmt dagegen gar nichts. Der Tunnel transportiert deine Pakete, er übersetzt sie nicht. Die Sprache ist eines von mehreren Signalen, die ein VPN verraten; die anderen stehen in So erkennen Websites dein VPN. Alles, was dein Browser geschrieben hat, kommt unverändert an, einschließlich des Headers „Mein Nutzer liest Englisch, nicht Niederländisch“. Umschreiben kann das VPN ihn auch nicht: Bei HTTPS reist der Header innerhalb der TLS-Verbindung zwischen Browser und Website, die das VPN nicht öffnen kann.

Was eine Abweichung beweist und was nicht

Sprache ist ein weiches Signal, noch weicher als die Zeitzone. Englisch kommt einer Werkseinstellung von Betriebssystemen am nächsten. en-US von einer Amsterdamer IP fällt deshalb allein kaum auf. Belgien hat drei Amtssprachen, die Schweiz vier. Auswanderer und Menschen im Homeoffice lesen ganz legitim andere Sprachen als ihre Nachbarn. Seriöse Erkennungssysteme berücksichtigen das. Eine Sprachabweichung verschiebt daher nur eine Bewertung.

Das Signal hat aber eine klare Richtung. Ein Browser mit pt-BR als bevorzugter Sprache hinter einer niederländischen Ausgangs-IP ist weniger mehrdeutig als Englisch: Die Person liest brasilianisches Portugiesisch. Die Niederlande haben viele IP-Adressen, aber vergleichsweise wenige Haushalte mit Portugiesisch als Hauptsprache. Zusammen mit einer Rechenzentrums-IP und einer Uhr auf America/Sao_Paulo wird die Behauptung „Amsterdam“ unglaubwürdig:

Was ein Bewertungsscript aus dem Paar liest
  1. nl-NL, nl + IP aus Amsterdam
    passt Beide Angaben passen zusammen. Nichts zu bewerten.
  2. en-US, en + IP aus Amsterdam
    mehrdeutig Englische Browser gibt es überall. Allein ein schwaches Signal, das zusammen mit anderen aber zählt.
  3. pt-BR, pt + IP aus Amsterdam
    Abweichung Der Browser deutet auf Brasilien, während die Pakete aus den Niederlanden kommen wollen. Jetzt wirst du interessant.
  4. Header: nl-NL + JavaScript: pt-BR
    Spoofing erkannt Der Browser widerspricht sich selbst. Außer gezielter Manipulation verursacht das kaum etwas.
Bewertungssysteme brauchen keine Gewissheit, sondern eine Richtung. Jede Stufe nach unten erhöht das Risiko. Die letzte ist halbfertigen Fälschungen vorbehalten.

Daneben gibt es einen unauffälligeren Preis. Die genaue Zusammenstellung deiner Liste, die Sprachen, ihre Reihenfolge und q-Werte, eignet sich für Fingerprinting. Die Panopticlick-Studie der EFF maß bei Accept-Headern etwa sechs Bit identifizierende Information. Deshalb funktioniert Accept-Language-Fingerprinting: en-US,en;q=0.9 geht in der Masse unter, nl-BE,fr-BE;q=0.9,en;q=0.8,de;q=0.7 wirkt fast wie eine Unterschrift. Zum Vergleich: Deine Schriftartenliste liefert mehr als doppelt so viele Bit. Sie muss aber erst vermessen werden, während der Header bei jeder Anfrage freiwillig mitkommt.

Browserhersteller wissen das. Safari sendet deshalb nur deine erste Sprache. Chrome-Entwickler haben einen Vorschlag zur Kürzung auf eine Sprache, und Brave vergröbert die Antwort gezielt pro Website. Gegen die Abweichung hilft das allerdings nicht: Die übrig gebliebene Sprache ist weiterhin deine.

Warum Google mit VPN die falsche Sprache verwendet

Zurück zum niederländischen Google. Wenn Browser ihre Sprache bei jeder Anfrage höflich nennen, warum ignorieren Websites sie beim VPN-Einsatz? Weil sie der IP-Geolokalisierung stärker vertrauen, und das schon lange vor deinem VPN. Google erklärte es in einer Ankündigung von 2017: Statt Länderversionen an Domains wie google.nl zu knüpfen, sollten sie sich nach dem erkannten Standort richten. Der Header gilt als Wunsch, die IP als Tatsache. Dieselbe Rangfolge nutzt ein Betrugserkennungssystem bei widersprüchlichen Angaben: Die IP gewinnt, der Header wird vom Wunsch zum Indiz.

Wenn dich vor allem die falsche Sprache stört, findest du die Lösung in deinen Kontoeinstellungen und nicht im VPN. Gespeicherte Sprachpräferenzen eines angemeldeten Kontos haben bei Google und vielen großen Websites meist Vorrang vor der IP-Schätzung. Das Datenleck selbst verschwindet dadurch nicht, denn es besteht im Header.

Wieder die Falle des halben Spoofings

Wer den Zeitzonenartikel gelesen hat, kennt die Falle. Bei der Sprache ist sie noch leichter zu übersehen, weil die Information an zwei Stellen liegt: im Netzwerk-Header Accept-Language und in navigator.languages in der JavaScript-Engine. In einem normalen Browser sind das zwei Ansichten derselben Einstellung und sie passen zusammen. Werkzeuge, die eine Seite fälschen, vergessen oft die andere.

Spoofing-Erweiterungen überschreiben meist die JavaScript-Seite, weil sie leicht erreichbar ist. Der Header sagt jedem Server weiterhin die Wahrheit. Proxys, die Header umschreiben, machen es umgekehrt und lassen navigator.languages unverändert. In beiden Fällen widerspricht der Browser sich selbst. Das ist für ein Erkennungssystem aussagekräftiger als die ursprüngliche Abweichung: Normale VPN-Nutzer erzeugen ständig Abweichungen, gezielte Manipulation erzeugt Widersprüche. Außerdem meldet ein überschriebener Getter für navigator.languages beim Auslesen seines Quelltexts nicht mehr [native code]. Dieses Erkennungszeichen behandeln wir im Artikel zur Bot-Erkennung.

Die Fälschung, die im großen Maßstab funktioniert, ist unspektakulär: Tor Browser antwortet in seiner englischen Standardkonfiguration für alle mit en-US,en;q=0.5. Deine Sprache verschwindet, weil du allen anderen Tor-Nutzern gleichst. Schutz gegen die offensichtliche Erkennbarkeit als Tor-Nutzer einzutauschen, ist die ehrliche Version dessen, was halbherzige Erweiterungen versprechen.

Was du konkret tun kannst

  1. Führe den Test aus. Das Widget vergleicht deine Browsersprachen mit deinem IP-Land nach denselben Erwartungen wie ein Betrugserkennungsscript. Lass das VPN dabei an, denn diese Konfiguration bestimmt deine Risikobewertung. Ergänze den vollständigen Browser-Scan für Zeitzone, WebRTC und Fingerprints.
  2. Passe die Sprachen an dein VPN an. Wie bei der Zeitzone ist die saubere Lösung, die Angabe wahr zu machen. Ergänze die Sprache des Ausgangslands in deiner Browserliste, in Chrome unter chrome://settings/languages, in Firefox unter „Bevorzugte Sprachen“. Deine echte Sprache kann daneben bleiben. Viele Systeme prüfen, ob irgendeine Sprache passt, nicht ob alle passen. Nutze die Browsereinstellungen statt einer Erweiterung, damit sich Header und JavaScript gemeinsam ändern.
  3. Bei mehreren Identitäten reichen manuelle Einstellungen nicht aus. Für jedes Profil müssen Sprachen, Zeitzone und IP in jeder Sitzung zusammenpassen. Das ständig von Hand zu pflegen, hält dem Arbeitsalltag kaum stand. Incogniton stimmt die Sprache jedes Profils auf dessen Proxy ab, gleichzeitig im Header und in JavaScript. So widerspricht der Browser seinen eigenen Paketen nicht.

Dein Browser hat dem zuletzt besuchten Server verraten, welche Sprache du liest. Das Widget oben zeigt, ob deine IP diese Aussage stützt.

Incogniton-Logo

Bring deine Privatsphäre aufs nächste Level

Pfeil