Só o domínio decide entre cookies first-party vs third-party

Qual é a diferença entre cookies first-party vs third-party?

Os navegadores separam cookies first-party vs third-party com um único teste, comparando o domínio que gravou o cookie com o domínio na barra de endereços: o cookie é first-party, ou seja do próprio domínio da página, quando os dois batem, e third-party, de um domínio alheio, quando não batem. Nada de dentro do cookie entra nesse teste, nem o nome, nem o valor, nem o dono. O guia da MDN sobre cookies third-party enuncia a regra sem rodeios: "If the cookie domain and scheme match the current page the user is looking at (the URL shown in the browser's address bar), the cookie is considered to be from the same site as the page, and is referred to as a first-party cookie." Em português: se o domínio e o esquema do cookie batem com a página que o usuário está vendo (a URL exibida na barra de endereços do navegador), o cookie é considerado do mesmo site que a página e é chamado de cookie first-party. Domínio ou esquema diferente, cookie third-party.

Quase toda página na internet descreve a divisão como o seu cookie contra o cookie de um anunciante. Esse enquadramento está errado. O cookie de uma rede de anúncios, lido no site da própria rede, é first-party; o seu próprio cookie de login, lido dentro de um iframe no site de um parceiro, é third-party.

Por que o mesmo cookie às vezes é first-party e às vezes third-party?

A categoria pertence à leitura, não ao cookie. Um cookie armazenado carrega um domínio, e o navegador refaz a comparação em cada requisição, então mover a leitura para outro site de nível superior inverte a resposta.

Pegue um widget de suporte que grava um cookie em widget.example. Um visitante parado em https://widget.example envia esse cookie como cookie first-party, porque o domínio do cookie bate com a barra de endereços. O mesmo visitante abre https://shop.example, onde o mesmo widget carrega em um iframe. O navegador compara widget.example com shop.example, não acha correspondência, e o cookie idêntico viaja como cookie third-party sob todas as restrições que o navegador impõe a essa categoria. Um cookie no armazenamento, duas categorias, decididas por requisição.

O que o Chrome fez de fato sobre a remoção dos cookies third-party?

O Chrome cancelou a remoção. Anthony Chavez, VP of Privacy Sandbox, escreveu em 22 de abril de 2025 que o Google havia "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Em português: tomado a decisão de manter a abordagem atual de oferecer aos usuários a escolha sobre cookies third-party no Chrome, e não vai lançar um novo aviso independente para cookies third-party. Os cookies third-party continuam ativados por padrão no modo de navegação normal do Chrome, e o controle continua nas configurações de Privacidade e segurança. A documentação de ajuda do Chrome diz que os cookies third-party são bloqueados por padrão no modo anônimo, então o bloqueio vale para um modo de navegação e não para o navegador.

Qualquer artigo que ainda cite uma data de encerramento está citando um plano que o Google retirou. Construa contra o que está no ar: o Safari bloqueia, o Firefox particiona, o Chrome permite fora do modo anônimo.

O que o Safari e o Firefox fazem com os cookies third-party?

O Safari apaga a categoria e o Firefox a divide. John Wilander anunciou o bloqueio total no blog do WebKit em 24 de março de 2020 em uma frase: "Cookies for cross-site resources are now blocked by default across the board." Em português: cookies de recursos entre sites agora estão bloqueados por padrão em todos os casos. A política de prevenção de rastreamento do WebKit confirma que a Intelligent Tracking Prevention "blocks all third-party cookies", ou seja bloqueia todos os cookies third-party, e deixa uma única rota de volta, a Storage Access API, que pergunta ao usuário primeiro.

O Firefox seguiu o outro caminho. A Mozilla lançou o Total Cookie Protection para todos os usuários do mundo em 14 de junho de 2022, e ele mantém os cookies third-party vivos dentro de um limite: "any time a website, or third-party content embedded in a website, deposits a cookie in your browser, that cookie is confined to the cookie jar assigned to only that website." Em português: toda vez que um site, ou conteúdo third-party incorporado em um site, deposita um cookie no seu navegador, esse cookie fica confinado ao pote de cookies atribuído somente àquele site. Um rastreador incorporado continua ganhando um cookie em cada site onde aparece, e ganha um diferente a cada vez, o que mata a junção entre sites sem matar o widget.

Cookies first-party vs third-party comparados

A última linha explica por que o bloqueio caiu de um lado só. Bloquear cookies third-party quebra o encanamento entre sites dos outros; bloquear cookies first-party quebraria a web.

O que quebra quando os cookies third-party são bloqueados?

O estado entre sites quebra, e só o estado entre sites. O single sign-on por um provedor de identidade dentro de um iframe para de reconhecer o usuário, um checkout ou widget de chat incorporado perde o cliente que volta, e uma plataforma de anúncios perde a atribuição de conversão e o limite de frequência, porque cada um precisa de um identificador lido em dois sites de nível superior diferentes.

Dois substitutos cobrem as partes que valem a pena manter. A Storage Access API deixa um frame incorporado pedir ao usuário os cookies não particionados dele. Os cookies particionados dão conta do resto.

Como os cookies particionados mudam o quadro?

Cookies particionados mantêm o cookie third-party e removem a junção entre sites acrescentando o site de nível superior à chave de armazenamento. A MDN documenta o mecanismo como CHIPS, Cookies Having Independent Partitioned State, e o registra como Baseline newly available desde dezembro de 2025. A mudança é uma linha de estrutura de chave:

storage key = (top-level site, cookie domain) em vez de storage key = (cookie domain)

Trabalhe um exemplo com os valores da própria MDN. Um widget em 3rd-party.example envia Set-Cookie: __Host-example=34d8g; SameSite=None; Secure; Path=/; Partitioned; enquanto está incorporado em site-a.example, e o navegador o armazena sob {("https://site-a.example"), ("3rd-party.example")}. Em site-b.example o widget pede o cookie, o navegador procura {("https://site-b.example"), ("3rd-party.example")} e não acha nada. O widget funciona nos dois sites e não liga nenhum ao outro.

Os cookies first-party sobrevivem a tudo?

Não, e a exceção pega a analytics primeiro. A política de prevenção de rastreamento do WebKit compromete a ITP a "deleting all cookies created in JavaScript and all other script-writeable storage after 7 days of no user interaction", em português: apagar todos os cookies criados em JavaScript e todo o resto do armazenamento gravável por script depois de 7 dias sem interação do usuário, o que cobre um cookie first-party escrito por um script de analytics no seu próprio domínio. A regra se prende a como o cookie foi escrito, não a de quem é o domínio onde ele fica, então o limite de 7 dias dos cookies no Safari encurta qualquer identificador do lado do cliente.

O efeito visível é uma contagem inflada de visitantes novos, porque um visitante que volta depois do limite chega sem identificador e começa uma nova sessão. Grave identificadores a partir do servidor em um cabeçalho de resposta Set-Cookie se você precisa que eles passem do limite.

O que isso significa para medir o seu próprio site?

Analytics que se apoia em um cookie third-party mede o modo de navegação normal do Chrome e pouca coisa além. Mover o identificador para um cookie first-party amplia a cobertura e esbarra no limite da ITP, e é por isso que a medição continua migrando para o servidor: leia os argumentos a favor do tracking do lado do servidor antes de reconstruir um identificador no cliente pela terceira vez.

Nenhuma das duas categorias escapa da lei de consentimento. O artigo 5(3) da Diretiva ePrivacy pergunta se a informação é armazenada no dispositivo ou lida dele, então um cookie first-party de analytics dispara a regra exatamente como um third-party dispara, que é o que um banner de consentimento existe para resolver. Não armazenar identificador nenhum remove o gatilho, e a analytics sem cookies cobre o que isso custa para você.

A Flowsery é construída assim. A analytics que prioriza a privacidade dela não usa cookies, é hospedada na UE e é GDPR by design, chega como um script único abaixo de 10 KB e não aplica amostragem de dados, então nunca cai em nenhum dos dois lados da divisão entre first-party e third-party.

Perguntas frequentes

Um cookie first-party está sempre a salvo do bloqueio do navegador?

Não. A ITP do Safari apaga cookies criados em JavaScript, junto com outro armazenamento gravável por script, depois de 7 dias sem interação do usuário, e isso vale no seu próprio domínio. Um cookie first-party gravado pelo servidor em um cabeçalho de resposta Set-Cookie fica fora dessa regra. O que importa é como o cookie foi escrito, não quem é dono do domínio.

O navegador olha para quem é dono do domínio?

Não. O navegador compara o domínio e o esquema do cookie com a página de nível superior na barra de endereços e nada mais. Propriedade, empresa e finalidade nunca entram na comparação, e é por isso que o cookie de um anunciante é first-party no site do próprio anunciante.

Um cookie pode ser first-party e third-party ao mesmo tempo?

Sim, e o mesmo cookie armazenado alterna entre os dois a cada requisição. Lido no domínio que o gravou, o cookie é first-party. Lido de um iframe em outro site de nível superior, o cookie idêntico é third-party e herda todas as restrições third-party.

Por que um cookie third-party precisa de SameSite=None e Secure?

Requisições entre sites carregam um cookie só quando ele está marcado como SameSite=None, já que o padrão do navegador é SameSite=Lax. A MDN diz que "if SameSite=None is set then the Secure attribute must also be set", em português: se SameSite=None for definido, o atributo Secure também precisa ser definido, o que o restringe a HTTPS. Sem os dois atributos, um navegador moderno nunca envia o cookie entre sites.

O Google chegou a remover os cookies third-party do Chrome?

Não. Anthony Chavez escreveu em 22 de abril de 2025 que o Google iria "maintain our current approach to offering users third-party cookie choice in Chrome", ou seja manter a abordagem atual de oferecer aos usuários a escolha sobre cookies third-party no Chrome, e não lançaria um aviso independente. O Chrome permite cookies third-party por padrão na navegação normal e os bloqueia por padrão no modo anônimo, segundo a documentação de ajuda do Chrome.

O Firefox apaga os cookies third-party como o Safari faz?

Não, o Firefox isola os cookies. O Total Cookie Protection, padrão no mundo todo desde 14 de junho de 2022, confina cada cookie ao "the cookie jar assigned to only that website", o pote de cookies atribuído somente àquele site, então um rastreador incorporado ganha um cookie separado em cada site onde aparece. O elemento incorporado continua funcionando, e o perfil entre sites nunca se monta.

O que significa CHIPS?

CHIPS significa Cookies Having Independent Partitioned State, o mecanismo que a MDN documenta por trás dos cookies particionados. Ele acrescenta o site de nível superior à chave de armazenamento do cookie, de modo que o mesmo domínio de cookie recebe um valor diferente em cada site que o incorpora. A MDN registra o CHIPS como Baseline newly available desde dezembro de 2025.

O que é a Storage Access API?

A Storage Access API permite que um iframe incorporado peça ao navegador acesso aos seus cookies não particionados, com um aviso ao usuário antes. A política de prevenção de rastreamento do WebKit, do Safari, a indica como a única via de volta depois de bloquear todos os cookies third-party. Os cookies particionados cobrem o restante do que o estado entre sites precisa para continuar funcionando.

Cookies first-party também precisam de consentimento?

O artigo 5(3) da Diretiva ePrivacy pergunta se uma informação é armazenada no dispositivo ou lida dele, não a quem pertence o domínio, então um cookie first-party de analytics aciona a mesma exigência de consentimento que um cookie third-party. Um banner de consentimento existe justamente para atender essa exigência, independente da categoria do cookie. Não armazenar nenhum identificador remove esse gatilho por completo.

Por que um visitante recorrente às vezes é contado como novo nas analytics?

Um visitante que retorna depois do limite de 7 dias do ITP do Safari chega sem identificador, então a ferramenta de analytics inicia uma nova sessão e o conta como novo. Essa regra vale para qualquer cookie escrito no lado do cliente via JavaScript, incluindo scripts de analytics first-party no seu próprio domínio. Definir os identificadores pelo servidor num cabeçalho de resposta Set-Cookie evita esse limite por completo.