Yes, but “should” is the operative word here. I don’t think most UUID libraries use good randomness, and the UUID RFC standard actively argues against using UUIDs as anything which has to be kept secret.
It's my impression that most of the people who use UUIDv4s for their unguessability, aren't actually using UUIDv4s at all (i.e. aren't using a distinct UUID library or runtime UUID datatype), but rather are pulling 16 bytes from a CSPRNG, and then formatting it manually into a UUIDv4 serialization format and calling it done.
Sometimes, but not often, the developer will remember that UUIDs have a structure, and so will mask out the relevant bits from the CSPRNG output to replace them with the right static tag-bits to define the serialized identifier as a UUIDv4.
But usually, developers aren't expecting the other end of any conversation to actually try to understand the UUID, but merely to hold onto it as an opaque 128-bit-packed or hex-string-encoded binary. Which is a valid expectation in practice! Even DBMSes with a UUID type don't actually validate the tag bits on the UUIDs inserted into such a column. There's no DBMS I know of that has a means to impose a constraint on which version of UUID a UUID-typed column should hold, or a constraint on the domain for a UUIDv1, or any of that.
A UUID might be an ADT with four distinct generation algorithms—but after generation, in practice, they become just opaque uint128 values, that nobody ever unwraps or parses or expects to mean anything, ever again.
Which means that, in practice, there's nothing stopping people from just taking 128 bits of CSPRNG randomness, and calling that a "UUID." And so that's mostly what they do!
> I don’t think most UUID libraries use good randomness, and the UUID RFC standard actively argues against using UUIDs as anything which has to be kept secret.
Windows core system libraries, and by extension .NET, SQL Server, etc. have used the system CSPRNG for type 4 UUID generation since at least as far back as Y2K.
If you don’t use a CSPRNG for type 4 UUIDs you get collisions from the small seed size of insecure PRNGs, which are traditionally seeded from the system clock. The number of UUIDs required to observe collisions was surprisingly low thanks to the birthday paradox.
These collisions were common enough back in SQL Server v7 that, as I recall, they changed the UUID generation mechanism NEWID() to use a CSPRNG in a service pack.
