Restricting window.ipfs to Secure Context

[lidel]

TL;DR
This is a notice of intent to ensure window.ipfs is available only in Secure Contexts.

Rationale

Re-use existing security perimeter and take advantage of its guarantees

The primary goal of secure contexts is to prevent man-in-the-middle attackers from accessing powerful APIs that could further compromise the victim of an attack. #

Follow convention of requiring secure context for all new features

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts. #

Avoid shimming of existing Web APIs in insecure contexts

Many Web APIs and features are only accessible in a secure context. #

Transitive dependencies such as js-multihashing-async rely on Web Crypto API, which does not work in insecure contexts, as noted in #475. This means we can't do a simple window.ipfs.object.put() without providing userland implementation of webcrypto before ipfs-postmsg-proxy is injected into every webpage.

While doable, it may not be feasible for multiple reasons:

• We want to be good web citizens
  • Browsers established secure context for good reasons, and if we start shipping workarounds that break guarantees of secure context it will send a very bad message.
• Increased bundle size and code complexity
  • Userland libs that provide webcrypto functionality will be used rarely, but need to be always shipped.
  • Insecure context in Chrome 65 exposes crypto but not crypto.subtle which requires additional orchestration.
  • Just not cost-effective: insecure contexts are a small % of real life usage. It makes more sense for website owner to fallback to own instance of js-ipfs/js-ipfs-api and webcrypto shims there, than introducing window property that exposes local node in insecure context.
• Degraded performance
  • We could shim with things like asmcrypto.js, but still much slower than a native API
  • More code injected to every webpage == degraded browsing experience

Related Reading

• Understanding Security Concerns around Browsers
• Refining security and UX constraints for window.ipfs
• Mozilla: Secure Contexts
• window.isSecureContext
• Mozilla Security Blog: Secure Contexts Everywhere
• Features restricted to secure contexts

[lidel]

No negative feedback so far. Assuming its fine to do this change, will PR soon.