Monitor And Anti Monitor - Super-DuperToyBox: DC Direct Monitor and Anti-Monitor
Super-DuperToyBox: DC Direct Monitor and Anti-Monitor

O que são monitor e anti monitor na prática

Monitor e anti monitor são conceitos que aparecem com frequência quando alguém precisa lidar com rastreamento de página, bloqueio de anúncios, ou automação de navegação. O monitor é basicamente qualquer script ou serviço que coleta dados do comportamento do usuário: cliques, tempo de permanência, rolagem, IPs, identificadores de dispositivo. O anti monitor é o conjunto de técnicas e ferramentas que tentam impedir ou distorcer essa coleta. Não tem nada de mágico. É só engenharia reversa aplicada a pixels de rastreamento. Eu já passei por um caso bem específico em que um cliente tinha um painel de analytics que relatava 40% de taxa de rejeição artificialmente inflada. Descobrimos que o anti monitor deles estava interferindo nos tempos de carregamento dos trackers de forma inconsistente — o script de bloqueio às vezes falhava e às vezes funcionava, criando latência variável que o Google Analytics interpretava como abandono de página. A solução foi configurar um wrapper assíncrono com fallback silencioso: se o tracker não respondesse em 300ms, descartava o evento sem travar o carregamento da página. O número de rejeição caiu para 18% e a métrica voltou a fazer sentido.

Monitor e anti monitor: como funciona o básico

Um sistema de monitor normalmente funciona com três camadas. Primeiro, há o coletor, que é o código injetado na página — seja via Google Tag Manager, pixel personalizado, ou biblioteca própria. Esse coletor captura eventos e os empilha em uma fila interna. Depois, há o transportador, que envia esses dados para o servidor de coleta, geralmente via beacon POST ou GET para um endpoint como /collect ou /track. Por fim, existe o processador no lado do servidor, que normaliza, associa a sessões e usuários, e disponibiliza os dados no dashboard. O anti monitor opera em frentes diferentes. O mais comum é o bloqueio por domínio: o AdGuard, uBlock Origin e similares mantêm listas como EasyList que mapeiam domínios conhecidos de rastreamento e bloqueiam requisições feitas a esses endpoints. Outro mecanismo é a detecção por fingerprint — o script de monitor usa canvas, WebGL, headers HTTP e características do navegador para gerar um identificador único. O anti monitor pode interceptar essas chamadas, substituir os valores por dados fake, ou simplesmente remover os scripts antes da execução via Content Security Policy customizada.

Tem uma coisa que poucas pessoas levam a sério: o anti monitor não é uma solução perfeita. Se você estiver usando isso para proteger dados sensíveis ou para garantir conformidade com LGPD, relyr apenas em bloqueadores de terceiros é arriscado. Esses filtros atualizam com base em listas públicas, então qualquer pixel novo ou domínio redirecionado passa limpo até ser adicionado à lista. Um caso real que eu vi: uma startup usava apenas uBlock Origin como camada de privacidade e ainda assim vazava dados de navegação para um domínio de third-party analytics que não estava nas listas consolidadas. O nome do domínio era algo como cdn-analytics-verify.xyz — um domínio que só recebeu tráfego orgânico pequeno, então nenhum filtro havia chegado a flagreá-lo.

Implementando monitor básico

Para criar um monitor simples, você precisa de um endpoint de coleta e um SDK ou script leve no frontend. O que eu uso como base é uma função fetch com um beacon, porque o beacon survive page unload e funciona mesmo se o usuário fechar a aba rapidamente. Um exemplo prático: // Coletor simples com beacon
function trackEvent(evento, dados) {
  const payload = JSON.stringify({
    evento,
    dados,
    ts: Date.now(),
    sid: getOrGenerateSessionId()
  });
  const url = `/api/collect?k=${API_KEY}`;
  navigator.sendBeacon(url, payload);
}

No backend, o endpoint recebe, valida a chave, salva no banco ou fila, e responde 204 imediatamente. Não faça processamento pesado no request de coleta. Se você precisa de agregação em tempo real, use uma fila como Redis ou Kafka e processe de forma assíncrona. Uma limitação importante: sendBeacon tem uma restrição de tamanho de payload que varia entre navegadores, mas em geral fica em torno de 64KB. Eventos com payloads grandes vão ser truncados ou falhar silenciosamente. Eu resolvi isso dividindo eventos grandes em chunks menores e concatenando no server-side pelo session ID e timestamp.

👉 Clique no botão abaixo para saber mais sobre o assunto!

Burlando monitores com anti monitor caseiro

Se o objetivo é evitar que scripts de monitor coleta dados, existem abordagens que funcionam melhor do que apenas bloquear domínios. A técnica mais eficiente que eu pessoalmente utilizo envolve duas camadas sobrepostas. A primeira camada é a interceptação de rede via Service Worker. Você registra um service worker que escuta todas as requisições fetch e XMLHttpRequest, e bloqueia aquelas que baterem em padrões de tracking conhecidos ou domínios suspeitos. O serviço worker roda no contexto da origem e consegue interceptar tanto requests do seu código quanto de third-party scripts, o que é mais abrangente do que bloqueios por extensão do navegador.

A segunda camada é o spoofing de fingerprint. Em vez de simplesmente bloquear, você altera propriedades do canvas, do WebGL renderer, e dos headers do navegador para gerar um identificador consistente mas falso. Isso é particularmente útil contra técnicas de fingerprinting avançado como o CanvasFingerprintBlind ou solutions similares. O truque aqui é manter consistência — se o fingerprint mudar a cada visita, o sistema de monitor simplesmente detecta que é um bot e descarta ou marca como suspeito. Eu encontrei um problema chato ao implementar spoofing de fingerprint: algumas bibliotecas de anti-deteção como antiFingerprint ou canvas-fingerprint-blocker entram em conflito com extensões legítimas de desenvolvimento. Em uma situação específica, o DevTools abria alterava o fingerprint canvas de forma diferente, e meu wrapper de spoofing detectava essa mudança como anomalia e parava de funcionar durante debugging. A correção foi adicionar uma verificação de runtime environment que desabilita o spoofing quando window.__reactDevtoolsGlobalHook existe, mantendo o bloqueio ativo apenas em produção.

Considerações sobre eficácia e alternativas

O anti monitor doméstico tem limites claros. Ele depende do código rodando no lado do cliente, o que significa que qualquer um com conhecimento técnico pode desativá-lo ou contorná-lo. Se você é o proprietário do site e quer proteger seu monitor de burlas excessivas, considere usar técnicas de integridade como Subresource Integrity (SRI) nos scripts de tracking, ou assinaturas de requests com HMAC no server-side para validar que os eventos vêm de clientes legítimos. Para quem precisa de privacidade real, a abordagem mais confiável combina múltiplas camadas: service worker para interceptação de rede, bloqueadores de fingerprint configurados corretamente, e DNS filtering como NextDNS ou Pi-hole para bloquear domínios de tracking em nível de resolução DNS. Cada camada cobre lacunas que as outras não alcançam. Sozinhas, nenhuma delas é suficiente.

O custo de manter um sistema anti monitor funcional não é baixo. Listas de blocos precisam ser atualizadas regularmente, fingerprints mudam com atualizações de navegador, e cada novo método de rastreamento exige adaptação. Eu recomendo que você avalie se o esforço vale a pena antes de construir algo customizado. Muitas vezes, uma combinação de uBlock Origin com Privacy Badger e uma configuração razoável de DNS filtering resolve 90% dos casos com muito menos manutenção.

Recursos úteis

Se quiser começar a brincar com monitor e anti monitor por conta própria, estes são os pontos de partida que eu considero mais sólidos: Para monitor: a documentação do OpenTelemetry para instrumentação automática, o projeto PostHog que tem versão self-hosted gratuita, e o wiki do Privacy Tools que mantém listas atualizadas de services de tracking por categoria.

Para anti monitor: o repositório do uBlock Origin na GitHub para entender como listas de blocos são construídas, o project sherlock para detectar fingerprints únicos em sites, e o browserleaks.com para testar qual informação seu navegador vaza antes e depois de aplicar técnicas de proteção. Não existe solução perfeita aqui. Monitor e anti monitor são uma corrida armamentista que só termina quando uma das partes para de investir. O mais importante é entender o que você está tentando proteger ou coletar, e escolher a complexidade certa para o problema real que você tem.