Cookies com estado particionado independente (CHIPS)

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

Status da implementação

• Compatível por padrão no Chrome 114 e em versões mais recentes.
• Um teste de origem, concluído, estava disponível do Chrome 100 a 116.
• Leia Intent de experimento e Intent de envio.

O que é CHIPS?

Os Cookies com Estado Particionado Independente (CHIPS) permitem que os desenvolvedores ativem um cookie no armazenamento de particionamento, com armazenamentos separados por site de nível superior, melhorando a privacidade e a segurança do usuário.

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

O CHIPS, a API Storage Access e os Conjuntos de sites relacionados são a única maneira de ler e gravar cookies de contextos entre sites, como iframes, quando cookies de terceiros estão bloqueados.

O CHIPS apresenta 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 está vinculado ao site de nível superior em que foi definido inicialmente 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 em que foram definidos inicialmente.

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 "Partitioned", 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ó vai 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 acessar o site C como um site de nível superior, o cookie particionado definido por C quando ele estava incorporado em A também não será enviado nessa solicitação.

Casos de uso

Por exemplo, o site retail.example pode querer trabalhar com um serviço de terceiros support.chat.example para incorporar uma caixa de chat de suporte no site. Muitos serviços de chat incorporáveis hoje em dia dependem de cookies para salvar o estado.

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 precisaria 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 de vários sites, sem os riscos associados a cookies não particionados.

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

• Incorporações de chat de terceiros
• Incorporações de mapas de terceiros
• Incorporações de pagamentos terceirizados
• Balanceamento de carga da CDN de subrecursos
• Provedores de CMS headless
• Domínios de sandbox para veicular conteúdo não confiável do usuário (como googleusercontent.com e githubusercontent.com)
• CDNs de terceiros que usam cookies para veicular conteúdo controlado por acesso com base no status de autenticação no site primário (por exemplo, fotos de perfil em sites de redes sociais hospedados em CDNs de terceiros).
• Frameworks de front-end que dependem de APIs remotas usando cookies nas solicitações
• Anúncios incorporados que precisam de estado no escopo por editor (por exemplo, capturar as preferências de anúncios dos usuários para esse site)

Por que o CHIPS usa um modelo de particionamento de inclusão

Quando o acesso a cookies de terceiros não particionados é bloqueado, outras abordagens de particionamento são tentadas.

O Firefox anunciou que está particionando todos os cookies de terceiros por padrão no modo ETP Strict e de navegação anônima. Assim, todos os cookies entre sites são particionados pelo site de nível superior. No entanto, a partição de cookies sem uma ativação de terceiros pode levar a bugs inesperados, já que alguns serviços de terceiros têm servidores integrados que esperam um cookie de terceiros não particionado.

O Safari tentou particionar cookies com base em heurísticas, mas acabou bloqueando todos eles, citando a confusão dos desenvolvedores como um dos motivos. Recentemente, o Safari demonstrou interesse em um modelo baseado em inclusão.

O que diferencia o CHIPS das implementações atuais 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) forem descontinuados.

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

Design técnico do particionamento de cookies

Hoje, os cookies são identificados pelo nome do host ou domínio do site que os definiu, ou seja, a chave do host.

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

Com o CHIPS, os cookies que ativam o particionamento são indexados duas vezes na chave do host e na chave de partição.

Uma chave de partição de 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 ao 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.

Nesse caso, a chave de partição é ("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 do cookie.

Veja como a chave de cookie no exemplo anterior aparece antes e depois do CHIPS.

Antes do CHIPS

key=("support.chat.example")

Depois do CHIPS

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

Design de segurança

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

• Os cookies particionados precisam ser definidos com Secure.
• Recomendamos usar o prefixo __Host- ao definir cookies particionados para vinculá-los ao nome do host (e não ao domínio registrável).

Exemplo:

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

Alternativas ao CHIPS

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

São alternativas ao particionamento CHIPS em que é necessário acesso a cookies não particionados entre sites.

Considere a API Storage Access e os conjuntos de sites relacionados em 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, sem que o mesmo cookie precise estar disponível em todos eles. Se o serviço definir um cookie particionado, a chave de partição será o site de nível superior, e esse cookie não estará 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 dependa de uma partição de cookie compartilhada em sites dentro de um RWS, forneça exemplos e feedback no problema do GitHub.

Demonstração

Esta demonstração mostra como os cookies particionados funcionam e como 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 desse 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 os cookies de terceiros são permitidos, o site B também pode definir e acessar o cookie não particionado.

Pré-requisitos

1. Chrome 118 ou 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.
2. Pressione Control+Shift+J (ou Command+Option+J no Mac) para abrir o DevTools.
3. Clique na guia Aplicativo.
4. Acesse Application > Storage > Cookies.
5. Clique em https://chips-site-b.glitch.me.

As DevTools vão mostrar todos os cookies da origem selecionada.

O site B só pode definir o cookie particionado em um contexto entre sites. O cookie não particionado será bloqueado:

• Você vai encontrar __Host-partitioned-cookie com a chave de partição do site de nível superior https://chips-site-a.glitch.me.

1. Clique em Acessar o site B.
2. No DevTools, navegue até Application > Storage > Cookies.
3. Clique em https://chips-site-b.glitch.me.

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.

Se você voltar ao site A, unpartitioned-cookie será armazenado no navegador, mas não 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ê vai encontrar o __Host-partitioned-cookie com a chave de partição do site de nível superior https://chips-site-a.glitch.me.

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

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

• unpartitioned-cookie com a chave de partição vazia.
• Cookie __Host-partitioned-cookie com a chave de partição https://chips-site-a.glitch.me.

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.
• Acesse Application > Storage > Cookies.
• Clique com o botão direito do mouse em https://chips-site-b.glitch.me.
• Clique em Limpar.

Recursos

• GitHub: leia a explicação, faça perguntas e acompanhe a discussão.
• Suporte para desenvolvedores: faça perguntas e participe das discussões no repositório de suporte para desenvolvedores do Sandbox de privacidade.