Kilka izolowanych obszarów roboczych w jednym oknie Chrome: jak to działa
Izolacja w jednym oknie to trzy warstwy jedna na drugiej: sesja i magazyn, trasowanie sieci, cykl życia. To nie wirtualizacja jądra i nie zmienia odcisku.
Dlaczego kilka okien to jeszcze nie kilka kont zalogowanych naraz
Zacznijmy od intuicji, którą trzeba rozebrać: okno nie jest jednostką izolacji. Dziesięć okien w jednym profilu dzieli jeden magazyn cookie, jeden localStorage i jeden cache HTTP, a witryna widzi jedną sesję. Tryb incognito ma wprawdzie osobny magazyn, ale tylko jeden i ginie razem z oknem, więc nie obsłuży dziesięciu kont. Prawdziwą jednostką jest kontener sesji: własny zestaw cookie, własna przestrzeń nazw magazynu i stabilna mapa przynależności. Chrome nie ma API kontenerów — wyjątkiem jest contextualIdentities w Firefoksie — więc rozszerzenie buduje je samo na poziomie sesji: zapisuje, która karta należy do którego kontenera, a potem rozdziela żądania i magazyn strony według tej mapy. CrispLogin działa właśnie tak: kontener to prowadzony przez rozszerzenie zapis przynależności, a nie mechanizm Chrome. Jednostką izolacji jest sesja, nie proces.
Warstwa pierwsza: dlaczego cookie się nie mieszają
Konta się nie mieszają dzięki wirtualnemu słoikowi cookie oraz przepisywaniu nagłówka żądania na poziomie karty. Każdy kontener trzyma w rozszerzeniu własne rekordy cookie. Zanim żądanie wyjdzie, session rule z declarativeNetRequest dopasowuje kartę przez condition.tabIds i ustawia nagłówek cookie w całości na wartość tego kontenera; gdy wraca odpowiedź, webRequest obserwuje Set-Cookie i zapisuje je do właściwego słoika. Słoik musi serializować cookie w kolejności długości ścieżki, a potem czasu utworzenia, inaczej nagłówek nie zgodzi się z tym, co wysłałaby sama przeglądarka.
Najczęściej umyka czas życia: tabIds działa tylko w session rules, a session rules są czyszczone przy zamknięciu przeglądarki i przy aktualizacji rozszerzenia. Reguły trzeba więc instalować od nowa przy każdym starcie; pominięcie tego daje objaw „po restarcie wszystkie obszary robocze to jedno konto”. Magazyn strony to druga płaszczyzna: document.cookie czyta prawdziwy magazyn cookie, a localStorage ma jedną przestrzeń nazw, więc skrypt w MAIN world musi pośredniczyć w odczycie i zapisie per kontener. To izolacja warstwy aplikacji: rozdziela dwa konta na tej samej witrynie, ale nie dotyka odcisku jądra.
Warstwa druga: jak proxy podąża za obszarem roboczym
Chrome nie ma API „proxy na kartę”. chrome.proxy.settings działa na cały profil, a FindProxyForURL(url, host) w skrypcie PAC nigdy nie dostaje tabId; declarativeNetRequest umie przepisywać nagłówki i przekierowywać, ale nie ma akcji „wybierz proxy nadrzędne”. Rozszerzenie może więc prowadzić mapę obszar roboczy → wyjście i przepisywać tę globalną konfigurację, gdy zmienia się karta na pierwszym planie.
PAC potrafi rozdzielać po domenie, ale na wejściu ma URL, nie kartę — ta sama witryna otwarta w dwóch obszarach roboczych dostaje od PAC jedną odpowiedź. Dlatego „dziesięć obszarów, każdy z własnym tunelem” w rozszerzeniu nie istnieje; gwarantowane jest „czyj obszar jest z przodu, tego jest wyjście”. To także powód widocznego połączenia od nowa przy przełączaniu: zmienia się konfiguracja proxy, więc ustanowione połączenia są odtwarzane. Granica: ta warstwa zmienia wyjściowy IP i ścieżkę żądania, a nie odcisk TCP/TLS (JA3/JA4); WebRTC można ograniczyć przez chrome.privacy.network.webRTCIPHandlingPolicy, odcinając UDP poza proxy, ale to polityka całej przeglądarki, nie pojedynczego obszaru.
Warstwa trzecia: czy powiązanie przetrwa zamknięcie karty i restart
Tło w MV3 to service worker: 30 sekund bez zdarzeń i zostaje zakończony, zabierając zmienne modułu i każdą Map w domknięciu. Dlatego „która karta należy do którego obszaru” nie może leżeć w pamięci — trafia do chrome.storage.session. Ten obszar trzyma się w pamięci, dopóki rozszerzenie jest wczytane, przeżywa recykling workera, a przy restarcie przeglądarki jest czyszczony. Uwaga: domyślnie nie jest udostępniony skryptom treści; jeśli strona ma czytać powiązanie, trzeba jawnie wywołać setAccessLevel.
To dzieli dane na dwa rodzaje: powiązania czasu wykonania w session, a wszystko, co musi przetrwać restart — lista obszarów, konfiguracja proxy, indeks migawek — w storage.local. Łańcuch przyczynowy jest prosty: ponieważ powiązanie leży w session, a nie w zmiennej, po wybudzeniu rozszerzenie nadal wie, do kogo należy każda karta, i nie wylewa cookie jednego obszaru na stronę drugiego. Trzymane tylko w pamięci sprawi, że gdy worker zaśnie, następne żądanie nie ma kogo zapytać o właściciela — widać to jako zduplikowane grupy i migawki wczytane do złego kontenera.
Warstwa czwarta: co migawka witryny zapisuje i co przywraca
Migawka odpowiada na inne pytanie: przenośność stanu logowania, a nie izolację w czasie działania. Jest czwarta na liście, ale nie należy do samej izolacji. Serializuje cookie jednej witryny w jednym kontenerze wraz z magazynem tej witryny, a przy przywracaniu wylewa je z powrotem do przestrzeni nazw tego kontenera. Oba mechanizmy są ortogonalne: izolacja nie pozwala dwóm obszarom przeszkadzać sobie, gdy istnieją jednocześnie; migawka oszczędza ponowne logowanie. Ziarnem jest witryna, nie przeglądarka: dwie witryny w jednym kontenerze to dwa niezależne rekordy.
Dlatego migawka musi należeć do kontenera — wlanie stanu A do B scala dwa konta w jedno. Równie ważne jest, czego nie robi: przywraca stan sesji warstwy aplikacji, a nie odcisk jądra, i nie obiecuje obejścia kontroli ryzyka ani walidacji urządzenia. Zastosowanie: Link wewnętrzny: migawki witryn w praktyce.
Czym to się różni od kilku profili
Wiele profili w Chrome to fizyczne cięcie na poziomie katalogu głównego magazynu: każdy profil ma własny magazyn cookie, własny magazyn, własne rozszerzenia i cache, więc izolacja jest pełna. Cena rozkłada się na cztery osie: pamięć — każdy profil ma własny kontekst sieciowy i własne procesy renderowania, więc trzy profile to w przybliżeniu potrójny koszt stały; procesy — drzewa są osobne; okna — jeden profil to jedno okno, a przełączanie oznacza zmianę okna; odcisk — profile dzielą jedno jądro i jedną maszynę, więc UA, Canvas i fonty są domyślnie identyczne. Jest też cichszy koszt: zakładki, rozszerzenia i historia nie są współdzielone, więc po trzecim profilu wszystko zaczyna żyć własnym życiem.
Podejście z rozszerzeniem odwraca to: jeden profil, jedno okno, wspólne procesy i jądro — w zamian równoległość w jednym oknie przy niemal zerowym koszcie przyrostowym, a ceną jest brak dostępu do warstwy odcisku jądra. To nie dwa stopnie tego samego, lecz dwa różne cięcia ziarna izolacji. Szczegółowe porównanie: Link wewnętrzny: profile Chrome a izolacja rozszerzeniem.
Granice możliwości: które warstwy rozszerzenie pokrywa, a których nie
Powyższe granice, ściśnięte w jedną tabelę. Czyta się ją pytaniem „co sprawdza platforma”: dla sesji i wyjścia — środkowa kolumna, dla spójności odcisku — prawa. I jeszcze raz: rozszerzenie robi izolację warstwy sesji, to nie ten sam stopień co przeglądarka antidetect; branie jej za „lżejszy antidetect” to błędna ocena ryzyka.
| Warstwa | Co pokrywa rozszerzenie | Poza zasięgiem albo cena |
|---|---|---|
| Cookie i stan logowania | Rozdzielone per kontener, serializowane do migawki | Jądro nie zna kontenerów; nagłówki są przepisywane, a utrata reguł oznacza mieszanie kont |
| Magazyn strony | localStorage i IndexedDB można prefiksować lub proxować per kontener | Service worker, SharedWorker i inne osobne konteksty wymagają własnego pokrycia |
| Wyjściowy IP | Przypisany do obszaru; zmiana pierwszego planu zmienia wyjście | Jedno wyjście na pierwszym planie naraz; brak równoległych tuneli |
| WebRTC | UDP poza proxy można odciąć (polityka całej przeglądarki) | Nie per obszar; ścieżki mediów nadal mogą omijać proxy |
| Odcisk TLS | Nic | JA3/JA4 zależą od jądra i stosu sieciowego |
| Canvas / WebGL / Audio | Nic | Renderowanie odbywa się w jądrze; nie ma API do przepisania |
| Enumeracja fontów | Nic | Tylko łatki JS na stronie, i są wykrywalne |
| Cache HTTP | Nic | Cache jest per profil i współdzielony między kontenerami |
Tabela pokazuje też sufit: rozszerzenie zastępuje motyw kupowania klienta wyłącznie po to, by logować się osobno, a nie samego klienta. Którą drogę wybrać, to osobne pytanie, porównane punkt po punkcie w Link wewnętrzny: rozszerzenie a przeglądarka antidetect.
Najczęstsze pytania
Czy izolacja cookie w rozszerzeniu to to samo co Partitioned Cookie w Chrome?
Nie. Partitioned Cookie są kluczowane witryną najwyższego poziomu, więc witryna ma jeden słoik na stronę najwyższego poziomu; partitionKey w API cookies to tylko klucz do odczytu i zapisu takich cookie, a jego jedynym składnikiem jest topLevelSite — nie da się nim wymyślać nowych partycji. Słoik obszaru roboczego jest dzielony per kontener, jedna witryna może mieć ich dowolnie wiele, a rozszerzenie prowadzi księgowość. Pierwsze to partycjonowanie prywatności w przeglądarce, drugie to abstrakcja sesji w rozszerzeniu.
Czy stan obszaru roboczego zostaje po zamknięciu karty?
Trzy przypadki. Karty nie ma, więc powiązanie znika razem z nią. Definicje obszaru — nazwa, proxy, indeks migawek — to dane, które muszą przetrwać restart, i zwykle leżą w storage.local. Stan logowania odtworzysz tylko wtedy, gdy zapisałeś migawkę; inaczej logujesz się ponownie. Zawartość storage.session jest czyszczona przy zamknięciu przeglądarki, więc nie traktuj jej jak warstwy trwałej.
Czy podejście z jednym oknem obciąża przeglądarkę?
Przyrost pochodzi od kart, nie od izolacji. Nie uruchamia się drugiej przeglądarki ani nie kopiuje jądra; koszt to dopasowywanie reguł i przepisywanie nagłówków, czyli stała wartość na żądanie. Prawdziwy koszt leży w liczbie kart i w samych stronach: przy dwudziestu obszarach zacina się renderowanie, a nie warstwa izolacji.
Czy dwa obszary robocze mogą jednocześnie używać różnych wyjściowych IP?
Nie. Konfiguracja proxy jest per profil, a rozszerzenie może ją przepisać tylko przy zmianie karty, więc w danej chwili własnego wyjścia używa wyłącznie obszar na pierwszym planie; te w tle są blokowane regułami albo idą bezpośrednio. Prawdziwie równoległe tunele wymagają klienta z własnym stosem sieciowym.
Źródła i ostatnia aktualizacja
Tam, gdzie tekst dotyka zachowania API, rozstrzyga oficjalna dokumentacja. Granice możliwości rozszerzenia zmieniają się wraz z wersjami Chrome — sprawdź je przed wdrożeniem.
- Chrome for Developers, chrome.declarativeNetRequest — czas życia session rules, zakres condition.tabIds i modifyHeaders dla nagłówka cookie: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers, chrome.storage — obszar session trzyma się w pamięci, jest czyszczony przy restarcie przeglądarki i domyślnie niedostępny dla skryptów treści: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers, chrome.cookies — partitionKey i semantyka klucza Partitioned Cookie (CHIPS): developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers, chrome.proxy — ustawienia proxy działają na cały profil przeglądarki, a PAC dostaje tylko URL i host: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers, The extension service worker lifecycle — zakończenie po 30 sekundach bezczynności i utrata zmiennych globalnych wraz z workerem: developer.chrome.com/…/service-workers/lifecycle
Ostatnia aktualizacja: 11 listopada 2026. Opisano tu ogólną ścieżkę implementacji dla tej klasy rozszerzeń; konkretny produkt może używać innych API i innego miejsca składowania danych, a o jego wnętrzu rozstrzyga jego własna dokumentacja.