Glossário

O que o limite de 7 dias dos cookies no Safari realmente restringe

Taras Shynkarenko
Taras Shynkarenko
•Atualizado: •8 min de leitura
O que o limite de 7 dias dos cookies no Safari realmente restringeO que o limite de 7 dias dos cookies no Safari realmente restringe

TL;DR, Resposta rápida

8 min de leitura

O limite de 7 dias dos cookies no Safari corta qualquer cookie gravado via JavaScript para uma validade de sete dias, não importa qual validade o script pediu. A Intelligent Tracking Prevention do WebKit encurta esse limite para 24 horas quando o cookie é gravado logo depois de um clique entre sites com parâmetros de URL do tipo tracking. Cookies gravados pelo servidor via cabeçalho de resposta Set-Cookie, incluindo cookies HttpOnly, não entram em nenhum dos dois limites.

O que é o limite de 7 dias dos cookies no Safari?

A Intelligent Tracking Prevention da Apple aplica o limite de 7 dias dos cookies no Safari cortando a validade de qualquer cookie gravado via JavaScript para sete dias a partir da criação, não importa a data de validade que o script pediu. Um script que chama document.cookie e pede validade de um ano recebe sete dias em vez disso; o Safari reescreve a validade em silêncio e não devolve nenhum erro para a página que gravou o cookie. O limite vale para o armazenamento do cookie no dispositivo, não para se o site pode continuar pedindo ao visitante que se autentique de novo.

Por que a Apple criou a Intelligent Tracking Prevention?

A Apple construiu a Intelligent Tracking Prevention dentro do WebKit para impedir que rastreadores usassem cookies de longa duração gravados por script como identificador permanente depois que o acesso a cookies entre sites foi restringido. Versões anteriores da ITP bloqueavam cookies third-party que seguiam um visitante por sites sem relação entre si; os rastreadores reagiram gravando o identificador deles em um cookie first-party de cada site via JavaScript, o que continuava funcionando porque um cookie first-party nunca era bloqueado. O limite de 7 dias fechou essa brecha ao fazer qualquer cookie do lado do cliente, first-party ou não, expirar em um relógio curto.

Uma pessoa toca em um anúncio no celular, exatamente o momento de clique até a landing page que pode acionar o limite mais curto de 24 horas.

O jogo de gato e rato por trás do limite de 7 dias
Cookies third-party bloqueados
Rastreadores migram para cookies first-party via JavaScript
O ITP limita cookies de script a 7 dias
As equipes passam a gravar o cookie pelo servidor
Cada restrição do ITP empurrou o rastreamento para uma nova camada, até o limite alcançar o último cookie que um script ainda consegue escrever.

Quando o limite cai para 24 horas em vez de 7 dias?

O WebKit encurta o limite para 24 horas quando um cookie é gravado via JavaScript logo depois de uma navegação entre sites cuja URL carrega decoração de link, como um parâmetro de query usado para passar um ID de clique ou de campanha, e o domínio de origem é um que o classificador embarcado do WebKit marcou como capaz de rastreamento entre sites. Essa regra mira exatamente o padrão que um clique em anúncio produz: um visitante clica em um anúncio, chega por um redirecionamento com um parâmetro de rastreamento, e a página de destino grava esse parâmetro num cookie na hora. Sem o limite mais curto, esse fluxo teria mantido os 7 dias completos.

Tipo de cookieGravado porLimite da ITP
Cookie padrão de JavaScriptdocument.cookie7 dias
Cookie de JavaScript depois de um clique marcado num link decoradodocument.cookie24 horas
Cookie de resposta do servidor, com qualquer configuração de HttpOnlyCabeçalho Set-CookieSem limite da ITP
Cookie de sessão sem validade definidaQualquer um dos doisFecha com a sessão do navegador, sem limite da ITP
Como o WebKit decide qual limite vale
1
Verificar quem gravou o cookie. Um cookie escrito por document.cookie entra no limite; um cookie escrito pelo servidor não.
2
Verificar o link de origem. Uma URL com parâmetros de query ou fragmento do tipo tracking marca a visita como decorada.
3
Verificar o classificador. O modelo embarcado do WebKit marca domínios que ele aprendeu que mostram comportamento de rastreamento entre sites.
4
Aplicar o limite. Um cookie de script simples recebe 7 dias; um cookie de script depois de um clique decorado marcado recebe 24 horas.
O limite mais rígido de 24 horas só entra quando um link decorado entre sites e um domínio marcado acontecem juntos.

O que sobrevive ao limite de 7 dias dos cookies no Safari?

Cookies gravados diretamente pelo servidor via cabeçalho de resposta Set-Cookie sobrevivem ao limite de 7 dias dos cookies no Safari intactos, já que o limite só reescreve a validade de cookies que uma página grava via JavaScript no lado do cliente. Um cookie de sessão sem atributo Expires ou Max-Age também sobrevive ao limite na prática, já que ele já termina quando a sessão do navegador fecha, antes de sete dias para a maioria dos visitantes. O que não sobrevive é qualquer identificador que um script de rastreamento depende de document.cookie para persistir além de uma semana sem o visitante voltar direto ao site.

Cookies HttpOnly gravados pelo servidor também têm limite?

Não. Um cookie HttpOnly só pode ser criado e lido via cabeçalho de resposta Set-Cookie do servidor, já que o HttpOnly existe justamente para impedir que o JavaScript toque no cookie, e o limite do Safari para cookies de script só vale para cookies que o JavaScript escreveu. Um cookie de sessão de login, um token CSRF, ou qualquer outro cookie que o seu backend grava e marca como HttpOnly mantém a validade que o servidor atribuiu a ele, sem nenhuma reescrita de sete dias ou 24 horas pela ITP.

O que o limite de 7 dias dos cookies no Safari quebra na atribuição?

O limite de 7 dias dos cookies no Safari quebra qualquer modelo de atribuição que depende de um cookie do lado do cliente para ligar um clique em anúncio a uma conversão mais de uma semana depois, e encurta essa janela para um único dia quando o clique carregava uma URL de rastreamento decorada. Uma venda B2B com um ciclo de vendas de três semanas, uma comissão de afiliado reivindicada numa visita de retorno dez dias depois do primeiro clique, ou uma campanha de remarketing que mede uma janela de atribuição de duas semanas perdem, no Safari, o cookie do lado do cliente que teria ligado o clique original à conversão final, bem antes de a conversão acontecer. O visitante não some do site; só some o cookie gravado por JavaScript que teria ligado duas visitas separadas.

Um desenvolvedor trabalha em um terminal numa sala de servidores, imagem da mudança de scripts no cliente para o tratamento de cookies no servidor.

Como as equipes contornam o limite de 7 dias dos cookies no Safari?

As equipes contornam o limite de 7 dias dos cookies no Safari movendo a gravação do cookie do JavaScript no lado do cliente para o servidor, já que um cabeçalho de resposta Set-Cookie do seu próprio domínio first-party não entra em nenhum dos dois limites da ITP. O tracking do lado do servidor grava o cookie identificador como parte da resposta HTTP em vez de uma chamada de script, e marcá-lo como HttpOnly tira ele completamente do alcance da ITP e ainda impede que qualquer script do lado do cliente leia ou mexa nele. Revisar quais dos seus cookies first-party e third-party ainda são gravados por JavaScript é o primeiro passo para achar cada identificador que esse limite pode expirar sem avisar.

O outro caminho é parar de depender de qualquer cookie para atribuição. A Flowsery entrega analytics sem cookies e hospedada na UE que conecta sessões a receita sem gravar nenhum identificador num cookie, então as configurações do Safari de um visitante e as regras de validade da Apple não têm nada para expirar desde o início.

Perguntas frequentes

O limite de 7 dias dos cookies no Safari vale para o Chrome ou o Firefox?

Não. Os limites de 7 dias e de 24 horas vêm da Intelligent Tracking Prevention do WebKit, que roda no Safari e em todo navegador construído sobre o WebKit, incluindo o Safari no iOS e no iPadOS. O Chrome e o Firefox rodam seus próprios sistemas de prevenção de rastreamento, separados, com regras diferentes e limites de duração diferente.

Só se o cookie for reescrito pelo servidor via cabeçalho Set-Cookie, ou se o visitante voltar direto ao site e o script da página gravar o cookie de novo antes de os sete dias acabarem; qualquer uma das duas ações começa uma janela nova de sete dias. Um cookie que nunca é renovado antes do sétimo dia expira e some, e o visitante precisa ser identificado de novo como se o cookie nunca tivesse existido.

O limite de 7 dias dos cookies no Safari também bloqueia cookies third-party?

Cookies third-party são bloqueados pelo Safari de cara, sob uma regra separada da ITP, e nunca chegam nem perto da questão dos sete dias. O limite de 7 dias mira especificamente os cookies first-party que o JavaScript grava, que é justo a saída que os rastreadores usaram assim que os cookies third-party pararam de funcionar.

Limpar os dados do site apaga o cookie na hora em vez de reiniciar o limite dele, então o site começa do zero na próxima vez que o visitante chega, exatamente como se sete dias já tivessem passado. O limite regula quanto tempo um cookie existente pode viver, não como o cookie se comporta depois de removido manualmente.

O armazenamento local tem o mesmo limite que os cookies?

Esta página cobre só o limite dos cookies, já que é a regra específica descrita aqui. Mecanismos de armazenamento do lado do cliente diferentes de cookies entram em outras partes da Intelligent Tracking Prevention, com condições próprias para quando os dados armazenados de um domínio são apagados, então trate limites de cookies e outros limites de armazenamento como regras separadas em vez de supor que um implica o outro.

Flowsery
Flowsery

Comece seu teste grátis de 14 dias

Painel em tempo real

Rastreamento de metas

Rastreamento sem cookies

Por que alguns sites ainda veem atribuição funcionar além de 7 dias no Safari?

Um site continua funcionando além de sete dias quando nunca dependeu de um cookie gravado por JavaScript para a ligação entre clique e conversão, porque grava o cookie identificador pelo servidor com Set-Cookie, ou porque identifica o visitante de novo por um login em vez de um cookie. Sites que medem conversões sem nenhum cookie, via correspondência de sessão do lado do servidor ou uma abordagem de analytics sem cookies, nunca entram no limite porque não existe cookie gravável por script para a ITP expirar.

O limite de 7 dias dos cookies no Safari vale para cookies que o JavaScript só lê, ou apenas para os que ele grava?

O limite só vale quando o JavaScript grava um cookie por document.cookie, não quando apenas o lê. Um cookie gravado pelo servidor que um script só lê mantém a validade definida pelo cabeçalho Set-Cookie, porque só as gravações feitas por script são reescritas. Cookies HttpOnly eliminam até esse acesso de leitura, mas a regra de gravação já cobre a leitura de qualquer cookie que o JavaScript conseguiria ver de outra forma.

Só se o link de afiliado carregar parâmetros de rastreamento decorados, como um ID de clique ou de campanha na URL, e o domínio de referência for um que o classificador do WebKit sinalizou como capaz de rastreamento cross-site. Sem as duas condições, um link de afiliado continua sob o limite padrão de 7 dias para qualquer cookie gravado por JavaScript. O exemplo de afiliado citado neste post, uma comissão reivindicada dez dias após o primeiro clique, já fica fora da janela de 7 dias, então o limite mais curto só pioraria essa lacuna.

O limite de 7 dias dos cookies no Safari também vale para scripts de analytics third-party?

Sim, se o script gravar o cookie por document.cookie no próprio domínio da página, porque o limite de 7 dias cobre qualquer cookie definido no lado do cliente, first-party ou não. O que importa para o ITP é como o cookie foi gravado, não qual empresa escreveu o script. Uma tag de analytics third-party que ainda depende de document.cookie para seu identificador perde esse identificador em sete dias, do mesmo jeito que um script de rastreamento first-party.

O limite de 24 horas só entra em ação para um cookie gravado logo depois do próprio clique cross-site decorado; ele não age para trás sobre um cookie que já existia no dispositivo. Um cookie gravado pelo JavaScript antes de o visitante clicar no anúncio continua sob o limite que valia quando foi criado, geralmente o padrão de 7 dias. O clique pode iniciar um cookie novo e mais limitado, mas não altera de forma retroativa um que já está em contagem.

Este artigo foi útil?

Diga-nos o que pensa!

Veja-nos mais no Google

Um clique marca a Flowsery como fonte preferida e nossos artigos passam a aparecer mais acima nas suas Principais notícias, no modo IA e nas visões gerais com IA.

Antes de ir...

Flowsery

Flowsery

Analytics orientado para receitas para o seu site

Rastreie cada visitante, fonte e conversão em tempo real. Simples, poderoso e sem cookies.

Painel em tempo real

Rastreamento de metas

Rastreamento sem cookies

Termos relacionados do glossário

Tamanho, validade, acesso e lei em local storage vs cookiesTamanho, validade, acesso e lei em local storage vs cookies
Glossário

Tamanho, validade, acesso e lei em local storage vs cookies

Comparamos local storage vs cookies pelas specs: tamanho, validade, o que vai em cada request, HttpOnly, Secure, SameSite, Safari ITP e ePrivacy.

•10 min de leitura
Como um atributo ausente decide cookie de sessão vs cookie persistenteComo um atributo ausente decide cookie de sessão vs cookie persistente
Glossário

Como um atributo ausente decide cookie de sessão vs cookie persistente

Comparamos cookie de sessão vs cookie persistente pela RFC 6265 e pelo MDN: Expires e Max-Age, session restore, o teto de 400 dias e o consentimento na UE.

•9 min de leitura
O que sete fornecedores publicam sobre retenção de dados de session replayO que sete fornecedores publicam sobre retenção de dados de session replay
Glossário

O que sete fornecedores publicam sobre retenção de dados de session replay

Comparamos a retenção de dados de session replay nas docs de FullStory, Hotjar, Clarity, LogRocket, PostHog, Sentry e Datadog, e o que o GDPR exige.

•9 min de leitura
O que o rrweb grava e como funcionam suas opções de privacidadeO que o rrweb grava e como funcionam suas opções de privacidade
Glossário

O que o rrweb grava e como funcionam suas opções de privacidade

Como o rrweb grava uma sessão como snapshot do DOM mais mutações, não vídeo: pacotes npm, licença MIT e opções de privacidade como maskAllInputs e blockClass.

•9 min de leitura
O que conta como tráfego de referência e o que silenciosamente não contaO que conta como tráfego de referência e o que silenciosamente não conta
Glossário

O que conta como tráfego de referência e o que silenciosamente não conta

O tráfego de referência é decidido por duas regras. O GA4 lê o medium, o Matomo lê o host do referrer, e o header Referer descarta quase toda a URL.

•10 min de leitura
O que realmente quebra em SameSite Lax vs Strict vs NoneO que realmente quebra em SameSite Lax vs Strict vs None
Glossário

O que realmente quebra em SameSite Lax vs Strict vs None

Decida entre SameSite Lax vs Strict vs None pelo texto da RFC e pelo padrão documentado do Chrome, incluindo a exigência de Secure e o que cada modo quebra.

•10 min de leitura

Artigos relacionados