Por que o CNAME cloaking não esconde mais rastreadores do Safari ou do Brave

O que é CNAME cloaking?

Um fornecedor de tracking usa o CNAME cloaking quando o dono de um site aponta um dos subdomínios do próprio site, como metrics.example.com, para o servidor do fornecedor por meio de um registro CNAME no DNS, para que o navegador trate as requisições do fornecedor como first-party. Os navegadores decidem entre first-party e third-party pelo domínio registrável, e um CNAME esconde o destino real uma camada abaixo da web, no DNS. O fornecedor ganha o acesso a cookies do seu próprio site sem aparecer como um domínio separado.

John Wilander, do WebKit, explicou o efeito em um post de 12 de novembro de 2020: o domínio de terceiros "is cloaked as sub.blog.example and thus has the same powers as the true first party." O guia do relatório de privacidade do Safari aponta endpoints com CNAME cloaking como algo a ser auditado.

Como um registro CNAME faz um rastreador parecer first-party?

Um registro CNAME faz um rastreador parecer first-party ao criar um alias de um nome sob o seu domínio para o hostname do rastreador antes de o navegador ver qualquer endereço IP, então todas as verificações que o navegador faz enxergam apenas o seu domínio. A cadeia fica assim:

1. A página em www.example.com carrega um script ou envia uma requisição para metrics.example.com.
2. O DNS responde que metrics.example.com é um CNAME de collect.tracker.example.
3. O DNS resolve collect.tracker.example para o endereço IP do fornecedor.
4. O navegador se conecta, mas a URL, o nome no certificado TLS e o escopo dos cookies dizem metrics.example.com.

Duas regras de cookies fazem esse esforço valer a pena para um rastreador. As requisições para metrics.example.com levam todos os cookies com escopo em example.com, o que, segundo o WebKit, inclui "login cookies and user identity cookies." E a resposta pode definir novos cookies para example.com por meio de um cabeçalho Set-Cookie, que o navegador arquiva como cookies first-party.

Essa segunda regra é o motivo de os rastreadores terem empurrado essa configuração. O Intelligent Tracking Prevention do Safari apaga os cookies criados em JavaScript depois de 7 dias sem interação do usuário com o site, tema que o guia do limite de 7 dias para cookies no Safari cobre em detalhe. Antes de novembro de 2020, os cookies definidos por um servidor em uma resposta HTTP ficavam fora desse limite. O WebKit foi direto: "Cross-site trackers have convinced site owners to set up CNAME cloaking in order to circumvent tracking prevention."

Como o Safari detecta o CNAME cloaking?

O Safari detecta o CNAME cloaking comparando o CNAME pelo qual um subrecurso first-party é resolvido com o próprio domínio do site e com o CNAME do frame principal, e limita a 7 dias qualquer cookie definido em uma resposta que não bate. O WebKit lançou essa defesa no Safari 14, no macOS Big Sur, no iOS 14 e no iPadOS 14, anunciada em 12 de novembro de 2020: "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days."

O WebKit define o gatilho com precisão: "a first-party subresource that resolves through a CNAME that differs from the first-party domain and differs from the top frame host's CNAME, if one exists." Essa última cláusula cobre sites atrás de uma CDN ou de um edge host, em que o site inteiro é resolvido por meio de um CNAME. A própria tabela do WebKit cobre esses casos:

Site principal (www.blog.example)	Subdomínio de tracking (track.blog.example)	Validade do cookie
Sem cloaking	Sem cloaking	Sem limite
Sem cloaking	Aponta para other.blog.example	Sem limite
Sem cloaking	Aponta para tracker.example	Limite de 7 dias
Aponta para abc123.edge.example	Sem cloaking	Sem limite
Aponta para abc123.edge.example	Aponta para o mesmo abc123.edge.example	Sem limite
Aponta para abc123.edge.example	Aponta para other.blog.example	Sem limite
Aponta para abc123.edge.example	Aponta para tracker.example	Limite de 7 dias

A página atual de tracking prevention do WebKit estende a mesma regra a truques de endereço que dispensam nomes de DNS: "ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days." Isso cobre a variante em que o registro de endereço de um subdomínio aponta para o endereço IP de um fornecedor em vez de um hostname do fornecedor.

Um cookie vindo de uma resposta com cloaking agora expira 7 dias depois de ser definido, o mesmo limite que os cookies de JavaScript enfrentam, então o cloaking não garante mais um ID de vida mais longa no Safari.

Como o Brave e o uBlock Origin desmascaram rastreadores com CNAME?

O Brave e o uBlock Origin desmascaram rastreadores com CNAME resolvendo o hostname por conta própria e conferindo o nome canônico com as listas de filtros de rastreadores, e bloqueiam a requisição se o destino real estiver na lista.

uBlock Origin no Firefox. O uBlock Origin 1.25.0 passou a pedir a permissão dns do Firefox, e as notas de versão dizem "From now on uBO will CNAME-uncloak network requests." O recurso depende da API browser.dns da Mozilla, e a equipe de pesquisa do Brave observou que "this solution only works in Firefox, as Chromium does not provide the browser.dns API." A wiki do uBlock Origin diz que a configuração "Uncloak canonical names" é uma configuração normal desde o uBO 1.34.0, vem "default enabled" e "is currently supported only on Firefox." O uBlock Origin no Chrome não consegue ver o CNAME de jeito nenhum.

Brave Shields. O Brave anunciou o bloqueio baseado em CNAME em 20 de julho de 2020 e o liberou para todos os usuários no Brave 1.17. O Brave confere duas URLs em cada requisição para um host com CNAME: "first, the original URL requested by the page, and second, the same URL, but with the CNAME'ed domain name replaced with the resolved 'canonical' domain name." O exemplo dele era 16ao.mathon.fr, um subdomínio com cara de first-party cujo nome canônico era et5.eulerian.net, um rastreador de terceiros.

Um detalhe do Brave pega os donos de sites de surpresa. Desde a versão 1.30, o modo padrão "standard" do Shields não aplica as listas de filtros de rede a subrecursos do mesmo site, e o modo "aggressive" as aplica a "all sub-resource requests, first and third-party alike." Os posts do Brave não dizem como o modo standard trata um subdomínio com cloaking depois de desmascarado, então teste o seu site no modo aggressive antes de contar com qualquer um dos resultados. Bloqueadores de anúncios e navegadores focados em privacidade já reduzem os totais do analytics, como explica o guia sobre o efeito dos bloqueadores de anúncios na precisão do analytics. O CNAME cloaking não recupera esses dados de forma confiável.

Três navegadores, três respostas a um subdomínio disfarçado

Safari 14 Deixa a requisição passar e limita a 7 dias os cookies da resposta

Brave 1.17 Compara o nome canônico com suas listas de filtros e bloqueia a requisição se o rastreador estiver listado

uBlock Origin Desmascara o CNAME e bloqueia as correspondências no Firefox, mas não enxerga o CNAME no Chrome

Quais são os riscos de segurança do CNAME cloaking?

O CNAME cloaking coloca o servidor de um fornecedor dentro do escopo dos seus cookies, então todo cookie que o seu site define no domínio raiz, incluindo os cookies de login e de sessão, vai para esse fornecedor a cada requisição. Isso é um risco de privacidade para os visitantes e um risco de segurança para você. O post do WebKit cita dois problemas. Donos de sites que deixam um subdomínio com cloaking no lugar depois de encerrar o contrato "risk full website takeovers or customer cookie hijacking if the CNAME records aren't properly managed." O post também cita um relatório sobre 250 sites "of banks, healthcare companies, restaurant chains, and civil rights groups" comprometidos por CNAME cloaking mal gerenciado. Um visitante que inspeciona as requisições no DevTools também vê só metrics.example.com, sem nenhum sinal de que os dados vão para uma empresa externa.

Um proxy reverso é o mesmo que CNAME cloaking?

Um proxy reverso não é CNAME cloaking, porque o seu próprio servidor recebe a requisição no seu domínio e a encaminha para o fornecedor, então o DNS desse hostname resolve para a sua infraestrutura, e não para a do fornecedor. Pela definição do WebKit, cloaking significa que o subrecurso "resolves through a CNAME that differs from the first-party domain." Um caminho como example.com/api/track tratado pelo seu próprio servidor web não se enquadra nisso.

As diferenças que importam para o analytics:

Pergunta	CNAME cloaking	Proxy reverso no seu servidor
Para onde o DNS aponta?	Para o hostname do fornecedor	Para o seu próprio servidor
Quem recebe os cookies do seu domínio raiz?	O fornecedor, diretamente	O seu servidor, que escolhe o que encaminhar
O Safari limita os cookies da resposta?	Sim, 7 dias	Não pelas regras de cloaking de CNAME ou de IP
O Brave ou o uBO veem um domínio de rastreador?	Sim, depois de desmascarar	Não há hostname de rastreador para desmascarar, mas as regras de filtro baseadas em caminho continuam valendo
Você ainda precisa divulgar o fornecedor?	Sim	Sim

Um proxy não muda quem processa os dados, então um fornecedor que monta perfis entre sites é o mesmo problema de privacidade nas duas configurações. O guia de tracking server-side cobre os servidores de tagueamento que ficam atrás de um CNAME.

Como verificar se o seu site usa CNAME cloaking?

Você verifica se há CNAME cloaking listando todos os subdomínios para os quais as suas páginas enviam requisições, resolvendo cada um e sinalizando os que resolvem para uma empresa que não é sua:

1. Abra o seu site no Chrome DevTools, vá ao painel Network, recarregue a página e anote todas as requisições para um subdomínio do seu domínio que não seja o host principal.
2. Para cada uma, rode dig CNAME metrics.example.com ou nslookup -type=CNAME metrics.example.com em um terminal.
3. Compare a resposta com a sua própria infraestrutura. A sua CDN ou o seu provedor de hospedagem são esperados. Um fornecedor de analytics, de ad tech ou de dados de clientes é um rastreador com cloaking.
4. Confira se os cabeçalhos de resposta dessas requisições têm Set-Cookie. Um cookie com escopo no seu domínio raiz vindo de um host de fornecedor é o padrão que o Safari limita.
5. Apague os CNAMEs que apontam para fornecedores que você não usa mais.

Como o Flowsery lida com configurações via proxy?

A documentação do Flowsery descreve uma configuração com proxy, e não com CNAME: você faz o proxy do script em /js/main.js e do endpoint em /api/track pelo seu próprio servidor, e "Flowsery Analytics auto-detects proxied setups. No data-api is needed if you proxy both /js/main.js and /api/track." A documentação publica guias de proxy para Next.js, Express.js, PHP, Flask, FastAPI, Vue.js, Nginx, Caddy, Astro, Laravel e DigitalOcean. O script de tracking do Flowsery roda sem cookies, com um hash de visitante que muda todo dia, e não coleta dados pessoais, então nesse modo não existe nenhum cookie de visitante para o Safari limitar. A página do recurso de analytics com foco em privacidade lista o que o tracker guarda e o que ele deixa de fora.

Perguntas frequentes

O CNAME cloaking importa para um analytics sem cookies?

A defesa do Safari contra CNAME limita cookies, então um script que não define nenhum cookie não deixa nada para o Safari limitar. O uBlock Origin no Firefox continua resolvendo o hostname e bloqueia um subdomínio com cloaking cujo nome canônico está nas listas dele, e o Brave faz a mesma verificação do nome canônico. Um script sem cookies passado por proxy no seu próprio servidor não dá a eles nenhum hostname de fornecedor para desmascarar.

O CNAME cloaking passa pelos bloqueadores de anúncios?

O CNAME cloaking passa pelos bloqueadores baseados em listas que só veem o hostname, o que inclui o uBlock Origin no Chrome. O uBlock Origin no Firefox resolve o nome canônico e bloqueia a requisição quando ele corresponde a um rastreador conhecido, e o Brave faz a mesma verificação desde a versão 1.17. O Safari não bloqueia a requisição, mas limita a 7 dias os cookies que ela define.

Qual versão do Safari trouxe a defesa contra CNAME cloaking?

O Safari 14 trouxe a defesa no macOS Big Sur, no iOS 14 e no iPadOS 14, anunciada pelo WebKit em 12 de novembro de 2020. O mesmo limite de 7 dias agora também cobre o cloaking de endereço IP de terceiros.

Um CNAME de CDN conta como cloaking no Safari?

Não quando a CDN fica na frente do site inteiro. A regra do WebKit isenta um subdomínio cujo CNAME corresponde ao CNAME do host do frame principal, então um site e os subdomínios dele no mesmo edge host mantêm a validade normal dos cookies. O limite vale quando um subdomínio resolve para um host diferente, de terceiros.

O tagueamento server-side atrás de um CNAME está a salvo do ITP?

Não. Um servidor de tagueamento acessado por um CNAME que aponta para um serviço hospedado pelo fornecedor se enquadra na definição de CNAME cloaking de terceiros do WebKit, então o Safari limita a 7 dias os cookies que vêm dele. Rodar o servidor na sua própria infraestrutura, com o DNS apontando para o seu próprio IP, evita essa regra.

Como remover o CNAME cloaking do meu site?

Apague o registro CNAME do subdomínio do fornecedor na sua zona de DNS e remova as tags que o chamam. Se você ainda precisa do fornecedor, encaminhe o endpoint dele por um proxy reverso que você opera e cite o fornecedor no seu aviso de privacidade.

Por que os rastreadores usam CNAME cloaking?

O navegador trata um subdomínio do seu site como first-party. As requisições a ele levam os cookies do domínio raiz, e a resposta pode criar novos cookies para esse domínio. Antes de novembro de 2020, os cookies criados por um servidor em uma resposta HTTP ficavam fora do limite de 7 dias do Safari.

O Brave bloqueia o CNAME cloaking por padrão?

O Brave compara o nome canônico com suas listas de filtros desde a versão 1.17. Desde a versão 1.30, o modo padrão do Shields não aplica listas de filtros de rede a subrecursos do mesmo site, enquanto o modo agressivo as aplica a todas as requisições de subrecursos. Os posts do Brave não dizem como o modo padrão trata um subdomínio disfarçado, então teste seu site no modo agressivo.

O uBlock Origin bloqueia o CNAME cloaking no Chrome?

No Chrome não. O Chromium não oferece a API browser.dns, então o uBlock Origin no Chrome não consegue ver o CNAME. No Firefox, a opção "Uncloak canonical names" vem ativada por padrão e bloqueia requisições cujo nome canônico coincide com um rastreador conhecido.

O que é IP address cloaking?

O IP address cloaking é a variante em que o registro de endereço de um subdomínio aponta para o IP de um fornecedor em vez de um hostname dele. O DNS não mostra nenhum CNAME. Segundo o WebKit, o ITP detecta isso e limita a 7 dias os cookies da resposta HTTP, igual ao CNAME cloaking.