LinkedIns BrowserGate – und warum eine einzige Browser-Identität nicht mehr ausreicht

Anfang April hat eine europäische LinkedIn-Nutzervereinigung namens Fairlinked e.V. eine Untersuchung veröffentlicht, die – je nach Zählweise – entweder die detaillierteste oder die am wenigsten überraschende Browser-Fingerprinting-Geschichte des Jahrzehnts war. Das hauseigene Frontend-JavaScript von LinkedIn, so zeigten sie, feuert bei jedem Seitenaufruf zwischen sechs- und siebentausend fetch()-Anfragen an chrome-extension://-URLs ab, prüft, ob jede einzelne auflöst, sammelt 48 weitere Geräte- und Browsermerkmale ein und schickt das ganze Paket – RSA-verschlüsselt, an jeden nachfolgenden API-Aufruf angehängt – zurück an LinkedIns Telemetrie-Endpunkt.

Die Berichterstattung wurde von The Next Web aufgegriffen, unabhängig von 404 Privacy verifiziert und in einer langen technischen Analyse, die die tatsächlichen Payloads Schritt für Schritt durchgeht, auf Code-Ebene rekonstruiert. Fairlinkeds Schwesterorganisation Teamfluence Signal Systems hatte bereits im Januar 2026 in München einen Antrag auf einstweilige Verfügung nach dem Digital Markets Act der EU (DMA – die europäische Verordnung, die vorgibt, wie Gatekeeper-Plattformen Nutzerinnen und Nutzer zu behandeln haben) gestellt. Das Gericht lehnte ihn ab. LinkedIn seinerseits erklärte gegenüber Journalistinnen und Journalisten, die Vorwürfe seien „schlicht falsch” und sein Scanning richte sich nur gegen Erweiterungen, die gegen die Nutzungsbedingungen verstoßen.

In diesem Beitrag geht es nicht darum, ob LinkedIn in Irland oder Deutschland im Recht ist. Es geht um das, was die Geschichte veranschaulicht: Der Browser, in dem Sie das gerade lesen, war niemals darauf ausgelegt, sich gegen diese Art von Vorgehen zu wehren – und, wichtiger noch, er kann sich nicht dagegen wehren, weil er nur eine einzige Identität zu vergeben hat.

Was die Seite beim Aufruf von linkedin.com tatsächlich tut

Es laufen zwei Mechanismen parallel, und beide sind es wert, verstanden zu werden, auch wenn Sie nie ein DevTools-Panel öffnen.

Aktive Erweiterungserkennung. Die Seite liefert eine fest einprogrammierte Liste von über 6.000 Chrome-Erweiterungs-IDs mit. Für jede einzelne feuert sie ein fetch() an eine bekannte Datei innerhalb des Erweiterungspakets – etwa chrome-extension://<id>/manifest.json oder ein bestimmtes Icon. Gelingt der Fetch, ist die Erweiterung installiert; lehnt Chrome die Anfrage ab, ist sie es nicht. Der Trick funktioniert nur bei Erweiterungen, die mindestens eine „web-accessible resource” freigeben – was die meisten echten Erweiterungen tun. Der Artikel berichtet, dass eine Tarnvariante window.requestIdleCallback() mit gestaffelten Verzögerungen einsetzt, um das Netzwerk-Panel nicht auflodern zu lassen.

Passives DOM-Scannen („Spectroscopy”). Parallel dazu durchläuft die Seite Ihr DOM und sucht nach chrome-extension://-URL-Referenzen. Das erfasst Erweiterungen, die Inhalte in die Seite injizieren – jene, die die fest einprogrammierte Liste womöglich übersehen hat, oder neuere, die die Liste noch nicht kennt.

Die Ergebnisse fließen in eine Fingerprinting-Pipeline, die LinkedIn intern APFC nennt – für „Anti-fraud Platform Features Collection”, mit einem zweiten Namen DNA für „Device Network Analysis”. Neben der Erweiterungsliste sammelt die Pipeline:

Diese Signale werden zu einem verschlüsselten Blob zusammengefügt und als HTTP-Header an jede nachfolgende API-Anfrage der Seite angehängt – so weiß LinkedIns Backend jederzeit, bei jedem Hop, genau, welches Gerät Sie sind. Die Untersuchung berichtet, dass LinkedIn Maßnahmen ergriffen hat – Kontosperrungen, Verwarnungen – gegen Nutzerinnen und Nutzer, die Erweiterungen verwenden, die ihm nicht passen; das ist der direkteste Beleg dafür, dass die Daten tatsächlich verwendet und nicht nur gesammelt werden.

Unter der rechtlichen Frage liegt eine echte Frage verborgen: Wenn LinkedIn das in diesem Umfang tut, wie viele andere Seiten tun dann eine kleinere Version davon? Die ehrliche Antwort: die meisten großen. LinkedIn ist nur insofern ungewöhnlich, als die Breite seiner Erweiterungsliste und die Sorgfalt, mit der sie konstruiert wurde, herausragen. Der Rest des Consumer-Webs fährt das gleiche Grundschema mit unterschiedlichem Raffinementgrad.

Das Problem ist nicht Fingerprinting. Es ist die Wiederverwendung der Identität.

Ein Schritt zurück. Canvas, WebGL, WebRTC, Schriftarten-Enumeration – das ist nichts Neues. Jede Sicherheitsforscherin und jeder Sicherheitsforscher der letzten zehn Jahre hat einen Essay geschrieben, der mit „Schalten Sie Firefox' resistFingerprinting ein” oder „Installieren Sie CanvasBlocker” endet. Dieser Rat ist nicht direkt falsch, aber er verfehlt die tragende Wand des Problems.

Selbst wenn Sie perfekten Fingerprinting-Schutz hätten – jedes Signal normalisiert, jedes Canvas leer, jede WebRTC-Verbindung verweigert –, hätte Ihr Browser immer noch ein einziges Cookie-Glas, eine einzige History-Datei, einen einzigen Satz angemeldeter Sitzungen, einen einzigen Passworttresor, eine einzige Liste installierter Erweiterungen, eine einzige IP-Adresse auf Netzwerkebene. Alles, was Sie im Web tun, kommt aus dieser einen Identität heraus. Ein Fingerprinter, der Ihr Canvas nicht lesen kann, erkennt dennoch, dass die Person, die sich bei LinkedIn eingeloggt hat, die Person, die sich bei Facebook eingeloggt hat, die Person, die sich eine kleine unabhängige Buchhandlung angesehen hat, und die Person, die ihr Gesundheitsportal geprüft hat, alle aus derselben Browser-Instanz mit denselben Cookies von derselben IP kamen. Und der Netzwerkeffekt ist seitenübergreifend: LinkedIns Daten werden in dem Moment nützlicher, in dem sie mit den Daten irgendeiner anderen Seite zusammengeführt werden.

Deshalb löst eine einzelne Anti-Fingerprinting-Erweiterung das Problem nicht wirklich, und deshalb löst auch „Benutzen Sie ein VPN” oben auf einem gewöhnlichen Browser das Problem nicht. Ein VPN ändert Ihre scheinbare IP, aber es teilt Ihren Browser nicht in mehrere Identitäten auf. Sie haben weiterhin ein einziges Cookie-Glas. Sie haben weiterhin einen einzigen Satz an Sitzungen. LinkedIn und Facebook sehen weiterhin dieselbe Maschine – und jetzt, für sie praktisch, eine Maschine, die gegen die IP-Historie eines VPNs gegengeprüft wurde.

Das Argument für ein VPN pro Tab

Hier beginnt sich etwas anders anzufühlen. Weil jeder Bromure-Tab seine eigene verwerfbare virtuelle Linux-Maschine ist, gehört das VPN zum Tab, nicht zum ganzen Browser. Nicht zum ganzen Computer. Zum Tab.

Sie können Ihrem LinkedIn-Profil einen Mullvad-Endpunkt in Schweden zuweisen, Ihrem Facebook-Profil einen ProtonVPN-Endpunkt in der Schweiz, Cloudflare WARP einem Profil für „zufällige Links” und Ihrem lokalen Banking-Profil gar nichts – alles gleichzeitig, auf demselben Mac, in derselben Bromure-App. LinkedIn sieht den schwedischen Ausgang. Facebook sieht den Schweizer Ausgang. Die Bank sieht Ihre tatsächliche Heimverbindung. Keiner hat eine saubere Möglichkeit zu bemerken, dass sie auf denselben Laptop derselben Person schauen.

Das ist keine theoretische Trennung. Bromure bootet pro Tab einen echten Linux-Kernel, über Apple's Virtualization.framework. Jede VM hat ihren eigenen Kernel-Netzwerkstack, ihre eigene /etc/hosts, ihren eigenen Prozessbaum, ihren eigenen Satz Chromium-Flags, ihr eigenes Profilverzeichnis auf einer eigenen virtuellen Festplatte. Zwei Tabs auf zwei Fingerprinting-Seiten, die über zwei verschiedene VPN-Endpunkte ausgeliefert werden, sind von zwei separaten Personen mit zwei separaten Laptops nicht zu unterscheiden, weil sie auf der Ebene, auf der Fingerprinting operiert, genau das sind.

Die Einstellung für das VPN pro Tab findet sich im Panel VPN & Ads des Profils und bietet drei Optionen: Cloudflare WARP (Cloudflares Verschlüsselungsdienst für Endnutzer), WireGuard (beliebiger Anbieter, beliebiger selbst gehosteter Server – eine .conf-Datei einfügen) oder IKEv2 (für Unternehmens-VPNs). Das VPN läuft innerhalb der VM, was bedeutet, dass selbst der Gast-Chromium-Prozess Ihre echte IP nicht sieht.

Bromure deaktiviert WebRTC standardmäßig

WebRTC ist die direkte Ursache des LAN-IP-Lecks in BrowserGate. Es wurde für Browser-zu-Browser-Video- und Audioanrufe entworfen und kann als Nebeneffekt der Art und Weise, wie es Netzwerkpfade entdeckt, dazu gebracht werden, Ihre lokalen Netzwerkschnittstellen zu enumerieren. Jede Seite – nicht nur die, mit denen Sie telefonieren – kann diese Enumeration im Hintergrund durchführen und Dinge wie „dieser Router hat dem Nutzer 192.168.1.47 zugewiesen, er ist also in einem typischen Heimnetzwerk, demselben Bereich wie beim letzten Besuch mit diesem Fingerabdruck” in Erfahrung bringen.

Bromure schaltet WebRTC standardmäßig für jedes Profil aus, bei dem nicht sowohl Webcam als auch Mikrofon aktiviert sind. Konkret: Wenn ein Profil keinen Webcam- oder Mikrofonzugriff benötigt, fügt der Bromure-Launcher zwei Chromium-Flags hinzu:

• --force-webrtc-ip-handling-policy=disable_non_proxied_udp
• --enforce-webrtc-ip-permission-check

und lädt eine kleine Browser-Erweiterung namens webrtc-block, die den RTCPeerConnection-Konstruktor durch einen leeren Stub ersetzt. Dieser letzte Teil ist wichtig: Das Policy-Flag allein verhindert das Durchsickern der IP über UDP, aber ein entschlossener Fingerprinter kann immer noch RTCPeerConnection instanziieren und Verhalten beobachten; der Stub bringt sogar den Konstruktor zum Scheitern. Das Nettoergebnis ist, dass eine Seite, die LinkedIns LAN-IP-Trick auf einem Bromure-Profil versucht, das WebRTC nicht braucht, nichts zurückbekommt.

Sie müssen dafür nichts umschalten. Es ist der Standardzustand für jedes Profil, in dem keine Video-Anruf-Hardware aktiviert ist. Wenn Sie in einem Profil im Panel Media die Webcam- oder Mikrofonfreigabe einschalten, kommen die VPN- und Videoanruf-Szenarien, die WebRTC benötigen, automatisch zurück. Die Einstellung lautet „nur an, wenn Sie es wirklich brauchen”, was näher an dem liegt, wie das Web funktionieren sollte.

Was Isolation nicht behebt

Zwei Dinge, die man gleich vorneweg benennen sollte. Erstens: Wenn Sie sich mit Ihrem echten Namen aus jedem Profil bei LinkedIn anmelden, weiß LinkedIn, dass Sie es sind. Isolation macht Sie nicht anonym gegenüber Diensten, bei denen Sie sich freiwillig anmelden; sie durchbricht seitenübergreifende Identitätsverknüpfung und stoppt passive Wiedererkennung zwischen Sitzungen. Das sind echte Gewinne, aber sie sind keine Anonymität.

Zweitens kann Bromure LinkedIn nicht davon abhalten, seinen Erweiterungs-Scan innerhalb der Bromure-VM auszuführen. Es kann – und tut – die Ergebnisse des Scans uninteressant machen: Ein Bromure-Profil hat standardmäßig keine Chrome-Erweiterungen installiert außer Bromures eigenen internen, und die leben auf anderen, profilgebundenen Erweiterungs-IDs, die nicht in LinkedIns fest einprogrammierter Liste stehen. Die Seite tastet brav 6.000 IDs ab; nichts kommt zurück. Der 48-Attribute-Fingerabdruck wird dennoch erfasst – aber er identifiziert eine verwerfbare VM, deren WebRTC, Cookies und IP sich nicht mit irgendeiner anderen VM überschneiden, die Sie betreiben.

Das reicht, um BrowserGate als Werkzeug zur seitenübergreifenden Korrelation zu entschärfen. Es reicht nicht, Sie vor LinkedIn zu verbergen, sobald Sie angemeldet sind, und wir werden nicht so tun, als wäre es anders.

Empfohlene Bromure-Einstellungen für LinkedIn (und vergleichbare Seiten)

Wenn Sie ein eigenes LinkedIn-Profil einrichten, oder ein Facebook-Profil, oder eine andere soziale Plattform, die bekanntermaßen aggressiv fingerprintet, sind das die Standards, die man prüfen sollte. Alles Folgende findet sich im Einstellungs-Panel pro Profil (Zahnradsymbol neben dem Profil in der Liste).

Ein paar nicht offensichtliche Hinweise. WebRTC ist für dieses Profil bereits aus, solange Webcam und Mikrofon beide aus sind – Sie müssen es nirgendwo einstellen, und es gibt kein Kontrollkästchen dafür, weil es aus diesen beiden Einstellungen abgeleitet wird.

Wenn Sie ein dediziertes LinkedIn-Profil für die Arbeit betreiben und möchten, dass die VPN-Sitzung einzelne Tab-Schließungen überdauert, kombinieren Sie Browsing-Daten behalten mit Beim Start verbinden unter WireGuard – das VPN kommt dann automatisch hoch, sobald Sie dieses Profil wieder öffnen.

Sie können das noch weiter treiben. Das Panel Erweitert enthält eine Option Browsing-Daten verschlüsseln, die die persistente Festplatte per LUKS mit einem im macOS Keychain hinterlegten Schlüssel verschlüsselt. Das ist ein vernünftiger Paranoiagrad für alles, was mit Social-Media-Nähe hat und Neustarts überleben soll.

Die Form der Lösung

BrowserGate ist ein treffendes Symbol für etwas, das seit einer Weile wahr ist und schlimmer wird: Gewöhnliche Browser können sich dieser Art von Überwachung nicht sinnvoll entgegenstellen, weil ihre gesamte Architektur um eine einzige Identität pro Browser-Instanz herum gebaut ist. Sie können Erweiterungen installieren, um bestimmte Lecks einzudämmen, und das sollten Sie auch; aber die strukturelle Antwort ist ein Browser, in dem jeder Tab sein eigener Computer ist, mit eigenem Netzwerk, eigener Privatsphäre-Oberfläche und eigener Möglichkeit, zu enden. Schließen Sie das Fenster, und diese Identität – was auch immer LinkedIns Scanner gesammelt hat, welche Korrelations-Cookies sich auch angehängt haben – ist weg.

Das ist die ganze Form der Lösung. Sie hängt nicht davon ab, dass LinkedIn zustimmt aufzuhören, und sie hängt nicht vom DMA ab. Sie hängt davon ab, dass Ihr Browser eine andere Form hat als der, der auf dem Laptop war, den Sie damit gekauft haben.