time_generator - any opinions about adding it?

[jeffreypedigo]

Hi,

I'm in some need for a time generator which our app uses to identify unique log elements streamed to various interested users. I'm no expert on UUIDs, but it seems to be a popular data element. The inherent order provided by time is used to organize the data downstream.

I'm just curious if there is a reason I am missing.

Cheers,
Jeff

[pdimov]

To implement time_generator, we'd need a way to get the node identifier (MAC address), which is platform-dependent and very tricky (e.g. in the presence of multiple LAN adapters, multiple wireless adapters, and multiple virtual adapters, one needs to choose one of the LAN adapters, which isn't trivial in general.)

I suppose we could just take it as a parameter, but then time_generator wouldn't provide much value?

It also requires persistent storage for the sequence numbers, which is another complication.

[Lastique]

I think, the general opinion is that time-based (v1) UUIDs are obsolete and may pose security risk, as the generated UUID contains information that may potentially identify the user (his MAC address). I don't think we should support them in Boost.UUID.

4. Privacy and network security issues arise from using a MAC address in the node field of Version 1 UUIDs. Exposed MAC addresses can be used as an attack surface to locate machines and reveal various other information about such machines (minimally manufacturer, potentially other details). Additionally, with the advent of virtual machines and containers, MAC address uniqueness is no longer guaranteed.

https://datatracker.ietf.org/doc/html/draft-peabody-dispatch-new-uuid-format-04#section-1

It may be worth exploring the other formats described in this draft. In particular, UUIDv6 (with a random value for node, not the MAC address) or UUIDv7.

[pdimov]

You don't have to use a MAC address, a pseudorandom 48 bit multicast address also works and is blessed by the RFC (section 4.5.) Such UUIDs are useful as unique event identifiers because they contain a timestamp. I agree that we shouldn't make any attempts to obtain the MAC address.

I've been looking at these v6/v7 UUIDs, but I'm not sure how "standard" they are. (v6 is exactly the same as v1, with the time fields rearranged so that UUIDs sort by time.)

[pdimov]

Reading up a bit, the v6/v7 appear to be reasonably popular and "standard" (although the IETF draft seems to be still actively developed and has been updated fairly recently), so it probably makes sense to have time_generator_v6 and time_generator_v7 in addition to time_generator_v1.

[Lastique]

If you're going to support v1, please be sure to mention in the docs that it doesn't use MAC address in the generated UUIDs.

[pdimov]

The two options for v1 (and v6) will be either pseudorandom, or user-supplied. We can explain that in the latter case using the MAC address is no longer advisable.

[Lastique]

Come to think of it, I'm not sure how you're going to achieve the same property of "ownership" of the v1 UUIDs with MAC addresses. The MAC address was supposed to make the generated UUIDs "unique" to the creator, but still the "node" portion was stable across multiple UUIDs generated by the same creator. If you use a random number for node, you will have to keep that random number constant across multiple UUIDs - possibly even across multiple application runs. Or you would have to give up this "ownership" property entirely.

[Lastique]

or user-supplied

Ah, right. So if the "ownership" property is important, we're going to let the user implement it.

[pdimov]

Most of the time the uses of time-based UUIDs (e.g. for identifying log entries as mentioned above) don't need persistence across application runs, but yes, the user could implement it if desired.

The main use case I see for the user-supplied state is distributed generation (multiple time_generator instances in separate threads.)

[computerquip-work]

A UUIDv7 generator would be awesome! Should a separate issue be created for that if this issue pertains to just UUIDv1?

[pdimov]

A separate issue won't be necessary; v6 and v7 are already on my to-do list.

[pdimov]

time_generator_v1/6/7 have now been implemented on develop/master.