Acquisizione di pagine web, social e contenuti online

Introduzione

Una pagina web non è un documento immobile. Può cambiare tra due caricamenti, mostrare contenuti differenti in base all’account, alla posizione geografica, al dispositivo, alla lingua, ai cookie, all’orario o a un test A/B. Un post social può essere modificato o eliminato; un commento può essere nascosto; una storia può cessare di essere disponibile; un video può essere sostituito mantenendo lo stesso indirizzo.

Per questo motivo l’acquisizione forense di contenuti online non coincide con la semplice esecuzione di uno screenshot. La schermata conserva ciò che era visibile, ma normalmente non documenta in modo completo URL, reindirizzamenti, header HTTP, risorse caricate, codice HTML, richieste di rete, identificativi del contenuto, certificato TLS, contesto dell’account o comportamento dinamico della pagina.

In una consulenza informatico-forense a Roma, l’obiettivo è costruire un insieme di reperti complementari e verificabili: cattura visiva, registrazione della navigazione, HTML o DOM, risorse native, file multimediali quando accessibili lecitamente, header, log di rete, archivi WARC o WACZ, hash, manifest, riferimenti temporali e documentazione dell’ambiente di acquisizione.

La procedura deve essere autorizzata, ripetibile per quanto consentito dalla volatilità della fonte e proporzionata al quesito. Le best practice SWGDE per l’acquisizione di contenuti online richiamano rilevanza, affidabilità, sufficienza, documentazione dell’ambiente e uso combinato di più metodi. La pagina acquisita deve inoltre essere collegata alla catena di custodia e, quando utile, alla timeline forense.

Sintesi operativa

Una procedura completa può essere sintetizzata nel seguente flusso:

1. definire quesito, perimetro, autorizzazione e priorità;
2. registrare data, ora, fuso, sincronizzazione e ambiente di acquisizione;
3. documentare browser, sistema, account, rete, IP di uscita e viewport;
4. acquisire URL completo e sequenza dei reindirizzamenti;
5. eseguire screenshot mirati e registrazione continua della navigazione;
6. salvare HTML/DOM, risorse, header e traffico HAR quando appropriato;
7. produrre, se utile, un archivio WARC o WACZ riproducibile;
8. acquisire media e risposte API solo se accessibili lecitamente;
9. documentare DNS, RDAP, certificato TLS e dati di contesto pertinenti;
10. calcolare SHA-256 sui singoli reperti e sull’intero dataset;
11. creare un manifest con strumenti, versioni, orari e operazioni;
12. effettuare acquisizioni ripetute se il contenuto è dinamico o effimero;
13. correlare il risultato con account, dispositivi, email, cloud e log;
14. separare osservazioni, inferenze, limiti e ipotesi alternative;
15. conservare originale, copie di lavoro, output e relazione tecnica.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente su contenuti pubblicamente accessibili o su aree per le quali il professionista e il committente dispongano di un titolo legittimo. Non autorizzano a eludere autenticazioni, paywall, controlli di accesso, sistemi anti-bot, cifrature, protezioni DRM o limitazioni tecniche di terzi.

• non utilizzare credenziali ottenute senza autorizzazione;
• non impersonare terzi e non creare interazioni ingannevoli;
• non forzare endpoint, directory o API non destinate all’accesso autorizzato;
• non modificare, cancellare o segnalare il contenuto prima della sua conservazione, salvo esigenze di sicurezza concordate;
• non diffondere dati di minori, dati sanitari, immagini intime o informazioni riservate oltre quanto necessario;
• consultare il legale per il perimetro dell’incarico e per l’eventuale richiesta di dati al provider.

2. Perché il web è una fonte volatile

Il contenuto online dipende da sistemi remoti che il perito normalmente non controlla. La stessa risorsa può cambiare perché il titolare modifica il testo, la piattaforma ricalcola l’ordine, una CDN sostituisce il file, un account viene sospeso, il contenuto scade o il server genera una risposta personalizzata.

Per tale ragione la ripetibilità non sempre significa ottenere una pagina identica in un momento successivo. Significa piuttosto poter ricostruire e spiegare il metodo, l’ambiente e gli output prodotti al momento dell’accesso.

3. Quali domande pone normalmente il cliente

• “Come posso conservare un post diffamatorio prima che venga eliminato?”
• “Questa pagina di vendita esisteva davvero alla data indicata?”
• “Il profilo social appartiene alla persona che viene indicata?”
• “Un commento è stato modificato o rimosso?”
• “Il video pubblicato è lo stesso file che ho ricevuto?”
• “È possibile documentare una storia o una diretta?”
• “Il sito mostrava condizioni contrattuali differenti?”
• “L’indirizzo web porta davvero al dominio dell’azienda?”
• “Una recensione è riconducibile a un account reale?”

La risposta tecnica deve essere preceduta da una definizione del quesito. Conservare la presenza di una pagina è diverso dal dimostrarne l’autore, la data originaria di pubblicazione, la completezza o la provenienza del singolo file multimediale.

4. Che cosa significa acquisire un contenuto online

Acquisire significa registrare in modo controllato una o più rappresentazioni e i dati di contesto necessari a comprenderle. Non esiste un unico formato capace di conservare ogni caratteristica del web moderno.

5. Gerarchia pratica delle fonti

Una cattura locale è spesso la prima fonte disponibile, ma può essere rafforzata da dati più vicini al sistema di origine. La seguente gerarchia è orientativa e non sostituisce la valutazione del caso:

1. contenuto visualizzato: screenshot e registrazione;
2. risorse ricevute dal browser: HTML, immagini, script, JSON, media;
3. archivio della sessione: WARC/WACZ, HAR e manifest;
4. dati dell’account: esportazioni, notifiche, cronologie e impostazioni;
5. dati del provider: log e contenuti ottenuti mediante canali autorizzati;
6. dati del dispositivo: cache, cronologia, download e artefatti applicativi.

La convergenza tra livelli indipendenti aumenta la robustezza della ricostruzione. Nessun livello consente automaticamente di attribuire il contenuto a una persona fisica.

6. Rilevanza, affidabilità e sufficienza

6.1 Rilevanza

Acquisire soltanto ciò che è pertinente al quesito, evitando raccolte indiscriminate di dati personali o contenuti estranei.

6.2 Affidabilità

Utilizzare procedure documentate, strumenti testati, output verificabili e almeno un controllo indipendente per gli elementi decisivi.

6.3 Sufficienza

Conservare abbastanza contesto da comprendere autore dichiarato, data visualizzata, URL, conversazione, sequenza, eventuali commenti e relazione con il fatto contestato.

7. Contenuto statico, dinamico ed effimero

La classificazione deve essere effettuata prima dell’acquisizione. Un sito apparentemente statico può caricare prezzi o disponibilità tramite chiamate API; una pagina social può cambiare ordine dei commenti durante la stessa sessione.

8. Provenienza e attribuzione non sono la stessa cosa

La provenienza tecnica può collegare un contenuto a un URL, a un dominio, a una risposta HTTP o a un identificativo di piattaforma. L’attribuzione soggettiva richiede invece elementi ulteriori: controllo dell’account, dispositivi, log di accesso, email di registrazione, dati del provider, pagamenti, testimonianze e contesto.

Anche la registrazione del dominio o il certificato TLS non identificano automaticamente l’autore della singola pagina. CDN, hosting condiviso, deleghe operative e account compromessi possono interrompere l’equivalenza tra infrastruttura e autore.

9. Che cosa richiedere al cliente

[ ] URL completo, non soltanto il nome del sito;
[ ] screenshot o video già disponibili;
[ ] data e ora della prima visualizzazione;
[ ] dispositivo e browser utilizzati;
[ ] account con cui il contenuto era visibile;
[ ] email, messaggi o notifiche che contengono il link;
[ ] eventuali file scaricati;
[ ] cronologia del browser o del dispositivo;
[ ] nomi utente, ID del post e parole chiave;
[ ] indicazione precisa di ciò che viene contestato;
[ ] eventuali versioni precedenti o successive;
[ ] urgenza dovuta a scadenza, storia o possibile rimozione.

Quando il cliente ha già aperto o interagito con la pagina, occorre documentarlo. Un “mi piace”, una visualizzazione o l’apertura di un messaggio possono generare eventi sul sistema remoto.

10. Che cosa non basta

• una fotografia del monitor senza URL e orario;
• un ritaglio che non mostra account, percorso e contesto;
• una stampa PDF priva delle risorse dinamiche;
• un link accorciato senza ricostruzione dei reindirizzamenti;
• una copia incollata del testo;
• un collegamento alla Wayback Machine senza acquisizione della pagina archiviata e dei relativi dati;
• il nome del profilo come prova dell’identità;
• un risultato RDAP o DNS come prova dell’autore del contenuto;
• il solo hash di uno screenshot come prova che la pagina fosse online.

L’hash protegge l’identità del file acquisito; non certifica l’accuratezza della rappresentazione né l’esistenza del contenuto sul server prima dell’acquisizione.

11. Triage e priorità di intervento

Il triage iniziale deve privilegiare ciò che può scomparire o cambiare più rapidamente.

12. Autorizzazione, perimetro e account

Prima dell’accesso occorre annotare se il contenuto è pubblico, disponibile a seguito di registrazione, visibile tramite account del cliente o collocato in un’area privata. Il perimetro deve indicare quali URL, profili, intervalli temporali e interazioni sono autorizzati.

Caso: RM-2026-WEB-016
Committente: [DATI]
Quesito: conservare il post e i commenti pertinenti
Fonte: profilo social pubblico / account autorizzato
Interazioni consentite: apertura commenti e riproduzione video
Interazioni escluse: messaggi, contatti, pubblicazione, segnalazione
Intervallo: 13/07/2026 10:00–11:30 CEST
Operatore: Dott. Marcello Quaranta

Le credenziali del cliente non devono comparire in chiaro nei report o nei comandi. Se necessario, utilizzare un gestore sicuro e documentare soltanto l’identificativo dell’account autorizzato.

13. Preparare l’ambiente di acquisizione

L’ambiente dovrebbe essere stabile, aggiornato e separato dall’attività ordinaria. Una macchina virtuale o un profilo dedicato riduce la contaminazione dovuta a estensioni, cookie, cache e personalizzazioni pregresse.

[ ] sistema operativo e build;
[ ] browser e versione;
[ ] estensioni installate e stato;
[ ] lingua, fuso e locale;
[ ] risoluzione, scaling e viewport;
[ ] profilo nuovo oppure profilo del cliente preservato;
[ ] antivirus/EDR e possibili modifiche al traffico;
[ ] proxy, VPN o DNS utilizzati;
[ ] strumenti di cattura e versioni;
[ ] spazio libero e destinazione degli output.

Un profilo “pulito” è utile per una vista neutrale; non deve però sostituire il profilo del cliente quando il quesito riguarda ciò che quello specifico utente vedeva. In tal caso si preserva prima il profilo e si lavora su una copia o in ambiente controllato.

14. Orologio, fuso orario e sincronizzazione

Ogni acquisizione deve riportare data, ora, fuso e stato della sincronizzazione. L’orario visualizzato sulla pagina e l’orario del sistema sono fonti differenti.

Linux

date --iso-8601=seconds
timedatectl status
chronyc tracking 2>/dev/null || true

Windows PowerShell

Get-Date -Format o
Get-TimeZone
w32tm /query /status

macOS

date -Iseconds
systemsetup -gettimezone 2>/dev/null
sntp -sS time.apple.com  # solo se previsto dalla procedura; documentare l’effetto

15. Rete, IP di uscita e DNS

La pagina può cambiare in base all’indirizzo IP e al resolver DNS. Documentare connessione, interfaccia, gateway, DNS e, se pertinente, IP pubblico di uscita. Una VPN può essere lecita e utile per riprodurre una determinata area geografica, ma deve essere dichiarata.

# Linux/macOS
ip addr 2>/dev/null || ifconfig
ip route 2>/dev/null || netstat -rn
cat /etc/resolv.conf

# Windows PowerShell
Get-NetIPConfiguration
Get-DnsClientServerAddress
Get-NetRoute -DestinationPrefix "0.0.0.0/0"

L’IP pubblico può essere registrato mediante un servizio affidabile approvato dalla procedura. Non inserirlo in una relazione pubblica se non necessario.

16. Browser, profilo ed estensioni

Annotare versione completa, user agent, estensioni, zoom, cache e modalità di navigazione. Traduttori, ad blocker, strumenti di accessibilità e password manager possono modificare il DOM o impedire il caricamento di risorse.

17. Struttura della cartella di caso

CASO_RM_2026_WEB_016/
├── 00_incarico/
├── 01_verbali/
├── 02_ambiente/
├── 03_url_e_redirect/
├── 04_screenshot/
├── 05_video_navigazione/
├── 06_html_dom_pdf/
├── 07_har_header_rete/
├── 08_warc_wacz/
├── 09_media_nativi/
├── 10_dns_rdap_tls/
├── 11_hash_manifest/
├── 12_copie_lavoro/
├── 13_analisi/
├── 14_relazione/
└── 15_allegati/

Nomi e cartelle devono essere stabili. Evitare di salvare output nella stessa directory in cui uno strumento sta producendo l’archivio, per non includere ricorsivamente file della sessione.

18. Catena di custodia dei contenuti online

La catena di custodia deve iniziare prima della navigazione. Il verbale descrive chi ha avviato la sessione, su quale macchina, con quale account, da quale rete e quali file sono stati prodotti.

Identificativo sessione:
Data/ora inizio e fine:
Fuso orario:
Operatore:
Sistema e browser:
Account utilizzato:
Rete/IP di uscita:
URL iniziale:
Azioni eseguite:
Strumenti/versioni:
Output prodotti:
Hash del manifest:
Anomalie e interruzioni:

Ogni conversione successiva, come estrazione di fotogrammi o stampa in PDF, deve essere identificata come derivata e collegata al reperto sorgente.

19. Calcolo degli hash

Singolo file

sha256sum -- screenshot_001.png
shasum -a 256 -- sessione.wacz
Get-FileHash -Algorithm SHA256 -LiteralPath ".\sessione.har"

Manifest dell’intera raccolta

find 04_screenshot 05_video_navigazione 06_html_dom_pdf 07_har_header_rete 08_warc_wacz 09_media_nativi   -type f -print0 | sort -z | xargs -0 sha256sum > 11_hash_manifest/manifest_sha256.txt
sha256sum 11_hash_manifest/manifest_sha256.txt > 11_hash_manifest/manifest_sha256.txt.sha256

Il manifest deve essere ricreato solo quando la raccolta originaria è chiusa. Gli output analitici successivi possono avere un manifest separato.

20. Creare l’inventario degli URL

L’URL deve essere copiato integralmente, senza abbreviazioni o omissioni. Parametri e frammenti possono contenere identificativi, filtri, timestamp o token sensibili.

ID: URL-001
URL visualizzato: https://www.example.com/post/123?lang=it
URL finale: https://www.example.com/post/123?lang=it
Referrer: https://www.example.com/profilo/utente
Metodo: GET
Data/ora: 2026-07-13T10:24:31+02:00
Account: profilo autorizzato A-01
Note: commenti espansi manualmente

21. Reindirizzamenti e URL accorciati

Un link può attraversare più host prima di raggiungere la pagina finale. Documentare la catena aiuta a distinguere il dominio mostrato nel messaggio dal dominio effettivamente raggiunto.

curl --location --max-redirs 10   --dump-header redirect_headers.txt   --output pagina_finale.bin   --write-out "url_finale=%{url_effective}\nhttp_code=%{http_code}\n"   "https://example.com/link" > redirect_summary.txt

Non usare il comando su URL sospetti nella workstation ordinaria. Per collegamenti di phishing o malware adottare un ambiente isolato e una procedura di sicurezza dedicata.

22. Prima cattura visiva

Quando il contenuto è volatile, la prima azione operativa è una registrazione continua che mostri orologio, URL e navigazione. Successivamente si effettuano catture statiche ad alta leggibilità.

[ ] avviare registrazione dello schermo;
[ ] mostrare data, ora e fuso del sistema;
[ ] aprire il browser e la pagina da un punto documentato;
[ ] rendere visibile la barra degli indirizzi;
[ ] registrare caricamento, scroll e apertura dei commenti;
[ ] evitare tagli o pause non documentati;
[ ] chiudere la sessione mostrando l’ora finale;
[ ] salvare il video e calcolare SHA-256.

La registrazione non sostituisce HTML, WARC o HAR, ma documenta le interazioni necessarie per ottenere la vista finale.

23. Screenshot del viewport

Lo screenshot del viewport conserva ciò che il browser mostrava in quel momento. Deve includere, quando possibile, URL, nome del profilo, data visualizzata, contesto e indicatori della piattaforma.

• acquisire schermate sovrapposte per dimostrare continuità;
• non ritagliare l’originale;
• creare eventuali evidenziazioni su copie derivate;
• registrare risoluzione e scaling;
• conservare il file nativo PNG quando prodotto dal sistema.

L’analisi del file e dei suoi limiti è trattata nel Capitolo 15.

24. Screenshot full-page e pagine lunghe

Una cattura full-page può essere generata dal browser o da un tool automatizzato. Non equivale a una singola esposizione visiva: il software scorre, ricompone o renderizza l’intero documento.

Elementi fissi possono ripetersi, contenuti lazy possono non caricarsi, video e canvas possono essere rappresentati in uno stato differente. Per questo la full-page deve essere accompagnata dalla registrazione della navigazione e dal dettaglio dello strumento.

25. Registrazione dello schermo

Il video di navigazione è particolarmente utile per contenuti dinamici, menu, commenti espandibili, storie e riproduzioni multimediali. Il file deve essere analizzato con gli stessi criteri dei video digitali: contenitore, codec, durata, frame rate e timestamp.

ffprobe -v error -show_format -show_streams -print_format json   navigazione.mp4 > navigazione_ffprobe.json
mediainfo --Output=JSON navigazione.mp4 > navigazione_mediainfo.json
sha256sum navigazione.mp4 > navigazione.mp4.sha256

Eventuali tagli tecnici dovuti a interruzioni devono essere annotati; non unire segmenti senza conservare gli originali. Vedere anche il capitolo sull’autenticità video.

26. Stampa o esportazione in PDF

La stampa PDF produce una rappresentazione documentale comoda da consultare, ma può riformattare la pagina, escludere contenuti fuori schermo, nascondere elementi interattivi e sostituire font o colori.

• annotare browser, versione e opzioni di stampa;
• includere intestazione con URL e data se appropriato;
• non usare il PDF come unico reperto;
• verificare firme, metadati e struttura del PDF prodotto;
• identificarlo come documento derivato dalla sessione.

Per l’analisi del contenitore vedere PDF, firme digitali e marche temporali.

27. Salvataggio HTML completo e MHTML

Il comando “Salva pagina” può produrre un file HTML con una cartella di risorse o un archivio MHTML. È utile soprattutto per pagine statiche, ma non garantisce la conservazione di dati caricati dinamicamente, risorse protette, video o contenuti generati dopo l’interazione.

28. HTML sorgente e DOM renderizzato

“Visualizza sorgente” mostra la risposta HTML originaria; il DOM ispezionato rappresenta invece la struttura dopo l’esecuzione di script e le modifiche del browser. In una pagina moderna i due oggetti possono differire in modo sostanziale.

Reperto A: risposta HTML ricevuta dal server
Reperto B: DOM serializzato dopo il caricamento
Reperto C: screenshot della vista renderizzata
Reperto D: richieste API e risorse correlate

La presenza di un testo nel DOM non dimostra necessariamente che fosse incluso nella risposta iniziale; potrebbe provenire da una chiamata API. Viceversa, dati nel sorgente possono non essere visibili all’utente.

29. Risorse esterne e dipendenze

Una pagina può dipendere da immagini, fogli di stile, font, script, iframe, CDN, tracker e API distribuiti su molti host. L’assenza di una risorsa può cambiare la rappresentazione durante il replay.

[ ] documento HTML principale;
[ ] CSS e font;
[ ] immagini e miniature;
[ ] script JavaScript;
[ ] iframe e contenuti incorporati;
[ ] JSON e risposte API;
[ ] file audio/video e manifest;
[ ] redirect e URL firmati;
[ ] service worker e cache rilevanti.

L’inventario delle risorse deve conservare URL, tipo MIME, stato HTTP, dimensione, hash e relazione con la pagina principale.

30. Header HTTP

Gli header documentano aspetti della transazione: stato, tipo di contenuto, cache, data del server, redirect, policy e origine. Non devono essere interpretati come dichiarazioni infallibili: alcuni campi sono configurabili o generati da proxy e CDN.

curl --location --compressed   --dump-header response_headers.txt   --output response_body.bin   --trace-time --trace-ascii curl_trace.txt   "https://www.example.com/pagina"

Evitare l’opzione --insecure: disabilitare la verifica TLS elimina un controllo importante e deve essere fatto soltanto in un test separato, motivato e chiaramente documentato.

31. HAR e pannello Network

Il formato HAR rappresenta richieste e risposte osservate dagli strumenti di sviluppo del browser. Può includere URL, metodi, status, header, timing, dimensioni e, a seconda delle opzioni, contenuti delle risposte.

Procedura indicativa in Chrome/Chromium:
1. aprire DevTools → Network;
2. attivare Preserve log se sono previsti redirect o navigazioni;
3. avviare la registrazione prima del caricamento;
4. ricaricare la pagina e compiere le sole interazioni autorizzate;
5. esportare HAR sanitizzato o con dati sensibili secondo il quesito;
6. annotare l’opzione scelta e calcolare SHA-256.

Il pannello Network non registra necessariamente tutto ciò che avviene fuori dalla sessione e può essere influenzato da cache, service worker e impostazioni del browser.

32. HAR, cookie e dati sensibili

Un HAR completo può contenere cookie, header Authorization, token, parametri personali e corpi di risposta riservati. La documentazione Chrome distingue esportazione sanitizzata ed esportazione con dati sensibili.

Se la sanitizzazione rimuove dati rilevanti per il quesito, conservare una copia integrale riservata e una copia redatta, entrambe con hash e relazione documentata.

33. Acquisizione mirata con curl

curl è utile per acquisire una specifica risorsa e conservare body, header e dati della transazione. Non esegue il JavaScript come un browser e quindi non sostituisce la cattura renderizzata.

mkdir -p curl_capture
curl --location --compressed   --dump-header curl_capture/headers.txt   --output curl_capture/body.bin   --write-out '%{json}
'   'https://www.example.com/pagina'   > curl_capture/transfer.json
sha256sum curl_capture/* > curl_capture/sha256.txt

Conservare la versione di curl: curl --version. Non inserire token o password direttamente nella riga di comando, perché potrebbero apparire nella cronologia o nell’elenco dei processi.

34. Acquisizione con GNU Wget

wget può salvare risorse e produrre archivi WARC. La ricorsione deve essere limitata al perimetro autorizzato per evitare acquisizioni eccessive.

mkdir -p wget_capture
wget   --warc-file=wget_capture/sessione_rm_016   --warc-cdx   --page-requisites   --adjust-extension   --convert-links   --no-parent   --directory-prefix=wget_capture/mirror   'https://www.example.com/pagina'   2>&1 | tee wget_capture/wget.log
sha256sum wget_capture/sessione_rm_016.warc.gz > wget_capture/sessione_rm_016.warc.gz.sha256

La copia locale con link convertiti è un derivato; il WARC conserva le transazioni raccolte. Per siti JavaScript complessi può essere necessario un browser archiving tool.

35. Il formato WARC

WARC è il formato standard utilizzato per conservare risorse web e relativi metadati. Può contenere richieste HTTP, risposte, risorse, informazioni sulla raccolta e record di rivisita. È particolarmente utile perché mantiene più oggetti in un unico flusso archivistico.

La presenza nel WARC non dimostra da sola che la pagina sia stata resa correttamente dal browser. Occorre verificare completezza e replay.

36. Verifica e indicizzazione di un WARC

Con strumenti della famiglia Webrecorder è possibile controllare la struttura e creare indici. I comandi devono essere verificati sulla versione effettivamente installata.

warcio check sessione.warc.gz
warcio index sessione.warc.gz > sessione_index.cdxj
sha256sum sessione.warc.gz sessione_index.cdxj > sessione_warc_manifest.txt

Il controllo sintattico non certifica che tutte le risorse siano state raccolte. Confrontare il replay con screenshot, HAR e inventario delle richieste.

37. Il formato WACZ

WACZ è un pacchetto ZIP strutturato che include dati WARC, indici e metadati di collezione. È progettato per consentire accesso e replay efficienti senza separare accidentalmente i componenti principali.

archive/
  data.warc.gz
indexes/
  index.cdx.gz
pages/
  pages.jsonl
datapackage.json
datapackage-digest.json  # se presente

WACZ non sostituisce il WARC: lo confeziona con indici e contesto. La specifica prevede hash delle risorse nel manifest; eventuali meccanismi di firma richiedono verifica separata e gestione della fiducia.

38. Creazione e validazione WACZ

pip install wacz
wacz create -o sessione_rm_016.wacz sessione.warc.gz --detect-pages --text
wacz validate sessione_rm_016.wacz
sha256sum sessione_rm_016.wacz > sessione_rm_016.wacz.sha256

La validazione verifica la conformità gestita dallo strumento; non prova la completezza della raccolta, l’identità dell’autore della pagina o la correttezza dell’orario di acquisizione. Registrare versione del pacchetto e output del comando.

39. Browsertrix, ArchiveWeb.page e ReplayWeb.page

Gli strumenti Webrecorder consentono acquisizione con browser, produzione di WARC/WACZ e replay locale. Browsertrix è adatto a crawling controllato; ArchiveWeb.page a catture interattive; ReplayWeb.page alla consultazione di archivi.

• definire scope, profondità e host consentiti;
• registrare configurazione del crawl e comportamento automatico;
• acquisire screenshot o testo quando previsti;
• verificare pagine principali e risorse mancanti;
• conservare log, WARC/WACZ e report di validazione.

40. Strumenti commerciali specializzati

Soluzioni come Hunchly, Page Vault e WebPreserver dichiarano funzioni di cattura, timestamp, hash, audit trail, espansione dei social e produzione di report. Possono facilitare workflow ripetibili, ma non eliminano la necessità di verificare metodo, versione, output, dipendenze dal fornitore e limiti del caso italiano.

Valutazione minima dello strumento:
[ ] modalità di acquisizione locale o remota;
[ ] dati conservati oltre alla schermata;
[ ] algoritmo di hash e firma;
[ ] gestione di account e credenziali;
[ ] esportabilità in formati aperti;
[ ] log e audit trail;
[ ] conservazione, localizzazione e cancellazione dei dati;
[ ] capacità di verifica indipendente;
[ ] documentazione della versione;
[ ] condizioni contrattuali e privacy.

Le affermazioni commerciali su “ammissibilità” o “validità” non devono essere riprodotte come conclusioni tecniche automatiche. La valutazione processuale spetta al legale e all’autorità competente.

41. API, JSON e dati strutturati

Quando una piattaforma mette a disposizione un’API autorizzata, la risposta può contenere ID, timestamp, autore dichiarato, conteggi e relazioni non visibili nell’interfaccia. Conservare richiesta, risposta, header, documentazione dell’endpoint e limiti dell’account utilizzato.

api_request.txt
api_response_headers.txt
api_response.json
api_tool_version.txt
api_scope_and_account.txt
api_response.sha256

42. Cache, service worker e modalità offline

Browser e applicazioni web possono servire risorse dalla cache o tramite service worker. Una pagina visualizzata non è necessariamente una nuova risposta dal server.

• annotare se la cache era abilitata;
• registrare gli indicatori “from disk cache” o “from ServiceWorker” nel pannello Network;
• eseguire, quando utile, una seconda acquisizione con cache disabilitata;
• non cancellare il profilo originale prima di preservarlo;
• distinguere dati remoti, cache locale e replay archivistico.

Se il contenuto era visibile soltanto offline, la prova può risiedere nel dispositivo e richiedere analisi Windows, macOS/Linux o mobile forensics.

43. JavaScript e DOM dinamico

Script lato client possono aggiungere, rimuovere o riordinare contenuti dopo il caricamento. L’ora della cattura e le interazioni diventano parte della ricostruzione.

[ ] tempo di attesa prima della cattura;
[ ] evento che ha caricato il contenuto;
[ ] pulsanti o menu utilizzati;
[ ] stato di login;
[ ] errori JavaScript;
[ ] richieste API associate;
[ ] DOM finale;
[ ] screenshot prima e dopo l’interazione.

Non modificare il DOM tramite DevTools per “mostrare meglio” un elemento. Qualsiasi elaborazione dimostrativa deve avvenire su una copia e non essere confusa con la pagina ricevuta.

44. Infinite scroll e lazy loading

Nei feed social e nei cataloghi, lo scroll genera nuove richieste e può scaricare elementi precedenti dalla memoria. Una cattura full-page non garantisce che ogni elemento sia stato caricato.

1. avviare la registrazione prima dello scroll;
2. scorrere con velocità controllata;
3. attendere il caricamento e annotare eventuali spinner;
4. catturare schermate sovrapposte;
5. registrare il numero o l’ID degli elementi acquisiti;
6. ripetere la verifica dal punto iniziale quando possibile.

L’ordine può cambiare tra due sessioni; indicarlo espressamente nella relazione.

45. WebSocket, chat live ed eventi in tempo reale

Alcune applicazioni utilizzano WebSocket o Server-Sent Events. Il contenuto può non comparire nelle normali risposte HTTP salvate e può essere disponibile soltanto durante la sessione.

La registrazione del pannello Network, il video dello schermo e gli eventuali frame esportabili dal browser devono essere coordinati. Un HAR può non rappresentare integralmente ogni messaggio, a seconda del browser e della versione.

46. Audio, video e streaming

Per un contenuto multimediale occorre conservare sia il contesto della pagina sia, quando tecnicamente e giuridicamente consentito, il file o i segmenti ricevuti dal browser. Manifest HLS/DASH, URL temporanei e segmenti possono scadere.

[ ] URL della pagina;
[ ] ID del video o della diretta;
[ ] screenshot e registrazione del player;
[ ] header e manifest di streaming accessibili;
[ ] file o segmenti ricevuti lecitamente;
[ ] ffprobe/MediaInfo;
[ ] hash;
[ ] data, ora, fuso e durata;
[ ] eventuali sottotitoli e descrizione.

Non aggirare DRM o cifrature. L’eventuale registrazione dello schermo documenta la riproduzione ma non equivale al file pubblicato. Vedere i capitoli su audio e video.

47. Acquisire un post social

[ ] piattaforma e URL permanente;
[ ] nome visualizzato e handle;
[ ] ID del post, se disponibile;
[ ] data/ora mostrata e formato relativo/assoluto;
[ ] testo completo;
[ ] media e descrizioni;
[ ] conteggi visibili;
[ ] commenti pertinenti e ordine;
[ ] stato di login;
[ ] eventuale indicazione “modificato”;
[ ] link condivisi;
[ ] pagina profilo di contesto.

Acquisire il post dalla sua pagina individuale quando disponibile, non soltanto dal feed. I conteggi di reazioni e visualizzazioni sono dinamici e devono essere descritti come valori osservati al momento della sessione.

48. Profili, handle e identificativi

Il nome visualizzato e l’handle possono cambiare. Quando la piattaforma espone un identificativo numerico o stabile, conservarlo insieme all’URL e al profilo.

L’attribuzione alla persona richiede log e dati dell’account, non soltanto la pagina pubblica.

49. Commenti, reazioni e condivisioni

Commenti e risposte possono essere compressi, ordinati per rilevanza, filtrati o caricati in blocchi. Documentare ogni comando “mostra altri”, l’ordine selezionato e il numero di elementi visibili.

Una reazione non prova che l’utente abbia letto tutto il contenuto; una condivisione può aggiungere testo autonomo; un commento può riferirsi a una versione precedente del post. Acquisire la relazione tra gli oggetti senza inferenze automatiche.

50. Storie e contenuti effimeri

Per storie, live e contenuti a scadenza la priorità è la continuità della cattura. È consigliabile una registrazione completa dall’apertura del profilo alla chiusura, con screenshot dei passaggi principali e acquisizione di eventuali risorse accessibili al browser.

[ ] ora di inizio e fine;
[ ] profilo e URL;
[ ] indicatore di avanzamento;
[ ] ordine dei segmenti;
[ ] audio attivo/disattivo;
[ ] durata osservata;
[ ] interazioni effettuate;
[ ] file prodotti e hash;
[ ] eventuale notifica o link originario.

La visualizzazione può essere registrata dalla piattaforma e notificata all’account. Il cliente deve essere informato prima dell’accesso.

51. Contenuti dietro autenticazione

L’accesso mediante account autorizzato deve essere documentato senza esporre la password. Conservare l’identificativo dell’account, il ruolo, il consenso del titolare e le differenze rispetto a una vista pubblica.

Quando il contenuto è disponibile soltanto in un portale privato, può essere opportuno chiedere al gestore una conservazione o un’esportazione nativa attraverso il legale. La cattura live resta una rappresentazione complementare.

52. Cookie, token e sessioni

Cookie e token possono spiegare perché il contenuto era visibile, ma sono dati di sicurezza ad alto rischio. Un token ancora valido può consentire accesso all’account.

• conservare soltanto ciò che è necessario;
• cifrare i reperti contenenti segreti;
• separare la copia integrale dalla copia redatta;
• documentare revoca o scadenza se effettuata dal titolare;
• non includere token nei comandi, negli screenshot o nella relazione pubblica.

53. Annunci, e-commerce e pagine di vendita

Per offerte e annunci acquisire prezzo, valuta, venditore dichiarato, ID annuncio, condizioni, disponibilità, spedizione, fotografie, recensioni, contatti e URL. Prezzo e disponibilità possono dipendere da account, localizzazione e ora.

In una possibile truffa online, correlare pagina, email, chat, IBAN, wallet, ricevute e reindirizzamenti. Evitare acquisti o contatti di prova non autorizzati.

54. Recensioni online

Una recensione deve essere acquisita insieme alla scheda dell’attività, al profilo recensore, alla data, al testo completo, alle risposte e all’ordinamento selezionato. Le piattaforme possono tradurre il testo o mostrarne versioni abbreviate.

55. RDAP e dati di registrazione del dominio

Per i domini generici, RDAP è la fonte standardizzata per i dati di registrazione pubblicamente disponibili. Conservare risposta, data di interrogazione, server autorevole e campi effettivamente visibili.

[ ] nome dominio normalizzato;
[ ] registry e registrar;
[ ] date di creazione, aggiornamento e scadenza;
[ ] status;
[ ] nameserver;
[ ] contatti pubblici o redatti;
[ ] identificativo della risposta;
[ ] data/ora dell’interrogazione;
[ ] hash dell’output.

La data di creazione del dominio non prova la data di pubblicazione della pagina. Dati protetti o oscurati non devono essere colmati con supposizioni.

56. DNS

Registrare i record DNS pertinenti al momento dell’acquisizione. I risultati possono variare per resolver, cache, geolocalizzazione e bilanciamento.

dig example.com A +noall +answer > dns_A.txt
dig example.com AAAA +noall +answer > dns_AAAA.txt
dig example.com NS +noall +answer > dns_NS.txt
dig example.com MX +noall +answer > dns_MX.txt
dig example.com TXT +noall +answer > dns_TXT.txt
sha256sum dns_*.txt > dns_manifest.txt

Un record A collega il nome a un indirizzo in quel momento; non identifica necessariamente il server originario, perché CDN e reverse proxy possono intermediare il traffico.

57. IP, CDN e hosting

L’indirizzo osservato può appartenere a una CDN, a un cloud o a un hosting condiviso. Non attribuire il sito al titolare dell’IP senza ulteriori riscontri.

58. Certificato TLS

Il certificato TLS aiuta a documentare l’identità del nome di dominio presentata durante la connessione e la catena di certificazione. Non certifica la verità del contenuto né l’identità dell’autore del post.

openssl s_client   -connect example.com:443   -servername example.com   -showcerts </dev/null   > tls_session.txt 2>&1
sha256sum tls_session.txt > tls_session.txt.sha256

Annotare eventuali errori di validazione, nome host, date del certificato e catena. Non disabilitare la verifica senza una ragione tecnica documentata.

59. Archivi web storici

Gli archivi pubblici possono mostrare versioni precedenti della pagina. Sono utili per confronto e ricerca storica, ma la copertura è incompleta e il replay può mescolare risorse acquisite in date differenti.

• acquisire URL della pagina archiviata e timestamp mostrato;
• salvare screenshot, HTML e header disponibili;
• documentare il servizio e la data di consultazione;
• verificare risorse mancanti o richieste alla rete live;
• non assumere che l’assenza di snapshot dimostri l’assenza della pagina.

60. Wayback Machine e Save Page Now

Save Page Now può creare uno snapshot di una singola pagina, ma il servizio stesso segnala che non avvia il crawl dell’intero sito e che alcune pagine o risorse possono non essere salvate. Deve quindi essere utilizzato come preservazione supplementare, non come unica acquisizione.

Registrare la pagina live, l’URL dello snapshot restituito, l’orario locale e gli hash degli output locali. Verificare subito la qualità del replay e l’eventuale assenza di immagini, video o contenuti dinamici.

61. Memento e accesso temporale alle risorse

Il framework Memento, descritto dall’RFC 7089, definisce meccanismi HTTP per accedere a stati precedenti di una risorsa mediante negoziazione temporale e TimeMap. È utile per comprendere la relazione tra URL originale, snapshot e data di archiviazione.

Un Memento rappresenta uno stato archiviato dal servizio che lo espone. Non deve essere confuso con una marca temporale crittografica sul file acquisito.

62. Servizi terzi di conservazione

Servizi come Perma.cc possono produrre link persistenti e copie archiviate. Prima di caricare contenuti occorre valutare riservatezza, copyright, dati personali, condizioni del servizio e possibilità di accesso pubblico.

Per materiale giudiziario o aziendale riservato è preferibile un’archiviazione locale o controllata. Un servizio terzo può costituire una conferma indipendente, ma introduce dipendenze operative e contrattuali.

63. Contenuto eliminato o modificato

Se la pagina non è più disponibile, ricercare fonti correlate senza concludere che non sia mai esistita: cache del dispositivo, notifiche, email, condivisioni, archivi pubblici, file scaricati, messaggi, log e dati del provider.

Un confronto tra versioni deve distinguere rimozione del testo, cambio dell’URL, modifica del media, visibilità limitata e sospensione dell’account. L’assenza corrente è un fatto osservato al momento della verifica, non una prova retroattiva.

64. Acquisizioni ripetute e monitoraggio

Per contenuti soggetti a variazione può essere utile eseguire acquisizioni a intervalli definiti. Ogni sessione deve avere propri orari, manifest e hash.

Sessione 01 — 13/07/2026 10:00 CEST
Sessione 02 — 13/07/2026 14:00 CEST
Sessione 03 — 14/07/2026 10:00 CEST

Confrontare:
- testo e media;
- status HTTP e redirect;
- ID e timestamp;
- commenti e conteggi;
- hash delle risorse;
- DNS e certificati pertinenti.

L’automazione deve rispettare il perimetro, evitare carichi eccessivi e conservare configurazione e log.

65. Acquisizione da prospettive multiple

Quando la pagina è personalizzata, una sola vista può essere insufficiente. Si possono confrontare, se autorizzato, profilo non autenticato, account del cliente, desktop, mobile e connessioni geografiche differenti.

Le viste devono essere trattate come sessioni separate; non fonderle in una rappresentazione unica.

66. Differenze tra mobile e desktop

La versione mobile può utilizzare URL, DOM, media e funzionalità differenti. L’emulazione nel browser è utile per il confronto, ma non sostituisce l’acquisizione da un dispositivo reale quando il quesito riguarda un’app o un comportamento mobile.

Per correlare la pagina con un telefono possono essere necessari Android o iPhone/iPad, inclusi cronologia, cache, app, download e notifiche.

67. Personalizzazione, ranking e test A/B

Feed, risultati e prezzi possono essere ordinati da sistemi algoritmici. Due utenti non necessariamente vedono gli stessi elementi nello stesso ordine.

Registrare account, cookie, lingua, user agent, IP, query, filtri e ordine selezionato. Evitare di descrivere il risultato come “la pagina” in senso assoluto quando è chiaramente personalizzato.

68. Manifest di acquisizione

Il manifest è il documento tecnico che collega ambiente, operazioni e file. Può essere in formato testuale, CSV o JSON.

{
  "case_id": "RM-2026-WEB-016",
  "session_start": "2026-07-13T10:00:00+02:00",
  "session_end": "2026-07-13T10:42:18+02:00",
  "timezone": "Europe/Rome",
  "operator": "Dott. Marcello Quaranta",
  "browser": "[nome e versione]",
  "os": "[sistema e build]",
  "network": "[descrizione]",
  "account": "A-01 autorizzato",
  "start_url": "https://www.example.com/post/123",
  "tools": ["[strumento/versione]"],
  "notes": "commenti espansi; nessuna pubblicazione"
}

Il manifest non deve contenere password, token o dati non necessari. Calcolarne l’hash dopo la chiusura della sessione.

69. Hash e riferimento temporale esterno

Dopo aver chiuso il dataset si può applicare un riferimento temporale esterno al manifest o al suo hash, ad esempio mediante un servizio di marcatura conforme alla procedura scelta. L’RFC 3161 descrive il protocollo tra client e Time-Stamping Authority.

openssl ts -query   -data manifest_sha256.txt   -sha256 -cert   -out manifest.tsq

# Dopo aver ottenuto una risposta dalla TSA autorizzata:
openssl ts -verify   -data manifest_sha256.txt   -in manifest.tsr   -CAfile tsa_chain.pem

La marca riguarda il dato sottoposto a hash e il momento attestato dal servizio; non certifica la veridicità del contenuto web rappresentato. Vedere il capitolo su firme e marche temporali.

70. Pagine di phishing, malware e contenuti rischiosi

URL sospetti possono distribuire malware, tracciare il visitatore o tentare di sottrarre credenziali. Utilizzare ambiente isolato, rete controllata, account non privilegiati e strumenti di sicurezza; evitare la workstation dell’ufficio e i dispositivi del cliente.

[ ] macchina virtuale sacrificabile;
[ ] snapshot prima dell’accesso;
[ ] nessuna credenziale reale;
[ ] condivisioni host disabilitate;
[ ] rete e DNS controllati;
[ ] registrazione traffico autorizzata;
[ ] download in quarantena;
[ ] hash senza esecuzione;
[ ] ripristino o distruzione dell’ambiente.

71. Correlazione con browser e dispositivo

La presenza di una pagina nella cronologia, nella cache o nei download può confermare l’accesso da un determinato sistema. Richiede tuttavia una corretta copia forense e analisi degli artefatti.

• cronologia URL e timestamp;
• cache e service worker;
• cookie e storage locale;
• download e file temporanei;
• sessioni e schede ripristinate;
• notifiche e database delle applicazioni;
• log DNS, firewall o proxy aziendali.

La cronologia prova normalmente che il profilo ha registrato un accesso o una navigazione, non chi fosse fisicamente alla tastiera.

72. Correlazione con account, cloud e provider

Dati esportati dall’account o forniti dal provider possono integrare la cattura live: ID, date, stato di pubblicazione, login, indirizzi IP e versioni. L’acquisizione deve seguire canali leciti e documentati.

Vedere cloud forensics, email e header e PEC per le fonti di conferma esterne alla pagina.

73. Limiti dell’attribuzione

L’acquisizione può dimostrare che un contenuto era disponibile a un determinato URL durante la sessione e può documentare gli identificativi dichiarati. L’attribuzione alla persona fisica richiede elementi che colleghino account, dispositivi e condotta.

Account compromessi, collaboratori, agenzie, dispositivi condivisi, automazioni e deleghe sono ipotesi alternative da valutare. Evitare conclusioni soggettive quando il materiale disponibile riguarda soltanto la pagina pubblica.

74. Caso pratico 1 — Post diffamatorio acquisito a Roma

Un avvocato di Roma segnala un post pubblico che contiene affermazioni contestate e teme la cancellazione. Lo Studio Quaranta avvia una sessione documentata, registra orologio e URL, acquisisce video continuo, screenshot sovrapposti, pagina individuale del post, profilo, commenti pertinenti, HAR sanitizzato e WACZ.

Il post viene eliminato il giorno successivo. La relazione non afferma chi abbia materialmente pubblicato il contenuto, ma documenta che durante l’acquisizione esso era accessibile dal profilo e dall’URL indicati, con i dati e i limiti descritti.

75. Caso pratico 2 — Sito di vendita sospetto

Un cliente romano riferisce di avere effettuato un bonifico dopo aver visitato un sito di e-commerce. La pagina è ancora attiva. Vengono conservati annuncio, condizioni, contatti, prezzo, URL, redirect, certificato TLS, RDAP, DNS, file ricevuti, email e chat.

L’IP risulta appartenere a una CDN e non viene attribuito al venditore. La convergenza tra IBAN, email, dominio, messaggi e cronologia viene ricostruita nel capitolo sulle truffe online.

76. Caso pratico 3 — Storia social a scadenza

Una professionista di Roma segnala una storia che utilizza senza consenso una sua immagine. Poiché il contenuto è effimero, si avvia immediatamente una registrazione continua dal profilo alla storia, con screenshot dei singoli segmenti, orari, account, ID visibili e file multimediali ricevuti dal browser quando accessibili.

La relazione precisa che la visualizzazione può essere stata registrata dalla piattaforma e che l’assenza successiva non consente di stabilire se la storia sia scaduta, eliminata o resa non visibile all’account.

77. Caso pratico 4 — Condizioni contrattuali modificate

Un’azienda romana contesta che le condizioni pubblicate sul sito del fornitore siano cambiate dopo l’ordine. Sono disponibili PDF salvati, email e uno snapshot storico. Il perito acquisisce la versione corrente, conserva lo snapshot con il relativo timestamp archivistico e confronta HTML, testo e documenti.

La conclusione descrive le differenze osservate e le date delle fonti, senza affermare che lo snapshot pubblico rappresenti necessariamente ogni risorsa esistente nel giorno indicato.

78. Caso pratico 5 — Portale privato autorizzato

Un’impresa di Roma deve documentare una comunicazione disponibile nel proprio portale cliente. L’accesso avviene con account aziendale autorizzato. Le credenziali non vengono registrate; si conservano ruolo dell’account, video, screenshot, PDF, HAR integrale cifrato e copia sanitizzata.

Viene richiesto al provider, tramite il legale, un export nativo e i log pertinenti. La cattura live documenta la vista dell’utente; l’export costituisce fonte complementare più vicina al sistema remoto.

79. Caso pratico 6 — Diretta video

Durante una diretta viene pronunciata una frase rilevante per una controversia a Roma. La registrazione dello schermo parte a evento già iniziato. Il perito conserva l’intervallo effettivamente osservato, la pagina, l’orario, il profilo e i dati tecnici del video.

La relazione dichiara che la parte iniziale non è stata acquisita e che il file è una registrazione della riproduzione, non il flusso nativo integrale. Non vengono ricostruiti passaggi mancanti per inferenza.

80. Procedura operativa completa

80.1 Preparazione

[ ] incarico e quesito;
[ ] perimetro URL/account;
[ ] priorità e volatilità;
[ ] ambiente e rete;
[ ] orologio e fuso;
[ ] strumenti/versioni;
[ ] spazio e cartella caso.

80.2 Acquisizione

[ ] video continuo;
[ ] screenshot viewport;
[ ] full-page;
[ ] URL e redirect;
[ ] HTML/DOM/PDF;
[ ] header/HAR;
[ ] WARC/WACZ;
[ ] media autorizzati;
[ ] DNS/RDAP/TLS.

80.3 Conservazione

[ ] SHA-256 dei singoli file;
[ ] manifest della sessione;
[ ] validazione WARC/WACZ;
[ ] copia di lavoro;
[ ] copia riservata e redatta;
[ ] eventuale riferimento temporale;
[ ] backup controllato.

80.4 Analisi

[ ] completezza della cattura;
[ ] risorse mancanti;
[ ] timestamp e fusi;
[ ] ID e account;
[ ] confronto tra sessioni;
[ ] correlazioni con dispositivo/provider;
[ ] ipotesi alternative;
[ ] limiti.

81. Errori da evitare

Errore 1 — Usare soltanto uno screenshot

Non conserva struttura, richieste e contesto tecnico.

Errore 2 — Nascondere la barra degli indirizzi

Si perde il collegamento visibile con l’URL.

Errore 3 — Ritagliare o annotare l’originale

Si altera il reperto e si rimuove contesto.

Errore 4 — Non registrare l’orario

Diventa difficile correlare fonti dinamiche.

Errore 5 — Confondere ora del server e ora locale

Sono campi differenti e possono divergere.

Errore 6 — Ignorare account e personalizzazione

La pagina potrebbe non essere uguale per altri utenti.

Errore 7 — Salvare solo il PDF

Il rendering di stampa può omettere contenuti.

Errore 8 — Considerare il WARC automaticamente completo

Il crawler può non avere acquisito risorse dinamiche.

Errore 9 — Esporre cookie e token

Si compromettono account e riservatezza.

Errore 10 — Usare credenziali non autorizzate

L’accesso deve rientrare nel titolo disponibile.

Errore 11 — Aggirare DRM o paywall

La procedura non autorizza elusioni tecniche.

Errore 12 — Attribuire il contenuto dal nome del profilo

L’identità richiede riscontri ulteriori.

Errore 13 — Attribuire il sito dall’IP

CDN e hosting condiviso rendono l’inferenza debole.

Errore 14 — Trattare RDAP come prova dell’autore

La registrazione del dominio non identifica il redattore.

Errore 15 — Considerare l’assenza in Wayback come prova

La copertura degli archivi è incompleta.

Errore 16 — Non verificare il replay

Un archivio può essere formalmente valido ma visivamente incompleto.

Errore 17 — Caricare materiale riservato su servizi pubblici

Si possono violare riservatezza e minimizzazione.

Errore 18 — Non conservare i log dello strumento

La procedura diventa meno auditabile.

Errore 19 — Unire video o sessioni senza dichiararlo

Si perde la distinzione tra reperti originali e derivati.

Errore 20 — Omettere i limiti

Le conclusioni devono essere proporzionate al materiale disponibile.

82. Checklist operativa finale

Autorizzazione

[ ] committente e quesito;
[ ] contenuto pubblico o account autorizzato;
[ ] interazioni consentite;
[ ] dati sensibili;
[ ] urgenza e volatilità.

Ambiente

[ ] OS/build;
[ ] browser/versione;
[ ] profilo/estensioni;
[ ] orologio/fuso/NTP;
[ ] rete/IP/DNS;
[ ] viewport e lingua.

Cattura

[ ] URL e redirect;
[ ] video;
[ ] screenshot;
[ ] HTML/DOM/PDF;
[ ] header/HAR;
[ ] WARC/WACZ;
[ ] media e API autorizzati;
[ ] DNS/RDAP/TLS.

Integrità

[ ] SHA-256;
[ ] manifest;
[ ] validazione;
[ ] copie di lavoro;
[ ] cifratura dati sensibili;
[ ] riferimento temporale;
[ ] backup.

Relazione

[ ] metodo e strumenti;
[ ] risultati osservati;
[ ] correlazioni;
[ ] versioni e differenze;
[ ] ipotesi alternative;
[ ] limiti;
[ ] allegati e hash.

83. Output minimo

1. incarico e verbale della sessione;
2. documentazione di sistema, browser, orologio e rete;
3. inventario completo degli URL;
4. video di navigazione e hash;
5. screenshot originali e hash;
6. HTML, DOM o MHTML quando prodotti;
7. PDF derivato, se utile;
8. header HTTP e dati dei redirect;
9. HAR sanitizzato e, se necessario, copia integrale cifrata;
10. WARC/WACZ e report di validazione;
11. media acquisiti lecitamente e relativi report;
12. DNS, RDAP e certificato TLS pertinenti;
13. manifest SHA-256 dell’intera raccolta;
14. eventuale token di marcatura temporale;
15. confronto tra sessioni o versioni;
16. relazione tecnica e hash degli allegati.

84. Struttura della relazione tecnica

84.1 Incarico e quesito

Indicare oggetto, committente, titolo autorizzativo, finalità e limiti.

84.2 Ambiente

Descrivere hardware, sistema, browser, account, rete, fuso, sincronizzazione e strumenti.

84.3 Fonti e URL

Elencare URL, profili, ID, link originari e canali attraverso cui sono stati ricevuti.

84.4 Metodo

Spiegare ordine delle operazioni, interazioni, formati, hash, WARC/WACZ e controlli.

84.5 Risultati

Separare contenuto visivo, dati di rete, risorse, infrastruttura e correlazioni.

84.6 Valutazione

Indicare compatibilità, divergenze, fonti indipendenti e ipotesi alternative.

84.7 Limiti

Dichiarare volatilità, risorse mancanti, account non disponibili, personalizzazione e impossibilità di attribuzione.

84.8 Conclusioni

Rispondere al quesito tecnico con formule proporzionate, senza sostituire la valutazione giuridica.

85. Modelli di frasi tecniche

85.1 Presenza del contenuto

85.2 Screenshot limitato

85.3 Archivio incompleto

85.4 Data visualizzata

85.5 Attribuzione

85.6 Dominio

85.7 Snapshot storico

85.8 Contenuto non più disponibile

85.9 Conclusione limitata

86. Immagini e figure suggerite

87. Riferimenti tecnici esterni

1. SWGDE — Best Practices for Acquiring Online Content, 21-F-001-1.1.
2. IIPC — WARC Format 1.1.
3. IIPC — WARC Implementation Guidelines.
4. Webrecorder — WACZ 1.1.1 Specification.
5. Webrecorder — py-wacz.
6. ReplayWeb.page — User Guide.
7. Browsertrix Crawler — Common Options.
8. Chrome DevTools — Network features and HAR export.
9. GNU Wget Manual.
10. curl Manual.
11. IETF RFC 7089 — Memento.
12. RFC 3161 — Time-Stamp Protocol.
13. Internet Archive — Save Pages in the Wayback Machine.
14. ICANN — Registration Data Access Protocol.
15. ICANN Lookup.
16. Hunchly — documentazione del prodotto.
17. Page Vault — documentazione del prodotto.
18. WebPreserver — documentazione del prodotto.

88. Collegamenti interni consigliati

Capitoli precedenti

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp
• Telegram, Signal e app di messaggistica
• Analisi forense di email e header
• Metadati e provenienza dei file
• Verifica forense di screenshot e schermate

Capitolo successivo

• Diffamazione online, cyberbullismo, stalking digitale e revenge porn

Capitoli correlati successivi

• Accessi abusivi ad account email, social e cloud
• Truffe online e financial cybercrime
• Analisi di log aziendali, firewall, VPN e cloud
• Cloud forensics
• Autenticità video
• Immagini manipolate e contenuti generati con AI
• Timeline forense
• Relazione tecnica e CTP informatico

Pagine servizio

• Perizia informatica forense a Roma
• Verifica screenshot, pagine web e social
• Analisi smartphone e computer
• Analisi email, PEC e documenti digitali
• Consulente tecnico di parte informatico a Roma
• Contatti

Anchor text consigliati

acquisizione forense di pagine web a Roma
conservazione di un post social
acquisizione tecnica di contenuti online
verifica URL e reindirizzamenti
archivio WARC e WACZ
acquisizione HAR e header HTTP
conservazione di una storia social
perizia su contenuti web cancellati
verifica tecnica di un sito internet
consulente informatico forense Roma

89. Box commerciale finale

Devi conservare una pagina web o un contenuto social a Roma?

Una valutazione preliminare è utile quando devi documentare:

[ ] un post, commento o profilo che potrebbe essere eliminato;
[ ] una storia, live o contenuto temporaneo;
[ ] un annuncio o una pagina di vendita sospetta;
[ ] condizioni contrattuali pubblicate online;
[ ] una recensione o risposta contestata;
[ ] un video o un file incorporato in una pagina;
[ ] un URL, redirect o dominio collegato a una truffa;
[ ] differenze tra versioni della stessa pagina;
[ ] contenuti visibili soltanto con account autorizzato;
[ ] dati da correlare con dispositivo, email, cloud o log.

Conserva il link completo, evita interazioni non necessarie e non limitarti a un ritaglio. Se il contenuto è effimero, esegui una prima registrazione continua e richiedi rapidamente una valutazione tecnica.

Lo Studio Quaranta Digital Forensics a Roma può svolgere acquisizione documentata, conservazione di pagine e social, analisi URL, HTML, HAR, WARC/WACZ, media, DNS, RDAP, TLS, confronto tra versioni, timeline e relazione tecnica.

90. Conclusione del capitolo

Il web è una fonte remota, dinamica e personalizzata. Una singola schermata può essere immediata, ma raramente conserva tutti gli elementi necessari a spiegare come il contenuto sia stato raggiunto, caricato e visualizzato.

Una corretta acquisizione combina rappresentazioni differenti: video e screenshot per il contesto visivo; HTML, DOM e risorse per la struttura; HAR e header per le transazioni; WARC o WACZ per l’archiviazione; hash e manifest per l’integrità; dati di account, dispositivi e provider per la correlazione.

La relazione deve distinguere:
- ciò che era visibile;
- ciò che il browser ha ricevuto;
- ciò che l’archivio ha conservato;
- ciò che è stato verificato tramite fonti indipendenti;
- ciò che può essere soltanto ipotizzato;
- ciò che non è stato possibile acquisire.

Il capitolo successivo applicherà queste procedure a situazioni particolarmente delicate, nelle quali rapidità, riservatezza e tutela delle persone assumono importanza centrale:

Capitolo 17 — Diffamazione online, cyberbullismo, stalking digitale e revenge porn

Saranno trattati triage, conservazione di post e messaggi, profili, immagini, video, contenuti effimeri, rischi di ulteriore diffusione, tutela dei minori, coordinamento con il legale, attribuzione prudente e costruzione della timeline.

Continua con il Capitolo 17 — Diffamazione online, cyberbullismo, stalking digitale e revenge porn →