Partisi Penyimpanan

Untuk memperkuat privasi pengguna dan memerangi pelacakan lintas situs saluran samping, Chrome kini mengisolasi sebagian besar API penyimpanan dan komunikasi dalam konteks pihak ketiga melalui proses yang disebut partisi penyimpanan.

Status penerapan

Fitur ini telah diaktifkan untuk semua pengguna di Chrome 115 dan yang lebih baru. Upaya partisi penyimpanan serupa juga diterapkan atau direncanakan di browser utama lainnya seperti Firefox dan Safari. Proposal Partisi Penyimpanan di GitHub terbuka untuk diskusi lebih lanjut.

Apa yang dimaksud dengan partisi penyimpanan?

Untuk mencegah jenis pelacakan lintas situs saluran samping tertentu, Chrome mempartisi API penyimpanan dan komunikasi dalam konteks pihak ketiga.

Tanpa partisi penyimpanan, situs dapat menggabungkan data di berbagai situs untuk melacak pengguna di seluruh web. Selain itu, hal ini memungkinkan situs tersemat menyimpulkan status tertentu tentang pengguna di situs tingkat atas menggunakan teknik side-channel seperti Serangan Waktu, XS-Leaks, dan COSI.

Secara historis, penyimpanan hanya diberi kunci berdasarkan asal. Artinya, jika iframe dari example.com disematkan di a.com dan b.com, iframe tersebut dapat mempelajari kebiasaan penjelajahan Anda untuk kedua situs tersebut dengan menyimpan dan berhasil mengambil ID dari penyimpanan. Dengan mengaktifkan partisi penyimpanan pihak ketiga, penyimpanan untuk example.com ada dalam dua partisi yang berbeda, satu untuk a.com dan satu lagi untuk b.com.

Secara umum, partisi berarti data yang ditulis oleh API penyimpanan seperti Local Storage dan IndexedDB dalam iframe tidak dapat lagi diakses oleh semua konteks yang memiliki origin yang sama. Sebagai gantinya, data tersebut kini diisolasi dan hanya tersedia untuk konteks yang memiliki origin dan situs tingkat teratas yang sama.

Partisi penyimpanan di iframe berantai

Kompleksitas partisi penyimpanan meningkat secara signifikan saat iframe disusun bertingkat, terutama saat origin yang sama muncul beberapa kali dalam rantai.

Misalnya, A1 berisi iframe untuk B yang berisi iframe untuk A2 dan A1 dan A2 berada di situs yang sama. Jika partisi hanya mempertimbangkan situs tingkat teratas dan origin frame saat ini, iframe A2 mungkin keliru diperlakukan sebagai 'pihak pertama' karena berbagi situs dengan tingkat teratas (A1), meskipun iframe lintas situs B berada di antaranya. Hal ini dapat membuat A2 rentan terhadap risiko keamanan seperti clickjacking jika A2 memiliki akses ke penyimpanan yang tidak dipartisi secara default.

Untuk mengatasi hal ini, Chrome menambahkan "bit ancestor" ke kunci partisi penyimpanan. Bit ini ditetapkan jika dokumen apa pun antara iframe saat ini dan situs tingkat atas berasal dari origin (lintas situs) yang berbeda. Dalam hal ini, Situs B bersifat lintas situs sehingga bit akan ditetapkan untuk A2 dan penyimpanannya akan dipartisi dari A1.

Jika rantai iframe hanya terdiri dari konteks situs yang sama (misalnya, Situs A1 yang berisi A2, yang kemudian berisi A3), bit ancestor tidak akan mempartisi penyimpanannya lebih lanjut. Dalam kasus tersebut, penyimpanannya tetap dibagikan, dengan kunci berdasarkan origin dan situs tingkat atas yang sama.

Untuk situs yang memerlukan akses tanpa partisi di seluruh iframe berantai, Chrome bereksperimen dengan memperluas Storage Access API untuk mengaktifkan kasus penggunaan ini. Karena Storage Access API mengharuskan situs yang dibingkai untuk memanggil API secara eksplisit, hal ini mengurangi risiko clickjacking.

Perubahan API karena partisi

API yang terpengaruh oleh partisi dapat dibagi menjadi grup berikut:

• Storage API
• Communication API
• Service Worker API
• Extension API

Storage API

• Sistem kuota

  Sistem kuota digunakan untuk menentukan jumlah ruang disk yang dialokasikan untuk penyimpanan. Sistem kuota mengelola setiap partisi sebagai bucket terpisah untuk menentukan jumlah ruang yang diizinkan, dan kapan ruang tersebut dikosongkan.

  Metode navigator.storage.estimate() kini memberikan informasi khusus untuk partisi penyimpanan. API khusus Chrome seperti window.webkitStorageInfo dan navigator.webkitTemporaryStorage tidak digunakan lagi.

  IndexedDB dan Penyimpanan cache menggunakan sistem kuota yang dipartisi.

• Web Storage API

  Web Storage API menyediakan mekanisme yang dapat digunakan browser untuk menyimpan pasangan nilai kunci. Ada dua mekanisme: Penyimpanan Lokal dan Penyimpanan Sesi. Volume tersebut tidak dikelola kuota, tetapi tetap dipartisi.

• Sistem File Pribadi Origin

  File System Access API memungkinkan situs membaca atau menyimpan perubahan langsung ke file dan folder di perangkat setelah pengguna memberikan akses. Sistem File Pribadi Origin memungkinkan origin menyimpan konten pribadi langsung ke disk. Konten ini tetap dapat diakses pengguna, tetapi sekarang dipartisi.

• Storage Bucket API

  Storage Bucket API sedang dikembangkan untuk Storage Standard yang menggabungkan berbagai API penyimpanan seperti IndexedDB dan localStorage menggunakan konsep baru yang disebut bucket. Data yang disimpan dalam bucket dan metadata yang terkait dengan bucket dipartisi.

• Header Clear-Site-Data

  Menyertakan header Clear-Site-Data dalam respons memungkinkan server meminta untuk menghapus data yang disimpan di browser pengguna. Cache, cookie, dan penyimpanan DOM dapat dihapus. Penggunaan header hanya akan menghapus penyimpanan dalam satu partisi.

• Penyimpanan URL Blob

  URL Blob memberikan akses ke blob, objek yang menyimpan data mentah. Tanpa partisi penyimpanan, URL blob yang dihasilkan di iframe pihak ketiga di satu situs dapat digunakan di iframe dengan origin yang sama yang disematkan di situs lain. Misalnya, jika iframe example.com disematkan di a.com dan b.com, URL blob yang dihasilkan di iframe yang disematkan di a.com dapat diteruskan, lalu digunakan oleh iframe yang disematkan di b.com tanpa batasan apa pun. Mulai Chrome 137 (dirilis 27 Mei 2025), URL Blob dipartisi untuk semua penggunaan kecuali navigasi tingkat teratas. Kasus yang kini akan diblokir meliputi saat URL blob lintas partisi digunakan dengan fetch() atau sebagai nilai atribut src untuk berbagai elemen HTML. Navigasi tingkat atas, seperti memanggil window.open() atau mengklik link dengan target='_blank', ke URL Blob tidak akan diblokir jika lintas partisi, tetapi noopener akan diterapkan jika situs URL blob lintas situs dari situs tingkat atas halaman yang memulai navigasi. Penerapan noopener berarti dokumen yang memulai navigasi akan dicegah untuk mendapatkan handle jendela untuk dokumen URL blob yang dibuka. Pada contoh sebelumnya, partisi akan mencegah iframe di b.com mengambil konten URL blob, tetapi masih dapat window.open().

API Komunikasi

Bersama dengan API penyimpanan, API komunikasi yang memungkinkan satu konteks untuk berkomunikasi di seluruh batas origin juga dipartisi. Perubahan ini terutama memengaruhi API yang memungkinkan penemuan konteks lain menggunakan siaran atau rendezvous origin yang sama.

Karena partisi, API komunikasi berikut mencegah iframe pihak ketiga bertukar data dengan konteks origin yang sama:

• Saluran Siaran

  Broadcast Channel API memungkinkan komunikasi antara konteks penjelajahan (jendela, tab, atau iframe) dan pekerja dari origin yang sama.

  Perilaku iframe lintas situs postMessage() tidak diusulkan untuk diubah, karena hubungan antara konteks tersebut sudah ditentukan dengan jelas.

• SharedWorker

  SharedWorker API menyediakan pekerja yang dapat diakses di seluruh konteks penjelajahan dari origin yang sama.

• Kunci Web

  Web Locks API memungkinkan kode yang berjalan di satu tab atau pekerja dari asal yang sama untuk mendapatkan kunci untuk resource bersama saat beberapa tugas dilakukan.

Service Worker API

Service Worker API memungkinkan situs melakukan tugas di latar belakang. Situs mendaftarkan pekerja layanan yang membuat konteks pekerja baru untuk merespons peristiwa. Secara tradisional, pekerja ini dapat berkomunikasi dengan konteks dengan origin yang sama. Namun, karena pekerja layanan dapat mengubah waktu permintaan navigasi, pekerja layanan berisiko menyebabkan kebocoran informasi lintas situs seperti sniffing histori.

Karena alasan ini, Pekerja Layanan yang terdaftar dari konteks pihak ketiga kini dipartisi.

Extensions API

Ekstensi adalah program yang memungkinkan pengguna menyesuaikan pengalaman penjelajahan mereka.

Halaman ekstensi (halaman dengan skema chrome-extension://) dapat disematkan di situs di seluruh web. Dalam skenario ini, halaman ekstensi terus memiliki akses ke partisi tingkat teratas. Ekstensi juga dapat menyematkan situs lain; saat melakukannya, situs tersemat tersebut akan mengakses partisi level teratas, asalkan ekstensi memiliki izin host untuk situs tersebut.

Untuk informasi selengkapnya, lihat dokumen ekstensi.

Demo: menguji partisi penyimpanan

Situs demo: https://storage-partitioning-demo-site-a.glitch.me/

Demo ini menggunakan dua situs: situs A dan situs B.

• Saat Anda mengunjungi situs A dalam konteks tingkat teratas, situs tersebut akan menetapkan data menggunakan berbagai metode penyimpanan.
• Situs B menyematkan halaman dari situs A dan penyematan tersebut mencoba membaca opsi penyimpanan yang ditetapkan sebelumnya.
• Saat disematkan di situs B, situs A tidak memiliki akses ke data tersebut saat penyimpanan dipartisi sehingga pembacaan gagal.
• Demo ini menggunakan keberhasilan atau kegagalan setiap pembacaan untuk menunjukkan apakah data dipartisi.

Untuk saat ini, Anda dapat menonaktifkan partisi penyimpanan di Chrome menggunakan tombol command line --disable-features=ThirdPartyStoragePartitioning. Catatan: Tombol command line ini ditujukan untuk tujuan pengembangan dan pengujian serta dapat dihapus atau diubah di versi Chrome mendatang.

Anda juga dapat menguji browser lain dengan cara yang sama untuk melihat status partisiannya.

Berinteraksi dan memberikan masukan

• GitHub: Baca proposal asli, ajukan pertanyaan, dan berpartisipasi dalam diskusi.
• Dukungan developer: Ajukan pertanyaan dan bergabunglah dalam diskusi di repo Dukungan Developer Privacy Sandbox.
• Melaporkan bug: Laporkan bug di pelacak Chromium jika Anda yakin ada sesuatu yang tidak berfungsi seperti yang diharapkan.