O modelo de segurança.

Criptografia

• Criptografia: cada nota é selada no seu telefone com AES-256-GCM (um nonce de 12 bytes e uma tag de autenticação de 16 bytes) antes de qualquer envio. Um texto cifrado adulterado falha na autenticação em vez de descriptografar em lixo.
• Derivação de chave: a chave vem de HKDF-SHA256 sobre 32 bytes aleatórios novos — a chave do fragmento — mais um sal aleatório de 16 bytes. Esses 32 bytes vão para o #fragmento do link e para mais nada.
• Frase secreta (opcional): se você definir uma, ela é reforçada com PBKDF2-HMAC-SHA256 a 600.000 iterações e misturada à derivação, de modo que o link sozinho já não basta. Tentativas erradas falham localmente no navegador do destinatário e nunca consomem visualizações.
• Verificado em dobro: as implementações em Swift e Kotlin nos apps e a implementação WebCrypto no visualizador são verificadas uma contra a outra com vetores de teste gerados de forma independente, então uma nota selada por uma sempre abre na outra.

O link com chave no fragmento

Um link de nota é assim: burnpony.app/n/<id>#<key>. Tudo depois do # é um fragmento de URL, e os navegadores não enviam fragmentos em requisições HTTP — nem para este servidor nem para nenhum outro. O servidor descobre o ID aleatório da nota; a chave existe apenas no próprio link e no navegador do destinatário enquanto ele lê. É por isso que «o servidor não pode ler sua nota» é uma propriedade de como a web funciona, não uma promessa.

O que o servidor armazena — e não pode ler

Enquanto uma nota está ativa, o servidor guarda: o ID aleatório da nota, o blob de texto cifrado selado, carimbos de criação e expiração, o limite e a contagem de visualizações, se uma confirmação de leitura foi solicitada, e um hash do token de gerenciamento que permite ao seu app queimar a nota antes. Se as confirmações estão ativas, os carimbos de abertura são registrados. Esse é o inventário. Ele nunca tem a chave, o texto da nota, nem a configuração de ocultar automaticamente — ela viaja criptografada dentro da nota. A limitação de taxa de criação usa hashes de IP com um segredo do servidor que expiram após cerca de duas horas, não logs de endereços brutos.

A queima, e o que sobra

Quando a última visualização permitida é buscada, o texto cifrado é apagado na mesma transação do banco de dados que o serviu. Notas expiradas são removidas por uma varredura que roda a cada cinco minutos. E, crucialmente, uma nota queimada, uma nota expirada e uma nota que nunca existiu retornam exatamente a mesma resposta — o servidor não pode ser usado como oráculo para confirmar que um dado link um dia foi real.

O visualizador

Os destinatários abrem uma única página autossuficiente: sem frameworks, sem cookies, sem analítica, sem requisições a lugar algum exceto a este servidor pela própria nota selada. Ela carrega uma Content-Security-Policy estrita (default-src 'none'), uma diretiva noindex e uma política sem referenciador para que o link nunca vaze pelos cabeçalhos de referenciador. A descriptografia acontece no WebCrypto embutido do navegador. A página é curta o bastante para auditar com Ver código-fonte — isso é um objetivo de design, não um acaso.

Confirmações de leitura, com honestidade

As confirmações são opcionais por nota. O destinatário vê «O remetente será notificado quando esta nota for aberta» antes de revelá-la. O push que você recebe é propositalmente genérico — «Uma nota foi aberta.» com apenas o ID da nota anexado — então nada do conteúdo da nota transita pelos servidores do provedor de push.

Modelo de ameaças

O BurnPony protege a confidencialidade e a integridade de uma nota contra o servidor, observadores de rede e qualquer um que mais tarde encontre a URL sem o seu fragmento — e limita por quanto tempo e quantas vezes uma nota é legível. Ele pressupõe que o seu telefone e o navegador do destinatário se comportem como documentado. Não defende contra malware em nenhum dos extremos, nem contra um destinatário que copia, captura ou fotografa a nota enquanto está visível — nenhuma ferramenta de queima-após-leitura pode. A autodestruição limita o acesso futuro; não pode policiar o momento da leitura.

Limites honestos

• O link é a chave. Qualquer pessoa que obtenha o link completo (e a frase secreta, se definida) antes de a nota queimar pode lê-la. Envie por um canal em que você confiaria o próprio segredo, ou adicione uma frase secreta e compartilhe-a separadamente.
• Telas podem ser capturadas. A contagem regressiva de ocultar automaticamente reduz o tempo de espiar por cima do ombro; não é proteção contra capturas de tela.
• Telefone perdido, gerenciamento perdido. As notas que você enviou continuam queimando e expirando no próprio cronograma, mas sem a aba Enviados do app você perde a capacidade de queimá-las antes ou verificar o status.
• Metadados de nível de rede existem. Como qualquer servidor web, este vê os endereços IP que se conectam em nível de rede enquanto atende requisições. O servidor web à frente do relay está configurado com o log de acesso desativado, e a aplicação mantém apenas os hashes de IP salgados de vida curta descritos acima.

A especificação exata

Cada afirmação nesta página é declarada com precisão, constante por constante, na página do protocolo v1, escrita com base no código congelado em o repositório público e verificável com os vetores de teste compartilhados.

Aberto à inspeção

O visualizador é auditável hoje em cada link de nota, e o núcleo criptográfico, o visualizador e o servidor de retransmissão estão planejados para publicação — veja a página de código aberto para saber como está.

Reportar uma vulnerabilidade

Encontrou algo? Envie um e-mail para NorseHorse@norsehor.se — criptografado com a chave PGP se preferir. Os relatos vão direto ao desenvolvedor, e as correções saem rápido porque não há comitê no caminho.