Leitura de placas com Bun: a lição do YouTuber vigiado

Um YouTuber montou uma câmera que lê placas de carro, no estilo das que a Flock Safety espalha pelos Estados Unidos. Só que ele apontou a câmera para a polícia. Pouco depois, segundo ele, uns policiais apareceram na porta dele. A história saiu no Gizmodo e me fez pensar em algo bem prático: hoje, montar leitura de placas com Bun, uma câmera barata e um modelo de OCR é projeto de fim de semana. E é justamente esse o problema.

O que aconteceu, em poucas linhas

A Flock vende câmeras de leitura automática de placas (ALPR, na sigla em inglês) para prefeituras, polícias e até condomínios. A câmera fotografa cada carro que passa, extrai a placa e manda tudo para uma base pesquisável. Já são milhares de cidades usando, e organizações como a ACLU criticam o modelo há anos: muita gente com acesso, regra de retenção pouco clara e quase nenhuma transparência.

O YouTuber resolveu inverter o jogo. Montou o equipamento dele, reconheceu viaturas e registrou por onde elas passavam. Ou seja, fez com a polícia exatamente o que a polícia faz com todo mundo. A reação veio rápido.

Não vou entrar no mérito jurídico do caso, que depende de estado e de detalhes que o relato não fecha. O que me interessa é outra coisa: a ferramenta é a mesma dos dois lados. Só muda quem está na frente da lente.

Quando o vigiado monta a mesma câmera, todo mundo de repente descobre que existe privacidade.

Por que isso importa para quem escreve código

Porque a parte difícil desse sistema deixou de ser difícil. Há dez anos, ALPR exigia hardware dedicado e software caro. Hoje você tem:

• uma câmera IP ou um Raspberry Pi com módulo de câmera;
• um modelo de detecção de placas open source;
• um backend que recebe as leituras e grava num banco.

Essa última parte é o que qualquer dev full stack faz toda semana. Um endpoint, um insert, uma busca por placa. Eu escreveria isso em Bun em meia hora, sem instalar quase nada, porque o runtime já traz servidor HTTP, SQLite e crypto de fábrica.

E é aí que mora a lição. O código de vigilância é igualzinho ao código de um app de estacionamento, de um controle de portaria, de um sistema de frota. A diferença está nas decisões que você toma sobre os dados.

Como fica a leitura de placas com Bun, do jeito responsável

Vou mostrar o backend que eu faria para um caso legítimo: um estacionamento que precisa saber se o carro que entrou já saiu. Nada de rastrear gente. O ponto é ver onde estão as escolhas que separam um sistema útil de uma máquina de vigilância.

import { Database } from "bun:sqlite";
import { createHmac } from "node:crypto";

const db = new Database("leituras.db");
db.run(`CREATE TABLE IF NOT EXISTS leituras (
  placa_hash TEXT NOT NULL,
  portao TEXT NOT NULL,
  lido_em INTEGER NOT NULL
)`);

const SEGREDO = process.env.PLACA_SECRET!;
const RETENCAO_MS = 72 * 60 * 60 * 1000; // 72 horas e acabou

const hash = (placa: string) =>
  createHmac("sha256", SEGREDO).update(placa.toUpperCase()).digest("hex");

Bun.serve({
  routes: {
    "/leitura": {
      POST: async (req) => {
        const { placa, portao } = await req.json();
        db.run("INSERT INTO leituras VALUES (?, ?, ?)", [hash(placa), portao, Date.now()]);
        return new Response(null, { status: 204 });
      },
    },
  },
});

setInterval(() => {
  db.run("DELETE FROM leituras WHERE lido_em < ?", [Date.now() - RETENCAO_MS]);
}, 60 * 60 * 1000);

São três decisões nesse trecho, e nenhuma delas é técnica de verdade:

1. A placa não é gravada em texto puro. Vai como HMAC com um segredo. Dá para checar "esse carro entrou e saiu?", mas ninguém que vaze o banco consegue listar placas.
2. O dado tem prazo de validade. 72 horas e sai. Sistema de estacionamento não precisa lembrar onde seu carro estava em março.
3. Não tem endpoint de busca. Se ninguém pediu "histórico de onde a placa X passou", não existe essa rota. O que não existe não vaza e não é intimado.

Repare que o código fica menor com essas escolhas. Privacidade aqui não é feature extra, é corte de escopo.

"Mas hash de placa não resolve, dá para fazer força bruta"

É uma objeção boa, e está certa em parte. Placa tem formato conhecido. No Brasil, o padrão Mercosul tem algo na casa de 450 milhões de combinações. Com SHA-256 puro, uma GPU caseira testa tudo isso em minutos.

Por isso o exemplo usa HMAC com segredo, e não hash simples. Sem a chave, a força bruta não serve para nada. Com a chave, o atacante já tem acesso ao servidor e você tem problemas maiores. Se quiser ir além, guarde o segredo fora da máquina (num gerenciador de segredos) e troque a chave junto com o ciclo de retenção. Leituras antigas ficam impossíveis de correlacionar.

Não é perfeito. Mas é muito melhor que o padrão do mercado, que costuma ser placa em texto puro, foto do carro e retenção de 30 dias ou mais, "por precaução".

O que o caso do YouTuber escancara

A parte que mais me pegou na história não foi a visita da polícia. Foi o desconforto. Quando alguém monta o mesmo sistema e mira em quem normalmente opera esse tipo de ferramenta, a sensação de invasão aparece na hora. A tecnologia é a mesma. O incômodo é o mesmo. Só que, de um lado, ele vira notícia e, do outro, vira contrato público.

Para nós, devs, isso deixa uma pergunta incômoda, mas útil para revisar qualquer sistema que guarda dado de localização:

• Eu ficaria tranquilo se esse banco tivesse o meu histórico de deslocamento?
• Quem consegue rodar um SELECT aqui sem pedir para ninguém?
• Se vazar amanhã, o que dá para descobrir sobre uma pessoa específica?

Se a resposta da primeira for "não", você está construindo uma Flock em miniatura. Aliás, você não precisa estar num projeto de câmera para cair nisso. App de delivery, app de entrega, rastreador de frota, check-in de academia: todos geram trilha de localização. E quase todos guardam mais do que precisam.

O que muda no seu fluxo de trabalho

Na prática, eu levo três hábitos desse caso para qualquer projeto:

• Retenção entra no schema, não no backlog. Coluna de data e job de limpeza no mesmo PR que cria a tabela. Se ficar para depois, nunca acontece.
• Dado sensível vira identificador opaco o mais cedo possível. HMAC na entrada, não num script de "anonimização" rodado uma vez por trimestre.
• Toda rota de busca precisa de um motivo escrito. Se o motivo for "pode ser útil um dia", ela não entra.

Bun ajuda aqui de um jeito meio sem graça: como SQLite, servidor e crypto já vêm no runtime, sobra menos desculpa de "depois eu configuro". O exemplo acima não tem nenhuma dependência para instalar. Dá para fazer certo desde o primeiro commit.

Minha opinião

Acho que o YouTuber fez, sem querer, a melhor demonstração possível do que a gente vem dizendo sobre ALPR: o problema nunca foi a câmera, foi o banco de dados atrás dela. E quem desenha esse banco somos nós. A polícia, a Flock ou o cara do YouTube só escolhem para onde apontar.

Então, da próxima vez que você criar uma tabela com placa, CPF ou coordenada, pense nesse caso por uns dez segundos. Prazo de validade, identificador opaco, nada de busca sem motivo. Custa umas vinte linhas. Se quiser ver como eu aplico isso em projeto real, dá uma olhada nos meus projetos.

Um YouTuber apontou uma câmera de leitura de placas para a polícia. Pouco depois, segundo ele, a polícia bateu na porta dele.

A ferramenta é a mesma dos dois lados. Só muda quem está na frente da lente.

Hoje, montar leitura de placas é projeto de fim de semana. O backend é um endpoint, um insert e uma busca. Em Bun eu faço em meia hora.

E é por isso que o problema nunca foi a câmera. É o banco de dados que fica atrás dela, e quem desenha esse banco somos nós.

Três hábitos que levo para qualquer projeto com placa, CPF ou localização: o prazo de retenção entra no schema, o dado sensível vira HMAC logo na entrada e nenhuma rota de busca entra sem um motivo escrito.

Privacidade aqui não é feature extra. É corte de escopo.

Escrevi o artigo completo com o código. Se esse tema te interessa, vale a leitura.

#Privacidade #DesenvolvimentoDeSoftware #Bun #LGPD #SegurançaDaInformação