tldr; I would like to revisit, and make a case for, RFC4122 v4 UUIDs. Here’s the start of a proposal: bcoe.github.io/uuid/.
v4 UUIDs are ubiquitous
uuid is a dependency of over 30,000 modules on npm, and downloaded 40,000,000 times a week (In analyis summarized here, it was found that about 80% of users of the library use the v4 algorithm).
v4 uuid’s have a wide variety of uses, once you start looking for them you see them everywhere:
- identifiers for request tracing (potentially frontend through to server).
- a method for anonymously tracking page views.
- a temporary document name, e.g., a Google sheet generated as the output of a report.
- resource names in unit tests.
- identifiers for inspector sessions.
- identifiers on physical items, such as shipping receipts.
- identifiers for IoT devices.
Bad implementations of UUID v4 are a risk to developers
Developers who have not been exposed to RFC 4122 might naturally opt to invent their own approaches to UUID generation.
TIFU by using Math.random() is a good discussion of why it’s important that UUIDs are generated using a sound algorithm, with a secure source of randomness.
When I disussed this with a colleague today, they had a great quote:
well I don’t want to write any kind of hash- or crypto-related code even it’s just 40 lines
Folks are excited about this idea
We just shipped WebCrypto on the Node.js project, and we’re likewise excited to add UUID support as a natual extension to this functionality – we’d love to do so in a platform agnostic way.