UUID: NewV7() always generates a UUID with 7000 on browsers (Golang)

UUID: NewV7() always generates a UUID with 7000 on browsers (Golang)(github.com)

34 points by mfrw 8 hours ago | 5 comments

JdeBP 21 minutes ago |

This sort of thing has always been tricky. There are a number of issues at play here:

* (Mentioned in the bug report) clock resolution may not be precise enough for that part of the timestamp on some platforms.

* Counters are hard to get right, especially if multiple processes may be calling this language library function and using the UUIDs side by side somewhere. So the implementation is sidestepping the whole problem of counters by not using them.

Alas, the fix for the problem only does the GOOS == "js" test when filling in rand_a. Unfortunately, it then checks for timestamp uniqueness always using rand_a as part of the timestamp value, which is not correct. The fix needs a little more work to not end up taking the extra 12 bits of random data as part of the timestamp, and potentially incrementing them, when the timestamp only has millisecond precision.

paulddraper 1 hour ago |

> This is because NewV7 assumes that the wallclock timer always has microsecond or nanosecond precision, though a browser's wallclock (new Date.getTime()) is millisecond precision.

That's true of Date, but not Temporal, which supported in most cases. [1]

There needs to be a fallback, but when supported `Temporal.Now.instant()` is the solution.

[1] https://caniuse.com/?search=temporal

john_strinlai 31 minutes ago | |

that wont work with anti-fingerprinting, which rounds

>In Firefox, the privacy.reduceTimerPrecision preference is enabled by default and defaults to 2ms.

saghm 23 minutes ago | | |

I thought some of the timer precision stuff was a specific security measure, not just a privacy one, because of stuff like Spectre[1]:

> The branch predictor would then be mistrained by iterating over a very large dataset using bitwise operations for setting the index to in-range values, and then using an out-of-bounds address for the final iteration. A high-precision timer would then be required in order to determine if a set of reads led to a cache hit or a cache miss. While browsers like Chrome, Firefox have restrictions on the resolution of timers, the Spectre author was able to create a high-precision timer using the web worker feature of HTML5.

> As of Firefox 57.0.4, Mozilla was reducing the resolution of JavaScript timers to help prevent timing attacks, with additional work on time-fuzzing techniques planned for future releases.

[1]: https://en.wikipedia.org/wiki/Spectre_(security_vulnerabilit...

OsrsNeedsf2P 25 minutes ago |

> I was gonna close this as wont fix, works as designed

Missing the forest for the trees