🍪 ubercookie

Uma demonstração educativa de como os sites identificam você de forma persistente — e por que "limpar os cookies" já não é suficiente.

O ubercookie planta um único id aleatório em 12 vetores diferentes de armazenamento do navegador de uma só vez. Cada vez que você visita, ele lê todos eles, chega a um consenso e reescreve o id de volta em todos os lugares. Limpe qualquer um dos armazenamentos — ou até mesmo todos os seus cookies — e os sobreviventes silenciosamente o ressuscitam. O site mostra a você, em linguagem simples, exatamente onde seu id está escondido e com que frequência ele reconheceu seu navegador.

É a mesma ideia por trás do clássico evercookie de Samy Kamkar — construído aqui como um auxílio de ensino aberto e transparente, focado na ressuscitação de armazenamento e na persistência de supercookies.

[!IMPORTANT] Este projeto rastreia o visitante de propósito, para conscientização. Ele é apenas first-party, armazena somente um id aleatório, contagens de visita, carimbos de data/hora de primeira/última visita e rótulos de origem de recuperação, não compartilha nada com terceiros e inclui um botão "Forget me" de verdade. Não o reaproveite para rastrear pessoas sem o conhecimento ou consentimento delas — isso é o oposto do objetivo. Veja Ética.

O que ele demonstra

Além desses, a página pede ao navegador armazenamento persistente (navigator.storage.persist()), o que isenta as cópias em IndexedDB / Cache / Service Worker / OPFS da remoção automática — tornando-as ainda mais difíceis de eliminar.

Os três vetores baseados em cache são a grande sacada da persistência: eles vivem no cache HTTP do navegador, então o JavaScript (incluindo o nosso próprio "Forget me") não pode excluí-los — apenas a limpeza do cache do navegador consegue. É assim que o id volta dos mortos.

Uma descrição completa dos vetores de armazenamento implementados, além da ideia de supercookie HSTS que ainda cabe neste projeto, está em docs/techniques.md.

Arquitetura

ubercookie/
├── backend/            FastAPI — server-side vectors + the observation log (SQLite)
│   └── app/
│       ├── main.py     endpoints: /api/visit, /api/whoami, /api/etag-id,
│       │               /api/lastmod-id, /api/cache-id.js, /api/clear-cookie,
│       │               /api/forget
│       ├── store.py    "we've seen this browser N times" memory
│       └── ids.py      mint/validate the 32-hex tracking id
└── frontend/           Vanilla JS + Vite — the dashboard and the client vectors
    └── src/ubercookie/
        ├── index.js    orchestrator: read-all → consensus → respawn → report
        └── vectors/    one self-contained module per storage vector

Como funciona uma visita (frontend/src/ubercookie/index.js):

1. Ler cada vetor em paralelo.
2. Consenso — escolher o id com o qual a maioria dos vetores concorda (ou nenhum, se você for novo).
3. Reportar ao servidor, que gera um id novo se você não tinha nenhum, registra a visita e define o cookie HttpOnly.
4. Ressuscitar — reescrever esse único id em cada vetor que estava sem ele.

Início rápido

Requer Python ≥ 3.11 (com uv) e Node ≥ 18.

make install        # backend deps (uv) + frontend deps (npm)

# then, in two terminals:
make backend        # FastAPI on http://localhost:8000
make frontend       # Vite on  http://localhost:5173  (proxies /api → :8000)

Abra http://localhost:5173 e veja você mesmo sendo rastreado. Abra o DevTools, exclua alguns armazenamentos, clique em Re-scan e observe-os ressuscitar.

Uma linha para iniciar os dois servidores de uma vez: ./scripts/dev.sh

Modo produção (o FastAPI serve o frontend compilado, origem única)

make build                                   # → frontend/dist
cd backend && uv run uvicorn app.main:app --port 8000
# open http://localhost:8000

Servir ambos a partir de uma única origem é a configuração mais fiel, porque os vetores de cache/ETag dependem de cache HTTP real de mesma origem.

Testes

make test           # backend pytest (server-side vector logic + observation log)
make build          # frontend production build

Os testes do backend exercitam os vetores do lado do servidor e o log de observação. O comportamento do navegador ainda precisa de um navegador real para ser verificado, porque vários vetores dependem de armazenamento de origem, Service Workers e cache HTTP.

Ética

Esta é uma ferramenta defensiva / de conscientização. Diretrizes incorporadas ao design:

• Transparência — todo valor armazenado é mostrado ao usuário na página.
• Apenas first-party — sem requisições a terceiros, sem rastreamento entre sites.
• Dados mínimos — um id aleatório, carimbos de data/hora de primeira/última visita, um contador de visitas e rótulos dos vetores que recuperaram o id. Sem PII e nada sai do servidor.
• Opt-out real — o botão Forget me limpa tudo o que é acessível e exclui o registro do servidor; a página é honesta sobre o que apenas uma limpeza de cache pode remover.

Mantenha qualquer fork no mesmo espírito: use-o para ensinar às pessoas como o rastreamento funciona para que possam se defender, não para rastreá-las secretamente.

Licença

MIT — veja LICENSE.