Una designer scrive a una cliente: ho ideato questo progetto a marzo, tu l'hai copiato a giugno. La cliente chiede una prova. La designer manda tre cose: uno screenshot di una cartella di progetto con una data, una email inoltrata di marzo, e un file le cui proprietà indicano "Data modifica: 14 marzo". L'avvocata della cliente guarda tutte e tre e fa una sola domanda. Chi controlla quella data. La risposta è la designer, e quella risposta è tutto il problema.
Lo screenshot
Uno screenshot è un'immagine di ciò che uno schermo mostrava nel momento in cui qualcuno l'ha catturata. Prova che l'immagine esiste. Non prova che il file dietro di essa esistesse alla data mostrata dallo screenshot, perché l'orologio di sistema che ha prodotto quella data appartiene a chi tiene in mano il dispositivo. Si imposta l'orologio, si scatta lo screenshot, si rimette l'orologio a posto. Nulla nell'immagine registra che ciò sia accaduto, e nulla in uno screenshot deve farlo, perché non è mai stato costruito per resistere a una domanda del genere.
L'email
Un'email porta un'intestazione con una data generata da server di posta che non controllate personalmente, il che sembra un miglioramento rispetto allo screenshot. Lo è, in parte. Il server registra quando un messaggio è passato attraverso di esso, non che cosa contenesse davvero l'allegato, né se il file ora prodotto come prova sia lo stesso che ha viaggiato in quel messaggio. Le conversazioni vengono inoltrate, salvate localmente, riaperte e riallegate, e ciascuno di questi passaggi può sostituire silenziosamente il file senza toccare una sola data visibile nella conversazione. Un'intestazione prova che un messaggio è passato attraverso un sistema in un certo momento. Non lega quel momento ai byte esatti del documento che state mostrando ora.
La data propria del file
"Data modifica" e "data creazione" sono proprietà che il sistema operativo tiene su un file, non proprietà che il file porta con sé. Copiate il file su un altro disco, sincronizzatelo tramite una cartella cloud, o semplicemente apritelo e risalvatelo, e quelle date spesso si azzerano al momento in cui è avvenuta quell'azione, a volte proprio nel pomeriggio in cui qualcuno doveva produrre una prova. Chiunque abbia accesso ordinario al file system può anche impostarle direttamente con un'utility comune, senza competenze particolari. Non è un difetto di un particolare sistema operativo. È ciò che accade quando un'affermazione e la prova di quell'affermazione stanno sulla stessa macchina, controllata dalla stessa parte che trae vantaggio dal fatto che la data dica una cosa precisa.
Avere il file originale non risolve nemmeno questo
Un istinto comune è pensare che il possesso chiuda la questione: ho ancora il file, quindi devo averlo fatto io. Il possesso prova che oggi avete una copia. Non dice nulla su quando quella copia, o una versione precedente di essa, sia esistita per la prima volta, perché un file sul vostro disco non porta alcun registro indipendente della propria storia. Il file e l'affermazione sulla sua età provengono dalla stessa fonte, ed è esattamente questa la debolezza che una controversia mette a nudo.
Lo schema comune a tutte e quattro
Ognuna di queste prove fallisce per la stessa ragione strutturale, non perché qualcuno menta. La maggior parte delle controversie coinvolge due persone che credono entrambe sinceramente alla propria versione dei fatti. La data risiede in un sistema che una parte controlla, e può essere cambiata da quella parte o alterata dall'uso ordinario, senza lasciare traccia che ciò sia accaduto. Una data che avete generato voi è una data che potete essere chiamati a giustificare, e "fidati di me" non è qualcosa su cui un tribunale, una cliente o una piattaforma di licenze possano basarsi quando sono in gioco denaro o paternità.
Che cosa fa diversamente una marca temporale qualificata
Una marca temporale elettronica qualificata non descrive un file. È legata a un file, crittograficamente. Un hash viene calcolato dai byte esatti del file, e un prestatore di servizi fiduciari qualificato emette la marca temporale su quell'hash, non su un nome di file, un percorso di cartella o una descrizione scritta. Cambiate un solo carattere nel documento e l'hash non corrisponde più, così non resta alcuna ambiguità su quale versione sia stata sigillata.
Ai sensi di eIDAS, una marca temporale elettronica qualificata gode di una presunzione legale quanto alla data e all'ora che indica e all'integrità dei dati a cui è associata. Questa presunzione esiste proprio perché la data non è stata generata da nessuna delle due parti di una futura controversia. Proviene da un terzo regolamentato la cui intera funzione è emettere marche temporali che nessuna delle due parti può poi modificare silenziosamente.
Questo non crea il diritto sottostante, ed è bene essere precisi su questo punto. Ai sensi della Convenzione di Berna, il diritto d'autore sorge automaticamente nel momento della creazione di un'opera, in oltre 180 paesi, senza registrazione né formalità. Una marca temporale non concede quella protezione, e non ne ha bisogno. Ciò che fornisce è la prova di quando esisteva una versione precisa di un file preciso, che è esattamente la domanda a cui uno screenshot, un'email o la data propria di un file non possono rispondere nel momento in cui qualcuno che non era nella stanza la pone direttamente.
Ciò che resiste a una domanda vera
La differenza smette di essere astratta appena si confronta ciò che ciascuna prova può sostenere. Uno screenshot sopravvive a uno sguardo distratto e fallisce alla prima domanda diretta sull'orologio di sistema. Un'email sopravvive finché qualcuno non chiede l'allegato originale invece della copia inoltrata tre messaggi più indietro. La data di modifica di un file sopravvive finché il file non viene copiato da qualche parte. Una prova costruita attorno a una marca temporale qualificata è pensata per la situazione opposta: deve poter essere verificata da qualcuno che non era nella stanza e non ha motivo di credervi sulla parola. Una pagina di verifica pubblica conferma l'hash, la dichiarazione e la marca temporale, senza account e senza bisogno di contattare chi sta affermando qualcosa.
Quest'ultimo punto è un test onesto da applicare fin da subito alle vostre stesse prove. Consegnate il vostro screenshot, la vostra email e le proprietà del vostro file a qualcuno realmente scettico, e chiedetegli di confermare la vostra affermazione senza farvi altre domande. Nessuno dei tre ci riesce da solo.
Oltre un'aula di tribunale
Le stesse prove deboli emergono anche fuori da un'aula di tribunale. Una piattaforma di licenze, o un'azienda che valuta se un contenuto sia stato usato senza autorizzazione, incontra lo stesso problema: uno screenshot o una data di creazione dichiarata non provano nulla sulla storia reale di un file e non possono essere confrontati su larga scala con altro. Un hash crittografico serve lì a uno scopo affine. Poiché deriva dal contenuto esatto di un file anziché da una sua descrizione, l'hash può essere confrontato con altri contenuti senza mai esporre il file originale. Questa proprietà rende una prova utile per tracciare dove un contenuto è stato usato, non solo per vincere una discussione su chi lo ha fatto per primo.
Costruire l'abitudine invece dell'archivio
La soluzione non è ricostruire anni di lavoro passato in un solo pomeriggio di raccolta prove. È cambiare ciò che accade nel momento in cui qualcosa è finito. Sigillare un file richiede pochi minuti e produce una prova costruita da un hash crittografico, una dichiarazione su come è stato realizzato il lavoro, e una marca temporale qualificata, sostenuta da un link di verifica che chiunque può aprire in modo indipendente. Fatelo al momento della pubblicazione o della consegna da qui in avanti, e la prossima controversia partirà da una prova pensata per rispondere alla domanda, invece che da una cartella di file di cui dovreste spiegare le date una per una.
