Cookies com estado particionado independente (CHIPS)

Permitir que os desenvolvedores optem por um cookie no armazenamento "particionado", com um cookie jar separado por site de nível superior.

Status da implementação

Compatibilidade com navegadores

  • 114
  • 114
  • x
  • x

Origem

O que são CHIPS?

Os cookies com estado particionado independente (CHIPS, na sigla em inglês) permitem que os desenvolvedores incluam um cookie no armazenamento particionado, com jars de cookie separados por site de nível superior, melhorando a privacidade e a segurança do usuário.

Sem o particionamento, os cookies de terceiros podem permitir que os serviços rastreiem os usuários e agrupem as informações deles em vários sites de nível superior não relacionados. Isso é conhecido como rastreamento entre sites.

Os navegadores estão prestes a deixar de usar cookies de terceiros não particionados. Portanto, quando os cookies de terceiros forem bloqueados, os CHIPS, a API Storage Access e os conjuntos de sites relacionados serão lidos e gravados em contextos entre sites, como iframes.

Diagrama mostrando como cookes podem ser compartilhados entre dois sites diferentes.
Sem o particionamento de cookies, um serviço de terceiros pode definir um cookie quando incorporado em um site de nível superior e acessar esse mesmo cookie quando o serviço estiver incorporado em outros sites de nível superior.

A CHIPS introduz um novo atributo de cookie, Partitioned, para oferecer suporte a cookies entre sites particionados por contexto de nível superior.

Cabeçalho "set-Cookie":

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

JavaScript:

document.cookie="__Host-name=value; Secure; Path=/; SameSite=None; Partitioned;"

Um cookie de terceiros particionado é vinculado ao site de nível superior onde é inicialmente definido e não pode ser acessado de outro lugar. Dessa forma, os cookies definidos por um serviço de terceiros só podem ser lidos no mesmo contexto incorporado do site de nível superior, onde foram inicialmente definidos.

Diagrama mostrando que dois sites diferentes incorporando um terceiro comum não compartilham mais cookies desse terceiro.
Com o particionamento de cookies, um serviço de terceiros que define um cookie quando incorporado em um site de nível superior não pode acessar o mesmo cookie quando está incorporado em outros sites de nível superior.

Com cookies particionados, quando um usuário visita o site A e o conteúdo incorporado do site C define um cookie com o atributo "Particionado", o cookie é salvo em um jar particionado designado apenas para cookies que o site C define quando está incorporado no site A. O navegador só enviará esse cookie quando o site de nível superior for A.

Quando o usuário visita um novo site (por exemplo, o site B), um frame C incorporado não recebe o cookie definido quando C foi incorporado ao site A.

Se um usuário visitar o site C como um site de nível superior, o cookie particionado que C definiu quando foi incorporado em A também não será enviado nessa solicitação.

Diagrama mostrando que os cookies não são compartilhados quando o mesmo terceiro está incorporado em dois sites diferentes.
Com o particionamento de cookies, um serviço de terceiros que define um cookie quando incorporado a um site não pode acessar o mesmo cookie, mesmo quando os usuários visitam o serviço como um site de nível superior.

Casos de uso

Por exemplo, o site retail.example trabalha com um serviço de terceiros support.chat.example para incorporar uma caixa de chat de suporte ao site. Atualmente, muitos serviços de chat incorporáveis dependem de cookies para salvar o estado.

Diagrama mostrando um site com um widget de chat incorporado
Site de nível superior retail.example incorporando um serviço de terceiros support.chat.example.

Sem a capacidade de definir um cookie entre sites, o support.chat.example precisaria encontrar métodos alternativos, geralmente mais complexos, para armazenar o estado. Como alternativa, ele precisa ser incorporado à página de nível superior, o que apresenta riscos porque permite que o script support.chat.example tenha privilégios elevados em retail.example, como a capacidade de acessar cookies de autenticação.

O CHIPS oferece uma opção mais fácil para continuar usando cookies entre sites, sem os riscos associados a cookies não particionados.

Os exemplos de casos de uso de CHIPS incluem todos os cenários em que sub-recursos entre sites exigem alguma noção de sessão ou estado persistente com escopo para a atividade de um usuário em um único site de nível superior, como:

  • Incorporações de chats de terceiros
  • Incorporações de mapas de terceiros
  • Incorporações de pagamento de terceiros
  • Balanceamento de carga de CDN de recursos secundários
  • Provedores de CMS sem comando
  • Domínios de sandbox para veiculação de conteúdo de usuários não confiáveis (como googleusercontent.com e githubusercontent.com)
  • CDNs de terceiros que usam cookies para veicular conteúdo com acesso controlado pelo status de autenticação no site próprio (por exemplo, fotos de perfil em sites de mídias sociais hospedados em CDNs de terceiros)
  • Frameworks de front-end que dependem de APIs remotas que usam cookies nas solicitações
  • Anúncios incorporados que precisam do estado por editor (por exemplo, capturar as preferências de anúncio dos usuários para o site)

Por que o CHIPS usa um modelo de particionamento de ativação

Como os navegadores estão removendo gradualmente os cookies de terceiros não particionados, algumas outras abordagens de particionamento foram tentadas.

O Firefox anunciou que está particionando todos os cookies de terceiros por padrão no modo ETP Strict e no modo de navegação privada. Assim, todos os cookies entre sites são particionados pelo site de nível superior. No entanto, o particionamento de cookies sem a permissão de terceiros pode causar bugs inesperados, porque alguns serviços de terceiros criaram servidores que esperam um cookie de terceiros não particionado.

O Safari já tentou particionar cookies com base em heurísticas, mas depois escolheu bloqueá-los completamente, citando confusão dos desenvolvedores como um dos motivos. Recentemente, o Safari demonstrou interesse em um modelo baseado em aceitação.

O que diferencia os CHIPS das implementações existentes de cookies particionados é a ativação de terceiros. Os cookies precisam ser definidos com um novo atributo para serem enviados em solicitações entre partes quando os cookies de terceiros (não particionados) se tornarem obsoletos.

Embora os cookies de terceiros ainda existam, o atributo Partitioned permite um tipo de comportamento de cookie mais restritivo e seguro. Os CHIPS são uma etapa importante para ajudar os serviços a fazer uma transição tranquila para um futuro sem cookies de terceiros.

Atualmente, os cookies são codificados no nome do host ou no domínio do site que os definiu, ou seja, na chave do host.

Por exemplo, para cookies de https://support.chat.example, a chave de host é ("support.chat.example").

No CHIPS, os cookies que optarem pelo particionamento terão chaves duplas na chave de host e na chave de partição deles.

A chave de partição de um cookie é o site (esquema e domínio registrável) do URL de nível superior que o navegador estava visitando no início da solicitação para o endpoint que definiu o cookie.

No exemplo anterior, em que https://support.chat.example está incorporado em https://retail.example, o URL de nível superior é https://retail.example.

A chave de partição nesse caso é ("https", "retail.example").

Da mesma forma, a chave de partição de uma solicitação é o site do URL de nível superior que o navegador está visitando no início de uma solicitação. Os navegadores só podem enviar um cookie com o atributo Partitioned em solicitações com a mesma chave de partição que esse cookie.

Veja como a chave do cookie no exemplo anterior é exibida antes e depois dos CHIPS.

O site A e o site C incorporado compartilham um cookie particionado. Quando não está incorporado, o site C não pode acessar o cookie particionado.
O site A e o site C incorporado compartilham um cookie particionado. Quando não está incorporado, o site C não pode acessar o cookie particionado.

Antes dos CHIPS

key=("support.chat.example")

Depois dos CHIPS

key={("support.chat.example"),("https", "retail.example")}

Design de segurança

Para incentivar boas práticas de segurança, com os CHIPS, os cookies são definidos e enviados apenas por protocolos seguros.

  • Cookies particionados precisam ser definidos com Secure.
  • É recomendável usar o prefixo __Host ao definir cookies particionados para torná-los vinculados ao nome do host, e não ao domínio registrável.

Exemplo:

Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned;

Alternativas aos CHIPS

A API Storage Access e os conjuntos de sites relacionados (RWS, na sigla em inglês) associados são mecanismos de plataforma da Web que permitem um acesso limitado a cookies entre sites para fins específicos voltados ao usuário.

Essas são alternativas ao particionamento CHIPS, em que o acesso a cookes não particionados e entre sites é necessário.

Considere a API Storage Access e os conjuntos de sites relacionados nas situações em que você precisa que o mesmo cookie esteja disponível para um serviço incorporado em vários sites relacionados.

O CHIPS permite que um serviço atue como um componente isolado em vários sites, em que o mesmo cookie não precisa estar disponível em vários sites. Se o serviço definir um cookie particionado, a chave de partição dele vai ser o site de nível superior, e esse cookie não vai ficar disponível para outros sites que também usam o serviço.

O design dos conjuntos de sites relacionados depende da API Storage Access e não se integra ao particionamento CHIPS. Se você tiver um caso de uso que depende de uma partição de cookie compartilhado entre sites em um RWS, forneça exemplos e feedback sobre o problema no GitHub (link em inglês).

Demonstração

Esta demonstração mostra como os cookies particionados funcionam e como é possível inspecioná-los no DevTools.

O site A incorpora um iframe do site B, que usa JavaScript para definir dois cookies: um particionado e um não particionado. O site B mostra todos os cookies acessíveis naquele local usando document.cookie.

Quando os cookies de terceiros são bloqueados, o site B só pode definir e acessar o cookie com o atributo Partitioned em um contexto entre sites.

Quando cookies de terceiros são permitidos, o site B também pode definir e acessar o cookie não particionado.

Site A e site B
Esquerda: os cookies de terceiros são bloqueados. À direita: cookies de terceiros são permitidos.

Pré-requisitos

  1. Chrome 118 ou versão mais recente
  2. Acesse chrome://flags/#test-third-party-cookie-phaseout e ative essa configuração

Usar o DevTools para inspecionar cookies particionados

  1. Acesse https://chips-site-a.glitch.me (em inglês).
  2. Pressione Control+Shift+J (ou Command+Option+J no Mac) para abrir o DevTools.
  3. Clique na guia Aplicativo.
  4. Navegue até Aplicativo > Armazenamento > Cookies.
  5. Clique em https://chips-site-b.glitch.me.

O DevTools exibirá todos os cookies da origem selecionada.

Cookies do site B na guia "Aplicativo" do DevTools.

No site B, só é possível definir o cookie particionado em contexto entre sites, e o cookie não particionado é bloqueado:

  • Você verá __Host-partitioned-cookie com a chave de partição do site de nível superior https://chips-site-a.glitch.me.
Chave de partição para __Host- particionada-cookie.
  1. Clique em Acessar o site B.
  2. No DevTools, acesse Aplicativo > Armazenamento > Cookies.
  3. Clique em https://chips-site-b.glitch.me.
Site B
No nível superior, o site B pode ver todos os cookies, particionados e não particionados.

Nesse cenário, como você está no site B em um contexto de nível superior, ele pode definir e acessar os dois cookies:

  • unpartitioned-cookie tem uma chave de partição vazia.
  • O cookie __Host-partitioned-cookie tem a chave de partição https://chips-site-b.glitch.me.
Cookies do site B na guia "Aplicativo" do DevTools ao acessar B como um site de nível superior. __O cookie particionado pelo host tem a chave de partição https://chips-site-b.glitch.me.

Se você voltar para o site A, o site unpartitioned-cookie será armazenado no navegador, mas não vai poder ser acessado pelo site A.

  1. Clique em Acessar o site A.
  2. Clique na guia Rede.
  3. Clique em https://chips-site-b.glitch.me.
  4. Clique na guia Cookies.

No site A, você verá __Host-partitioned-cookie com a chave de partição do site de nível superior https://chips-site-a.glitch.me.

Guia "Rede" mostrando cookies do iframe do site B que podem ser acessados quando está incorporado no site A.

Se você marcar a opção Mostrar solicitações de cookies filtradas, o DevTools mostrará que o cookie não particionado está bloqueado, destacado em amarelo com a dica: "Este cookie foi bloqueado devido às preferências do usuário".

Guia "Rede" mostrando cookies bloqueados do iframe do site B.

Em Aplicativo > Armazenamento > Cookies, clique em https://chips-site-b.glitch.me para mostrar:

  • unpartitioned-cookie pela chave de partição vazia.
  • __Host-partitioned-cookie pela chave de partição https://chips-site-a.glitch.me.
Cookies do site B na guia "Aplicativo" do DevTools. O cookie __Host-partitioned-cookie tem a chave de partição https://chips-site-a.glitch.me. O unpartitioned-cookie é exibido, mas não pode ser acessado pelo iframe do site B quando está incorporado no site A.

Limpar cookies

Para redefinir a demonstração, limpe todos os cookies do site:

  • Pressione Control+Shift+J (ou Command+Option+J no Mac) para abrir o DevTools.
  • Clique na guia Aplicativo.
  • Navegue até Aplicativo > Armazenamento > Cookies.
  • Clique com o botão direito do mouse em https://chips-site-b.glitch.me.
  • Clique em Limpar.

Recursos