Generatore di UUID

Un UUID versione 4 è quasi tutto casualità, quindi la sola cosa che conta davvero è la sorgente. Qui è `crypto.getRandomValues`, il generatore crittografico del browser, che attinge all’entropia del sistema operativo. `Math.random()` non è quello: è veloce, è deterministico a partire da uno stato interno e non è pensato per resistere a nessuno.

La differenza è invisibile guardando il risultato, ed è precisamente questo il problema. Un UUID prodotto male ha lo stesso aspetto, supera qualunque validazione di forma e funziona per anni, finché non arriva qualcuno che, avendone visti abbastanza, riesce a prevedere il successivo. È un difetto che non si scopre osservando, solo leggendo il codice.

Un UUID sono 128 bit, ma nella versione 4 sei sono fissi: quattro dichiarano la versione e due la variante. Restano 122 bit casuali, che sono comunque un numero difficile da rendere intuitivo.

La formulazione più onesta è quella per confronto: generando un miliardo di UUID al secondo per circa ottantacinque anni si arriverebbe a una probabilità del cinquanta per cento di aver prodotto una sola coppia ripetuta. Nella pratica di qualunque applicazione, la collisione non è il rischio da valutare — lo è la qualità del generatore, che è la ragione della sezione precedente.

Stanno in due posizioni fisse. La versione è la prima cifra del terzo gruppo: in un UUID versione 4 quel gruppo comincia sempre con `4`. La variante è la prima cifra del quarto gruppo e in quella standard vale `8`, `9`, `a` o `b`.

Da qui si legge una cosa utile a colpo d’occhio: un identificatore il cui terzo gruppo comincia con `1` porta con sé un timestamp e un indirizzo di rete, e uno che comincia con `7` è ordinato nel tempo. Sono due informazioni che cambiano il modo in cui quell’identificatore va trattato, e si vedono senza strumenti.

La versione 1 costruisce l’identificatore con l’ora corrente e l’indirizzo MAC della scheda di rete. È una scelta ragionevole per garantire l’unicità e una pessima scelta per tutto il resto: quell’identificatore dice quando è stato creato e su quale macchina.

Non è una preoccupazione ipotetica. Nel 1999 l’autore del virus Melissa fu individuato anche grazie all’identificatore incorporato in un documento Word, che conteneva l’indirizzo MAC del computer che l’aveva scritto. Se un UUID finisce in una URL, in un file esportato o in una risposta di API, la versione 4 non racconta niente e la versione 1 racconta due cose di troppo.

La versione 7, standardizzata nel 2024 dalla RFC 9562, mette un timestamp in millisecondi nei bit più significativi e riempie il resto di casualità. Il risultato è ordinabile nel tempo pur restando imprevedibile nella parte che identifica.

Il motivo per cui interessa è l’indice. Le chiavi casuali si inseriscono in punti sparsi di un indice B-tree, il che frammenta le pagine e peggiora sia le scritture sia la cache; le chiavi crescenti si aggiungono in coda. Su tabelle grandi la differenza è misurabile, ed è per questo che la versione 7 sta sostituendo la versione 4 come chiave primaria — mentre per un identificatore che comparirà in una URL la versione 4 resta preferibile, perché non dichiara quando è stato creato.

La forma canonica è in minuscolo, trentasei caratteri con quattro trattini. Esistono però altre scritture dello stesso valore: le maiuscole, che vanno confrontate senza distinzione di caso; le parentesi graffe intorno, convenzione di Windows e dell’ecosistema COM; e il prefisso `urn:uuid:`, definito dalla specifica.

La differenza fa danni in un posto solo, il confronto testuale. Due sistemi che scrivono lo stesso identificatore in due forme diverse producono un mancato riscontro che sembra un dato mancante. La regola pratica è normalizzare quando si salva — minuscolo, senza parentesi, senza prefisso — e non quando si confronta, perché a quel punto è già tardi.

Un UUID versione 4 ha 122 bit casuali, quindi come valore imprevedibile regge il confronto con un token. Il problema non è la casualità ma il ciclo di vita: gli UUID vengono trattati come identificatori, quindi finiscono nelle URL, nei log, negli export, nei ticket di assistenza e negli screenshot.

Un token si può revocare, ha una scadenza e non compare in un log per progetto. Un identificatore usato come chiave d’accesso — il classico link «segreto» a un documento — non ha nessuna di quelle proprietà, e la prima volta che qualcuno incolla quella URL in una chat il controllo è finito. Se serve un segreto, si genera un token e lo si tratta come tale.

Parecchi generatori online chiedono gli identificatori a un server. Sembra irrilevante e non lo è del tutto: quel server sa quali valori ti ha dato e quando, e se poi quegli identificatori compaiono da qualche parte il collegamento è già stato fatto da qualcun altro.

Qui vengono prodotti nella tua scheda con il generatore del browser, e non parte nessuna richiesta né per chiederli né per registrarli. È anche il motivo per cui funzionano senza rete: una volta caricata la pagina, non c’è niente da domandare a nessuno.

Di per sé un UUID versione 4 non contiene niente. Nel momento in cui viene assegnato a una persona in un database, però, diventa un identificatore di quella persona, e nel senso del GDPR è un dato personale come lo sarebbe un numero cliente — la definizione guarda alla possibilità di collegamento, non al contenuto della stringa.

La conseguenza pratica è che sostituire un indirizzo email con un UUID è pseudonimizzazione, non anonimizzazione, esattamente come lo è un hash. È una misura di sicurezza utile e sensata; chiamarla anonimizzazione in un registro dei trattamenti significa dichiarare una cosa che la tabella di corrispondenza smentisce.