Accept shared ArrayBufferView also?

[jimmywarting]

I tried to use shared ArrayBuffer view along with crypto api. Didn't work

crypto.getRandomValues(new Uint8Array(new SharedArrayBuffer(1)))
crypto.subtle.digest(algo, sharedBuffer)

Failed to execute 'getRandomValues' on 'Crypto': 
  The provided ArrayBufferView value must not be shared.

Failed to execute 'digest' on 'SubtleCrypto': 
  The provided ArrayBufferView value must not be shared.

Is there any reason why it would not be allowed? didn't find any issue or text in the spec mention anything about sharedArrayBuffer

[sideshowbarker]

Jimmy, do you have a plan for getting some browser implementors engaged in discussion here about this proposal?

[jimmywarting]

not really

[sideshowbarker]

OK, then unless there’s somebody else who weighs in on this relatively soon with some plan, I’m gonna propose that we close this

[jimmywarting]

Today i tried to use BigUint64Array with getRandomValues

I think some web crypto stuff have fallen behind since we have got new types of array's (big int, sharedArrayBuffer etc)
This didn't work in chrome, FF, and Safari TP are missing BigUint64Array

crypto.getRandomValues(new BigUint64Array(1))

Chrome:
Uncaught DOMException: Failed to execute 'getRandomValues' on 'Crypto': 
The provided ArrayBufferView is of type 'BigUint64', which is not an integer array type.

BigUint64Array is a ArrayBufferView so it should work imo.
ArrayBuffer.isView(new BigUint64Array(1)) // true

Looking at the spec then it looks to be somewhat outdated... and don't seem to be a specific browser issue.

10.2.1. The getRandomValues method
The getRandomValues method generates cryptographically random values. It must act as follows:

If array is not of an integer type (i.e., Int8Array, Uint8Array, Int16Array, Uint16Array, Int32Array, Uint32Array or UInt8ClampedArray), throw a TypeMismatchError and terminate the algorithm.

Why should it be just dose types? I think it should be changed to something like eg:
"If array is not of an ArrayBufferView or a (Shared)ArrayBuffer" throw a TypeMismatchError and terminate the algorithm.

[ChALkeR]

Why should it be just dose types? I think it should be changed to something like eg:
"If array is not of an ArrayBufferView or a (Shared)ArrayBuffer" throw a TypeMismatchError and terminate the algorithm.

getRandomValues should not accept float views, as filling floats with random binary data won't give any meaningful distribution of values. Moreover, a significant part will be (different) NaNs. Definitely not usable in anything near cryptography.

That's a footgun that would be used incorrectly
It still can be, with manual conversion, but a reminder not to do that (which not accepting them directly is) is helpful

[sideshowbarker]

I'm going ahead and closing this. There's been no implementor interest expressed in this at all, and there's been no evidence of any effort having been made to seek out or gauge implementor interest on it.

@twiss if you reckon we should still keep this open, of course feel free to reopen it.

[vapier]

it feels like this issue was reported for one reason (shared array buffer support), but got lost in the weeds in debating taking ArrayBufferViews vs TypedArrays. do we need to file a 2nd bug to clarify ?

shared array buffers are gaining in importance as implementations improve support for threading, or as a way of reducing message passing overhead.

[sideshowbarker]

it feels like this issue was reported for one reason (shared array buffer support), but got lost in the weeds in debating taking ArrayBufferViews vs TypedArrays. do we need to file a 2nd bug to clarify ?

Please do file a separate issue, if you believe it merits one.