You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This was brought up at TC39, with respect to whether random UUIDs should be based on a separate API that would provide a single "source of truth" for generating cryptographically-secure pseudo-random numbers similar to crypto.getRandomValues. This had to do primarily with @erights's concerns about mocking an API.
The main issue with possibly subsuming crypto.getRandomValues from the Web API is the dependence on DOMException-derived errors, and that changing those cases to TypeErrors and RangeErrors could go against "web reality" where people may be filtering exceptions using instanceof.
I put together an outline for a proposal to adopt the semantics of crypto.getRandomValues under a different name, and wanted to spark further discussion here before considering whether to make it a full-blown proposal: https://gist.github.com/rbuckton/0777210dc3086e1a90375354b045a3a7
The idea being to add an ArrayBuffer.fillRandom(view) static method that uses the same semantics as the Web Crypto APIs, except with the errors swapped. I propose making it a method on ArrayBuffer for several reasons:
Does not introduce a new global namespace for cryptography, as specifying a crypto global in ECMA-262 could cause complications with how to specify it such that the Web cryptography APIs could be layered on top.
Provides a single location for mocking the CSPRNG, vs a method on each TypedArray prototype.
The text was updated successfully, but these errors were encountered:
This was brought up at TC39, with respect to whether random UUIDs should be based on a separate API that would provide a single "source of truth" for generating cryptographically-secure pseudo-random numbers similar to
crypto.getRandomValues
. This had to do primarily with @erights's concerns about mocking an API.The main issue with possibly subsuming
crypto.getRandomValues
from the Web API is the dependence onDOMException
-derived errors, and that changing those cases toTypeError
s andRangeErrors
could go against "web reality" where people may be filtering exceptions usinginstanceof
.I put together an outline for a proposal to adopt the semantics of
crypto.getRandomValues
under a different name, and wanted to spark further discussion here before considering whether to make it a full-blown proposal: https://gist.github.com/rbuckton/0777210dc3086e1a90375354b045a3a7The idea being to add an
ArrayBuffer.fillRandom(view)
static method that uses the same semantics as the Web Crypto APIs, except with the errors swapped. I propose making it a method onArrayBuffer
for several reasons:crypto
global in ECMA-262 could cause complications with how to specify it such that the Web cryptography APIs could be layered on top.TypedArray
prototype.The text was updated successfully, but these errors were encountered: