Particionamento de armazenamento

Para evitar determinados tipos de rastreamento entre sites por canal lateral, o Chrome particionava a maioria das APIs de armazenamento e comunicação em contextos de terceiros.

Status da implementação

O recurso foi ativado para todos os usuários no Chrome 115 e posterior. A proposta de particionamento de armazenamento está aberta para mais discussão.

Os sites que não tiveram tempo de implementar a compatibilidade com o particionamento de armazenamento de terceiros podem participar de um teste de descontinuação para cancelar a partição temporariamente (continuar o isolamento com a política de mesma origem, mas remover o isolamento pelo site de nível superior) e restaurar o comportamento anterior de armazenamento, service workers e APIs de comunicação no conteúdo incorporado no site.

O que é o particionamento de armazenamento?

Para evitar determinados tipos de rastreamento entre sites por canal lateral, o Chrome está particionando APIs de armazenamento e comunicação em contextos de terceiros.

Sem o particionamento de armazenamento, um site pode agrupar dados de diferentes sites para rastrear o usuário na Web. Além disso, ele permite que o site incorporado infira estados específicos sobre o usuário no site de nível superior usando técnicas de canal lateral, como ataques de velocidade, XS-Leaks e COSI.

Historicamente, o armazenamento tem sido codificado apenas por origem. Isso significa que, se um iframe de example.com for incorporado em a.com e b.com, ele poderá aprender sobre seus hábitos de navegação para esses dois sites armazenando e recuperando um ID do armazenamento. Com o particionamento de armazenamento de terceiros ativado, há armazenamento para example.com em duas partições diferentes, uma para a.com e outra para b.com.

O particionamento geralmente significa que os dados armazenados por APIs de armazenamento, como armazenamento local e IndexedDB por um iframe, não são mais acessíveis a todos os contextos na mesma origem. Em vez disso, os dados só estarão disponíveis para contextos com a mesma origem e o mesmo site de nível superior.

Antes

Diagrama de APIs de armazenamento sem particionamento.
Antes do particionamento de armazenamento, example.com pode gravar dados quando incorporado em a.com e lê-los quando incorporado em b.com.

Depois

Diagrama de APIs de armazenamento com particionamento.
Após o particionamento de armazenamento, example.com, quando incorporado em b.com, não poderá acessar o armazenamento de example.com quando incorporado em a.com.

Particionamento de armazenamento em iframes encadeados

Quando um iframe contém um iframe, ele começa a ficar mais complicado. Isso acontece principalmente quando a mesma origem está em mais de um lugar na cadeia.

Por exemplo, A1 contém um iframe para B que contém um iframe para A2 e ambos A1 e A2 estão no mesmo site. Se considerarmos apenas os contextos de nível superior e de nível atual ao particionar, o iframe A2 poderá ser considerado próprio, já que está no mesmo site que o de nível superior (A1), apesar do iframe de terceiros (B) interveniente. Isso poderia abrir a A2 para riscos de segurança, como clickjacking, se a A2 tivesse acesso ao armazenamento não particionado por padrão.

Para resolver isso, o Chrome inclui um "bit ancestral" extra como parte da chave da partição de armazenamento, que é definido se algum documento entre o contexto atual e o contexto de nível superior for do site ao contexto atual. Nesse caso, o local B é entre sites, de modo que o bit definido como A2 e o armazenamento dele é particionado da A1.

Quando não há contexto entre sites na cadeia, o armazenamento não é particionado. Por exemplo, o site A1 que contém um iframe para A2 com um iframe para A3 não seria particionado para A1, A2 nem A3, já que todos estão no mesmo site.

Para sites que precisam de acesso não particionado em iframes encadeados, o Chrome está testando a extensão da API Storage Access para ativar esse caso de uso. Como a API Storage Access exige que o site com frame invoque explicitamente a API, isso reduz o risco de clickjacking.

APIs atualizadas

As APIs afetadas pelo particionamento podem ser divididas nos seguintes agrupamentos:

APIs Storage

  • Sistema de cotas
    O sistema de cotas é usado para determinar quanto espaço em disco está alocado para armazenamento. O sistema de cotas gerencia cada partição como um bucket separado para determinar quanto espaço é permitido e quando ele é liberado.
    O navigator.storage.estimate() retorna as informações da partição. As APIs exclusivas do Chrome, como window.webkitStorageInfo e navigator.webkitTemporaryStorage, serão descontinuadas.
    O IndexedDB e o armazenamento em cache usam o novo sistema de cotas particionadas.
  • API Web Storage
    A API Web Storage oferece mecanismos para os navegadores armazenarem pares de chave-valor. Há dois mecanismos: Armazenamento local e Armazenamento de sessão. No momento, eles não são gerenciados por cotas, mas ainda estão particionados.
  • Sistema de arquivos particulares de origem
    A API File System Access permite que um site leia ou salve mudanças diretamente em arquivos e pastas no dispositivo depois que o usuário conceder acesso. O sistema de arquivos privados de origem permite que uma origem armazene conteúdo particular em disco, que pode ser acessado facilmente pelo usuário e é particionado.
  • API Storage Bucket
    A API Storage Bucket está sendo desenvolvida para o Storage Standard, que consolida várias APIs de armazenamento, como IndexedDB e localStorage, usando um novo conceito chamado buckets. Os dados armazenados nos intervalos e os metadados associados a eles são particionados.
  • Cabeçalho "Clear-Site-Data"
    Incluir o cabeçalho Clear-Site-Data na resposta permite que um servidor solicite a limpeza dos dados armazenados no navegador do usuário. O cache, os cookies e o armazenamento DOM podem ser apagados. Usar o cabeçalho apenas limpa o armazenamento em uma partição.
  • Repositório URL do Blob
    Um blob é um objeto que contém dados brutos a serem processados. É possível gerar um URL de blob para acessar o recurso. Os repositórios de URLs do blob não são particionados. Para oferecer suporte a um caso de uso de navegação em um contexto de nível superior para qualquer URL de blob (grupo de discussão), o repositório de URLs de blob pode ser particionado pelo cluster do agente em vez do site de nível superior. Esse recurso ainda não está disponível para teste e o mecanismo de particionamento pode mudar no futuro.

APIs de comunicação

Assim como as APIs de armazenamento, as APIs de comunicação que permitem que um contexto se comunique entre limites de origem também são particionadas. As mudanças afetam principalmente as APIs que permitem a descoberta de outros contextos por transmissão ou encontros de mesma origem.

Para as seguintes APIs de comunicação, o iframe de terceiros não pode mais se comunicar com o contexto de mesma origem:

  • Canal de transmissão
    A API Broadcast Channel permite a comunicação entre contextos de navegação (janelas, guias ou iframes) e workers da mesma origem.
    Iframe entre sites postMessage() em que a relação entre contextos é claramente definida não tem proposta de mudança.
  • SharedWorker
    A API SharedWorker oferece um worker que pode ser acessado em contextos de navegação com a mesma origem.
  • Bloqueios da Web
    A API Web Locks permite que o código em execução em uma guia ou worker da mesma origem receba um bloqueio para um recurso compartilhado enquanto algum trabalho é realizado.

API Service Worker

A API Service Worker fornece a interface para realizar tarefas em segundo plano. Os sites criam registros persistentes que criam um novo contexto de worker para responder a eventos e esse worker pode se comunicar com qualquer contexto da mesma origem. Além disso, a API Service Worker pode alterar o tempo das solicitações de navegação, o que pode gerar vazamentos de informações entre sites, como a detecção de histórico.

Portanto, os service workers registrados em um contexto de terceiros são particionados.

APIs de extensão

Extensões são programas que permitem que os usuários personalizem a experiência de navegação.

As páginas de extensão (páginas com um esquema chrome-extension://) podem ser incorporadas em sites em toda a Web e, nesses casos, elas continuarão tendo acesso à partição de nível superior. Essas páginas também podem incorporar outros sites. Nesse caso, esses sites terão acesso à partição de nível superior, desde que a extensão tenha permissões de host para o site.

Para mais informações, consulte os documentos da extensão.

Demonstração: como testar o particionamento de armazenamento

Site de demonstração: https://storage-partitioning-demo-site-a.glitch.me/ (em inglês)

Captura de tela do site de demonstração mostrando todas as marcas de seleção verdes à esquerda e cruzes vermelhas à direita em cada teste.
Captura de tela da demonstração, mostrando a saída de um navegador com o particionamento de armazenamento à esquerda e à direita.

A demonstração usa dois sites: o site A e o site B.

  • Quando você acessa o site A no contexto de nível superior, ele define dados usando vários métodos de armazenamento.
  • O site B incorpora uma página do site A, que tenta ler as opções de armazenamento definidas anteriormente.
  • Quando o site A é incorporado ao B, ele não tem acesso aos dados quando o armazenamento é particionado, e as leituras falham.
  • A demonstração usa o sucesso ou a falha de cada leitura para mostrar se os dados estão particionados.

Por enquanto, você pode desativar o particionamento de armazenamento no Chrome definindo a flag chrome://flags/#third-party-storage-partitioning do Chrome como disabled para confirmar a falha no teste de partes.

Também é possível testar outros navegadores da mesma maneira para conferir o status de particionamento deles.

Interaja e compartilhe feedback