> The most important problem with this scheme is that there's no way to provide assurance that the browser JS runtime is what the user of an application expects it to be.
That's correct. We only use the native runtime (ie, no shims) but obviously users have to trust that that's the case unless they want to inspect the code. If there's no working window.crypto (or for certain blacklisted platforms with partial implementations) we go straight to out-of-browser keygen. Furthermore, the user has to trust that we're not sending the private key back to us by some channel: they could do this fairly easily by inspecting the code but if they're uncomfortable it's easier to click the 'make keys on my server' option.
That's correct. We only use the native runtime (ie, no shims) but obviously users have to trust that that's the case unless they want to inspect the code. If there's no working window.crypto (or for certain blacklisted platforms with partial implementations) we go straight to out-of-browser keygen. Furthermore, the user has to trust that we're not sending the private key back to us by some channel: they could do this fairly easily by inspecting the code but if they're uncomfortable it's easier to click the 'make keys on my server' option.