Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye integers, hello UUIDv7

buildkite.com

Post reply on HN
Print view View original

191–200 of 376 posts

Re: Goodbye integers, hello UUIDv7

#191

Post by jjgreen »

wenc wrote: post #28
akira2501 wrote: post #8

Earlier quoted context omitted.

UUIDv7: Timestamp up front, random in the back.

I know HN doesn't like jokes, but this is really funny. And the subcomment about mullets too. (for folks who don't get it, mullets are a 1980s haircut (think MacGyver) with a short front but a long tail in the back. A funny description of them is "business in the front, party in the back")

Sitting on a tram in Sheffield, early noughties, a chap with a magnificent unreconstructed ROCK mullet gets off. I see two women chatting on the street, they are stunned into slack-jawed amazement as he struts past -- one of the women makes a scissor-snipping hand gesture behind him as he passes, the whole tram erupts in laughter.

Re: Goodbye integers, hello UUIDv7

#192

Post by wolletd »

matharmin wrote: post #158
BiteCode_dev wrote: post #100

Earlier quoted context omitted.

What benefice over uuid4 ?

Reading their docs: No real benefits, just misconceptions. 1. Collision resistance / "weak" PRGNs used to generate UUIDv4. Firstly, these are properties of the implementation , not the spec. Secondly, the source for calling the browser `Crypto.getRandomValues()` insecure is an issue that has been fixed back in 2016. I would not trust the developers of this implementation to do a better job than current browsers. 2. "…

I once had UUID collisions in Linux Boot IDs when we started developing our own embedded systems at my company.

Found them because systemd-journald isn't very happy when Boot IDs repeat and (apparently, then) stops showing earlier boots once it hits a repeating boot ID. And I wanted to see an earlier boot. Then I started logging the Boot ID in a textfile myself and it took less than 10 reboots to have duplicate Boot IDs.

Long story short, some weeks earlier, I "optimized" the Kernel config for that system and some config flags that didn't sound like something I'd need. As it turns out, an ARCH_ZYNQ target apparently also needs ARCH_VEXPRESS set. Otherwise it works absolutely fine, but with a broken RNG that you will notice weeks later.

That was a valuable "don't take down a fence until you know the reason why it was put up" lesson. Don't unset kernel config flags until you know why they are set.

Aside from breaking RNGs, I've never experienced any UUID collisions either.

Re: Goodbye integers, hello UUIDv7

#193

Post by londons_explore »

andix wrote: post #180
oconnore wrote: post #55

Earlier quoted context omitted.

Given that a UUID identifier fits in a single cipher block, and the whole point is that these are unique by construction (no IV needed so long as that holds true), it seems like a single round of ECB-mode AES-128 would enable quickly converting between internal/external identifiers. 128 bits -> 128 bits

I like the idea, but I think it's not possible to rotate the key with that approach, without introducing a breaking change. Eternal secrets are usually a very bad idea, because at some point they are going to be leaked.

But the private data you are protecting (the user's account creation time) has the same properties as an eternal secret.

Therefore there doesn't seem to be much downside in this specific case.

Re: Goodbye integers, hello UUIDv7

#194

Post by Sebb767 »

earnesti wrote: post #187
Nevermark wrote: post #183

Earlier quoted context omitted.

Security by obscurity is a necessary step in most software security. It hardens, completes and complements other measures. Examples of every day security using obscurity: every password and encryption key EDIT: Thanks for the replies. Ignore above! Obscurity is the low bit of security. But when it’s convenient, it still helps.

Obscurity and secrecy are different things. Though I agree with you. Moderate amount of well implemented obscurity is helpful.

> Moderate amount of well implemented obscurity is helpful.

You're getting that wrong: Everything else being equal, the more obscure system will always be the safer one. It's just that obscurity can easily be lost, so your system should, if in any way possible, still be secure even if fully known. In the end, however, no system is 100% secure, but more obscurity will make it harder to find the inevitably existing issues.

Re: Goodbye integers, hello UUIDv7

#195

Post by jhealy »

LAC-Tech wrote: post #47

Why use UUIDv7 over ULIDs? As Lazare points out in this thread they're basically the same thing, except with ULIDs you get those 6 extra bits of randomness back that UUIDs have to use for metadata.

I'm not the author, but I work at the same company. ULIDs are nice, but we're a 10 year old company with many TBs of data across multiple logical databases and most rows had UUIDv4 ids.

Maybe if we were starting from scratch ULIDs would have been an option, but given where we were UUIDv7 was a much easier transition.

Re: Goodbye integers, hello UUIDv7

#196

Post by greatgib »

jonhohle wrote: post #35

This is great for internal distributed systems where having ordered keys is useful, however, it should probably be noted that these probably shouldn't be used as public identifiers (even though this will probably be the defacto standard and used publicly without thought). Having any information, specifically time information, leaking from your systems may or may not have unanticipated security or business implication…

Fyi, the timestamp is already encoded inside uuid4. But for having a good distribution of values, the low bits half of the timestamp is stored before the high bits half.

Here uuidv7 will just re-order that. So the content of the uuid in itself does not change.

Re: Goodbye integers, hello UUIDv7

#197

Post by RobIII »

danwee wrote: post #159
dgb23 wrote: post #157

Earlier quoted context omitted.

The maximum url length is typically quite long. Another thing is that you don’t necessarily need to encode uuids canonically. They are just u128’s. It’s relatively straightforward to find a url friendly string representation that is shorter.

> It’s relatively straightforward to find a url friendly string representation that is shorter. Are we talking about shortening the whole URL or shortening specific UUIDs? If the latter then I imagine one would still need to keep track of the mapping UUID shorten version, somewhere, right? If so, why not just add yet another field/column for an old good numeric integer that can be used for filtering? Would that work?

You could simply base32, base36 or base64 encode the UUID's (as an example).

Other than that; in IE6 times URL's had a limitation of 1K or 4K or something around that lenght IIRC, so unless you're using dozens of UUID's in a URL this hasn't been a problem for ages.

Re: Goodbye integers, hello UUIDv7

#198

Post by toni88x »

IMO the benefit of UUIDs over integers is that they can be generated client-side without clashing. But you cannot trust timestamps generated by clients and therefore the order. So what is the benefit over UUID4?

Re: Goodbye integers, hello UUIDv7

#199

Post by ahoka »

wvh wrote: post #160

A few years back, I wrote some code that generates a sortable 128-bit UUID-like identifier starting with a milliseconds-since-epoch timestamp, a node number and a random byte tail. It has been working fine in Postgresql, using its builtin UUID type. I suppose downstream system have been using the string representation though. The main reason for going such an identifier was being able to generate them from different,…

Isn’t that almost the same as v1?

Re: Goodbye integers, hello UUIDv7

#200

Post by BeFlatXIII »

Traubenfuchs wrote: post #129
rossant wrote: post #121

Earlier quoted context omitted.

The dashes do not take up any space, they are not encoded. I think it's fairly common to reserve some space to versions and ECC in uuids, packets etc. That's a price to pay to avoid many bugs and compatibility issues.

UUIDs are often pushed around in JSON and as string types, including the none random parts.

Do those dashes cause any meaningful performance impact, or is this just a microoptimization obsession?
Post reply on HN