Resumo

  • Um rascunho individual de 27 de outubro propõe que cada versão dos termos e políticas de um serviço tenha um selo com nome do documento, versão, URL e SHA-256 do texto simples. O arquivo antigo deve continuar disponível naquele endereço.
  • A proposta liga chaves de empresas e agentes a domínios, conserva o histórico dessas chaves e faz observadores guardar checkpoints assinados de um log Merkle. O conjunto identifica autoria e data; a veracidade do enunciado exige outra avaliação.

O arquivo que a página inicial não mostra

Pense numa cobrança contestada. O cliente pergunta qual regra autorizava o valor; a empresa aponta para os termos atuais. Se a cláusula mudou, a resposta perdeu o alvo. Um resumo da alteração conta a história do operador. Uma captura guardada pelo cliente conta apenas o que apareceu naquela tela. O que falta é a versão inteira que vigorava quando o botão foi apertado, disponível para ambos e verificável sem a senha de administrador da empresa.

O Internet-Draft de Furkan Yanteri, datado de 27 de outubro de 2026, desenha uma obrigação mais exigente na seção 4.2. Toda versão dos termos e políticas do serviço seria selada com quatro referências: nome do documento, identificador de versão, URL daquele arquivo e SHA-256 do texto simples. Toda versão selada continuaria acessível na URL indicada. O operador pode publicar uma regra nova. Não pode trocar silenciosamente a antiga sem produzir uma divergência verificável.

As quatro referências têm trabalhos diferentes. A URL leva ao texto antigo; o hash confere se ele ainda é o mesmo; o número da versão o distingue da regra atual; o registro público mostra que essa combinação já existia antes da briga. Apague o arquivo e sobra apenas uma impressão digital sem pessoa para identificar. Guarde o arquivo sem o registro e alguém poderá dizer que foi montado depois. O cliente não precisa dominar a matemática para entender o risco: a prova não pode morar só no painel de quem está sendo questionado.

O Datatracker da IETF registra o documento como rascunho individual em estado I-D Exists. Não há, neste pacote de originais, adoção por grupo de trabalho nem um caso nomeado de cliente que tenha usado toda a cadeia numa disputa. A proposta deve ser examinada pelo que especifica: uma maneira de fazer a organização levar consigo as próprias palavras de ontem.

De qual boca saiu aquela assinatura?

A seção 3.1 adota uma forma limitada de JSON canônico baseada na RFC 8785. Ordena as chaves recursivamente, elimina espaços dispensáveis e restringe os tipos de valores. A seção 3.2 põe o conteúdo canônico numa envoltória com chave pública e assinatura Ed25519, descrita pela RFC 8032. Essa preparação impede que dois verificadores discordem por causa de formatação. Uma assinatura válida continua sendo uma assinatura de uma frase, inclusive quando a frase está errada.

A atribuição institucional requer outra amarra. A chave de uma empresa ou agente seria vinculada ao domínio por um registro DNS TXT _humancollab. Um arquivo HTTPS pode ajudar no primeiro vínculo; trocar uma chave já vinculada exige prova DNS. A chave antiga não pode ser reaproveitada em outro domínio. O histórico público conserva cada chave e o índice da primeira declaração feita por ela no log. Assim, uma mudança no controle do domínio não fica escondida atrás de um selo genérico de “verificado”.

Controlar o DNS dá poder para nomear a chave deste sistema. Não dá poder automático para transformar qualquer promessa de um agente em contrato empresarial ou qualquer informação assinada em fato. A seção 6 separa as conclusões: assinatura válida mais vínculo de domínio atribuem a declaração ao controlador; inclusão num checkpoint visto por observadores mostra quando ela entrou no registro; uma fonte independente pode demonstrar que a afirmação conflita com a realidade. O objetivo é deixar um autor localizável diante de uma frase preservada. Julgar a frase é outra tarefa.

Uma testemunha fora do prédio

O log proposto é uma árvore Merkle com regras de hash alinhadas à RFC 9162. Oferece provas de inclusão e consistência, assina checkpoints e ancora raízes publicadas no tempo com OpenTimestamps. Observadores comparam cada checkpoint ao anterior e guardam cópias. O texto pede um observador operado fora da infraestrutura do serviço e permite que qualquer pessoa opere outro.

O detalhe importa porque o dono da página não deve ser também o único dono do passado. Dois checkpoints válidos, com o mesmo tamanho de árvore e raízes diferentes, provam que o log mostrou histórias incompatíveis. Mas alguém precisa ter guardado os dois. Se todos os checkpoints ficam sob a mesma administração que controla o site, uma tela bonita de transparência pode virar apenas outra página que o operador edita. O observador independente é um arquivista adversarial no dia em que versões deixam de combinar.

Um dossiê técnico sobre uma regra antiga reuniria texto simples, selo da versão, prova de inclusão contra um checkpoint guardado externamente e histórico da chave vinculada ao domínio na data relevante. Isso permite testar a redação, a atribuição e a continuidade do registro. Ainda será preciso determinar o que o cliente viu, se o agente tinha delegação e como a regra incide na relação específica. Essas perguntas não precisam começar com uma briga sobre qual página existia.

Uma instituição pode mudar de ideia. O privilégio de editar o presente não deve incluir a capacidade de apagar a formulação que orientou uma decisão anterior. A prova proposta transforma a memória institucional em algo que outras pessoas conseguem verificar sem pedir acesso ao painel de administração.

Fontes