4 ms·

I fully agree. It makes no sense. Yet... The only guesses I'm having is that we originally generated UUIDv4s on a user's phone before sending it to the databas

I fully agree. It makes no sense. Yet... The only guesses I'm having is that we originally generated UUIDv4s on a user's phone before sending it to the database, and the UUID generated this morning that collided was created on an Ubuntu server. I don't fully know how UUIDv4s are generated and what (if anything) about the machine it's being generated on is part of the algorithm, but that's really the only change I can think of, that it used to generated on-device by users, and for many months now, has moved to being generated on server.

stubish 5mo ago
The UUIDv4 collision is statistically extremely unlikely. What is more likely is both systems used the same seed. This might be just a handful of bytes, increasing the chance of collision to one in billions or even millions.
- tracker1 5mo ago
  The shim for node:crypto in the browser is likely a weaker implementation in JS than the node implementation... you can cheat and use the browser itself to get a UUIDv4... function uuid4() { var temp_url = URL.createObjectURL(new Blob()); var uuid = temp_url.toString(); URL.revokeObjectURL(temp_url); return uuid.split(/[:\/]/g).pop().toLowerCase(); // remove prefixes }
  - DarkUranium 5mo ago
    No need for this dance in a modern browser: `crypto.randomUUID()` is a thing nowadays.
AntiUSAbah 5mo ago
You let users generate a UUID? To be honest, the chance that you are doing something weird is probably higher than you experiencing a real UUID conflict. How did your database 'flag' that conflict?
- mittermayr 5mo ago
  user-generated (as in: on the user's phone) was only at the very early stages of this product, and we've since moved to on-server. It's a cash-register type of app, where the same invoice must not be stored twice. So we used to generate a fresh invoice_id (uuidv4) on the user's device for each new invoice, and a double-send of that would automatically be flagged server-side (same id twice). This has since moved on to a server-only mechanism. The database flagged it simply by having a UNIQUE key on the invoice_id column. First entry was from 2025, second entry from today.
  - bitsandbits 5mo ago
    If the server or the user's phone had the wrong time and if the date is used in generating the ID...
    - whatevaa 5mo ago
      uuidv4 is random. uuidv7 includes time.
  - tracker1 5mo ago
    Assuming the phone is using the default JS engine, it's whatever is being shimmed for node:crypto package's random bytes method... which is likely weaker. I wrote a different implementation that cheats by using browser's methods of getting a uuid. https://github.com/tracker1/node-uuid4/blob/master/browser.mjs https://github.com/tracker1/node-uuid4/blob/master/browser.m...
- wongarsu 5mo ago
  If it's UUIDv4 and you validate that the UUID is valid and not conflicting I don't really see the issue with user-generated UUIDs. Being able to generate unique keys in an uncoordinated manner is the main selling point of UUIDs Sure, it's something I'd flag in any design to spend two minutes to talk about potential security implications. But usually there aren't any
  - 5mo ago
lazyjones 5mo ago
Better check what crypto.js is actually doing in your exact setup. Weak polyfills exist...
wongarsu 5mo ago
If it was two on-device generated UUIDs I could see a collision happening. There have been instances of cheap end devices not properly seeding their random number generators, leading to colliding "random" values. And cases of libraries using cheap RNGs instead of a proper cryptographic RNG, making it even worse But on a server that shouldn't happen, especially not in 2026 (in the past, seeding the rngs of VMs used to be a bit of an issue). Even if one UUID was badly generated, a truly random UUID statistically shouldn't collide with it. You'd need an issue in both generators
- tracker1 5mo ago
  The library is using node:crypto, but with a phone target, that's likely shimmed with a JS implementation...

stubish 5mo ago

The UUIDv4 collision is statistically extremely unlikely. What is more likely is both systems used the same seed. This might be just a handful of bytes, increasing the chance of collision to one in billions or even millions.

tracker1 5mo ago
The shim for node:crypto in the browser is likely a weaker implementation in JS than the node implementation... you can cheat and use the browser itself to get a UUIDv4... function uuid4() { var temp_url = URL.createObjectURL(new Blob()); var uuid = temp_url.toString(); URL.revokeObjectURL(temp_url); return uuid.split(/[:\/]/g).pop().toLowerCase(); // remove prefixes }
- DarkUranium 5mo ago
  No need for this dance in a modern browser: `crypto.randomUUID()` is a thing nowadays.

AntiUSAbah 5mo ago

You let users generate a UUID? To be honest, the chance that you are doing something weird is probably higher than you experiencing a real UUID conflict. How did your database 'flag' that conflict?

mittermayr 5mo ago
user-generated (as in: on the user's phone) was only at the very early stages of this product, and we've since moved to on-server. It's a cash-register type of app, where the same invoice must not be stored twice. So we used to generate a fresh invoice_id (uuidv4) on the user's device for each new invoice, and a double-send of that would automatically be flagged server-side (same id twice). This has since moved on to a server-only mechanism. The database flagged it simply by having a UNIQUE key on the invoice_id column. First entry was from 2025, second entry from today.
- bitsandbits 5mo ago
  If the server or the user's phone had the wrong time and if the date is used in generating the ID...
  - whatevaa 5mo ago
    uuidv4 is random. uuidv7 includes time.
- tracker1 5mo ago
  Assuming the phone is using the default JS engine, it's whatever is being shimmed for node:crypto package's random bytes method... which is likely weaker. I wrote a different implementation that cheats by using browser's methods of getting a uuid. https://github.com/tracker1/node-uuid4/blob/master/browser.mjs https://github.com/tracker1/node-uuid4/blob/master/browser.m...
wongarsu 5mo ago
If it's UUIDv4 and you validate that the UUID is valid and not conflicting I don't really see the issue with user-generated UUIDs. Being able to generate unique keys in an uncoordinated manner is the main selling point of UUIDs Sure, it's something I'd flag in any design to spend two minutes to talk about potential security implications. But usually there aren't any
- 5mo ago

lazyjones 5mo ago

Better check what crypto.js is actually doing in your exact setup. Weak polyfills exist...

wongarsu 5mo ago

If it was two on-device generated UUIDs I could see a collision happening. There have been instances of cheap end devices not properly seeding their random number generators, leading to colliding "random" values. And cases of libraries using cheap RNGs instead of a proper cryptographic RNG, making it even worse But on a server that shouldn't happen, especially not in 2026 (in the past, seeding the rngs of VMs used to be a bit of an issue). Even if one UUID was badly generated, a truly random UUID statistically shouldn't collide with it. You'd need an issue in both generators

tracker1 5mo ago
The library is using node:crypto, but with a phone target, that's likely shimmed with a JS implementation...