Application group at dayjob ran into a guardrail today.
They need an FE-generated ID token, low-security, unique in a low-volume setting. Sounds like a UUID to me!
But.
`crypto.randomUUID()`, in order to prevent low-security IDs being used where high-security is needed, is not accessible outside a secure context, and the application in question runs in an insecure context.
On the core team, our go-to “unique-enough id” is nanoid. nanoid is pretty spiffy; if available, it’ll use the browser crypto API to generate good-quality entropy and good random numbers. But! If not available, it’ll fall back, all the way to Math.random() if it needs to.
Secure? No! But not everything is a health info transfer, sometimes we just need a quick and handy number to tie some stuff together.
Moral of the story:
If you prevent your user (user-developer) doing dangerous things, you’ll also prevent them doing clever things. Document the scary bits and mark the holes, but don’t put up impassible guardrails or users will just find another way.
