UUID-generator

Er wordt `crypto.getRandomValues` gebruikt, de cryptografische generator van de browser, die zijn entropie van het besturingssysteem betrekt. Dat is niet `Math.random()`, waarvan de uitvoer uit de interne toestand te reproduceren is en die nooit een identifier zou moeten voeden die iemand niet mag raden.

Het verschil is aan het resultaat niet te zien: allebei leveren ze reeksen op met de juiste vorm en allebei komen ze door elke vormcontrole heen. Het valt pas op op de dag dat iemand de volgende identifier voorspelt, en dan staat het al in productie. Biedt de browser de cryptografische generator niet, dan stopt het hier in plaats van naar de zwakke terug te vallen.

Een UUID is 128 bits, maar in versie 4 liggen er vier vast door het versienummer en twee door de variant. Er blijven er 122 willekeurig over, en dat zijn er nog altijd zoveel dat de kans op een botsing verwaarloosbaar is, ook als je er miljarden maakt.

Die ruimte is precies wat toelaat ze verspreid te maken zonder afstemming: twee diensten die nooit met elkaar praten, kunnen tegelijk identifiers maken zonder iets af te spreken. Het is de eigenschap waarvoor UUID’s bestaan, en de reden dat een automatisch oplopende teller ophoudt te werken zodra er meer dan één machine schrijft.

De versie is het eerste teken van de derde groep, oftewel het dertiende hexadecimale cijfer: hier altijd een `4`. De variant is het eerste teken van de vierde groep en moet `8`, `9`, `a` of `b` zijn, want die vier cijfers delen de beginbits `10` die RFC 4122 voor zichzelf opeist.

Dat is met het blote oog te controleren, en het is de snelste manier om een zelfgebouwde generator te herkennen. Wie 32 willekeurige hexcijfers aan elkaar plakt zonder die twee posities vast te zetten, maakt identifiers die op UUID’s lijken, het formeel niet zijn en jarenlang werken tot iets ze serieus controleert.

Een UUID van versie 1 bevat het moment van aanmaken met een precisie van 100 nanoseconden en, van oudsher, het MAC-adres van de netwerkkaart. Allebei zijn ze te reconstrueren door wie de identifier heeft, dus een databasesleutel die van buiten zichtbaar is, wordt een aanwijzing over de machine en het tijdstip.

Dat is geen theoretische zorg: het was de weg waarlangs in 1999 de maker van het Melissa-virus werd geïdentificeerd, omdat Word het MAC-adres in de document-id’s schreef. Waar een identifier van buiten zichtbaar is, is versie 4 de juiste keuze.

Versie 7 zet een tijdstempel in milliseconden vooraan en vult de rest met toeval, zodat de identifiers vanzelf op tijd geordend zijn. Dat lost het probleem op waarom veel teams UUID’s als primaire sleutel hebben gemeden.

De oorzaak is de index. Willekeurige sleutels schrijven op steeds wisselende plekken in een B-boom, wat pagina’s splitst en de cache verspilt; bij grote tabellen kost dat meetbaar schrijfprestatie. Een oplopende sleutel schrijft altijd achteraan. De prijs is dat het moment van aanmaken weer leesbaar wordt.

Hier worden ze in kleine letters en zonder opsmuk gemaakt, en dat is wat de specificatie bij het aanmaken vraagt. Bij het lezen hoor je hoofdletters te accepteren, en in de praktijk schrijven .NET en veel Windows-gereedschap ze van oudsher zo.

Daarnaast circuleren twee omhulsels: de accolades, uit de notatie van het Windows-register, en een `urn:uuid:` ervoor, uit de URN-naamruimte. Geen van beide hoort bij de identifier. Wie zelf vergelijkt, moet naar kleine letters normaliseren en de omhulsels weghalen, anders vallen twee gelijke identifiers uit elkaar op hun schrijfwijze.

Een identifier van versie 4 is in de praktijk niet te raden, en van daar naar hem als toegangstoken gebruiken is een stap die te vaak wordt gezet: een «privélink» waarvan de enige bescherming is dat er een UUID in de URL staat.

Het probleem is niet de entropie maar waar de URL terechtkomt: in de geschiedenis, in de referrer-header van de volgende klik, in het logboek van een proxy, in het bericht waarin iemand hem doorstuurt. Een token hoort te verlopen en intrekbaar te zijn, en een UUID doet geen van beide.

Er zijn diensten die UUID’s via een API teruggeven, en die gebruiken betekent dat iemand anders precies de identifiers heeft gezien die je in je database gaat zetten. Het is niet rampzalig en het is ook niet nodig: genereren is een lokale bewerking van een paar regels.

Hier gebeurt het in je tabblad, met de cryptografie van de browser. Er komt geen verzoek aan te pas, dus het werkt na het laden van de pagina net zo goed zonder verbinding — in de trein, achter een bedrijfsproxy of op een machine die niet aan het netwerk hangt.

Je kunt er tot honderd in één keer maken, één per regel. Die grens heeft niets met rekenkracht te maken — honderdduizend identifiers maken kost een browser nauwelijks tijd — maar met wat een tekstveld en een selectie met de muis nog behapbaar houden.

Heb je er duizenden nodig, dan is een lijst in een tabblad hoe dan ook het verkeerde gereedschap. Dan hoort het in het script dat de gegevens wegschrijft, waar de identifiers meteen op hun plek belanden in plaats van via het klembord — een omweg waarbij een enkele regel gemakkelijk verloren gaat.

Een UUID vervangt geen natuurlijke sleutel. Een ordernummer dat een mens moet uitspreken aan de telefoon, een factuurnummer dat opeenvolgend moet zijn voor de administratie, een productcode die betekenis draagt: geen van die drie wordt beter van 36 tekens willekeur.

En hij is niet gratis in opslag. Als tekst kost een UUID 36 bytes, als binaire waarde 16, tegenover 8 voor een groot geheel getal — en dat vermenigvuldigt zich in elke index en elke vreemde sleutel die ernaar wijst. Dat is meestal een prima ruil voor het verspreid kunnen maken, maar het is een ruil en geen gratis verbetering.

Een vers gegenereerde UUID bevat geen enkel persoonsgegeven — het zijn willekeurige bits. Hij wordt een pseudoniem zodra hij in jouw systeem aan een persoon wordt gekoppeld, en vanaf dat moment gelden dezelfde verplichtingen als voor elke andere gebruikers-identifier.

Wat deze pagina waarborgt is het stuk daarvoor: de identifiers ontstaan op je eigen machine en gaan niet langs een tussenliggende dienst. Dat is een klein en echt verschil, zeker wanneer je ze in een reeks maakt voor een migratie van echte gegevens.