Satu jendela Chrome dengan beberapa ruang kerja terisolasi: bagaimana sebenarnya cara kerjanya
Isolasi dalam satu jendela adalah tiga lapisan bertumpuk: sesi dan penyimpanan, perutean jaringan, siklus hidup. Bukan virtualisasi kernel, dan tidak mengubah sidik jari.
Mengapa membuka lebih banyak jendela bukan berarti beberapa akun login sekaligus
Mari bongkar dulu satu intuisi: jendela bukan satuan isolasi. Sepuluh jendela dalam satu profil berbagi satu penyimpanan cookie, satu localStorage, dan satu cache HTTP, dan situs melihat satu sesi. Mode penyamaran memang punya penyimpanan terpisah, tetapi hanya satu dan ikut mati saat jendela ditutup, jadi tidak cukup untuk sepuluh akun. Satuan yang sebenarnya adalah kontainer sesi: kumpulan cookie sendiri, ruang nama penyimpanan sendiri, dan peta kepemilikan yang stabil. Chrome tidak punya API kontainer — pengecualiannya contextualIdentities di Firefox — jadi ekstensi membangunnya di lapisan sesi: mencatat tab mana milik kontainer mana, lalu membagi permintaan dan penyimpanan halaman menurut peta itu. CrispLogin bekerja begitu: kontainer adalah catatan kepemilikan yang dijaga ekstensi, bukan primitif Chrome. Satuan isolasinya adalah sesi, bukan proses.
Lapisan satu: mengapa cookie tidak tercampur
Akun tidak tercampur karena toples cookie virtual ditambah penulisan ulang header permintaan per tab. Setiap kontainer menyimpan catatan cookie-nya sendiri di dalam ekstensi. Sebelum permintaan keluar, session rule declarativeNetRequest mencocokkan tab lewat condition.tabIds dan menetapkan header cookie sepenuhnya ke nilai kontainer itu; saat respons kembali, webRequest mengamati Set-Cookie dan menuliskannya ke toples yang sesuai. Toples harus menserialkan cookie dengan urutan panjang path lalu waktu pembuatan, kalau tidak header-nya tidak akan sama dengan yang seharusnya dikirim browser.
Yang sering terlewat adalah masa hidupnya: tabIds hanya berlaku pada session rule, dan session rule dihapus saat browser ditutup serta saat ekstensi diperbarui. Jadi aturannya harus dipasang ulang setiap kali mulai; melewatkannya memunculkan gejala “setelah restart semua ruang kerja jadi akun yang sama”. Penyimpanan halaman adalah sisi lain: document.cookie membaca penyimpanan cookie yang asli dan localStorage hanya punya satu ruang nama, jadi skrip di MAIN world harus memproksikan baca-tulis per kontainer. Ini isolasi di lapisan aplikasi: memisahkan dua akun di situs yang sama, tetapi tidak menyentuh sidik jari kernel.
Lapisan dua: bagaimana proxy mengikuti ruang kerja
Chrome tidak punya API proxy per tab. chrome.proxy.settings berlaku untuk seluruh profil, dan FindProxyForURL(url, host) pada skrip PAC tidak pernah menerima tabId; declarativeNetRequest bisa menulis ulang header dan mengalihkan, tetapi tidak punya aksi “pilih proxy hulu”. Yang bisa dilakukan ekstensi adalah menjaga peta ruang kerja → jalur keluar dan menulis ulang konfigurasi global itu ketika tab terdepan berganti.
PAC bisa memisahkan berdasarkan domain, tetapi masukannya URL, bukan tab: situs yang sama di dua ruang kerja hanya mendapat satu jawaban dari PAC. Jadi “sepuluh ruang kerja masing-masing punya terowongan sendiri” tidak ada di ekstensi; yang dijamin adalah “ruang kerja yang sedang di depan itulah jalur keluarnya”. Itu juga sebabnya berpindah ruang kerja memunculkan satu koneksi ulang: konfigurasi proxy berubah, koneksi yang sudah terbentuk dibangun kembali. Batas: lapisan ini mengganti IP keluar dan jalur permintaan, bukan sidik jari TCP/TLS (JA3/JA4); WebRTC bisa dibatasi dengan chrome.privacy.network.webRTCIPHandlingPolicy untuk membuang UDP non-proksi, tetapi itu kebijakan seluruh browser, bukan per ruang kerja.
Lapisan tiga: apakah pengikatan bertahan saat tab ditutup atau browser di-restart?
Latar MV3 adalah service worker: 30 detik tanpa peristiwa dan ia dihentikan, membawa serta variabel tingkat modul dan Map apa pun di dalam closure. Jadi “tab mana milik ruang kerja mana” tidak boleh disimpan di memori; ia masuk ke chrome.storage.session, yang tetap di memori selama ekstensi dimuat dan bertahan saat worker didaur ulang, tetapi dikosongkan ketika browser di-restart. Perhatikan: area ini tidak terbuka untuk content script secara bawaan; kalau sisi halaman perlu membaca pengikatan, setAccessLevel harus dipanggil eksplisit.
Dari situ data terbagi dua: pengikatan runtime di session, dan semua yang harus bertahan melewati restart — daftar ruang kerja, konfigurasi proxy, indeks snapshot — di storage.local. Rantai sebabnya langsung: karena pengikatan ada di session dan bukan di variabel, setelah worker dibangunkan ekstensi tetap tahu tab mana milik siapa dan tidak menuangkan cookie satu ruang kerja ke halaman ruang kerja lain. Kalau hanya di memori, begitu worker tidur permintaan berikutnya tidak punya pemilik untuk ditanyakan, dan itu muncul sebagai grup ganda serta snapshot yang masuk ke kontainer salah.
Lapisan empat: apa yang disimpan snapshot situs dan apa yang dipulihkannya
Snapshot menjawab pertanyaan lain: portabilitas status login, bukan isolasi saat berjalan. Ia berada di urutan keempat tetapi bukan bagian dari isolasi itu sendiri. Ia menserialkan cookie satu situs di dalam satu kontainer beserta penyimpanan situs itu, lalu saat dipulihkan menuangkannya kembali ke ruang nama kontainer tersebut. Keduanya ortogonal: isolasi mencegah dua ruang kerja saling mengganggu selama keduanya ada, snapshot menghindarkan login ulang. Granularitasnya situs, bukan browser: dua situs dalam satu kontainer adalah dua catatan yang tidak berhubungan.
Karena itu snapshot harus milik sebuah kontainer — menuangkan status login A ke B berarti menggabungkan dua akun jadi satu. Sama pentingnya menyebut apa yang tidak dilakukannya: ia memulihkan status sesi lapisan aplikasi, bukan sidik jari tingkat kernel, dan tidak menjanjikan bisa melewati kontrol risiko atau validasi perangkat suatu platform. Pemakaian: Tautan internal: pemakaian nyata snapshot situs.
Apa bedanya dengan membuka beberapa profil?
Beberapa profil di Chrome adalah pemotongan fisik pada tingkat direktori akar penyimpanan: setiap profil punya penyimpanan cookie, penyimpanan, ekstensi, dan cache sendiri, jadi isolasinya tuntas. Harganya muncul di empat sumbu: memori, karena setiap profil punya konteks jaringan dan proses render sendiri, sehingga tiga profil kurang lebih tiga kali biaya menetap; proses, karena pohon prosesnya terpisah; jendela, karena satu profil satu jendela dan berpindah berarti berpindah jendela; sidik jari, karena antarprofil berbagi kernel dan mesin yang sama, sehingga UA, Canvas, dan font identik secara bawaan. Ada biaya yang lebih senyap: markah, ekstensi, dan riwayat tidak dibagi, jadi lewat tiga profil semuanya mulai berjalan sendiri-sendiri.
Jalur ekstensi membaliknya: satu profil, satu jendela, proses dan kernel dibagi, ditukar dengan paralelisme dalam satu jendela pada biaya tambahan nyaris nol — dan harganya adalah tidak bisa menjangkau lapisan sidik jari kernel. Keduanya bukan dua tingkat dari hal yang sama, melainkan dua cara memotong granularitas isolasi. Perbandingan: Tautan internal: profil Chrome versus isolasi ekstensi.
Batas kemampuan: lapisan mana yang dijangkau ekstensi dan mana yang tidak
Semua batas di atas, dipadatkan jadi satu tabel. Cara membacanya: tanyakan apa yang diperiksa platform. Untuk sesi dan jalur keluar, lihat kolom tengah; untuk konsistensi sidik jari, lihat kolom kanan. Perlu ditegaskan: ekstensi melakukan isolasi lapisan sesi, yang tidak setingkat dengan browser antidetect; menganggapnya antidetect yang lebih ringan berarti salah membaca risiko.
| Lapisan | Bisa dijangkau ekstensi | Tidak terjangkau, atau harganya |
|---|---|---|
| Cookie dan status login | Dipisah per kontainer, bisa diserialkan jadi snapshot | Kernel tidak mengenal kontainer; header ditulis ulang, dan kalau aturan hilang, akun tercampur |
| Penyimpanan halaman | localStorage dan IndexedDB bisa diberi prefiks atau diproksikan per kontainer | Service worker, SharedWorker, dan konteks terpisah lain perlu cakupan sendiri |
| IP keluar | Terikat ke ruang kerja; ganti yang terdepan, ganti jalur keluar | Hanya satu jalur keluar terdepan pada satu waktu; tanpa terowongan bersamaan |
| WebRTC | UDP non-proksi bisa dimatikan (kebijakan seluruh browser) | Tidak per ruang kerja; jalur media masih bisa melewati proxy |
| Sidik jari TLS | Tidak ada | JA3/JA4 ditentukan kernel dan tumpukan jaringan |
| Canvas / WebGL / Audio | Tidak ada | Render terjadi di kernel; tidak ada API untuk menulis ulang |
| Enumerasi font | Tidak ada | Hanya tambalan JS di halaman, dan itu bisa dideteksi |
| Cache HTTP | Tidak ada | Cache bersifat per profil dan dibagi antar kontainer |
Tabel ini juga menunjukkan di mana langit-langitnya: yang digantikan ekstensi adalah alasan membeli klien hanya untuk login terpisah, bukan kliennya. Jalur mana yang dipilih adalah pertanyaan lain, dibandingkan butir demi butir di Tautan internal: ekstensi versus browser antidetect.
Pertanyaan umum
Apakah isolasi cookie oleh ekstensi sama dengan Partitioned Cookie bawaan Chrome?
Bukan. Partitioned Cookie dikunci berdasarkan situs tingkat atas, jadi satu situs hanya punya satu toples per halaman tingkat atas; partitionKey di API cookies hanyalah kunci untuk membaca dan menulis cookie semacam itu, dan satu-satunya komponennya topLevelSite — tidak bisa dipakai membuat partisi baru. Toples ruang kerja dipisah per kontainer, satu situs bisa punya berapa pun, dan ekstensi yang mencatatnya. Yang pertama adalah pemartisian privasi browser, yang kedua abstraksi sesi milik ekstensi.
Apakah status ruang kerja tetap ada setelah tab ditutup?
Tiga kasus. Tabnya hilang, pengikatannya ikut hilang. Definisi ruang kerja — nama, proxy, indeks snapshot — termasuk data yang harus melewati restart dan biasanya ada di storage.local. Status login hanya bisa dipulihkan kalau Anda menyimpan snapshot; kalau tidak, harus login lagi. Isi storage.session dikosongkan saat browser ditutup, jadi jangan memperlakukannya sebagai lapisan permanen.
Apakah pendekatan satu jendela membebani kinerja browser?
Tambahan biayanya datang dari tab, bukan dari isolasinya. Tidak ada browser kedua yang dijalankan dan tidak ada kernel yang disalin; biayanya pencocokan aturan dan penulisan ulang header, besaran tetap per permintaan. Biaya sebenarnya ada pada jumlah tab dan halamannya: dengan dua puluh ruang kerja, yang tersendat adalah render, bukan lapisan isolasi.
Bisakah dua ruang kerja memakai IP keluar berbeda pada saat yang sama?
Tidak. Konfigurasi proxy bersifat per profil dan ekstensi hanya bisa menulis ulang saat tab berganti, jadi pada satu waktu hanya ruang kerja terdepan yang memakai jalur keluarnya sendiri; yang di belakang diblokir aturan atau langsung konek. Untuk terowongan yang benar-benar bersamaan perlu klien dengan tumpukan jaringan sendiri.
Sumber dan pembaruan terakhir
Bagian yang menyentuh perilaku API mengikuti dokumentasi resmi. Batas kemampuan ekstensi bergerak mengikuti versi Chrome — periksa ulang sebelum memakai.
- Chrome for Developers, chrome.declarativeNetRequest — masa hidup session rule, cakupan condition.tabIds, dan modifyHeaders pada header cookie: developer.chrome.com/docs/extensions/reference/api/declarativeNetRequest
- Chrome for Developers, chrome.storage — area session menetap di memori, dikosongkan saat browser di-restart, dan tidak terbuka untuk content script secara bawaan: developer.chrome.com/docs/extensions/reference/api/storage
- Chrome for Developers, chrome.cookies — partitionKey dan semantik kunci Partitioned Cookie (CHIPS): developer.chrome.com/docs/extensions/reference/api/cookies
- Chrome for Developers, chrome.proxy — pengaturan proxy berlaku untuk seluruh profil browser dan PAC hanya menerima URL dan host: developer.chrome.com/docs/extensions/reference/api/proxy
- Chrome for Developers, The extension service worker lifecycle — berhenti setelah 30 detik menganggur, variabel global hilang bersama worker: developer.chrome.com/…/service-workers/lifecycle
Pembaruan terakhir: 11 November 2026. Yang ditulis di sini adalah jalur implementasi umum untuk kelas ekstensi ini; API dan lokasi data yang dipakai tiap produk bisa berbeda, dan dokumentasi produk itulah yang berlaku untuk bagian dalamnya.