Privileged window.ipfs API access for WebUI

[lidel]

Background

We need a way to expose full API without any sandboxing or ACL controls for use in safe pages bundled with extension itself (eg. we plan to do that with new WebUI).
Below is the battle plan and work done so far.

cc @olizilla

Tasks

Prerequisites

• Secure window.ipfs first (remove access to sensitive namespaces)
  • ✔️ Improving security of window.ipfs (low hanging fruits) #484 (comment)
• Add PoC window.ipfs support to WebUI
  • ✔️ done, but more and more pages fail as they require access to ipfs.config.get and other sensitive spaces
• Provide a way of using window.ipfs without sandboxing (full MFS, r/w config etc)

Research

• Research if we can access window.ipfs in moz-extension:// contexts
  • ❎ the usual route won't work: regular context scripts are not injected into moz-extension:// URLs, even if <all_urls> is used (most likely a security feature to block extensions from snooping in internals of other extensions).
  • ✔️ ... however if we ship WebUI as a page under moz-extension://<companion>/webui/index.html, it will be running in browser extension context. This means it will see browser.* namespace, enabling it to detect browser.extension.getBackgroundPage() just like regular websites detect window.ipfs. This way the IPFS API Client used by extension itself can be obtained via WebExtension API directly.
    • 👍 Accessing client this way probably won't require any proxying, which is a huge win for performance. Pushing bits over postMessage is no fun performance-wise (eg. Storing files of a few megabytes to window.ipfs.files.add hangs Firefox for a minute or more #485) and this approach works around that problem space entirely.
    • 👉 This does not solve "privileged access" for third party dapps running in web browser context, everything remains sandboxed and ACL'd.

      • Digression: On the other hand it may be a security feature. It may not be a good idea to open such possibility before we have access controls at the HTTP API level in place (HTTP API, access control and API tokens notes#159, Is it possible now to use authenticate http token request?  notes#234). Even then, we have a solution for HTTP API. What about API exposed by embedded js-ipfs? Too many open questions. I feel window.ipfs in web browser should remain limited to non-sensitive namespaces for the foreseeable future.

Implementation

• Make WebUI into an embeddeddable NPM package
• Add WebUI as a dependency to IPFS Companion
• Implement feature detection (getBackgroundPage) in WebUI
  • PR: feat: add support for IPFS API exposed in ipfs-companion context ipfs-inactive/ipfs-redux-bundle#3
• Think about disabling window.ipfs in WebUI
  • Not used anyway: a non-privileged version of IPFS API is not enough for what WebUI wants to provide
  • It makes development harder (requires suspending IPFS Companion)
• What about IPFS Desktop? The plan was for it to use window.ipfs
  • Actually, there is more freedom in Electron context. We can just create a real HTTP API Client and use it the same way API accessed via getBackgroundPage is in browser extension.

---

Professor Butts and the Privileged API Access for WebUI (1931)

[lidel]

Note to self: support for this should land in https://github.com/ipfs-shipyard/ipfs-redux-bundle https://github.com/ipfs-shipyard/ipfs-provider

(detect browser.* namespace, get ipfs via browser.extension.getBackgroundPage())

[lidel]

Closing due to #589 (comment)
Access to IPFS node is guarded by CORS, relevant explainer and error recovery landed in ipfs-webui a while ago.