Ask HN: We just had an actual UUID v4 collision...

· Source ↗

A team hit a real UUID v4 collision in production—an event so statistically improbable it almost always signals broken entropy, not bad luck. Here is what the thread surfaced.

What Matters

  • UUID v4 collision probability is ~1 in 2^122; an actual collision almost always means a defective or poorly seeded entropy source, not random chance.
  • crypto.getRandomValues() carries no guaranteed minimum entropy; a poorly initialized PRNG is the most common collision cause.
  • [HN: @jandrewrogers] “The security of UUIDv4 is based on the assumption of a high-quality entropy source”—hardware defects and software bugs routinely invalidate that assumption, and almost no one audits it.
  • [HN: @e12e] Googlebot’s crypto.getRandomValues() is deterministic, per a filed uuidjs issue (#546); frontend UUID generation is structurally unreliable.
  • [HN: @danpalmer] Segment built its core analytics product on browser-generated UUIDs and suffered pervasive collisions that undermined data quality at a foundational level.
  • Frontend UUID generation is the highest-risk path; backend generation with a verified OS entropy source is the recommended mitigation.
  • If UUIDs must be accepted from untrusted clients, collision-handling logic is required—treat client-supplied IDs as untrustworthy by default.

Original | Discuss on HN

Related coverage