Use of UUIDs

UUID values are defined by an IETF standard (RFC 4122):

www.ietf.org/rfc/rfc4122.txt

IIRC, the UUIDs you get out of the Foundation module combine clock time with hardware-generated true random values. Because of the time component, you can't get a duplicate unless two UUIDs are requested at exactly the same time (exactly the same time), and if two UUIDs are requested at exactly the same time, you can't get a duplicate unless two 48-bit random numbers happen to be the same.

The net result is that the chance of getting two identical UUIDs ever is pretty **** small.

What QuinceyMorris said but I want to speak further on this point.

But that still means there is a possibility of getting a duplicate.

Computer programmers really want absolute certainty, and thus the fact that UUIDs are only statistically unique tends to cause consternation. However, you have to consider this in the context of other random events. If the chance of getting a duplicate UUID is less than the chance of a cosmic ray toggling a bit in memory such that your programmer misbehaves in some way, it’s OK to accept that UUIDs are effectively unique and move on. Or, looking at it the other way, if you worry about UUID collisions then you also need to start worrying about cosmic rays, and that way lies madness.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thank you so much QuincyMorris and Eskimo for your insights! I'm not worried about cosmic rays, so I shall not worry about duplicate UUID 😝

In that case, privacy wise, is it sensitive to transfer one device's UUID from its Core Data into another device's Core Data? Also, do I need keychain encryption if it is possible to transfer UUIDs across? I am planning to use Core Bluetooth to append survey results in Core Data across different users (devices). One of the attributes to append is the users' UUID to ensure unique results.

UUIDs are not inherently sensitive information, so there's no reason not to transfer them freely (typically as unique "names" of things that don't have inherently unique names, but for any purpose you want).

There may be situations where you want to use a UUID to make it hard to guess which "key" or "name" a piece of information is stored under. However, this comes under the heading of "security through obscurity" and isn't very secure at all.

So unless you have a particular attack scenario in mind, I suggest you don't treat them as a cause for concern.

Okay noted. Thanks QuinceyMorris! Really appreciate your help!