Uma designer escreve a uma cliente: criei este conceito em março, você copiou em junho. A cliente pede uma prova. A designer envia três coisas: uma captura de ecrã de uma pasta de projeto com uma data, um e-mail reencaminhado de março, e um ficheiro cujas propriedades indicam "Data de modificação: 14 de março". A advogada da cliente olha para as três e faz uma única pergunta. Quem controla essa data. A resposta é a designer, e essa resposta é todo o problema.
A captura de ecrã
Uma captura de ecrã é uma imagem daquilo que um ecrã mostrava no momento em que alguém a tirou. Prova que a imagem existe. Não prova que o ficheiro por trás dela existia na data que a captura mostra, porque o relógio do sistema que produziu essa data pertence a quem tem o aparelho nas mãos. Ajustar o relógio, tirar a captura, repor o relógio. Nada na imagem regista que isso aconteceu, e nada numa captura de ecrã precisa disso, porque nunca foi concebida para resistir a esse tipo de pergunta.
O e-mail
Um e-mail traz um cabeçalho com uma data gerada por servidores de correio que você não controla pessoalmente, o que parece uma melhoria em relação à captura de ecrã. É uma melhoria parcial. O servidor regista quando uma mensagem passou por ele, não o que o anexo continha de facto, nem se o ficheiro agora apresentado como prova é o mesmo que viajou nessa mensagem. As conversas são reencaminhadas, guardadas localmente, reabertas e reanexadas, e cada um desses passos pode trocar silenciosamente o ficheiro sem tocar numa única data visível na conversa. Um cabeçalho prova que uma mensagem passou por um sistema num determinado momento. Não liga esse momento aos bytes exatos do documento que está agora a apresentar.
A data própria do ficheiro
"Data de modificação" e "data de criação" são propriedades que o sistema operativo mantém sobre um ficheiro, não propriedades que o ficheiro carrega consigo. Copie o ficheiro para outra unidade, sincronize-o através de uma pasta na nuvem, ou simplesmente abra-o e guarde-o de novo, e essas datas frequentemente reiniciam para o momento em que essa ação ocorreu, por vezes na mesma tarde em que alguém precisava de apresentar uma prova. Qualquer pessoa com acesso normal ao sistema de ficheiros também pode defini-las diretamente com um utilitário comum, sem competência especial. Isto não é uma falha de um sistema operativo em particular. É o que acontece quando uma alegação e o registo dessa alegação estão na mesma máquina, controlada pela mesma parte que beneficia de a data dizer uma coisa específica.
Ter o ficheiro original também não resolve isto
Um instinto comum é pensar que a posse resolve a questão: ainda tenho o ficheiro, logo devo tê-lo feito eu. A posse prova que hoje tem uma cópia. Não diz nada sobre quando essa cópia, ou uma versão anterior dela, existiu pela primeira vez, porque um ficheiro no seu próprio disco não carrega nenhum registo independente da sua própria história. O ficheiro e a alegação sobre a sua idade vêm da mesma fonte, e é exatamente essa a fraqueza que uma disputa expõe.
O padrão por trás dos quatro
Cada uma destas provas falha pela mesma razão estrutural, não porque alguém esteja a mentir. A maioria das disputas envolve duas pessoas que acreditam genuinamente na sua própria versão dos factos. A data reside num sistema que uma parte controla, e pode ser alterada por essa parte, ou modificada pelo uso normal, sem deixar qualquer vestígio de que isso aconteceu. Uma data que você próprio gerou é uma data que pode ter de justificar, e "confie em mim" não é algo sobre o qual um tribunal, uma cliente ou uma plataforma de licenciamento possam agir quando há dinheiro ou autoria em jogo.
O que um carimbo temporal qualificado faz de diferente
Um carimbo temporal eletrónico qualificado não descreve um ficheiro. Está ligado a um ficheiro, criptograficamente. Um hash é calculado a partir dos bytes exatos do ficheiro, e um prestador qualificado de serviços de confiança emite o carimbo sobre esse hash, não sobre um nome de ficheiro, um caminho de pasta ou uma descrição escrita. Mude um único carácter no documento e o hash deixa de corresponder, pelo que não resta ambiguidade posterior sobre qual a versão que foi selada.
Ao abrigo do eIDAS, um carimbo temporal eletrónico qualificado beneficia de presunção legal quanto à data e à hora que indica e à integridade dos dados a que está associado. Essa presunção existe precisamente porque a data não foi gerada por nenhuma das partes de uma futura disputa. Vem de um terceiro regulado cuja função integral é emitir carimbos temporais que nenhuma das partes pode depois alterar silenciosamente.
Isto não cria o direito subjacente, e vale a pena ser preciso quanto a isso. Ao abrigo da Convenção de Berna, o direito de autor nasce automaticamente no momento da criação de uma obra, em 181 países, sem necessidade de registo ou formalidade. Um carimbo temporal não concede essa proteção, e não precisa de o fazer. O que lhe dá é uma prova de quando existiu uma versão concreta de um ficheiro concreto, que é exatamente a pergunta que uma captura de ecrã, um e-mail ou a data própria de um ficheiro não conseguem responder assim que alguém que não estava presente a coloca diretamente.
O que resiste a uma pergunta real
A diferença deixa de ser abstrata assim que se compara aquilo que cada prova consegue suportar. Uma captura de ecrã sobrevive a um olhar casual e falha na primeira pergunta direta sobre o relógio do sistema. Um e-mail sobrevive até alguém pedir o anexo original em vez da cópia reencaminhada três mensagens atrás. A data de modificação de um ficheiro sobrevive até o ficheiro ser copiado para qualquer lado. Uma prova construída em torno de um carimbo temporal qualificado é pensada para a situação oposta: destina-se a ser verificada por alguém que não estava presente e não tem motivo para acreditar na sua palavra. Uma página de verificação pública confirma o hash, a declaração e o carimbo temporal, sem conta e sem necessidade de contactar quem faz a alegação.
Esse último ponto é um teste justo para aplicar às suas próprias provas já agora. Entregue a sua captura de ecrã, o seu e-mail e as propriedades do seu ficheiro a alguém genuinamente cético, e peça-lhe que confirme a sua alegação sem lhe perguntar mais nada. Nenhuma das três consegue isso sozinha.
Para além de um tribunal
As mesmas provas fracas aparecem também fora de um tribunal. Uma plataforma de licenciamento, ou uma empresa que avalia se um conteúdo foi usado sem autorização, depara-se com o mesmo problema: uma captura de ecrã ou uma data de criação alegada não provam nada sobre a história real de um ficheiro e não podem ser comparadas em grande escala com outra coisa. Um hash criptográfico serve aí um propósito relacionado. Como deriva do conteúdo exato de um ficheiro em vez de uma descrição dele, o hash pode ser comparado com outros conteúdos sem nunca expor o ficheiro original. Essa propriedade torna uma prova útil para rastrear onde um conteúdo foi usado, não apenas para ganhar uma discussão sobre quem o fez primeiro.
Construir o hábito em vez do arquivo
A solução não é reconstruir anos de trabalho antigo numa única tarde de recolha de provas. É mudar o que acontece no momento em que algo fica pronto. Selar um ficheiro demora poucos minutos e produz uma prova construída a partir de um hash criptográfico, uma declaração de como o trabalho foi feito, e um carimbo temporal qualificado, apoiada por uma ligação de verificação que qualquer pessoa pode abrir de forma independente. Faça isto no momento da publicação ou da entrega a partir de agora, e a próxima disputa começará a partir de uma prova concebida para responder à pergunta, em vez de uma pasta de ficheiros cujas datas teria de explicar uma a uma.
