Copied from https://github.com/mongodb/bson-ruby/pull/291#issuecomment-1242511428

According to ObjectId specification:

If possible, use a PRNG with OS supplied entropy that SHOULD NOT block to wait for more entropy to become available.

For Ruby this is the SecureRandom.MRI uses multiple sources of seed for Kernel.rand.
Reference:
https://github.com/ruby/ruby/blob/55c771/random.c#L655
This may or may not include urandom on *nix depending on how you compile it.

The objective of the spec is to lower the probability of collision on ObjectID, given that the collision on a 16-bit machine identifier should not be that rare. For Ruby's truncated MD5(hostname), all it takes is people to name the same hostname on different servers. And when two identical server restarts, it's not that unusual to have Ruby with the same PID.

Even if these two events occur, the last safeguard is the counter with a randomized init value. Now the quality of randomization matters. Even if the randomization doesn't need to be cryptographically secure, the orthogonal to other values in the tuple is a desirable property.

If Kernel.rand was seeded with time, for example, you'll end up with something deterministic. Not independent between each process.

That part about PID has no reference, but the seed for Kernel.rand has pretty much the same requirement as MongoDB.
(No need for cryptographically secure randomization)

I wouldn't surprised if some implementor chooses to seed it with time / MachineID / ProcessID; this is undesirable because it will make the counter initialization not orthogonal to other values in ObjectID.