Should we support or forbid TypedArrays backed by SharedArrayBuffer

[rbuckton]

The getRandomValues method in the Web Cryptography API does not specify whether a SharedArrayBuffer is permitted in its specification text. Per w3c/webcrypto#213 it seems that implementations forbid its use.

• Should we also forbid use of SharedArrayBuffer?
• If we allow SharedArrayBuffer, do we need to set any expectations around getRandomValues not being an atomic operation (i.e., other threads might see a partially written buffer)?

[annevk]

I suspect that would allow for creation of a high-resolution timer and would therefore need to be behind the cross-origin isolated flag (COOP+COEP) at least in some host environments.

[ckknight]

Given that one could fill an ArrayBuffer with random data and then manually copy that data (in an atomic way, even) to a SharedArrayBuffer, then it seems like the safest default is to forbid SharedArrayBuffer. In the future, I could imagine a SharedArrayBuffer.fillRandom that may have different semantics where atomicity is controlled.

[vapier]

Considering platforms might be able to mitigate the hrtimer attack (e.g. Chrome's site isolation), it seems wrong for the spec to ban. Leave it to the platform to decide whether it may be safely supported.

[annevk]

Chrome's site isolation is not sufficient mitigation and they also plan to migrate to a more restrictive environment: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer/Planned_changes.

[vapier]

So you agree that the spec shouldn't be banning it, but leaving it to implementations to decide whether & when it is supported.

[annevk]

I'm saying that if it's allowed there needs to be a hook for host environments that can indicate whether it's supported so it can plug into the cross-origin isolated flag in HTML, for instance.

[vapier]

Sure, but that's an implementation consideration/problem, not something the spec needs to be mandating.

[annevk]

No it's not, it's a host problem and something the host needs to have a say over. I.e., it's a spec problem.

[vapier]

I have no idea what you mean by "host". The spec is not a host.

Whether implementations are able to support shared buffers safely as a backend (or whether the concerns at hand are even relevant) is something only implementations can possibly know. The spec should not be forbidding behavior simply because some implementations (which don't even support SharedArrayBuffer now for webcrypto APIs) don't take into consideration all the factors.

[annevk]

https://tc39.es/ecma262/#sec-overview second sentence.

[vapier]

The second sentence doesn't define "host" precisely. But the high level statement seems to agree with/match my points.

The only thing that knows whether shared array buffers may be used safely is the host environment, not the spec. Hence the spec should not be banning its usage.

Simply fix the spec to say that shared array buffers are permitted, but the host environment may block its usage, and then include a non-normative section giving examples of where that might come up.