Como os cookies particionados CHIPS dão a cada site seu próprio pote

O que são cookies particionados CHIPS?

Os navegadores guardam os cookies particionados CHIPS em um pote separado para cada site de nível superior, então o cookie que um widget de suporte define enquanto está incorporado em retail.example fica ilegível para esse mesmo widget incorporado em news.example. CHIPS significa Cookies Having Independent Partitioned State e funciona com um único atributo opcional: adicione Partitioned ao cabeçalho Set-Cookie e o navegador armazena o cookie sob duas chaves em vez de uma, o host que o definiu mais o site de nível superior sob o qual ele foi definido. Use-o em qualquer cookie entre sites restrito a um único site de nível superior, como uma sessão de chat, uma dica de balanceamento de carga de uma CDN ou uma localização salva em um mapa.

A chave dupla é o que separa o CHIPS do cookie third-party comum, que acompanha o conteúdo incorporado por toda parte e alimenta o rastreamento entre sites. Um cookie particionado não consegue sair do site onde nasceu, então um conteúdo incorporado recebe um identificador novo por site de nível superior e nada para cruzar entre eles. Se as duas categorias se misturam para você, comece pelos cookies first-party e third-party.

O que o atributo Partitioned exige?

O atributo Partitioned exige Secure, e os navegadores descartam qualquer cookie particionado que chegue sem ele. O explainer do CHIPS no W3C Privacy Community Group instrui quem implementa: "User agent must reject any cookie set with Partitioned that does not also include the Secure." Em português: o agente de usuário deve rejeitar qualquer cookie definido com Partitioned que não inclua também Secure. A documentação do Privacy Sandbox do Google repete isso para desenvolvedores: "Partitioned cookies must be set with Secure.", ou seja, cookies particionados devem ser definidos com Secure. O rascunho do IETF draft-cutler-httpbis-partitioned-cookies-01, de 10 de novembro de 2022, dá o motivo em suas considerações de segurança: "This proposal takes the opportunity of defining the semantics of a new cookie attribute in order to require the Secure attribute, restricting this feature to secure protocols." Em português: esta proposta aproveita a definição da semântica de um novo atributo de cookie para exigir o atributo Secure, restringindo este recurso a protocolos seguros.

O Path=/ de todo exemplo oficial vem de uma segunda regra, trazida pelo prefixo de nome __Host- e não pelo próprio Partitioned. A RFC 6265bis, rascunho 22 de dezembro de 2025, seção 4.1.3.2, a define: "If a cookie's name begins with a case-sensitive match for the string __Host-, then the cookie will have been set with a Secure attribute, a Path attribute with a value of /, and no Domain attribute." Em português: se o nome de um cookie começar com a string __Host-, respeitando maiúsculas e minúsculas, então o cookie terá sido definido com um atributo Secure, um atributo Path com valor / e nenhum atributo Domain. Dê ao cookie o nome __Host-something e o navegador impõe Path=/ por você, rejeitando qualquer outra coisa. O explainer do CHIPS recomenda o prefixo sem exigi-lo: "Although it is not required, it is still recommended to still include the __Host- prefix." Navegadores que ignoram Partitioned continuam impondo __Host-, então o prefixo garante vínculo ao host em clientes que nunca ouviram falar do CHIPS.

O SameSite é a terceira peça. O explainer diz que os agentes de usuário podem aceitar Partitioned apenas quando SameSite é None, e um cookie feito para funcionar dentro de um frame entre sites precisa de SameSite=None de qualquer forma. Veja o guia de cookies do navegador para iniciantes para entender como os atributos interagem.

O que é exatamente a chave de partição?

A chave de partição é o site da página na barra de endereço, não o site do conteúdo incorporado. O explainer do CHIPS a define com precisão: "A cookie's partition key is the site (i.e. scheme and registrable domain) of the top-level URL the browser was visiting at the start of the request to the endpoint that set the cookie." Em português: a chave de partição de um cookie é o site, isto é, o esquema e o domínio registrável, da URL de nível superior que o navegador estava visitando no início da requisição ao endpoint que definiu o cookie. Duas palavras ali fazem trabalho de verdade. "Site" significa o domínio registrável, então support.shoppy.example e checkout.shoppy.example compartilham uma partição. "Scheme" coloca o protocolo na chave, então http://shoppy.example e https://shoppy.example não compartilham.

O Chrome acrescenta mais um campo. O Chrome Platform Status registra a mudança: "Chrome 128 adds a cross-site ancestor bit to the keying of the partitioned cookie's CookiePartitionKey." Em português: o Chrome 128 adiciona um bit de ancestral entre sites à formação da chave CookiePartitionKey do cookie particionado. Esse bit registra se há um frame entre sites entre o documento de nível superior e o frame que faz a requisição, o que impede um conteúdo incorporado de alcançar os próprios cookies particionados do site de nível superior por meio de um iframe aninhado. A partir do Chrome 128, a chave é um trio: esquema, domínio registrável, bit de ancestral.

Como é um cabeçalho Set-Cookie real?

Um cookie particionado é um cabeçalho Set-Cookie comum com quatro atributos. Este é o exemplo que a documentação do Privacy Sandbox do Google e o MDN publicam, caractere por caractere:

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

Essa resposta precisa chegar por HTTPS, já que Secure e __Host- exigem uma origem segura. Em uma requisição posterior ao mesmo conteúdo incorporado sob o mesmo site de nível superior, o navegador devolve o cookie puro:

Cookie: __Host-example=34d8g

Navegue para outro site de nível superior e esse segundo cabeçalho desaparece. O conteúdo incorporado não vê nenhum cookie e gera um valor novo, que é exatamente o objetivo.

Quais navegadores aceitam o atributo Partitioned?

Três engines aceitam. Estas versões vêm dos dados de compatibilidade de navegadores do MDN para Partitioned.

O MDN marca os cookies particionados como Baseline newly available desde dezembro de 2025. Clientes que não reconhecem o atributo o ignoram e tratam o cookie como um cookie SameSite=None comum, então o seu fallback é o que aquele navegador faz com cookies third-party. No Safari, o fallback é nada, porque o Intelligent Tracking Prevention os bloqueia por completo e limita cookies definidos por script com o limite de 7 dias para cookies no Safari.

Quanto um conteúdo incorporado pode armazenar em uma única partição?

O Chrome limita uma partição a 180 cookies e 10 KB por site incorporado. A documentação do CHIPS dele afirma isso diretamente: "Chrome has a limit of maximum 180 cookies per partition that cannot exceed 10 KB per-embedded-site." Em português: o Chrome tem um limite máximo de 180 cookies por partição, que não podem passar de 10 KB por site incorporado. O teto de bytes é atingido primeiro na maioria dos conteúdos incorporados, então o número a conferir é:

bytes de partição usados = número de cookies x média de bytes por cookie

Um conteúdo incorporado que armazena 20 cookies com média de 500 bytes cada usa 20 x 500 = 10.000 bytes e bate no teto de 10 KB com 160 das 180 vagas livres. Passado o orçamento de bytes, o navegador remove cookies, então planeje pelo tamanho, não pela quantidade.

O Chrome ainda vai acabar com os cookies third-party?

Não. O anúncio mais recente do Google sobre o Privacy Sandbox, "Update on Plans for Privacy Sandbox Technologies", de Anthony Chavez, VP of Privacy Sandbox, datado de 17 de outubro de 2025, remete à decisão anterior "that Chrome will maintain our current approach to offering users third-party cookie choice in Chrome.", isto é, que o Chrome mantém a abordagem atual de deixar os usuários escolherem sobre cookies third-party. Nenhuma descontinuação para o navegador inteiro está programada e nenhum aviso novo vem por aí. O Chrome permite cookies third-party na navegação normal e os bloqueia no modo anônimo.

O mesmo anúncio é o motivo pelo qual vale a pena construir sobre o CHIPS. Ele aposentou a Attribution Reporting API, Protected Audience, Topics, Private Aggregation e Related Website Sets, e depois destacou o CHIPS para o tratamento oposto: "CHIPS and FedCM, which improve cookie privacy and security and streamline identity flows respectively, have seen broad adoption, including support from other browsers. We'll continue to support those APIs and evaluate opportunities for future enhancements." Em português: o CHIPS e o FedCM, que melhoram a privacidade e a segurança dos cookies e simplificam os fluxos de identidade, respectivamente, tiveram ampla adoção, incluindo o suporte de outros navegadores. Vamos continuar dando suporte a essas APIs e avaliar oportunidades de melhorias futuras. Related Website Sets está na lista de aposentados. O CHIPS não.

O que isso significa para o seu analytics?

Um analytics que não define cookies pula a questão. O particionamento resolve um problema que você só tem quando um script lembra um visitante pelo armazenamento do navegador, então o rastreamento sem cookies elimina o modo de falha em vez de isolá-lo. O analytics sem cookies e hospedado na UE do Flowsery registra sessões e replays sem cookies, então não existe chave de partição para configurar errado.

A conta muda se o seu produto entrega um widget que outras empresas incorporam. Esse widget precisa de estado, o site de nível superior não é seu, e o CHIPS o mantém funcionando. Adicione Partitioned, use o prefixo __Host-, mantenha SameSite=None; Secure e teste a primeira requisição em uma partição nova, porque esse caminho agora roda em cada novo site de cliente.

Perguntas frequentes

O atributo Partitioned precisa de Path=/?

Não por causa do próprio Partitioned. O explainer do CHIPS, o rascunho do IETF e a documentação do CHIPS do Google omitem Path=/ dos requisitos do atributo. Ele aparece em todo exemplo oficial porque esses exemplos usam o prefixo __Host-, e a RFC 6265bis exige que cookies __Host- tenham um Path de / e nenhum atributo Domain.

O prefixo __Host- é obrigatório para cookies particionados?

Não. O explainer do CHIPS diz que o prefixo "is not required", mas é "still recommended", ou seja, não é obrigatório, mas continua recomendado, então um cookie particionado sem ele é aceito. Use mesmo assim: navegadores que ignoram Partitioned continuam impondo o prefixo e vinculam o seu cookie ao host exato.

Cookies particionados ainda precisam de consentimento pelo GDPR?

Sim. O particionamento muda quem pode ler um cookie, não se ele chega ao dispositivo. A exigência de consentimento da Diretiva ePrivacy se aplica ao armazenamento de informações no equipamento terminal de um usuário ou ao acesso a elas, e um cookie particionado faz as duas coisas. Cookies estritamente necessários continuam isentos em qualquer caso.

Um site de nível superior pode apagar os cookies particionados de um conteúdo incorporado?

Não. O explainer do CHIPS afirma que sites de nível superior não devem conseguir apagar os cookies de terceiros na sua partição, já que isso deixaria um site hospedeiro interferir no código dentro de frames incorporados. Um conteúdo incorporado apaga a própria partição enviando Clear-Site-Data, que afeta apenas a partição do site de nível superior atual.

Qual a diferença entre o CHIPS e o particionamento de estado do Firefox?

O Firefox particiona o armazenamento de cookies third-party por padrão, sem nenhuma ação do site. O CHIPS é um atributo que um serviço adiciona de propósito, e ele vale igualmente em contextos first-party e third-party. O MDN recomenda ativar o CHIPS em vez de depender do particionamento de estado, porque o atributo explícito é o mais compatível entre navegadores.

O que substitui o CHIPS se um conteúdo incorporado precisa de um cookie em vários sites?

A Storage Access API. O Related Website Sets cobria esse caso declarando um grupo de domínios relacionados, e o anúncio do Google de 17 de outubro de 2025 o incluiu entre as tecnologias aposentadas. A Storage Access API pede permissão ao usuário para usar armazenamento não particionado em um frame entre sites, e é o caminho com suporte que resta para estado compartilhado.

O Partitioned funciona com SameSite=Lax ou SameSite=Strict?

O explainer do CHIPS permite que os navegadores aceitem Partitioned só quando SameSite é None, então um cookie com Lax ou Strict pode ficar sem partição mesmo com o atributo. Essa combinação faz sentido para o caso de uso, já que um cookie particionado importa dentro de um embed entre sites, e um embed precisa de SameSite=None para receber um cookie. Defina SameSite=None; Secure junto com Partitioned e a dúvida deixa de existir.

O que acontece quando uma partição ultrapassa o limite de 10 KB do Chrome?

O Chrome impõe um limite de 180 cookies e 10 KB por partição para cada site incorporado, e assim que o armazenamento ultrapassa qualquer um dos dois limites, o navegador remove cookies dessa partição. O limite de bytes costuma se aplicar primeiro: um punhado de cookies com algumas centenas de bytes cada pode preencher 10 KB enquanto dezenas dos 180 slots continuam livres. Planeje pelo total de bytes armazenados por site de nível superior, não pelo número de cookies definidos.

É possível definir um cookie particionado por HTTP simples?

Secure impede isso. O atributo Partitioned exige Secure, e o rascunho do IETF aponta exatamente essa combinação como o motivo de definir o novo atributo, restringindo o recurso a protocolos seguros. Um cabeçalho Set-Cookie enviado por HTTP simples perde tanto o Partitioned quanto o cookie que o carrega.

O que é o bit de ancestral cross-site na chave de partição do Chrome?

A partir do Chrome 128, a chave de partição ganha um terceiro campo, além do esquema e do domínio registrável, que registra se existe um frame cross-site entre o documento de nível superior e o frame que fez a solicitação. Esse bit de ancestral impede que um conteúdo incorporado alcance os próprios cookies particionados do site de nível superior por meio de um iframe aninhado. Versões mais antigas do Chrome e outros navegadores chaveiam partições apenas pelo esquema e domínio registrável.