UUID v1 Privacy Concerns
kesne opened this issue · comments
I'm happy that the current proposal only exposes a v4 UUID generation, but I saw that some committee members had some use-cases on v1 (which were not discussed in the meeting, but I'm hoping they get brought up here). I just wanted to share that I'm in favor of not exposing a v1 API, and just wanted to share some concerns about UUID v1 generation.
It is common practice to use UUIDs as external ids to uniquely identify users. With UUID v4, the randomness of the id gives you a sort of guarantee that two ids can't be connected. In my understanding, with UUID v1, the inclusion of the MAC address adds stable non-random bits that effectively create an identifier that can be used to identify the client even if the id has changed. This feels like a privacy footgun, where you can introduce problems even if you're trying to do the right thing.
For example, if you use a client-generated UUID v1 to uniquely identify clients, and clients reset this identifier (for example, this is stored in a cookie, and a user clears cookies), the mac address + time aspects of the ID actually make it possible to identify the client, even though the ids have changed. With v4, this isn't the case, and simply generating a new id is sufficient.
If the MAC is substituted for random bits, and only the timestamp is used, this is less of a concern.
Thanks for raising this again @kesne! This has been discussed in https://github.com/tc39-transfer/proposal-uuid/tree/master/analysis#background (e.g. there are rumors that the presence of the MAC address lead to the arrest of the authors of the Melissa Virus).
Do you think we should move this aspect into an FAQ item of the main proposal README?
On the other hand there still seem to be some valid use cases for v1 UUIDs especially when used with certain databases that make use of the specific properties of v1 UUIDs.
We could/should then still mandate in this spec that a random node value is being used instead of the MAC address.
@ctavan Ah didn't see the analysis document, sorry about that!
I can imagine that there are valid use-cases for UUID v1s, but given a huge chunk of JavaScript executes on the client (where this risk exists), I'd rather the UUID v1 generation continue to be done in userland when people really want time-ordering of ids.
I do think calling out the privacy concerns with v1 could be worth calling out in the FAQs, which only currently speak to the uniqueness problem.
@kesne please feel free to re-open if you think that the privacy concerns you have raised are not yet fully covered in the readme.