Link effimeri 2026: sono davvero sicuri? 4 implementazioni a confronto
Equivoco diffuso: "autodistruzione" non è sinonimo di "sicurezza"
I link a lettura singola (burn-after-read) sono diventati una specie di feticcio negli ultimi anni. Dalle password condivise via chat al file sensibile mandato al commercialista, molti italiani considerano "link monouso" e "comunicazione sicura" sinonimi.
Diciamocelo: non lo sono. Le implementazioni differiscono enormemente tra servizi, e alcune — tecnicamente parlando — non garantiscono affatto la distruzione effettiva dei dati. Vediamo le tre architetture principali, i punti deboli di ciascuna, e come i professionisti italiani dovrebbero valutarle prima di fidarsi.
Le tre architetture dei link usa-e-getta
Architettura 1: server-side deletion (token-based)
La più diffusa e la meno sicura:
- L'utente carica il contenuto, il server memorizza in chiaro e genera un token univoco (UUID o random string).
- Il server restituisce un link tipo
https://example.com/view/abc123. - Il primo visitatore apre il link, il server fornisce il contenuto e marca il token come "usato".
- I visitatori successivi ricevono "link scaduto".
Analisi di sicurezza:
Il problema radicale: il server ha il contenuto in chiaro. Prima della "distruzione" possono accedervi:
- Amministratori del server
- DBA
- Qualsiasi attaccante con accesso infrastrutturale
- Sistemi di backup (i backup spesso contengono ancora i dati "cancellati")
- Richieste di autorità giudiziaria o amministrativa (in Italia, art. 132 Codice Privacy per dati di traffico)
Occhio a un dettaglio tecnico: la "cancellazione" nei sistemi moderni è spesso solo un flag. I dati restano sui settori disco fino a sovrascrittura fisica. TRIM sugli SSD e remanenza magnetica sono vie note di recovery.
Architettura 2: client-side encryption (Zero-Knowledge)
La più sicura. Rappresentata da PrivNote e, storicamente, Firefox Send (chiuso).
- Utente inserisce contenuto in browser.
- Il browser genera chiave AES-256 casuale.
- Cifra il contenuto localmente.
- Carica solo il ciphertext sul server.
- Il server memorizza ciphertext, non vede la chiave.
- La chiave è nel URL fragment (parte dopo
#).
Esempio: https://example.com/view/abc123#chiave-qui
Dettaglio crittografico cruciale: il fragment URL (dopo #) NON viene trasmesso al server. Il server vede solo ciphertext, mai la chiave. È l'architettura Zero-Knowledge.
Il destinatario apre il link:
- Browser scarica ciphertext dal server.
- Estrae chiave dal fragment URL.
- Decifra localmente.
- Server cancella ciphertext.
Analisi di sicurezza:
Anche con server compromesso, l'attaccante ottiene solo ciphertext indecifrabile. Ma residuano minacce:
- Estensioni browser malevole: possono leggere URL completo inclusi fragment.
- Cronologia browser: URL completo (con chiave) salvato in locale.
- Referrer header: alcune versioni browser inoltravano fragment in referrer (i browser moderni hanno mitigato).
- Supply chain attack: JS server-side compromesso può esfiltrare la chiave prima della cifratura.
Architettura 3: ibrida
Combina server-side control e client-side encryption:
- Cifratura client-side (come Architettura 2).
- Controllo accessi server (token monouso + password + scadenza).
- Autenticazione multi-fattore (password per accedere al ciphertext).
- Server cancella ciphertext dopo accesso, logga audit (senza contenuto).
Miglior bilanciamento tra sicurezza e usabilità.
Threat model: cosa i link monouso NON possono fermare
Indipendentemente dall'architettura, alcune minacce restano irriducibili.
Screenshot e screen recording
Il limite fondamentale. Renderizzato sullo schermo del destinatario, nessuna protezione software può impedire screenshot, foto con telefono, registrazione video. Alcuni servizi disabilitano tasto destro o scorciatoie di cattura: misure banalmente aggirabili, efficaci solo contro utenti tecnicamente ingenui.
CDN e proxy caching
Se il contenuto passa per una CDN, i nodi edge possono aver copia in cache. Anche dopo cancellazione server origine, la cache sopravvive fino al TTL. Molti servizi ignorano questa falla.
Corretto: impostare Cache-Control: no-store, no-cache, must-revalidate e CDN-Cache-Control: no-store.
Browser cache
Il browser può cachare il contenuto decrittato su disco locale. Le immagini sono particolarmente vulnerabili — la cache immagini è separata dal controllo cache pagina.
Man-in-the-middle (MITM)
Con pure token (Architettura 1) e senza HTTPS, qualsiasi MITM (ISP, firewall aziendale, WiFi pubblico compromesso) vede contenuto in chiaro.
In ambiente aziendale italiano, attenzione speciale: SSL Inspection (usato in molte aziende strutturate e in alcune PA) decifra e logga traffico HTTPS. La client-side encryption (Arch. 2) difende perché c'è un secondo layer oltre TLS.
Log server-side
Contenuto cancellato, ma log ancora presenti: URL acceduto, IP, timestamp, User-Agent. In Architettura 1, questi log correlano "chi ha acceduto cosa, quando, da dove". Per GDPR la retention di questi log è regolata (tipicamente max 6-12 mesi per log di sicurezza).
Confronto servizi burn-after-read
Dati pubblici da documentazione tecnica e codice sorgente, marzo 2026:
| Servizio | Cifratura | Open Source | Chiave | Server può leggere? | Password | Tipo contenuto |
|---|---|---|---|---|---|---|
| PrivNote | Client AES | No | URL fragment | No (zero-knowledge) | No | Testo |
| 1ty.me | Server | No | Server | Sì | Opzionale | Testo |
| Snappass (Pinterest) | Server AES | Sì | URL path | Sì | Opzionale | Testo |
| hat.sh | Client XChaCha20 | Sì | URL fragment | No | No | File |
| OnionShare | Client + Tor | Sì | Locale | No | Opzionale | File |
| Yopass | Client OpenPGP | Sì | URL fragment | No | No | Testo + file |
| PrivateBin | Client AES | Sì | URL fragment | No | Opzionale | Testo |
Nota importante: open source è un segnale critico di sicurezza. Servizi proprietari possono dichiarare client-side encryption ma non sono verificabili. L'open source permette audit indipendenti.
Uso corretto in contesto italiano
Quando un link monouso ha senso
- Invio one-time password o credenziali di accesso.
- Condivisione informazioni sensibili a valore temporale limitato (codice di sicurezza, link di reset).
- Comunicazione che non deve restare in cronologia chat.
Quando NON basta
- Informazioni aziendali strategiche (M&A, dati finanziari) → usa E2E encryption vera (Signal, PGP).
- Situazioni che richiedono non-ripudio legale → una volta distrutto, non puoi provare nulla.
- Dati classificati o di sicurezza nazionale → trasporto offline obbligatorio.
Best practice consigliate
- Preferisci servizi client-side encryption: server non deve poter leggere i tuoi dati.
- Preferisci open source: verifica delle dichiarazioni di sicurezza.
- Aggiungi password: link intercettato resta inutilizzabile senza password.
- Canali separati per link e password: link via email, password via Signal/Telegram. Se un canale è compromesso, il contenuto resta protetto.
- Non in reti aziendali per dati ultra-sensibili: SSL Inspection può decifrare TLS.
Contesto italiano: PEC, SPID, e burn-after-read
L'Italia ha infrastrutture digitali specifiche che vale la pena citare.
PEC (Posta Elettronica Certificata): equivalente legale di raccomandata con ricevuta di ritorno. Non è burn-after-read — i messaggi restano archiviati con valore legale. Per contenuti dove serve prova di invio/ricezione, PEC è lo standard.
SPID e CIE: per autenticazione robusta verso Pubblica Amministrazione. Se un documento richiede autenticazione SPID, non passarlo via link monouso — è già tutelato da sistema identità digitale.
Fatturazione elettronica SdI: le fatture B2B/B2G italiane passano da Sistema di Interscambio. Non c'è nulla di "burn-after-read" qui — la retention è decennale per legge.
Per condivisione informale di secret (password amministrative, credenziali di test, contenuti sensibili a basso profilo legale), il burn-after-read in modalità client-side è appropriato. Per qualsiasi contesto che richieda valore probatorio, no.
lpic.cc e il modello di password protection
Per condivisione immagini, lpic.cc offre password protection — chi ha il link vede l'immagine solo se inserisce la password corretta.
Precisazione onesta: la password protection di lpic.cc è controllo d'accesso server-side (analogo all'Architettura 1), non Zero-Knowledge client-side encryption. In pratica:
- Il server lpic.cc ha ancora i dati immagine in chiaro.
- La password funziona da controllo accessi, non da crittografia end-to-end.
- Adatto per esigenze di privacy quotidiana ("non voglio che chiunque col link veda").
- Non adatto per scenari che richiedono garanzie crittografiche (whistleblowing, dati medicali, documenti legali sensibili).
Se hai bisogno di sicurezza quotidiana — condividere screenshot con famiglia, foto di progetto con cliente ma non volerli pubblici — la password protection di lpic.cc è comoda e pratica. Per livelli militari, strumenti E2E dedicati (Signal, hat.sh, Tresorit).
FAQ
Un link burn-after-read "aperto" è davvero irrecuperabile?
Dipende dall'architettura. Server-side deletion: i dati possono sopravvivere in backup, cache CDN, settori disco non sovrascritti. Client-side encryption: se la chiave è distrutta (URL sparito da ogni posto), il ciphertext è crittograficamente irrecuperabile. Ma il contenuto già renderizzato sullo schermo del destinatario è fuori controllo.
La modalità incognito aumenta la sicurezza dei link monouso?
In parte sì. Niente cronologia, cookie, cache locale — la URL con chiave non resta sul PC. Ma non protegge da monitoraggio di rete (ISP, firewall) né da screenshot.
Il countdown "il link si autodistrugge in 30 secondi" è utile?
Limitato. Il countdown è puro JavaScript client-side — chiunque con DevTools ferma il timer. Valore principale: psicologico, segnala "è contenuto sensibile". Valore tecnico: basso.
I link monouso prevengono l'inoltro?
No. Il destinatario può inoltrare il link prima di aprirlo, il terzo lo apre al posto suo. La password abbassa il rischio (va inoltrata anche la password), ma non può impedire che il destinatario originale screenshot-i e inoltri.
In ambiente aziendale italiano è sicuro usare burn-after-read per credenziali?
Molto meglio che plaintext in email, ma attenzione all'SSL Inspection. Aziende bancarie, sanitarie e grandi PA italiane spesso ispezionano TLS. In questi contesti, preferire servizi client-side encryption open source (Yopass, hat.sh, PrivateBin). Per password di sistema critiche, le password manager enterprise (Bitwarden, 1Password Business) con condivisione interna sono più appropriate.
Cosa dice il GDPR su burn-after-read e retention?
Il GDPR chiede data minimization e storage limitation (art. 5). Burn-after-read è tecnicamente aligned con questi principi. Ma attenzione: i log di accesso (anche per servizi burn-after-read) contengono dati personali (IP, timestamp) e devono avere retention definita e base giuridica. Per uso aziendale, il servizio dovrebbe fornire DPA (Data Processing Agreement) trasparente.
WhatsApp ha funzione "messaggio temporaneo". È equivalente?
Diversa. I messaggi temporanei WhatsApp durano 24h/7gg/90gg e sono E2E encrypted (WhatsApp non ha la chiave). Ma Meta ha i metadati (chi, quando, con chi). Per leak di contenuto: protetto. Per analisi pattern di comunicazione: no. Per massima privacy, Signal con messaggi che scadono resta lo standard.