Um Site Vê Seu Histórico de Navegação? Teste ao Vivo

Você olhou umas botas de trilha uma vez, no site de uma loja. Agora todo site que você abre quer vender botas de trilha. A conclusão óbvia é que os sites leem o seu histórico de navegação e o repassam. Não leem. Nos navegadores atuais nenhum site consegue ler a lista dos sites que você visitou, e mesmo assim os anúncios seguem você.

O widget desta página pergunta ao seu próprio navegador o que ele conta a uma página sobre por onde você andou. Quase nada, e de propósito.

Nenhuma API entrega o seu histórico

Veja o que window.history oferece a um script: back(), forward(), go(), pushState(), replaceState(), state, scrollRestoration e um length. Nada ali devolve um endereço. history.length conta as entradas da aba atual e para em 50 no Chrome e no Firefox (o Safari guarda 100), então diz pouco sobre o quanto você navegou.

Já a Navigation API, mais recente, devolve endereços com navigation.entries(), mas só os de entradas da aba atual que tenham a mesma origem da página, e só a sequência ininterrupta delas. A página lê o próprio rastro e o de mais ninguém. No meu teste no Chromium 156, depois de seguir um link de uma origem para esta página em outra, history.length marcou 2 e navigation.entries() listou uma entrada, a própria página. Não testei Firefox nem Safari.

O truque do :visited e como ele morreu

Durante anos existiu uma porta dos fundos. Os navegadores pintam os links visitados de outra cor, e uma página podia perguntar em que cor um link ficou. Então um script criava um link invisível para a página de login de um banco, lia a cor calculada e sabia se você já tinha estado lá. A Mozilla estimou a velocidade em centenas de milhares de links por minuto, sem nenhum aviso e sem nada que você pudesse notar.

Em março de 2010, a Mozilla anunciou a correção: getComputedStyle passaria a responder como se todo link fosse não visitado, e os links visitados só poderiam ser estilizados com algumas propriedades de cor. Hoje todos os principais engines de navegador funcionam assim. A primeira linha do widget mostra isso. Ela pergunta sobre um link para a página que você está lendo agora, que por definição você visitou, e o seu navegador diz que não.

Mentir sobre cores só fecha o caminho direto. Os pesquisadores continuaram encontrando canais laterais, como o ataque de Paul Stone em 2013 que mede quanto tempo um link visitado leva para ser redesenhado, e cada um precisou do seu próprio patch. A resposta do Chrome, disponível desde a versão 136 no desktop e no Android, muda o lugar onde as visitas são guardadas. A lista de links visitados deixou de ser uma lista só. Cada entrada é guardada sob três chaves: o endereço do link, o site de nível superior em que você estava e o frame que mostrava o link. Uma página em blog.example que procura o link do banco agora consulta uma chave diferente daquela sob a qual a sua visita ao banco foi guardada, e não encontra nada.

As páginas do próprio site continuam aparecendo como visitadas onde você as abriu pela primeira vez, e os links em que você clicou nesse site também. Isso não expõe nada de novo, porque o site já sabe as duas coisas. Até onde consegui verificar, Firefox e Safari não têm nada equivalente ao particionamento, e o Chrome no iOS também não, já que roda sobre o WebKit. Mesmo assim, a regra de 2010 não era à prova de falhas: as notas do Safari 26.6, de julho de 2026, corrigem um bug do WebKit que deixava os sites saberem se você tinha visitado determinado link.

O que um site consegue ver da sua navegação?

O referrer. Se você chega por um resultado de busca, a página pode descobrir qual site mandou você. Desde o Chrome 85 e o Firefox 87, o padrão para navegações entre origens é enviar só a origem, ou seja, https://www.google.com/ e não a sua pesquisa, a menos que o site de origem defina a própria política. O Safari também reduz os referrers entre sites. No mesmo teste no Chromium 156, a página de onde eu vim tinha um caminho longo e document.referrer devolveu só a origem dela. Se você digitou o endereço ou usou um favorito, o referrer vem vazio. É também por isso que um site em que você clica não vê o que você pesquisou: as suas buscas ficam com o buscador e com a sua conta, não com a página.

Os próprios registros. Este é o mais importante, e também o mais sem graça. Um site que gravou um cookie quando você o visitou na terça passada reconhece você nesta terça. É um histórico de um site só, não da web, e todo site que você visita guarda um sobre você. O dono de um site vê os próprios visitantes nas ferramentas de análise (analytics), com endereços de página, endereços IP e referrers, e essa visão termina na borda do site.

Alguns vazamentos nas bordas. Truques entre sites às vezes conseguem dizer se você está logado em outro lugar, carregando algo que só funciona para quem está autenticado e medindo o que acontece. A wiki XS-Leaks cataloga essa família de técnicas. Ela dá à página um bit sobre um site de cada vez, e alguns canais são fechados enquanto novos continuam surgindo. Nada ali lembra uma lista.

Como os rastreadores ainda montam um histórico de navegação seu

Os anúncios seguem você, em geral, por causa de quem mais está na página. O script de uma rede de anúncios fica na loja de calçados e no site de notícias. Se ele consegue reconhecer você nos dois, tem um histórico de navegação montado site por site, sem nenhuma ajuda do histórico do seu navegador. A FTC tem uma visão geral em linguagem simples de como sites e apps coletam isso.

O Safari bloqueia cookies de terceiros por completo, e o Firefox os particiona por site. Em novembro de 2026, o Chrome ainda os permite por padrão. Cookies são só um jeito de reconhecer você. Um fingerprint de canvas pode continuar igual em todos os sites, na maioria dos navegadores, sem guardar nada, e é por isso que limpar o histórico não adianta contra ele.

O script de um rastreador também roda dentro da página em que está, então pode ler o endereço e o título dela, e não só anotar que você apareceu. Nosso artigo sobre o que uma página consegue observar durante uma visita trata do resto.

Quem mais consegue ver o seu histórico de navegação

Deixe a página de lado e olhe para todos os outros no caminho entre você e um site. A maioria vê só uma parte. A conta sincronizada do navegador é a exceção.

O seu provedor de internet (ISP), ou quem cuida do Wi-Fi do hotel ou do escritório, não consegue ler endereços de página em sites HTTPS. Em geral ainda vê os nomes de domínio, porque a consulta de DNS e o início da conexão TLS nomeiam o site. O DNS criptografado e o Encrypted Client Hello podem esconder isso em alguns sites, mas o endereço IP do servidor continua visível. Uma VPN não apaga essa fatia. Ela entrega a maior parte para a empresa da VPN, e o seu provedor fica sabendo apenas que você usa uma. Explicamos como os sites percebem isso em detecção de VPN.

A linha que as pessoas esquecem é a da própria conta do navegador. Com a sincronização do histórico ligada, uma lista completa dos endereços que você abriu pode ficar no servidor da empresa do navegador. No Chrome, o Google consegue ler o histórico sincronizado, a menos que você defina uma frase secreta de sincronização, e, com ela, só são sincronizados os endereços que você digitou na barra de endereços. O Firefox Sync e o iCloud criptografam o histórico, então essas empresas não conseguem lê-lo.

Modo anônimo, limpar o histórico ou usar o celular mudam alguma coisa?

A navegação privada impede que o seu próprio navegador salve a lista e começa a sessão sem cookies. O site, o seu provedor e o dono do Wi-Fi continuam vendo a visita, e na maioria dos navegadores um fingerprint ainda reconhece você. Safari, Firefox em janelas privadas, Brave e Tor acrescentam ruído ou uniformidade que dificulta isso. Limpar o histórico apaga a lista que o seu navegador guarda, e a cópia sincronizada junto, mas não o que sites, rastreadores ou o seu provedor já têm. Um registro de atividade da conta, como a Minha Atividade do Google, mantém a própria cópia até você apagá-la ali. O celular segue a mesma lógica: a página recebe as mesmas poucas leituras, e o histórico que importa fica na sua conta ou na rede, não no navegador. Então, quando a preocupação é o cônjuge ou os pais, confira dois lugares: uma conta que os dois possam abrir, com a sincronização e o registro de atividade, e a rede por onde o tráfego passa.

O que fazer na prática

1. Confira a primeira linha do widget. Ela deve dizer “Fechado”. Se disser “Vaza”, o seu navegador é anterior à correção de 2010 ou está sem algum patch. Atualize-o, e no Safari confirme que você está na versão 26.6 ou mais recente.
2. Confira o que você sincroniza. Abra as configurações de sincronização do navegador e decida se o histórico precisa estar na conta. No Chrome, uma frase secreta de sincronização impede o Google de lê-lo. O Firefox Sync e o iCloud criptografam o histórico por padrão.
3. Limpar o histórico não impede o rastreamento. Apaga a lista que o seu navegador guarda, e a cópia sincronizada junto. Não mexe nos cookies nem nos dados dos sites, e não alcança o que sites, rastreadores ou o seu provedor já têm. Limpar os cookies corta a metade do rastreamento que depende deles, e na maioria dos navegadores a metade do fingerprint sobrevive às duas coisas.
4. Mantenha as identidades separadas de propósito. Os rastreadores funcionam ligando os pontos, então tudo o que não pode ser ligado precisa de cookies, armazenamento e fingerprint próprios. Se você gerencia várias contas assim, o Incogniton dá a cada perfil cookies, armazenamento e fingerprint próprios, e assim um rastreador que está em dois sites vê dois desconhecidos, desde que você abra cada site em um perfil diferente e dê a cada perfil o seu próprio endereço IP por meio de um proxy.

O widget verifica o que uma página consegue ler. O scan completo do navegador verifica o que uma página consegue deduzir sobre você a partir de propriedades que parecem inofensivas isoladas: os hashes de fingerprint, os vazamentos em torno do seu endereço IP e se o seu navegador conta uma história consistente.