The only reason you can think of is a weird conspiracy?

WebCrypto only arguably skirts Mozilla's original (2015) definition of new features that shouldn't be enabled for insecure contexts.

(Mozilla says you might want to allow new features that could anyway be polyfilled, and though a polyfilled WebCrypto would be slow and under powered it could be built)

You can't bootstrap your "security on network channel (in web app)" without a secure origin because it's a house built on sand.

Some of the things people want to do in that issue are merely daft (e.g. people who are sad that they can't access a crypto-hash for their problem which would be much better suited to a fast non-crypto hash) but a bunch of them, like yours, involve hand-waving the real problem and then insisting you need "security" on a fundamentally insecure basis. If you actually trust that network then you don't need "security on network channel" and if (as is much more likely) you don't or shouldn't trust it then the exercise is hopeless because that network can trivially betray every element of your hoped-for WebCrypto feature set if you don't have a secure origin.

Well, I'm not just hand-waving (at least I don't think I am), I'm actually got burnt by this. I was building a demo of my app on top of libp2p, and then I discovered that I need to issue domain name and certificate for each node in my p2p network.

This wasn't hard – caddy2 makes it super easy. But I see it as a pretty weird requirement. I don't understand, why can't I sign some data with public key without being on secure origin.

> The only reason you can think of is a weird conspiracy? I didn't mean to assume conspiracy theories, I agree that this is a pretty unprobable story. I'm just saying: "It's so weird that my only sound explanation is a weird conspiracy theory", meaning that I don't understand how this came to be, and motivation behind that :)

> why can't I sign some data with public key without being on secure origin.

I'm guessing you mean sign with a private key.

In a secure context the Browser gets to promise the context that this private key stays private if it wants. For example, should the the private key be posted to Twitter?

In a secure context you get to decide, because only code your wrote runs in that context, if you don't add "post private key to Twitter" code then it doesn't happen.

But in insecure contexts any on-path attacker can substitute their own code for yours. Now your "private" key is in a Twitter post, hilarious.

How do you implement your own security on a network channel if the first network request is over http and subject to man in the middle attack?

Does ed25519.sign not work on origins with self signed certs?

If you don't trust the CAs, then getting a certificate from one of them so that https is enabled and crypto works is no worse than no encryption at all, is it?

I understand it might give people a false sense of security, or perhaps they trust the CA system and it's not false in their eyes, but if distrust of CAs is the reason to use plaintext connections instead, I'm not sure that's the best choice.

I think the issue is that your use of the crypto functions is dependent on permission from a CA. Depending on the nature of the application you're serving over HTTPS, a CA could be compelled under DMCA to revoke your certificate, and thus your permission to use the crypto APIs.

I suppose that's a valid point, even if it seems far-fetched that this would be the most effective way of killing someone's software.

I know it's going to be more effort, but is anything physically stopping you from running whatever crypto you like as a wasm module? I'm sure one could do NaCl-over-wasm?

I agree it's not the same convenience as having an API built in though.

There's a great wasm-crypto library out there, and while its authors are doing amazing work, there's much more effort put in WebCrypto by a lot more people.

There's also an option to compile some e.g. Rust library to wasm, and use it, but it could hide some exotic security vulnerabilities that arise only in this narrowly-adopted use case, so it's a pretty high risk.