Riferimento

Che cosa conserviamo su un dominio

Scritto per avvocati e responsabili della protezione dei dati. Ogni termine tecnico è spiegato dove compare per la prima volta.

Questa pagina risponde per intero a una sola domanda: se MachineWitness osserva un dominio, che cosa finisce esattamente nell'archivio? Non un riassunto, ma i campi stessi. Seguiamo un esempio svolto, beispielfirma.example, dal momento in cui il nostro osservatore si connette fino al punto in cui un tribunale potrebbe verificare il record anni dopo.

Prima di prelevare qualunque dei file elencati sotto, leggiamo il robots.txt del dominio e lo rispettiamo. Quando ci indica di non prelevare un file, non lo preleviamo, e il record lo dichiara: l'osservazione di quel giorno è registrata come disallowed_by_robots, con la provenienza policy: robots_respected, al posto di una risposta. È un'affermazione diversa da quella di un server che non ha risposto, e l'archivio tiene distinti i due casi. Il 10 agosto 2026 ciò riguardava circa 14.000 dei 128.347 domini dell'anello, per i tre file diversi dal robots.txt stesso. Potremmo prelevarli comunque (quei file sono pubblici), e non lo facciamo. Anche il modo in cui un robots.txt viene letto è datato: fino all'8 settembre 2026 entrambi i testimoni lo interpretavano con urllib.robotparser di Python, anteriore alla RFC 9309; il testimone 2 lo legge secondo la RFC 9309 (protego) dal 9 settembre 2026, il testimone 1 dall'11 settembre 2026. I due analizzatori divergono soltanto in casi limite (caratteri jolly, prevalenza della corrispondenza più lunga); il file registrato è lo stesso in entrambi i casi, può differire solo la decisione se prelevare o meno gli altri file in quei giorni.

Due precisazioni meritano di precedere il dettaglio. Primo, preleviamo soltanto ciò che qualunque browser può prelevare senza autenticarsi: una manciata di piccoli file di policy che un sito pubblica perché le macchine li leggano. Non eseguiamo la scansione del contenuto delle pagine, non seguiamo collegamenti verso applicazioni e non registriamo nulla sulle persone che visitano un sito. Secondo, nulla di tutto ciò è segreto. Il valore di questo archivio non sta in che cosa detiene, che chiunque potrebbe prelevare oggi da sé; sta nel fatto che lo abbiamo detenuto in una data passata determinata e che possiamo provare che il record non è stato alterato da allora.

1. Che cosa preleviamo, per dominio

Cinque richieste. Nient'altro, mai, per un dominio del nostro anello ampio.

Risorsa	Che cos'è e perché conta sul piano giuridico
/robots.txt	Il più antico file di istruzioni leggibile dalle macchine del web. Indica ai crawler nominati quali parti di un sito possano prelevare. Poiché le imprese di IA pubblicano i nomi dei propri crawler (GPTBot, ClaudeBot, Google-Extended e altri), è in questo file che la maggior parte dei siti esprime, o omette di esprimere, un rifiuto all'addestramento dei modelli di IA.
/ai.txt	Una convenzione più recente, specifica per l'IA, con la medesima finalità. Non è ancora standardizzata, ed è proprio per questo che la sua presenza o assenza in una data determinata può essere contestata in seguito.
/.well-known/tdmrep.json	La riserva formale e leggibile dalle macchine dei diritti di estrazione di testo e di dati (TDM Reservation Protocol, W3C). Ai sensi dell'articolo 4, paragrafo 3, della direttiva UE sul diritto d'autore nel mercato unico digitale, la riserva del titolare dei diritti è efficace solo se consente la lettura automatizzata; l'Oberlandesgericht di Amburgo ha confermato nel dicembre 2025 che le sole condizioni redatte in linguaggio naturale non bastano. Questo file è il modo più netto di formulare tale riserva.
/llms.txt	Una convenzione emergente rivolta direttamente ai grandi modelli linguistici.
/ (pagina iniziale)	Prelevata soltanto per le intestazioni di risposta e i primi kilobyte, mai la pagina intera. Alcuni siti esprimono la propria riserva in un'intestazione HTTP o in un meta tag anziché in un file.

Ogni risposta è soggetta a un limite rigido di byte. Questi file sono normalmente di pochi kilobyte; il limite esiste affinché un server mal configurato non possa farci scaricare qualcosa di voluminoso.

Modifica del metodo, con effetto dal 3 agosto 2026

Da quella data l'archivio applica le regole che seguono. Sono enunciate qui anziché lasciate implicite, perché una modifica del metodo cambia ciò che un record di una data determinata consente di provare. Nulla di anteriore al 3 agosto 2026 è stato alterato; le giornate precedenti conservano il metodo in vigore quando furono sigillate.

Due anelli. Le regole differiscono tra un piccolo anello principale e un vasto anello ampio. L'anello ampio è definito da un criterio enunciato, non da una selezione: tutti i domini dell'Unione presenti nell'elenco Tranco del primo milione, come prelevato il 2 agosto 2026. L'anello principale è un insieme assai più ristretto di domini osservati più da vicino. È composto a mano e non ne pubblichiamo ancora i criteri, quindi va letto come una selezione di lavoro, non come un registro curato.

I quattro file di riserva continuano a essere prelevati ogni giorno, per ogni dominio. È la parte che ha peso giuridico, ed è rimasta invariata.
La pagina iniziale è prelevata ogni settimana, non ogni giorno, per i domini dell'anello ampio. La conseguenza, detta francamente: quando un sito esprime la propria riserva soltanto in un meta tag o in un'intestazione HTTP della pagina iniziale, il nostro record di quella riserva nell'anello ampio è preciso alla settimana, non al giorno. Per l'anello principale nulla cambia: lì la pagina iniziale è ancora prelevata ogni giorno.
I limiti di byte differiscono per anello. Anello principale: senza limite. Anello ampio: 256 KB, con tutto ciò che eccede contrassegnato come truncated. Ciò che viene conservato è sempre l'inizio della risposta, dove questi segnali si trovano.
Le risposte di errore sono registrate senza il corpo. Codice di stato, tutte le intestazioni, dimensione e impronta del contenuto sono conservati, cosicché il fatto e la forma dell'errore restino provabili; la pagina di errore stessa non viene conservata. Un'eccezione: i corpi delle risposte 403 Forbidden sono conservati fino a 32 KB, perché talvolta è lì che viene formulato un rifiuto rivolto ai crawler.

Modifica del metodo, con effetto dal 17 settembre 2026

Da quella data il record cresce in tre punti. Come prima, nulla di anteriore è stato alterato: le giornate precedenti il 17 settembre 2026 conservano il metodo in vigore quando furono sigillate. Il primo prelievo con il nuovo perimetro è iniziato il 17 settembre 2026 alle 03:00 UTC.

L'anello principale ha ora un criterio enunciato. Fino al 16 settembre 2026 era una selezione di lavoro di 115 domini, composta a mano. Dal 17 settembre comprende 1.133 domini, così composti: 1.057 domini di organizzazioni dell'Unione che pubblicano, registrate in Wikidata con un sito attivo, siano essi giornali e siti di notizie, emittenti radiotelevisive, editori di libri, agenzie di stampa e agenzie fotografiche o società di gestione collettiva, e il cui sito recava al tempo stesso un segnale rivolto ai crawler di IA che avevamo già osservato: una regola per un bot di IA nominato nel robots.txt oppure un'intestazione Content-Signal. Si distribuiscono in 26 Stati membri. A questi si aggiungono 43 ulteriori editori registrati in Wikidata che erano già nell'anello e non recano tale segnale; 14 domini mantenuti dalla selezione precedente per un motivo enunciato; 4 domini che recano tale segnale ma non hanno una voce in Wikidata; e i 15 domini della società del gestore stesso, tenuti come serie di controllo anziché nascosti. Per ogni dominio dell'anello principale il record indica ora l'organizzazione, il suo Paese e il suo identificativo Wikidata. Dove Wikidata attribuisce un dominio a più di un'organizzazione, è stata presa l'etichetta più breve e la voce è contrassegnata come non definita (61 domini), da correggere nel corso della curatela; il dominio in sé non ne è toccato. Le regole dell'anello principale del 3 agosto 2026, pagina iniziale ogni giorno e nessun limite di byte, si applicano a tutti dal 17 settembre. L'anello ampio è invariato. Un dominio della società del gestore che non si risolve più nel DNS è stato ritirato dall'anello lo stesso giorno, e altri tre sono stati aggiunti; il manifesto dell'anello di quella data elenca ogni dominio con il suo anello.

Dichiarazioni degli operatori. Per ciascuno di 13 operatori di crawler (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Microsoft, Mistral, OpenAI, Perplexity) le dichiarazioni che l'operatore stesso pubblica sui propri crawler, la pagina di documentazione e gli intervalli IP pubblicati (JSON), sono prelevate ogni giorno, senza limite di byte, e sottoposte a hash, sigillate e ancorate come ogni altro artefatto: 26 indirizzi. Non verifichiamo se un accesso sia effettivamente avvenuto da quegli intervalli; è attestato soltanto ciò che l'operatore ha dichiarato nel giorno T. Dove esisteva un reindirizzamento, viene registrata la destinazione, così che la provenienza accompagni il documento e non il reindirizzamento. Escluse, con il motivo enunciato: le pagine che non consegnano nulla a un client privo di browser (la documentazione sui crawler di Meta), perché un involucro vuoto non prova nulla.

Dichiarazioni dei fornitori. Con lo stesso meccanismo, le politiche d'uso, le condizioni e le politiche sui crawler pubblicate da 12 di questi operatori (AI2, Amazon, Anthropic, Apple, Cohere, Common Crawl, Diffbot, DuckDuckGo, Google, Meta, Microsoft, Mistral): 32 indirizzi, ogni giorno, senza limite di byte. Due operatori, OpenAI e Perplexity, non consegnano queste pagine a un client che non sia un browser; le loro condizioni non sono quindi nel record, e lo diciamo qui anziché colmare la lacuna con altri mezzi. Insieme costituiscono la controparte dei file di riserva: che cosa un sito aveva riservato nel giorno T, e che cosa l'operatore aveva dichiarato lo stesso giorno sulla propria condotta. Nulla viene valutato: il record conserva il testo, non un giudizio su di esso.

2. Che cosa contiene un'osservazione

Un'osservazione è la registrazione di una risorsa in un dato istante. Eccone una completa, per il nostro dominio di esempio, nella forma in cui l'archivio la conserva.

Il contenuto stesso

GET https://beispielfirma.example/robots.txt
→ HTTP 200, 412 byte

User-agent: *
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

I byte esatti consegnati dal server, conservati senza modifiche e compressi. Non un nostro riassunto, né una resa: i byte. In una controversia la domanda non è mai «che cosa dice il file», ma «che cosa diceva il 14 agosto 2027».

L'impronta

payload_sha256 = 9f2a41d7c8e05b3a…7d1e6084bb93c2f5
payload_size   = 412 byte

Un'impronta SHA-256 (hash) è un codice breve, di lunghezza fissa, calcolato dai byte esatti di un file. Basta cambiare un carattere e il codice cambia interamente, ed è praticamente impossibile costruire un file diverso con lo stesso codice. Funziona come l'impronta di una versione determinata di un documento. È anche il numero di protocollo: il contenuto è conservato sotto la propria impronta, cosicché nulla possa essere sostituito senza che l'etichetta cessi di corrispondere.

Le circostanze della consegna

observed_at   = 2027-08-14 03:00:11 UTC
observer_id   = witness-1
status_code   = 200
final_url     = https://www.beispielfirma.example/robots.txt   (dopo reindirizzamento)
http_version  = HTTP/1.1
headers       = content-type: text/plain; charset=UTF-8
                cache-control: max-age=600
                x-served-by: cache-fra-…
                (intestazioni di risposta complete, alla lettera)
tls_version   = TLSv1.3
peer_cert     = subject:  *.beispielfirma.example
                issuer:   GlobalSign Atlas R3 DV TLS CA
                valid:    2027-06-01 → 2028-06-01
                sha256:   3b8c07f2ad91…e5240ac71f6b88
                (impronta del certificato del server,
                 più i cinque campi analizzati sopra)
peer_cert_chain = 3b8c07f2ad91…e5240ac71f6b88   (certificato del server)
                6f1d0ba47c33…9a7e1c40db2f51   (intermedio)
                c04e83fa1d67…2b95e7708aa361   (intermedio)
                (la catena così come il server l'ha consegnata, in
                 quest'ordine; ogni certificato conservato per intero)
observer_addr = l'indirizzo IP da cui il nostro osservatore si è connesso
peer_addr     = l'indirizzo IP che ha risposto

È ciò che i giuristi chiamano catena di custodia: non semplicemente «questo file esisteva», ma «questo server, presentando questo certificato TLS, ha consegnato questi byte a questo osservatore in questo momento». Il certificato TLS conta perché collega la consegna a un soggetto in grado di ottenere un certificato per quel dominio. Il tutto è sigillato insieme al contenuto, cosicché nessuna parte possa essere scambiata in seguito.

Che cosa viene esattamente registrato qui, e che cosa no. Dal 15 settembre 2026 conserviamo la catena di certificati completa così come il server la consegna: il certificato del server e gli intermedi inviati insieme a esso, ciascuno conservato per intero, con le impronte registrate nell'ordine di arrivo. Non si tratta di una catena ricostruita rispetto al nostro archivio di fiducia: un testimone registra ciò che è stato consegnato, e se quella catena sia valida è questione del perito, non nostra. Accanto continuiamo a registrare l'impronta SHA-256 del certificato del server e i cinque campi analizzati indicati sopra.

La modifica non opera retroattivamente. Per le osservazioni anteriori al 15 settembre 2026 esiste soltanto l'impronta, non il certificato; qualora quel certificato serva, di norma può essere ottenuto in modo indipendente dai registri pubblici di trasparenza dei certificati (RFC 6962), la stessa infrastruttura di audit su cui si basano i browser. I record più vecchi conservano lo stato che avevano allora, e nulla viene integrato a posteriori. Ciò adempie l'impegno che questa pagina recava dal 1º agosto 2026.

L'indicatore di modifica

changed = true   (l'impronta differisce dall'osservazione precedente)

Impostato quando l'impronta odierna differisce da quella del giorno prima per la stessa risorsa. È la ragione d'essere di questo archivio: questi file cambiano in silenzio, senza una cronologia pubblica, e il cambiamento stesso è spesso il fatto contestato.

3. Come si presenta un file assente

Registrare che «lì non c'era nulla» è anch'esso una prova, e va registrato con la stessa cura di un contenuto. Se il nostro dominio di esempio non serve alcun ai.txt:

GET https://beispielfirma.example/ai.txt
→ HTTP 404, nessun contenuto conservato
   stato, intestazioni complete, impronta del contenuto e
   dettagli TLS registrati come sopra

Questa distinzione ha un peso reale. «Il sito non aveva pubblicato alcuna riserva di IA leggibile dalle macchine a quella data» è spesso il fatto decisivo in una controversia sull'estrazione di testo e di dati, e può essere dimostrato solo da qualcuno che ha guardato e ha annotato di non aver trovato nulla. Altri due casi sono registrati con la stessa esplicitezza: un server che rifiuta il nostro osservatore (HTTP 403) produce il record del rifiuto, non di un contenuto; e una risorsa che il robots.txt del sito ci chiede di non prelevare è registrata come deliberatamente non prelevata. Rispettiamo quell'indicazione e registriamo di averlo fatto.

4. Come viene sigillato il registro

Un archivio tenuto da una parte interessata prova di per sé poco: potremmo, in linea di principio, riscrivere la nostra stessa banca dati. Quattro passi rispondono a questa obiezione, ciascuno indipendente dagli altri.

Passo 1 · lo stesso giorno

Tutte le osservazioni del giorno sono legate in un unico valore

Tutte le impronte registrate quel giorno vengono combinate a coppie, livello dopo livello, finché non resta una sola radice giornaliera che dipende da ogni record sottostante. Modificate poi una sola osservazione e la radice non corrisponde più. È la costruzione usata dai registri pubblici su cui i browser si basano per verificare i certificati TLS (RFC 6962).

Passo 2 · depositata lo stesso giorno

Quel valore è depositato fuori dalla nostra portata

La radice giornaliera è inviata lo stesso giorno a OpenTimestamps, che la aggrega verso la blockchain di Bitcoin, e separatamente a un'autorità di validazione temporale RFC 3161 indipendente, che restituisce immediatamente un token firmato. Dal 31 luglio 2026 si ottiene inoltre una validazione temporale elettronica qualificata ai sensi di eIDAS. Non possiamo riscriverne nessuno. È ciò che eleva il sigillo da affermazione interna a prova esterna: dimostra che il record esisteva non oltre quel giorno.

Stato dell'ancoraggio Bitcoin: completato il 7 agosto 2026. Le due autorità di validazione temporale restituiscono la loro prova immediatamente, e quei token sono conservati qui. OpenTimestamps opera in due fasi: la radice viene inviata subito, ma la ricevuta ottenuta diventa autosufficiente solo una volta reintegrata la conferma di Bitcoin. Fino al 7 agosto 2026 non avevamo compiuto quel secondo passo, e una versione precedente di questo passaggio lo dichiarava. Ora è stato compiuto per ogni giornata sigillata su entrambi i testimoni, e da allora se ne occupa un processo quotidiano, cosicché le ricevute qui conservate rinviano a intestazioni di blocchi Bitcoin anziché a server calendario. Quel passo ha modificato le ricevute, ma non ciò che attestano: l'impronta di cui ciascuna ricevuta è testimone è stata rilevata prima e dopo ed è invariata per ogni giornata. Il percorso Bitcoin non dipende più dalla raggiungibilità di quei server calendario. Gli ancoraggi RFC 3161 ed eIDAS qualificato non ne sono stati toccati e valgono per sé.

Passo 3 · lo stesso giorno

La radice viene pubblicata

Ogni radice giornaliera compare nel nostro registro pubblico delle radici, con indirizzi stabili e in forma leggibile dalle macchine. Chiunque può conservarne una propria copia il giorno in cui compare; diversi sistemi di terzi la acquisiscono automaticamente.

Passo 4 · in funzione dal 2026-08-04

Un secondo testimone indipendente osserva gli stessi obiettivi

Un sistema distinto, su un'infrastruttura diversa in un altro Paese e con una diversa chiave di gestione, registra in modo indipendente e pubblica la propria radice giornaliera. Nessuna delle due macchine possiede credenziali per l'altra e nessuna può scrivere nella banca dati dell'altra. Due resoconti tenuti in modo indipendente sono più difficili da liquidare di un testimone che si ripete.

Due limiti, detti con chiarezza. Primo, ciò è iniziato il 4 agosto 2026: ogni giornata sigillata dal 22 luglio al 3 agosto 2026 poggia sul solo primo testimone, e il registro pubblico mostra quello scarto anziché nasconderlo. Secondo, le due radici giornaliere non sono mai identiche, per costruzione: ciascun testimone esegue la scansione secondo il proprio calendario, cosicché l'insieme delle osservazioni dietro ciascuna radice differisce. Il confronto si fa quindi osservazione per osservazione, non verificando se due radici coincidano; radici identiche indicherebbero anzi che i due sistemi non sono indipendenti.

5. Che cosa contiene un estratto probatorio

L'archivio non è consultabile liberamente, per scelta. Ciò che produciamo su richiesta, per un dominio e un periodo determinati, è un estratto probatorio: un pacchetto contenente

il contenuto conservato di ciascuna osservazione del periodo, byte per byte;
l'insieme delle circostanze di consegna sigillate, come esposte al punto 2;
l'impronta di ciascuna osservazione;
una prova di inclusione: una breve ricevuta matematica che dimostra che quella specifica osservazione è contenuta nella radice di quel giorno, verificabile senza fidarsi di noi e senza accesso al resto dell'archivio;
la radice giornaliera e le ricevute di validazione temporale esterne;
istruzioni di verifica passo per passo, che qualunque perito tecnico competente può seguire con strumenti comuni.

Il senso dell'ultimo punto merita di essere detto chiaramente: l'estratto è concepito perché il perito della controparte possa verificarlo. Un record che una sola parte può controllare non è una prova.

Come richiederne uno, a quali condizioni viene rilasciato e quanto costa è esposto nella pagina estratto probatorio. Se questo archivio osservi un determinato dominio può essere verificato prima, gratuitamente, con la verifica di copertura.

6. Se qualcuno ci chiede di cancellare

La maggior parte di ciò che deteniamo non contiene dati personali: sono file tecnici di policy pubblicati da organizzazioni. Quando una richiesta legittima di cancellazione ai sensi dell'articolo 17 del GDPR riguarda effettivamente un contenuto archiviato, eseguiamo quello che chiamiamo marcatore di cancellazione: il contenuto conservato viene eliminato e sostituito da un marcatore. Cancellato significa cancellato, e nessun backup lo ripristina.

Ciò che resta è l'impronta, il sigillo e le prove. La conseguenza merita di essere compresa con precisione: da quel momento nessuno può sapere che cosa dicesse il file, ma resta provabile che un file con esattamente quell'impronta si trovava a quell'indirizzo in quella data, e che i record circostanti di quella giornata sono intatti. La conservazione dell'impronta si fonda sull'articolo 17, paragrafo 3, lettera e), del GDPR, perché cancellarla spezzerebbe la catena probatoria di tutte le altre osservazioni sigillate quel giorno, comprese quelle di terzi estranei.

Su richiesta escludiamo inoltre un dominio da ogni osservazione futura, con o senza cancellazione. Entrambe le cose sono gratuite e nessuna richiede una motivazione. Per un'esclusione chiediamo però di dimostrare che Lei ha il controllo del dominio: un record DNS TXT, oppure un file a un percorso che indichiamo noi, a Sua scelta. Non perché la richiesta debba essere giustificata, ma perché un'esclusione chiesta da un terzo toglierebbe un dominio dal registro senza che il suo gestore ne venga mai a conoscenza. Una cancellazione ai sensi dell'articolo 17 del GDPR non comporta questo passaggio: lì chiediamo un'identificazione solo in caso di dubbio reale. Si vedano Privacy e Crawler & contatti.

7. Che cosa questo record non prova

Enunciare i limiti con precisione fa parte dell'essere un testimone credibile.

Dimostra che cosa un server ha consegnato al nostro osservatore, nei momenti registrati. Non dice nulla sugli intervalli fra le osservazioni, né su ciò che hanno visto altri visitatori.
Dimostra il contenuto e le circostanze della consegna, non la paternità, l'intenzione o la liceità. Se una riserva fosse efficace, se un crawler l'abbia rispettata e che cosa ne consegua sul piano giuridico sono questioni per il difensore e per il giudice.
L'ancoraggio esterno prova che un record esisteva non oltre la data del suo ancoraggio. Non prova nulla su una data anteriore.
Un file mancante prova che la risorsa era assente a quell'indirizzo in quel momento, non che il gestore non abbia mai riservato i propri diritti in altro modo.
Registriamo dichiarazioni pubbliche e leggibili dalle macchine provenienti da organizzazioni. Non osserviamo dati privati, né comportamenti degli utenti, né persone fisiche.

Siamo la scatola nera, non l'investigatore. Che cosa significhi il record, spetta ad altri discuterlo.

L'esempio sopra è costruito a fini illustrativi. Un estratto svolto su un dominio reale, verificabile rispetto al registro pubblico delle radici, sarà aggiunto quando quel dominio avrà accumulato una cronologia di osservazioni significativa.