Skip to content
This repository has been archived by the owner on Aug 24, 2021. It is now read-only.

Why the requirement on webcrypto? #22

Closed
jackkleeman opened this issue Mar 23, 2017 · 7 comments
Closed

Why the requirement on webcrypto? #22

jackkleeman opened this issue Mar 23, 2017 · 7 comments
Labels
exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue P2 Medium: Good to have, but can wait until someone steps up

Comments

@jackkleeman
Copy link

It would be fairly simple to import native-crypto or a similar library that falls back on js libraries for crypto in the absence of webcrypto; in the meantime, js-ipfs doesn't work in a webworker in safari, and in other bad browsers.

@dignifiedquire
Copy link
Member

If you want to do that, you can shim the global object appropriately. But we don't want to include these shims as they increase the bundle size very considerably.

@jackkleeman
Copy link
Author

Ok true, why not use js libraries for hash functions though? Is the performance improvement worth the loss in browser support?

@dignifiedquire
Copy link
Member

Is the performance improvement worth the loss in browser support?

The combination of size increase + performance was worth for us yes. The majority of js-ipfs in the browser relies on webrtc to do real peer to peer connections in the browser, which restricts us to new browsers already in a lot of use cases.

But it would be great to have a shim that one could just include in older browsers to offer support there. It shouldn't be too hard to implement one that just takes the js based implementations and emulates the same api.

@dignifiedquire dignifiedquire changed the title Require webcrypto Why the requirement on webcrypto Mar 23, 2017
@dignifiedquire dignifiedquire added the kind/support A question or request for support label Mar 23, 2017
@dignifiedquire dignifiedquire changed the title Why the requirement on webcrypto Why the requirement on webcrypto? Mar 23, 2017
@daviddias
Copy link
Member

The combination of size increase + performance was worth for us yes.

Almost 10x perf improv. It is definitely valuable to have a way to use JS crypto libraries instead of WebCrypto, happy to accept a PR that brings that in.

@daviddias daviddias added the status/deferred Conscious decision to pause or backlog label Apr 5, 2017
@jackkleeman
Copy link
Author

I have my own fork which uses the native-crypto package, which will use webcrypto when available and js libraries elsewhere. It might be overkill for this though, as we only use hashing functions.

https://github.com/duomarket/js-multihashing-async

Note this fork uses a native-crypto global when available, it's not a dependency, this is because in my use case native crypto is imported by a different browserify bundle.

@daviddias daviddias added status/ready Ready to be worked exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue P2 Medium: Good to have, but can wait until someone steps up and removed status/deferred Conscious decision to pause or backlog kind/support A question or request for support labels Oct 17, 2017
@lidel
Copy link
Member

lidel commented May 10, 2018

FYSA WebCrypto in Chrome is available only in secure contexts and Firefox is also planning to introduce the same restriction.

We should provide a better error message to address errors caused by insecure origin (PR #30).

@hugomrdias
Copy link
Member

old issue gonna close this, feel free to reopen

@ghost ghost removed the status/ready Ready to be worked label Apr 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exp/expert Having worked on the specific codebase is important help wanted Seeking public contribution on this issue P2 Medium: Good to have, but can wait until someone steps up
Projects
None yet
Development

No branches or pull requests

5 participants