281–290 of 376 posts
Earlier quoted context omitted.
Why not just use the AES-128 result as the UUID then? What's the benefit of the internal structure at all? If AES-128 is an acceptable external UUID (and likely an acceptable internal one), then you might as well just stick with a faster RNG.
> What's the benefit of the internal structure at all? Purely random identifiers are the bane of DB indices. The internal structure is sequential-ish and therefore indexes well.
Is there some reason new versions of UUID keep appearing? It seems like the desired properties are never quite achieved so new ones appear later. Is there a table with UUID version across the top and characteristics down the side, so I can see the differences and pick one that fits my needs? That might also help to explain why there are so many variants.
Unless you have specific needs, the only type of UUID you should care about is v4. v1: mac address + time + random v4: completely random v5: input + seed (consistent, derived from input) v7: time + random (distributed sortable ids)
Speaking of RDBMs, how good are UUIDs when making joins and fetching a certain record?
Unless you're manually storing them as strings... (Not ideal, but most dbs are pretty good at dealing with that too)
Earlier quoted context omitted.
As someone who only cares about v4, I periodically wonder why don't I just use fully random 128-bit identifiers instead (without the version information).
UUID v4 isn't large enough to prevent collisions, that is why segment.io created https://github.com/segmentio/ksuid which is 160bit vs the 128bit of a UUIDv4.
If you need to sort by insert order, use an autoincrementing integer, if you need uniqueness, UUIDv4 is fine, if you need both use both.
Use timestamps when you need to record the time, just don't commit the sin of presuming that clock time will never run backwards, I assure you, it does.
Earlier quoted context omitted.
If you were using something like UUIDv4, you wouldn't be exposing that information at all though, neither in cleartext or ciphertext. It seems weird to say, "the user ID contains secret information so we encrypt it with an eternal fixed pre-shared key then share the ciphertext with the world", when you could've just said "the user ID contains no secret information". It feels like the right solution here is to pick be…
You could just randomize the timestamp. adding +/- month or two to the UUIDv7 won't break the advantages all that much.
Earlier quoted context omitted.
Having sequential ID's is more than just a security risk, it's an information risk. Competitors can use them to estimate the size of your business, the number of customers you have, and all sorts of stuff. This was used in the war to estimate the number of German tanks based on the sequential IDs https://en.wikipedia.org/wiki/German_tank_problem So just for business intelligence you don't want to leak your IDs.
Not disagreeing with the general concept - these IDs leak information - but these are sequential IDs, not auto-incrementing IDs. The leak is the time the ID was generated, not the volume of IDs generated.
Or from a list of most recently added customers/users, you can figure out the rate of signups.
Revealing timestamps is bad because it can reveal way too much information about the health of your business that you prefer to keep private, if a sequential list of ID's ever gets exposed (which is hard to prevent).
Speaking of RDBMs, how good are UUIDs when making joins and fetching a certain record?
More or less identical to integer ids - they're stored and referenced as a 16-byte integer. Unless you're manually storing them as strings... (Not ideal, but most dbs are pretty good at dealing with that too)
Earlier quoted context omitted.
I’ve heard this argument many times, but I’ve never seen anyone actually post a reference to it happening (as in, a company finding and using this information; not the German tank problem). To me, it reeks of solving imaginary problems while causing new ones.
It's perhaps embarrassing for a new startup to have a user ID of "10". That's about the only problem I can discern.
Relying on timestamps to be sortable, when clock skew and ntd guarantee that they won't always be, strikes me as poor design. If you need to sort by insert order, use an autoincrementing integer, if you need uniqueness, UUIDv4 is fine, if you need both use both. Use timestamps when you need to record the time, just don't commit the sin of presuming that clock time will never run backwards, I assure you, it does.