Vai al contenuto
creapassword.com

Come funziona

Dove va ogni cosa, passo per passo

Due funzioni indipendenti, con due modelli diversi. Il generatore non parla con la rete. La condivisione ci parla, ma le manda solo ciò che non serve a leggere il contenuto.

Il generatore: nessuna richiesta, nessun server

Quando premi Rigenera succede questo, e solo questo:

  1. Il browser chiede alla propria sorgente crittografica un numero casuale (crypto.getRandomValues).
  2. Il numero viene ridotto a un indice dell’alfabeto scelto, scartando i valori che renderebbero alcuni caratteri più probabili di altri invece di piegarli con un resto.
  3. Il carattere viene aggiunto alla sequenza. Si ripete fino alla lunghezza richiesta.

Non c’è un passo quattro. La sequenza esiste in una variabile e nel documento, e sparisce quando chiudi la pagina. Nel codice del generatore non compare fetch, non compare XMLHttpRequest, non compare sendBeacon: puoi verificarlo aprendo il pannello di rete del browser e rigenerando quante volte vuoi.

La condivisione: chi tiene la chiave

Quando crei un segreto, l’ordine delle operazioni è la cosa che conta.

Perché la parte dopo il cancelletto non arriva a noi

In un indirizzo web, tutto ciò che segue il carattere # si chiama frammento. Serve al browser per posizionarsi dentro la pagina, e per come è definito il protocollo non viene incluso nella richiesta HTTP: non compare nella riga di richiesta, non compare nell’intestazione Referer, non compare nei log di nessun server o proxy sul percorso.

Non è una nostra promessa: è il modo in cui i browser sono fatti, ed è verificabile con qualunque strumento di analisi di rete. Noi ci limitiamo a metterci la chiave e a non copiarla altrove.

Quando qualcuno apre il collegamento

  1. Il browser chiede la pagina /s/<id>. Al server arriva l’identificativo, non la chiave. Questa richiesta non consuma il segreto.
  2. La pagina mostra un bottone e un avviso. Finora non è successo nulla di irreversibile: un’anteprima automatica o un crawler si fermano qui.
  3. Al clic, il browser chiede il contenuto cifrato. Il server incrementa il contatore delle letture e restituisce la busta nella stessa operazione: due richieste simultanee non possono ottenere entrambe l’ultima lettura disponibile.
  4. Il browser legge la chiave dal frammento, decifra e mostra il testo. Se il contatore era esaurito, la riga viene cancellata subito.

Perché scriviamo «end-to-end»

È l’unica affermazione di questo sito che non puoi verificare da solo in due minuti, quindi è l’unica che non ci permettiamo di fare a occhio. La parola non è comparsa da nessuna parte finché non è esistita una prova che gira da sola, a ogni collaudo:

  • un browser vero apre il sito, crea un segreto e lo riapre, mentre ogni richiesta uscente viene intercettata e ispezionata — indirizzo, intestazioni e corpo. Se il testo in chiaro o la chiave comparissero in una qualsiasi di esse, il collaudo fallisce;
  • subito dopo, la stessa prova apre il file del database e ci cerca dentro il testo in chiaro, byte per byte;
  • una terza prova verifica che nessun indirizzo di richiesta contenga un frammento e che nessun Referer venga inviato.

E c’è un passaggio in più, che consideriamo il vero: queste prove vengono falsificate. Una copia del codice viene rotta apposta — la pagina di condivisione allega la chiave alla richiesta — e si verifica che il collaudo se ne accorga. Un collaudo verde che non sa distinguere il codice giusto da quello rotto non sta misurando nulla.

Che cosa succede se perdi il collegamento

Niente di recuperabile. Non esiste un elenco dei tuoi segreti, non esiste un account a cui siano associati, non esiste una funzione «rimandami il link». Il server non sa chi ha creato che cosa, e senza la chiave non potrebbe leggere il contenuto nemmeno volendo.

È un requisito, non una lacuna: un servizio capace di recuperare un segreto per te è un servizio capace di leggerlo.