Partizionamento dello spazio di archiviazione

Per rafforzare la privacy degli utenti e combattere il monitoraggio tra siti laterale, Chrome ora isola la maggior parte delle API di archiviazione e comunicazione in contesti di terze parti tramite un processo chiamato partizionamento dello spazio di archiviazione.

Stato dell'implementazione

La funzionalità è stata attivata per tutti gli utenti su Chrome 115 e versioni successive. Sforzi simili di partizionamento dello spazio di archiviazione sono in atto o pianificati anche in altri browser principali come Firefox e Safari. La proposta di partizionamento dello spazio di archiviazione su GitHub è aperta a ulteriori discussioni.

Che cos'è il partizionamento dello spazio di archiviazione?

Per impedire determinati tipi di monitoraggio tra siti laterale, Chrome partiziona le API di archiviazione e comunicazione in contesti di terze parti.

Senza il partizionamento dell'archiviazione, un sito può unire i dati di diversi siti per monitorare l'utente sul web. Inoltre, consente al sito incorporato di dedurre stati specifici dell'utente nel sito di primo livello utilizzando tecniche di canale laterale come attacchi di temporizzazione, XS-Leaks e COSI.

Storicamente, l'archiviazione è stata indicizzata solo in base all'origine. Ciò significa che se un iframe di example.com è incorporato in a.com e b.com, potrebbe conoscere le tue abitudini di navigazione per questi due siti memorizzando e recuperando correttamente un ID dallo spazio di archiviazione. Con il partizionamento dello spazio di archiviazione di terze parti attivato, lo spazio di archiviazione per example.com esiste in due partizioni diverse, una per a.com e l'altra per b.com.

In generale, il partizionamento significa che i dati scritti dalle API di archiviazione come Local Storage e IndexedDB all'interno di un iframe non sono più accessibili a tutti i contesti che condividono la stessa origine. Questi dati sono ora isolati e disponibili solo per i contesti che condividono la stessa origine e lo stesso sito di primo livello.

Prima

API Storage senza partizionamento.
Prima del partizionamento dell'archiviazione, example.com può scrivere dati quando è incorporato in a.com e poi leggerli quando è incorporato in b.com.

Dopo

API Storage con partizionamento.
Dopo il partizionamento dell'archiviazione, example.com, quando è incorporato in b.com, non può accedere all'archiviazione di example.com quando è incorporato in a.com.

Partizionamento dello spazio di archiviazione su iframe concatenati

La complessità del partizionamento dell'archiviazione aumenta in modo significativo quando gli iframe sono nidificati, in particolare quando la stessa origine viene visualizzata più volte all'interno della catena.

Ad esempio, A1 contiene un iframe per B che contiene un iframe per A2 e sia A1 che A2 si trovano sullo stesso sito. Se il partizionamento prendesse in considerazione solo il sito di primo livello e l'origine del frame corrente, l'iframe A2 potrebbe essere trattato erroneamente come "first-party" perché condivide un sito con il sito di primo livello (A1), nonostante l'iframe cross-site B intermedio. Ciò potrebbe esporre A2 a rischi per la sicurezza come il clickjacking se A2 avesse accesso allo spazio di archiviazione non partizionato per impostazione predefinita.

Per risolvere questo problema, Chrome aggiunge un "bit antenato" alla chiave di partizione di archiviazione. Questo bit viene impostato se un documento tra l'iframe corrente e il sito di primo livello proviene da un'origine diversa (cross-site). In questo caso, il sito B è cross-site, quindi il bit verrà impostato per A2 e il relativo spazio di archiviazione verrà partizionato da A1.

Quando la catena di iframe è costituita esclusivamente da contesti dello stesso sito (ad esempio, il sito A1 contiene A2, che a sua volta contiene A3), il bit antenato non partiziona ulteriormente lo spazio di archiviazione. In questi casi, lo spazio di archiviazione rimane condiviso, identificato dalla loro origine comune e dal sito di primo livello.

Per i siti che richiedono l'accesso non partizionato a iframe concatenati, Chrome sta sperimentando l'estensione dell'API Storage Access per consentire questo caso d'uso. Poiché l'API Storage Access richiede che il sito in frame richiami esplicitamente l'API, questo mitiga il rischio di clickjacking.

Modifiche all'API dovute al partizionamento

Le API interessate dal partizionamento possono essere suddivise nei seguenti gruppi:

API Storage

  • Sistema di quote
    Il sistema di quote viene utilizzato per determinare la quantità di spazio su disco allocata per l'archiviazione. Il sistema di quote gestisce ogni partizione come un bucket separato per determinare la quantità di spazio consentita e quando viene liberato.
    Il metodo navigator.storage.estimate() ora fornisce informazioni specifiche per la partizione di archiviazione. Le API solo per Chrome, come window.webkitStorageInfo e navigator.webkitTemporaryStorage, sono state ritirate.
    IndexedDB e Cache Storage utilizzano il sistema di quote partizionato.
  • API Web Storage
    L'API Web Storage fornisce meccanismi tramite i quali i browser possono memorizzare coppie chiave-valore. Esistono due meccanismi: Memoria locale e Memoria di sessione. Non sono gestiti in base alla quota, ma sono comunque partizionati.
  • Origin Private File System
    L'API File System Access consente a un sito di leggere o salvare le modifiche direttamente su file e cartelle del dispositivo dopo che l'utente concede l'accesso. Origin Private File System consente a un'origine di archiviare contenuti privati direttamente sul disco. Questi contenuti rimangono accessibili agli utenti, ma ora sono partizionati.
  • API Storage Bucket
    L'API Storage Bucket è in fase di sviluppo per Storage Standard, che consolida varie API di archiviazione come IndexedDB e localStorage utilizzando un nuovo concetto chiamato bucket. I dati archiviati nei bucket e i metadati associati ai bucket sono partizionati.
  • Intestazione Clear-Site-Data
    L'inclusione dell'intestazione Clear-Site-Data nella risposta consente a un server di richiedere la cancellazione dei dati memorizzati nel browser dell'utente. Cache, cookie e spazio di archiviazione DOM possono essere cancellati. L'utilizzo dell'intestazione cancella solo lo spazio di archiviazione all'interno di una partizione.
  • Archivio URL blob
    Un URL blob fornisce l'accesso a un blob, un oggetto che contiene dati non elaborati. Senza il partizionamento dello spazio di archiviazione, un URL blob generato in un iframe di terze parti su un sito può essere utilizzato in un iframe con la stessa origine incorporato in un altro sito. Ad esempio, se example.com iframe sono incorporati sia in a.com che in b.com, un URL blob generato nell'iframe incorporato in a.com può essere passato e poi utilizzato dall'iframe incorporato in b.com senza alcuna limitazione. A partire da Chrome 137 (rilasciato il 27 maggio 2025), gli URL Blob vengono partizionati per tutti gli utilizzi, ad eccezione delle navigazioni di primo livello. I casi che verranno ora bloccati includono l'utilizzo di URL blob tra partizioni con fetch() o come valore dell'attributo src per vari elementi HTML. Le navigazioni di primo livello, come la chiamata di window.open() o il clic su un link con target='_blank', agli URL blob non verranno bloccate se sono cross-partition, ma noopener verrà applicato se il sito dell'URL blob è cross-site rispetto al sito di primo livello della pagina che avvia la navigazione. L'applicazione di noopener impedisce al documento che avvia la navigazione di ottenere un handle della finestra per il documento URL blob che ha aperto. Nell'esempio precedente, il partizionamento impedirà all'iframe su b.com di recuperare i contenuti dell'URL blob, ma potrà comunque window.open().

API di comunicazione

Oltre alle API di archiviazione, vengono partizionate anche le API di comunicazione che consentono a un contesto di comunicare oltre i limiti dell'origine. Le modifiche riguardano principalmente le API che consentono l'individuazione di altri contesti utilizzando la trasmissione o il rendezvous con la stessa origine.

A causa del partizionamento, le seguenti API di comunicazione impediscono agli iframe di terze parti di scambiare dati con i contesti della stessa origine:

  • Canale broadcast
    L'API Broadcast Channel consente la comunicazione tra contesti di navigazione (finestre, schede o iframe) e i worker della stessa origine.
    Il comportamento dell'iframe cross-site postMessage() non verrà modificato, in quanto la relazione tra questi contesti è già chiaramente definita.
  • SharedWorker
    L'API SharedWorker fornisce un worker a cui è possibile accedere in tutti i contesti di navigazione della stessa origine.
  • Serrature web
    L'API Web Locks consente al codice in esecuzione in una scheda o in un worker della stessa origine di acquisire un blocco per una risorsa condivisa durante l'esecuzione di un'attività.

API Service Worker

L'API Service Worker consente ai siti di eseguire attività in background. Sites registra i service worker che creano nuovi contesti di worker per rispondere agli eventi. Tradizionalmente, questi worker potevano comunicare con qualsiasi contesto della stessa origine. Tuttavia, poiché i service worker possono alterare la tempistica delle richieste di navigazione, rappresentano un rischio di perdite di informazioni cross-site come lo sniffing della cronologia.

Per questo motivo, i service worker registrati da un contesto di terze parti ora sono partizionati.

API di estensione

Le estensioni sono programmi che consentono agli utenti di personalizzare la propria esperienza di navigazione.

Le pagine delle estensioni (pagine con schema chrome-extension://) possono essere incorporate in siti su tutto il web. In questo scenario, le pagine delle estensioni continuano ad avere accesso alla partizione di primo livello. Le estensioni possono anche incorporare altri siti. In questo caso, i siti incorporati accederanno alla partizione di primo livello, a condizione che l'estensione disponga delle autorizzazioni host.

Per saperne di più, consulta la documentazione dell'estensione.

Demo: test del partizionamento dello spazio di archiviazione

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

Sito demo che mostra segni di spunta verdi a sinistra e croci rosse a destra.
Screenshot della demo, che mostra l'output per un browser con partizionamento dell'archiviazione a sinistra e senza partizionamento dell'archiviazione a destra.

La demo utilizza due siti: il sito A e il sito B.

  • Quando visiti il sito A nel contesto di primo livello, imposta i dati utilizzando vari metodi di archiviazione.
  • Il sito B incorpora una pagina del sito A e questo tentativo di incorporamento di leggere le opzioni di archiviazione impostate in precedenza.
  • Quando il sito A è incorporato nel sito B, non ha accesso a questi dati quando l'archiviazione è partizionata e quindi le letture non vanno a buon fine.
  • La demo utilizza la riuscita o il mancato tentativo di lettura per mostrare se i dati sono partizionati.

Per il momento, puoi disattivare il partizionamento dell'archiviazione in Chrome utilizzando l'--disable-features=ThirdPartyStoragePartitioning opzione della riga di comando. Nota: questo switch della riga di comando è destinato a scopi di sviluppo e test e potrebbe essere rimosso o modificato nelle versioni future di Chrome.

Puoi anche testare altri browser nello stesso modo per visualizzarne lo stato di partizionamento.

Richiedere tempo aggiuntivo per la migrazione

Per i siti che hanno bisogno di più tempo per eseguire la migrazione delle dipendenze, la prova relativa al ritiro di DisableThirdPartyStoragePartitioning3 è stata estesa. Questa prova offre un meccanismo temporaneo per consentire ai siti di primo livello di attivare spazio di archiviazione non partizionato, service worker e API di comunicazione per contesti di terze parti incorporati nelle loro pagine.

Per saperne di più, visita Rinnovo del periodo di prova del ritiro del partizionamento dello spazio di archiviazione.

Partecipare e condividere feedback