Partizionamento dello spazio di archiviazione

Per rafforzare la privacy degli utenti e contrastare 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. Sono in corso o pianificati sforzi simili per il partizionamento dello spazio di archiviazione anche in altri browser importanti, come Firefox e Safari. La proposta di partizionamento dello spazio di archiviazione su GitHub è aperta per 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 partitioning dello spazio di archiviazione, un sito può unire i dati di siti diversi 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.

In passato, lo spazio di archiviazione era basato solo sull'origine. Ciò significa che se un frame 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 abilitato, lo spazio di archiviazione per example.com è presente in due partizioni diverse, una per a.com e l'altra per b.com.

In generale, la partizione significa che i dati scritti da 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. Ora questi dati sono isolati e disponibili solo per i contesti che condividono la stessa origine e lo stesso sito di primo livello.

Prima

API di archiviazione senza partizionamento.
Prima del partizionamento dello spazio di archiviazione, example.com può scrivere dati quando è incorporato in a.com e poi leggerli quando è incorporato in b.com.

Dopo

API di archiviazione con partizionamento.
Dopo il partizionamento dello spazio di archiviazione, example.com, se incorporato in b.com, non può accedere allo spazio di archiviazione di example.com se incorporato in a.com.

Partizionamento dello spazio di archiviazione su iframe incatenati

La complessità del partizionamento dello spazio di archiviazione aumenta notevolmente 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 entrambi A1 e A2 si trovano sullo stesso sito. Se il partizionamento tenesse conto solo del sito di primo livello e dell'origine del frame corrente, l'iframe A2 potrebbe essere erroneamente considerato "proprietario" 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 il problema, Chrome aggiunge un "bit di antenato" alla chiave della partizione dello spazio di archiviazione. Questo bit viene impostato se un documento tra l'iframe corrente e il sito di primo livello proviene da un'origine diversa (tra siti). In questo caso, il sito B è cross-site, quindi il bit verrà impostato per A2 e lo spazio di archiviazione verrà partizionato da A1.

Quando la catena di iframe è costituita esclusivamente da contesti dello stesso sito (ad esempio, il sito A1 contenente A2, che contiene A3), il bit antenato non suddivide ulteriormente lo spazio di archiviazione. In questi casi, lo spazio di archiviazione rimane condiviso, con chiave in base all'origine e al sito di primo livello comuni.

Per i siti che richiedono l'accesso non partizionato tra iframe incatenati, Chrome sta sperimentando l'estensione dell'API Storage Access per abilitare questo caso d'uso. Poiché l'API Storage Access richiede che il sito incorniciato richiami esplicitamente l'API, il rischio di clickjacking viene ridotto.

Modifiche all'API dovute al partizionamento

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

API di archiviazione

  • Sistema di quote
    Il sistema di quote viene utilizzato per determinare la quantità di spazio su disco allocata per lo spazio di archiviazione. Il sistema di quote gestisce ogni partizione come un bucket separato per determinare lo spazio consentito e quando viene cleared.
    Il metodo navigator.storage.estimate() ora fornisce informazioni specifiche sulla partizione di archiviazione. Le API solo per Chrome, come window.webkitStorageInfo e navigator.webkitTemporaryStorage, sono state ritirate.
    IndexedDB e Spazio di archiviazione della cache utilizzano il sistema di quote partizionato.
  • API Web Storage
    L'API Web Storage fornisce i meccanismi con cui 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 suddivisi.
  • File system privato di Origin
    L'API File System Access consente a un sito di leggere o salvare le modifiche direttamente su file e cartelle sul dispositivo dopo che l'utente ha concesso l'accesso. Il file system privato dell'origine consente a un'origine di archiviare contenuti privati direttamente sul disco. Questi contenuti rimangono accessibili agli utenti, ma ora sono suddivisi.
  • 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 vengono suddivisi in parti.
  • Intestazione Clear-Site-Data
    L'inclusione dell'intestazione Clear-Site-Data nella risposta consente a un server di richiedere l'eliminazione dei dati memorizzati nel browser dell'utente. È possibile svuotare la cache, eliminare i cookie e lo spazio di archiviazione DOM. L'utilizzo dell'intestazione consente di cancellare lo spazio di archiviazione solo all'interno di una partizione.
  • Repository di URL blob
    Un URL BLOB fornisce l'accesso a un blob, un oggetto contenente 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 della stessa origine incorporato in un altro sito. Ad esempio, se gli iframe di example.com sono incorporati sia in a.com che in b.com, un URL del 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 dei blob vengono suddivisi per tutti gli utilizzi, ad eccezione delle navigazioni di primo livello. Le situazioni che ora verranno bloccate 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 l'utilizzo di window.open() o il clic su un link con target='_blank', agli URL BLOB non verranno bloccate se sono tra partizioni diverse, ma noopener verrà applicato se il sito dell'URL BLOB è su un altro sito rispetto al sito di primo livello della pagina che avvia la navigazione. Se noopener viene applicato, al documento che avvia la navigazione viene impedito di ottenere un handle della finestra per il documento URL del blob che ha aperto. Nell'esempio precedente, il partizionamento impedirà all'iframe su b.com di recuperare i contenuti dell'URL del blob, ma potrà comunque window.open()arlo.

API di comunicazione

Oltre alle API di archiviazione, vengono partizionate anche le API di comunicazione che consentono a un contesto di comunicare oltre i confini dell'origine. Le modifiche riguardano principalmente le API che consentono la scoperta 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 relativi contesti dello stesso dominio:

  • Broadcast Channel
    L'API Broadcast Channel consente la comunicazione tra contesti di navigazione (finestre, schede o iframe) e worker della stessa origine.
    Non è prevista la modifica del comportamento dell'iframe cross-site postMessage(), in quanto la relazione tra questi contesti è già chiaramente definita.
  • SharedWorker
    L'API SharedWorker fornisce un worker a cui è possibile accedere in diversi 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 alcuni compiti.

API Service Worker

L'API Service Worker consente ai siti di eseguire attività in background. Sites registra i worker che creano nuovi contesti di worker per rispondere agli eventi. Tradizionalmente, questi lavoratori potevano comunicare con qualsiasi contesto dello stesso dominio. Tuttavia, poiché i worker possono modificare la tempistica delle richieste di navigazione, rappresentano un rischio di fuga di informazioni tra siti, come lo sniffing della cronologia.

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

API di estensione

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

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

Per ulteriori informazioni, 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 i segni di spunta verdi a sinistra e le croci rosse a destra.
Screenshot della demo che mostra l'output per un browser con il partizionamento dello spazio di archiviazione a sinistra e senza partizionamento dello spazio di 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, vengono impostati i dati utilizzando vari metodi di archiviazione.
  • Il sito B incorpora una pagina del sito A e questo incorporamento tenta di leggere le opzioni di archiviazione impostate in precedenza.
  • Quando il sito A è incorporato nel sito B, non ha accesso a questi dati quando lo spazio di archiviazione è partizionato e le letture non riescono.
  • La demo utilizza il successo o l'errore di ogni lettura per mostrare se i dati sono partizionati.

Per il momento, puoi disattivare il partizionamento dello spazio di archiviazione in Chrome utilizzando il --disable-features=ThirdPartyStoragePartitioning parametro a riga di comando. Nota: questo parametro a 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 vedere il loro stato di partizione.

Coinvolgere e condividere feedback