Ein Chrome-Fenster, mehrere isolierte Arbeitsbereiche: wie das technisch funktioniert
Isolation in einem einzigen Fenster sind drei Schichten übereinander: Sitzung und Speicher, Netzwerkrouting, Lebenszyklus — keine Virtualisierung des Kernels. Der Fingerprint bleibt, wie er ist.
Warum mehrere Fenster noch keine mehreren gleichzeitig angemeldeten Konten sind
Zuerst eine Intuition, die weg muss: Ein Fenster ist keine Isolationseinheit. Zehn Fenster in einem Profil teilen sich einen Cookie-Speicher, ein localStorage und einen HTTP-Cache; die Website sieht eine Sitzung. Der Inkognito-Modus hat tatsächlich einen eigenen Speicher, aber nur einen, und er stirbt mit dem Fenster — für zehn Konten reicht das nicht. Die echte Einheit ist ein Sitzungscontainer: ein eigenständiger Cookie-Bestand, ein eigener Speicher-Namensraum und eine stabile Zuordnung. Chrome kennt keine Container-API (Firefox’ contextualIdentities ist die Ausnahme), also baut die Erweiterung sie auf der Sitzungsebene selbst: Sie merkt sich, welcher Tab zu welchem Container gehört, und teilt danach Anfragen und Seitenspeicher auf. CrispLogin arbeitet so: Der Container ist eine Zuordnung, die die Erweiterung führt, kein Chrome-Primitiv. Die Einheit der Isolation ist die Sitzung, nicht der Prozess.
Schicht eins: warum Cookies nicht überlaufen
Konten bleiben getrennt durch ein virtuelles Cookie-Glas plus tabgenaues Umschreiben des Anfrage-Headers. Jeder Container hält in der Erweiterung eigene Cookie-Einträge. Bevor eine Anfrage rausgeht, gleicht eine declarativeNetRequest-Session-Rule den Tab über condition.tabIds ab und setzt den cookie-Anfrage-Header komplett auf den Wert dieses Containers. Kommt die Antwort zurück, beobachtet webRequest das Set-Cookie und schreibt es in das passende Glas. Das Glas muss seine Cookies nach Pfadlänge und Erstellzeit sortieren und serialisieren, sonst entspricht der Header nicht dem, was der Browser selbst gesendet hätte.
Der häufig übersehene Teil ist die Lebensdauer: tabIds funktioniert nur bei Session-Rules, und Session-Rules werden beim Beenden des Browsers und beim Update der Erweiterung gelöscht. Die Regeln müssen also bei jedem Start neu installiert werden — bleibt das aus, lautet das Symptom „nach einem Neustart sind alle Arbeitsbereiche dasselbe Konto“. Der Seitenspeicher ist eine zweite Fläche: document.cookie liest den echten Cookie-Speicher, und localStorage hat genau einen Namensraum, also muss ein Skript in der MAIN-World Lese- und Schreibzugriffe pro Container vermitteln. Das ist Isolation auf Anwendungsebene: Sie trennt zwei Konten derselben Website, berührt aber den Kernel-Fingerprint nicht.
Schicht zwei: wie der Proxy dem Arbeitsbereich folgt
Chrome hat keine API für einen Proxy pro Tab. chrome.proxy.settings gilt für das gesamte Profil, und FindProxyForURL(url, host) in einem PAC-Skript bekommt nie eine tabId. declarativeNetRequest kann Header ändern und umleiten, hat aber keine Aktion „Upstream-Proxy wählen“. Was eine Erweiterung leisten kann, ist eine Zuordnung Arbeitsbereich → Ausgang zu führen und diese profilweite Konfiguration neu zu schreiben, wenn der vordere Tab wechselt.
PAC kann nach Domain trennen, aber die Grundlage ist die URL, nicht der Tab — dieselbe Website in zwei Arbeitsbereichen bekommt von PAC eine einzige Antwort. „Zehn Arbeitsbereiche, jeder mit eigenem Tunnel“ gibt es in einer Erweiterung deshalb nicht; garantiert ist „welcher Arbeitsbereich vorne ist, dessen Ausgang gilt“. Deshalb sieht man beim Wechsel einen Reconnect: Ändert sich die Proxy-Konfiguration, werden bestehende Verbindungen neu aufgebaut. Grenze: Diese Schicht tauscht Ausgangs-IP und Anfrageweg, nicht den TCP/TLS-Fingerprint (JA3/JA4). WebRTC lässt sich mit chrome.privacy.network.webRTCIPHandlingPolicy auf nicht-proxied UDP beschränken, aber das ist eine browsweite Richtlinie, keine pro Arbeitsbereich.
Schicht drei: überlebt die Zuordnung geschlossene Tabs und einen Neustart?
Der MV3-Hintergrund ist ein Service Worker: 30 Sekunden ohne Ereignis, und er wird beendet — samt Modulvariablen und jeder Map in einer Closure. „Welcher Tab gehört zu welchem Arbeitsbereich“ darf also nicht im Speicher liegen, sondern gehört in chrome.storage.session. Dieser Bereich bleibt im Speicher, solange die Erweiterung geladen ist, übersteht das Recyceln des Workers und wird beim Neustart des Browsers geleert. Zu beachten: Er ist standardmäßig nicht für Content-Scripts offen; soll die Seite die Zuordnung lesen, muss setAccessLevel explizit aufgerufen werden.
Damit teilen sich die Daten in zwei Sorten: Laufzeitzuordnungen in session, alles Neustartfeste — Arbeitsbereichsliste, Proxy-Konfiguration, Snapshot-Index — in storage.local. Die Kausalkette ist direkt: Weil die Zuordnung in session liegt und nicht in einer Variablen, weiß die Erweiterung nach dem Aufwachen weiterhin, welcher Tab wohin gehört, und schüttet nicht die Cookies des einen Arbeitsbereichs in die Seite des anderen. Läge sie nur im Speicher, hätte die nächste Anfrage nach dem Einschlafen des Workers keinen Besitzer — sichtbar als doppelte Gruppen und Snapshots, die im falschen Container landen.
Schicht vier: was ein Website-Snapshot speichert und was er zurückspielt
Ein Snapshot beantwortet eine andere Frage: die Portabilität des Login-Zustands, nicht die Isolation zur Laufzeit. Er steht an vierter Stelle, gehört aber nicht zur Isolation selbst. Er serialisiert die Cookies einer Website in einem Container samt deren Speicher und spielt sie beim Wiederherstellen in den Namensraum dieses Containers zurück. Beides ist orthogonal: Isolation verhindert, dass zwei Arbeitsbereiche sich stören, solange beide existieren; ein Snapshot erspart die erneute Anmeldung. Die Körnung ist die Website, nicht der Browser: zwei Websites in einem Container sind zwei unabhängige Datensätze.
Deshalb muss ein Snapshot zu einem Container gehören — den Login-Zustand von A in B zu schütten verschmilzt zwei Konten zu einem. Ebenso wichtig ist, was er nicht tut: Er stellt Anwendungszustand wieder her, keinen Kernel-Fingerprint, und er verspricht nicht, Risikoprüfungen oder Gerätevalidierung einer Plattform zu umgehen. Zur Anwendung: Interner Link: Website-Snapshots in der Praxis.
Worin unterscheidet sich das von mehreren Profilen?
Mehrere Profile in Chrome sind ein physischer Schnitt auf Ebene des Speicher-Stammverzeichnisses: Jedes Profil bekommt eigenen Cookie-Speicher, eigenen Speicher, eigene Erweiterungen und eigenen Cache — die Isolation ist vollständig. Der Preis zeigt sich auf vier Achsen: Arbeitsspeicher, weil jedes Profil einen eigenen Netzwerk-Kontext und eigene Renderer-Prozesse hat, drei Profile also rund dreimal so viel Grundlast bedeuten; Prozesse, weil die Prozessbäume getrennt sind; Fenster, weil ein Profil ein Fenster ist und Wechseln Fensterwechsel heißt; Fingerprint, weil Profile sich einen Kernel und eine Maschine teilen und UA, Canvas und Schriften standardmäßig identisch sind. Dazu kommt ein leiser Kostenpunkt: Lesezeichen, Erweiterungen und Verlauf werden nicht geteilt, ab drei Profilen driftet alles auseinander.
Der Erweiterungsweg kehrt das um: ein Profil, ein Fenster, geteilte Prozesse und ein geteilter Kernel — dafür Parallelität im Einzelfenster zu nahezu null Zusatzkosten, und der Preis ist, dass die Kernel-Fingerprint-Schicht unerreichbar bleibt. Das sind nicht zwei Stufen derselben Sache, sondern zwei Schnitte derselben Granularität. Im Vergleich: Interner Link: Chrome-Profile versus Erweiterungsisolation.
Grenzen: welche Schichten eine Erweiterung abdeckt und welche nicht
Die bisherigen Grenzen, in einer Tabelle verdichtet. Die Leseart: Was prüft die Plattform? Für Sitzung und Ausgang die mittlere Spalte, für Fingerprint-Konsistenz die rechte. Und noch einmal deutlich: Eine Erweiterung macht Isolation auf der Sitzungsebene, nicht dieselbe Stufe wie ein Antidetect-Browser. Wer sie für einen leichteren Antidetect-Browser hält, schätzt das Risiko falsch ein.
| Schicht | Von der Erweiterung abgedeckt | Nicht erreichbar oder der Preis |
|---|---|---|
| Cookies und Login-Zustand | Pro Container getrennt, als Snapshot serialisierbar | Der Kernel kennt keine Container; Header werden umgeschrieben, gehen die Regeln verloren, läuft es über |
| Seitenspeicher | localStorage und IndexedDB lassen sich pro Container präfixen oder proxyen | Service Worker, SharedWorker und andere getrennte Kontexte brauchen eigene Abdeckung |
| Ausgangs-IP | An den Arbeitsbereich gebunden, vorderer Tab wechselt den Ausgang | Nur ein Ausgang gleichzeitig; keine parallelen Tunnel |
| WebRTC | Nicht-proxied UDP lässt sich abschalten (browsweite Richtlinie) | Nicht pro Arbeitsbereich; Medienpfade können den Proxy weiterhin umgehen |
| TLS-Fingerprint | Nichts | JA3/JA4 kommen aus Kernel und Netzwerk-Stack |
| Canvas / WebGL / Audio | Nichts | Rendering läuft im Kernel; keine API zum Umschreiben |
| Font-Enumeration | Nichts | Nur Patches auf Seiten-JS, und die sind erkennbar |
| HTTP-Cache | Nichts | Der Cache gilt pro Profil und wird zwischen Containern geteilt |
Die Tabelle zeigt auch, wo die Decke liegt: Eine Erweiterung ersetzt das Motiv, allein zum getrennten Anmelden einen Client zu kaufen — nicht den Client. Welcher Weg passt, ist eine andere Frage und wird Punkt für Punkt verglichen in Interner Link: Erweiterung versus Antidetect-Browser.
Häufige Fragen
Ist die Cookie-Isolation einer Erweiterung dasselbe wie Chromes Partitioned Cookies?
Nein. Partitioned Cookies werden nach Top-Level-Site verschlüsselt, eine Website hat also pro Top-Level-Seite genau ein Glas; partitionKey in der cookies-API ist nur der Schlüssel zum Lesen und Schreiben dieser Cookies, und sein einziger Bestandteil ist topLevelSite — neue Partitionen lassen sich damit nicht erfinden. Das Glas eines Arbeitsbereichs ist nach Container getrennt, eine Website kann beliebig viele haben, und die Erweiterung führt die Bücher. Das eine ist Datenschutz-Partitionierung des Browsers, das andere eine Sitzungsabstraktion der Erweiterung.
Bleibt der Zustand eines Arbeitsbereichs erhalten, wenn ich den Tab schließe?
Drei Fälle. Der Tab ist weg, die Zuordnung geht mit. Arbeitsbereichsdefinitionen — Name, Proxy, Snapshot-Index — müssen einen Neustart überleben und liegen üblicherweise in storage.local. Der Login-Zustand ist nur wiederherstellbar, wenn ein Snapshot gespeichert wurde; sonst meldet man sich neu an. Inhalte von storage.session werden beim Schließen des Browsers gelöscht, behandeln Sie sie nicht als dauerhaft.
Kostet der Einzelfenster-Ansatz Performance?
Der Zuwachs kommt von den Tabs, nicht von der Isolation. Es startet kein zweiter Browser, kein Kernel wird kopiert; der Aufwand sind Regelabgleich und Header-Umschreiben, also ein konstanter Betrag pro Anfrage. Die echten Kosten liegen in der Zahl der Tabs und den Seiten selbst: Bei zwanzig Arbeitsbereichen ruckelt das Rendering, nicht die Isolationsschicht.
Können zwei Arbeitsbereiche gleichzeitig verschiedene Ausgangs-IPs nutzen?
Nein. Die Proxy-Konfiguration gilt profilweit, und eine Erweiterung kann sie nur beim Tabwechsel neu schreiben. Zu jedem Zeitpunkt nutzt also nur der vordere Arbeitsbereich seinen eigenen Ausgang; hintere Arbeitsbereiche werden durch Regeln blockiert oder gehen direkt raus. Echte parallele Tunnel brauchen einen Client mit eigenem Netzwerk-Stack.
Quellen und letzte Aktualisierung
Wo dieser Artikel API-Verhalten berührt, gilt die offizielle Dokumentation. Die Grenzen einer Erweiterung verschieben sich mit den Chrome-Versionen — prüfen Sie vor dem Einsatz die dann aktuelle Dokumentation.
- Chrome for Developers, chrome.declarativeNetRequest — Lebensdauer von Session-Rules, Reichweite von condition.tabIds und modifyHeaders für den cookie-Anfrage-Header: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers, chrome.storage — der session-Bereich liegt im Speicher, wird beim Browser-Neustart geleert und ist standardmäßig nicht für Content-Scripts offen: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers, chrome.cookies — partitionKey und die Schlüsselsemantik von Partitioned Cookies (CHIPS): developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers, chrome.proxy — Proxy-Einstellungen gelten für das gesamte Browserprofil, PAC erhält nur URL und Host: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers, The extension service worker lifecycle — Beendigung nach 30 Sekunden Leerlauf, globale Variablen gehen mit dem Worker verloren: developer.chrome.com/…/service-workers/lifecycle
Letzte Aktualisierung: 11. November 2026. Beschrieben ist der allgemeine Umsetzungsweg dieser Art von Erweiterung; welche APIs und Speicherorte ein Produkt tatsächlich nutzt, kann abweichen, und für dessen Interna gilt dessen eigene Dokumentation.