proposal-csprng icon indicating copy to clipboard operation
proposal-csprng copied to clipboard

Add spec text to be compatible with WebCrypto

Open rbuckton opened this issue 5 years ago • 8 comments

This Draft PR is intended to explore the possibility of devising a crypto global that would be compatible with the Web Cryptography API, such that web hosts could extend the API to encompass the full Web Cryptography API without issues with compatibility.

rbuckton avatar Feb 06 '20 03:02 rbuckton

be aware that the default node repl exposes builtin modules as globals and crypto is the name of one of them.

$ echo 'typeof globalThis.crypto' | node -i
Welcome to Node.js v12.13.1.
Type ".help" for more information.
> typeof globalThis.crypto
'object'

bmeck avatar Feb 06 '20 14:02 bmeck

I am aware, and mentioned that during the meeting as well.

rbuckton avatar Feb 06 '20 18:02 rbuckton

I don't think there's much of a concern with breaking this feature of node's repl, tho, is there?

ljharb avatar Feb 06 '20 18:02 ljharb

I have no opinion on breakage, just want to keep it recorded as being thought about.

bmeck avatar Feb 06 '20 18:02 bmeck

@bmeck I made your comment into an issue so that we can ensure we track this and follow up with someone from Node about concerns and possible remediations.

rbuckton avatar Feb 06 '20 21:02 rbuckton

There's a slight difference here in that getRandomValues as currently specified in WebCrypto must be invoked with a receiver which is a crypto object: (0, crypto.getRandomValues)(new Uint8Array()) fails.

Note that the receiver just needs to be a crypto object:

let i = document.createElement('iframe');
document.body.append(i);
i.contentWindow.crypto.getRandomValues.call(crypto, new Uint8Array());

works.

The fact that crypto works this way is pretty unfortunate and, as I understand it, is just an accident of history: I'm pretty sure it's because crypto was specified before namespaces were introduced to WebIDL, which was done specifically to make (0, console.log)() work (done here). But it is what it is.

bakkot avatar Feb 06 '20 21:02 bakkot

I don't believe this to be a web compatibility issue, however. Not throwing an error shouldn't make any existing code break today, though it would be worthwhile to discuss this more with someone directly involved with the WebCrypto spec about maintaining compatibility.

rbuckton avatar Feb 06 '20 21:02 rbuckton

@bakkot I've also made your comment above a separate issue so that we can track the discussion.

rbuckton avatar Feb 06 '20 21:02 rbuckton