Downstream crypto modules wont work on insecure (http) sites

[andrewheadricke]

I just realized that I cant use this module on HTTP hosted sites due to webcrypto restrictions on insecure sites.

There are plenty of custom hashing libraries that do work on HTTP, is it possible to add a fallback option in case crypto.subtle is not available?

Interestingly, Firefox works even on HTTP, but Brave does not. And in Brave, window.crypto exists, which is why the checks here https://github.com/multiformats/js-multihashing-async/blob/3fcbe427b10452f653f3d9219d295fdff9116984/src/sha.browser.js#L8 don't catch it.

[mikeal]

We may want to move this bug tomultihashing-async.

Interestingly, Firefox works even on HTTP, but Brave does not. And in Brave, window.crypto exists, which is why the checks here https://github.com/multiformats/js-multihashing-async/blob/3fcbe427b10452f653f3d9219d295fdff9116984/src/sha.browser.js#L8 don't catch it.

We should make the check for web.crypto more resilient, we should just consider this a bug in cross-browser support.

There are plenty of custom hashing libraries that do work on HTTP, is it possible to add a fallback option in case crypto.subtle is not available?

It’s rather difficult to “fallback” without increasing the bundle size for the non-fallback use case.

If we use import() then webpack will do code splitting, but that will drastically increase the startup for the fallback since these hashes are needed very early and this will cause another roundtrip. What you want is for people who need the fallback to have it in their bundle, and for people who don’t to not have it in their bundle, since this use case splits more along application lines than individual user lines, since an application is either served over HTTPS or it isn’t.

So we’re left with a few options:

• Separate packages for each use case.
• Add an API to configure the hash function. This would optimize for the HTTPS case but allow for a user to import and configure a different hash function. It’s a manual step, but probably the right one.

In general, I don’t think that we should optimize the default experience for insecure protocols. Browsers are getting very aggressive about locking down functionality for insecure protocols, rightly so, and we’ll find it quite difficult to continue to ship usable innovations if we have to support insecure protocols OOTB.

[rvagg]

For anyone else interested in the reasoning and history surrounding this, see w3c/webcrypto#28, it's a fascinating study in the quest for the perfect vs the reality of modern development (especially lower comments and note reactions). Or perhaps it's the theoretician class vs the practitioner class.

[andrewheadricke]

My app is decentralized and is expected to be running on both HTTP and HTTPS depending on where and how the user is accessing it (LAN/IPFS etc). So I would prefer to ship it with a larger bundle that contains the fallback hashing algos.

It seems to me the webcrypto detection could be improved to handle the cross-browser differences a bit better, then simply fallback to non native hashing if its been included in the bundle. I think that is similar to what you mean by add a API to configure the hash.

Without rehashing (pardon the pun) what was said in the w3c chat linked above, HTTPS is a big problem for decentralized applications, the two are not compatible. HTTPS as used by modern browsers demands a central entity dictate who can do what.

[andrewheadricke]

Will pursue this on the js-multihashing-async repo. Thanks for the feedback.

[andrewheadricke]

Did some experimentation, I removed js-multihashing-async and replaced it with js-multihashing, this blew out the size to over 600KiB. So then I replaced it with sha.js and a hard-coded sha2-256 on the blob. Seems to work. Bundle size was reduced a little. I'll live with sha2-256 only for the time being.