Flashpaper: segredos que se destroem sem banco de dados

O que aconteceu

O Flashpaper, apresentado no Show HN, permite compartilhar segredos que se apagam após uma única leitura ou depois de um prazo definido. O serviço dispensa armazenar o dado sensível em banco. Quando o segredo é consumido, ele desaparece do servidor sem deixar rastro.

O projeto mira uma dor comum em automação: passar credencial ou token temporário entre serviços sem persistir nada. Usando arquitetura sem estado e provas criptográficas, entrega a mesma função de ferramentas tradicionais com superfície de ataque menor.

Por que isso importa para quem constrói

• Confiança zero no armazenamento — o segredo nunca fica guardado, o que reduz risco de vazamento acidental ou uso indevido interno. Útil quando agentes rotacionam chaves de API em tempo de execução.
• Conformidade mais simples — sem banco de segredos, boa parte da carga regulatória de retenção desaparece. O fluxo ainda prova que o segredo foi usado, sem que o valor bruto permaneça.
• Menos operação — sem banco, não há backup, replicação nem atualização de versão para manter.
• Desempenho — serviço sem estado escala na horizontal com latência menor, o que ajuda em pipeline de alta vazão que busca credencial nova com frequência.

A leitura da Tyna

O argumento de conformidade é o mais forte do lote, e vale explicitar por quê: o dado que você não guarda é o dado que você não precisa proteger, justificar nem reportar em caso de incidente.

Boa parte do esforço de adequação à LGPD é gasto criando controle em torno de dado armazenado — política de retenção, criptografia em repouso, controle de acesso, plano de resposta a vazamento. Arquitetura que simplesmente não retém corta esse trabalho na origem, em vez de administrá-lo. É a diferença entre construir um cofre melhor e não ter o que guardar.

O detalhe que sustenta a proposta é a separação entre registrar o acesso e registrar o conteúdo. O sistema sabe que um segredo foi lido, quando e por quem, sem saber qual era. Isso preserva a auditoria — que é o que o auditor pede — sem criar o passivo. É um padrão que vale copiar para além de segredos: em muitos fluxos, o que precisa ser provado é que algo aconteceu, não o que estava escrito.

Uma advertência operacional que o material não faz: leitura única e automação se dão mal por padrão. Se um fluxo falha e é reexecutado, a segunda tentativa encontra o segredo já consumido e falha de novo — agora por um motivo diferente do original, o que confunde o diagnóstico. Vale desenhar a repetição de tentativa para buscar credencial nova em vez de reusar o link, e tratar "segredo já consumido" como um caso explícito de erro, não como falha genérica de rede.

Perguntas frequentes

P: Ainda consigo auditar quem acessou um segredo?

R: Sim. O serviço registra os eventos de acesso sem armazenar o segredo em si, o que preserva a auditabilidade enquanto o dado permanece transitório.

P: Como funciona a expiração?

R: Você define um tempo de vida ou marca o segredo como de uso único. Passado o prazo ou feita a leitura, o sistema apaga automaticamente.

P: Serve para segredo compartilhado entre vários serviços?

R: Sim. Gera-se um link que qualquer serviço seguinte pode consumir, válido apenas pela janela configurada ou por um único uso.