I think this gets to the crux of the issue.

It's not about using hard-to-guess UUIDs[0], but restricting access to the underlying data[1].

[0] https://en.m.wikipedia.org/wiki/Security_through_obscurity

[1] https://en.m.wikipedia.org/wiki/Access_control

It's not really security through obscurity. In these case I understand the ids where related to data that the company was making available to users through email links. A cryptographically secure 128bit UUID is impossible to guess, no more than a cryptographic access token. Now of course, you would probably rather want to have an authentication scheme on top of that, but that comes at a support cost in term of customers loosing their passwords, locking themselves out of their account, etc. And it is not clear you have increased security as people re-use passwords.

Then of course there is the issue that email is for the most part un-encrypted (or encrypted without validating certificates).

It's still an access control issue in that case. The user should never be aware of the UUID's. Only the backend should deal with it. If you have a _public_ API that deals with UUIDs, therein lies the issue.

And a side note: I wouldn't trust that the prng for your UUIDs are cryptographically secure. That's not a part of the spec.

I know, but as they're easier to guess, what's the point? Might as well just go back to ints.

Is MSSQL's NEWSEQUENTIALID secure? I didn't think it was.

Is the point of non mono tonic is schemes to make them -secure- secure?

I thought they were a bit of a hack to raise the bar a touch. In which case the crypto security properties of that function isn’t interesting. Instead the ergonomics are.

No, the cryptographic security of the identifier matters a lot. A GUID generated from an insecure PRNG can be used to predict other GUIDs. A UUID generated from 16 bytes of /dev/urandom can't be used to get anything but the object to which it refers.