Tutti gli articoli

9 min di lettura

Autenticità dei media: cosa dimostra un timestamp e cosa non può dimostrare

Una prova Label 309 mostra che un file multimediale esisteva entro un certo momento pubblico. L’autenticità richiede di più: contesto di acquisizione, provenienza, firme e verifica umana. Ecco come si inserisce il livello del timestamp.

Una Proof of Existence può mostrare che un determinato file multimediale esisteva entro un certo momento. Da sola, però, non può dimostrare che la scena davanti all’obiettivo fosse reale.

È proprio questa distinzione il cuore dell’articolo. Con Label 309 puoi calcolare l’hash di una foto, di un video, di un file audio, di un manifest Content Credentials (C2PA) o di un fascicolo di prove redazionali, e ancorarlo su Cardano. In seguito, chiunque abbia il file può controllare se corrisponde all’impegno con timestamp. È un meccanismo reale e utile — ma è un solo livello dentro uno stack più ampio. Per stabilire da dove arriva un contenuto multimediale servono ancora il contesto di acquisizione, i metadati di provenienza, le firme, la catena di custodia e il giudizio umano.

Cosa dimostra davvero una prova su un file multimediale?

Dimostra che una sequenza esatta di byte esisteva entro un certo momento pubblico.

Calcola l’hash di una foto, ancora quel digest con Label 309 e in seguito potrai verificare lo stesso file foto rispetto all’hash on-chain. Se l’hash corrisponde, il verificatore sa che il file successivo è, byte per byte, lo stesso contenuto vincolato al block time registrato. Non serve appellarsi a un server, a un fornitore o all’identità di un emittente — bastano i metadati della transazione, il file e un explorer pubblico di Cardano.

Lo stesso meccanismo vale per qualsiasi asset digitale:

  • video e registrazioni audio;
  • foto raw ed esportazioni modificate;
  • miniature, trascrizioni e sottotitoli;
  • manifest C2PA;
  • fascicoli di prove redazionali e manifest delle camera card;
  • pacchetti di esportazione dai social media.

Questo conta perché i media digitali sono modificabili con estrema facilità. Un impegno pubblico e indipendente sui byte esatti rende molto più difficile negare una sostituzione silenziosa.

Cosa non dimostra una prova su un file multimediale?

Non dimostra che la fotocamera abbia visto il mondo reale.

Si può applicare un timestamp a un’immagine sintetica. E lo stesso vale per un deepfake, una foto messa in scena o un video modificato prima ancora di calcolarne l’hash. Un file veritiero e un file ingannevole possono entrambi portare una Proof of Existence perfettamente valida. La prova risponde a una sola domanda — questi byte esistevano entro questo momento? — e a nient’altro.

Da sola, non ti dice:

  • chi ha acquisito il file;
  • dove è stato acquisito;
  • se la scena era reale;
  • se il file è stato modificato prima della marcatura temporale;
  • se il soggetto ha dato il consenso;
  • se l’uso del file è lecito;
  • se la storia attorno al file è vera.

Questa onestà è il senso stesso del sistema, non un suo limite. Un timestamp è prova di tempistica e integrità, non una finestra sulla realtà. (Per una trattazione più completa, vedi cosa una prova non dimostra.)

Se non dimostra la realtà, perché è utile?

Perché tempistica e integrità sono esattamente i punti su cui ruotano le dispute sui media.

Le indagini hanno regolarmente bisogno di sapere se un file esisteva prima o dopo un evento, se una redazione possedeva un file sorgente prima della pubblicazione, se un filmato contestato è stato alterato dopo la consegna, oppure se un archivio conserva ancora lo stesso file che qualcuno aveva esaminato mesi prima. Una Proof of Existence dà a tutti questi casi un punto di ancoraggio stabile e confrontabile:

  • questo file esisteva prima dell’affermazione pubblica;
  • questa esportazione è identica a quella esaminata;
  • questo pacchetto sorgente esisteva prima che l’articolo uscisse;
  • questo manifest C2PA esisteva prima della rimozione;
  • questo lotto di asset esisteva prima del lancio della campagna;
  • questo fascicolo di prove esisteva prima dell’inizio del contenzioso.

Nessuno di questi casi richiede di fidarsi di chi pubblica. Offrono agli investigatori un termine di paragone fisso, che spesso è proprio il tassello mancante.

Come funziona Label 309 insieme a C2PA?

Coprono parti diverse del problema e si incastrano in modo pulito.

C2PA — la Coalition for Content Provenance and Authenticity, presentata agli utenti come Content Credentials — è un livello di provenienza strutturato, non un semplice timestamp. Descrive come un contenuto è nato: creazione, modifiche, ingredienti, dichiarazioni sugli strumenti e altre asserzioni firmate legate all’asset. Label 309 svolge il compito complementare: ancora un hash — dell’asset, del manifest o di una Merkle root su molti di essi — al tempo pubblico di Cardano, senza alcuna autorità nominata di cui fidarsi.

Un buon flusso di autenticità dei media può combinarli in più livelli:

  • una firma di dispositivo o di acquisizione;
  • un manifest C2PA;
  • l’hash del file originale;
  • l’hash dell’esportazione modificata;
  • un manifest del pacchetto sorgente;
  • un’àncora temporale Label 309;
  • note sulla catena di custodia;
  • la verifica redazionale o di piattaforma.

C2PA aiuta a raccontare la storia della provenienza. Label 309 dimostra quando una specifica versione di quella storia esisteva. Approfondiamo questo abbinamento in Proof of Existence vs C2PA e perché C2PA ha bisogno di un’àncora temporale.

Cosa dovrebbe marcare temporalmente una redazione?

Il fascicolo di prove, non solo l’immagine pubblicata.

Quando l’obiettivo è difendere una storia in un secondo momento, la cosa che vale la pena ancorare è tutto ciò che l’ha sostenuta:

  • file multimediali originali e forniti dalle fonti;
  • esportazioni dei metadati di acquisizione;
  • manifest C2PA;
  • trascrizioni e file di traduzione;
  • note di verifica e prove di geolocalizzazione;
  • screenshot delle ricerche per immagini inverse;
  • testimonianze e log delle decisioni di montaggio;
  • l’esportazione pubblicata ed eventuali registri di correzione.

Gran parte di questo materiale è sensibile e dovrebbe restare privato. Va benissimo così: al registro pubblico servono solo gli hash e le Merkle root. I byte sottostanti possono restare offline, oppure essere sigillati in modo che venga conservato il testo cifrato mentre il testo in chiaro rimane in mano a chi detiene le chiavi.

Come può una piattaforma marcare temporalmente i media su larga scala?

Ancorando i lotti invece dei singoli caricamenti.

Una piattaforma che gestisce grandi volumi non vuole una transazione Cardano per file. Può invece costruire periodicamente una Merkle root su molti hash di media, record di moderazione, manifest di provenienza o dati sorgente dei report di trasparenza, e ancorare una singola root. Per esempio:

  • una root all’ora per i caricamenti ad alto rischio;
  • una root al giorno per le prove sui media rimossi;
  • una root per campagna per gli asset di brand verificati;
  • una root per lotto di pubblicazione per i media dei partner;
  • una root per fascicolo di prove di rimozione.

In seguito, la piattaforma può dimostrare che un singolo asset o record di moderazione faceva parte di un lotto con timestamp, producendo la inclusion proof di quell’item rispetto alla root pubblicata. La meccanica è descritta in un record per migliaia di file.

In che modo questo aiuta contro i deepfake?

Aiuta con le cronologie, non con un rilevamento magico.

Una prova può mostrare che un presunto originale esisteva prima che emergesse un deepfake, che una piattaforma ha ricevuto un caricamento contestato a un certo momento, oppure che il file sorgente o la cartella di progetto di un creatore precedevano un derivato ingannevole. Sono fatti reali, capaci di orientare le decisioni in una disputa.

Quello che non può fare è guardare un file e dichiararlo reale o falso. Il rilevamento dei deepfake, l’acquisizione sicura, i metadati di provenienza, la validazione delle fonti e l’indagine umana continuano a svolgere quel lavoro. Il contributo qui è più ristretto e più affidabile: ecco il file o il manifest vincolato in precedenza, ed ecco quando esisteva.

Il file multimediale stesso dovrebbe essere conservato per sempre?

A volte — ma rifletti bene prima di rendere permanente il testo in chiaro.

Per media genuinamente pubblici, il file o il manifest può essere conservato in modo aperto tramite storage indirizzato per contenuto. Per media sensibili, un record sigillato è di solito la scelta più sicura: il testo cifrato viene preservato mentre il testo in chiaro resta leggibile solo a chi detiene le chiavi previste. Sigillare mantiene il contenuto riservato, ma non garantisce l’anonimato, e un destinatario può comunque divulgare il testo in chiaro una volta decifrato.

Le prove multimediali destinate a durare a lungo devono soppesare:

  • privacy e consenso;
  • la sicurezza dei soggetti e delle fonti;
  • il segreto professionale e la protezione delle fonti;
  • la politica di conservazione;
  • l’accesso dei destinatari e le esigenze di verifica future.

La conservazione pubblica permanente del testo in chiaro è raramente l’impostazione predefinita giusta. Un impegno permanente sull’hash è spesso tutto ciò che davvero serve; i byte possono vivere ovunque la situazione richieda. Vedi divulgazione confidenziale senza file pubblici per lo schema del record sigillato.

Cosa dovrebbero conservare i creatori?

Il file originale e tutto ciò che serve per spiegare la prova in seguito.

Un pacchetto di prova multimediale duraturo di solito contiene:

  • il file originale ed eventuali esportazioni modificate;
  • il manifest e l’algoritmo di hash utilizzato;
  • il riferimento della transazione Label 309;
  • il manifest C2PA, se ne è stato creato uno;
  • la foglia Merkle e la inclusion proof, se l’item è stato raggruppato in un lotto;
  • la chiave pubblica di firma del record, se è stato firmato;
  • note sulla fonte e sulla catena di custodia.

Se alcuni di questi elementi vanno persi, la prova in sé di solito esiste ancora on-chain — ma diventa molto più difficile da spiegare e presentare in modo convincente. L’àncora on-chain è la parte durevole; il contesto che la circonda è ciò che la rende leggibile.

In breve

L’autenticità dei media è uno stack, non una singola funzionalità.

Label 309 può dimostrare che un determinato file multimediale, manifest o fascicolo di prove esisteva entro un certo momento pubblico, verificabile da chiunque abbia il file e un explorer di Cardano. Può sostenere la provenienza C2PA, la verifica redazionale, le prove legali, la moderazione delle piattaforme e i flussi di lavoro dei creatori — e può farlo senza chiedere a nessuno di fidarsi di chi pubblica.

Quello che non può fare è dimostrare la realtà da solo. Trattalo come il livello di tempistica e integrità all’interno di un processo di autenticità più solido, e abbinalo ai livelli di provenienza, firma e verifica umana che dimostrano il resto.

Approfondimenti

mediaauthenticitydeepfakes