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.
> 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.
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.
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.
> 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
that wont work with anti-fingerprinting, which rounds
>In Firefox, the privacy.reduceTimerPrecision preference is enabled by default and defaults to 2ms.
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...
Shucks, it works in the spec.
> I was gonna close this as wont fix, works as designed
Missing the forest for the trees
Why the bad faith interpretation, the very next like they cite the RFC and realise their mistake