3 ms·
Maybe you don’t want to leak the time component.
by minitoar 6y ago
Maybe you don’t want to leak the time component.
- Vanderson 6y agoI had not considered that. In my use case it's not an issue, but I can see that if the ID value is publicly viewable (ie, in a URL) and can reveal sensitive info via the timestamp... thanks.
- mianas 6y agoThis occurred to me after looking at the Wikipedia article [1], and seeing the different "versions" and the rationale about not leaking data in the ID. In general, if you want to encode info in your IDs, you can do that. Just make sure you want to do that, and that you don't run out of entropy. I view random UUIDs as a silver-bullet type solution to assigning IDs, without overlap. (8 bytes should be enough to just assign them at random) 1: https://enwp.org/UUID https://enwp.org/UUID
- jepler 6y ago8 bytes will have a non-negligible (say, 1 in 1 million) chance of generating the same identifier twice even if you only generate a few million million IDs -- see https://en.wikipedia.org/wiki/Birthday_problem#Probability_table https://en.wikipedia.org/wiki/Birthday_problem#Probability_t... and look at the "16 hex digits" row. Depending on your use case, this may or may not be a problem.
- j-pb 6y agoMicrosoft research has a great blog post on this. https://devblogs.microsoft.com/oldnewthing/20160114-00/?p=92851 https://devblogs.microsoft.com/oldnewthing/20160114-00/?p=92... TLDR: It's far more likely for a UUIDv1 to be corrupted to a collision due to memory errors and bit-flips, than for two UUIDv4 to collide. TLDRTLDR: All computing is approximate at scale.