Refine security and UX constraints for window.ipfs

[lidel]

(This is a continuation of endeavor to expose IPFS API as window.ipfs, started in #330)

IPFS Companion v2.2.0 shipped with window.ipfs enabled by default.

It has access controls in place, but is time to refine it it both in terms of UX (not nagging user when we can sandbox/scope instead) and security (sniffing/spoofing/fingerprinting).

Feel free to provide general feedback in this issue, we will extract specifics when needed.

Tasks

• Document a coherent framework for defining security constraints for window.ipfs
  It could be just a section in window.ipfs.md. The goal is to have a set of guidelines, our 'rule of thumb' to follow when a new API is added. Should simplify decisions such as: should API X be exposed under window.ipfs? does it require sandboxing/chroot?
  • Improving security of window.ipfs (low hanging fruits) Improving security of window.ipfs (low hanging fruits) #484
  • Support explicit whitelist of exposed APIs Support explicit whitelist of exposed APIs ipfs-inactive/ipfs-postmsg-proxy#29
• Enable users to disable creation of window.ipfs (Firefox only)
  (Prevent websites from knowing I have IPFS running in my browser) Enabling users to remove window.ipfs attribute #451
• Chrome Error: Please use a browser with webcrypto support Chrome Error: Please use a browser with webcrypto support #475
• Disable window.ipfs.config.{set,replace}. Provide a capabilities api. Disable sensitive APIs (eg. window.ipfs.config). Provide a capabilities API. #478
• [Improve] Performance of window.ipfs Performance of window.ipfs #460
• Privileged API access for WebUI Privileged window.ipfs API access for WebUI #514

Open Questions

• Restricting window.ipfs to Secure Context Restricting window.ipfs to Secure Context #476
• Should IPFS paths at different gateways share the same ipfs.files chroot? Should IPFS paths at different gateways share the same ipfs.files chroot? #453
• How to improve error handling "User denied access to ipfs.foo" Improve error handling for window.ipfs #455
• How to decrease number of dialog windows?
  • Idea to pre-emptively request permissions was suggested in Refine security and UX constraints for window.ipfs #454 (comment)

[JonKrone]

I have a question about UX. Is there a supported way for an app to pre-emptively request permissions?

Say an app window.ipfs.files.adds a big video file, it takes 2 minutes, and then wants to pubsub.publish the CID to some channel. Right now, we would wait to ask for the pubsub.publish permissions until after the file has uploaded. This can be a surprising UX when the action the app is taking has some delay between steps. You might have navigated away from the page or otherwise started doing something else, and then pop, a prompt comes up.

Test it out: setTimeout(() => window.ipfs.pubsub.publish('test', {}), 5000)

I think a better UX could be to provide a mechanism for pre-emptively asking for a group of permissions. Solutions that come to mind are like those that mobile app stores provide for apps (Apple's below).

I don't know how far it's possible to go with Browser prompt customization. We could do a super simple implementation that displayed a sequence of prompts for each permission. I think a proper solution requires moving away from browser prompts and opening the ipfs-companion extension view (not the settings page) with a permission screen or injecting a UI like a modal into the page.

That's a bit of a bummer but it also allows us to build a better permissions experience on top of it, like adding options for expiration!

[lidel]

This is a very good insight.

Yes, replacing one-dialog-per-api-method with one-dialog-per-scope would improve UX a lot, but it comes with a price tag attached.

The problem with a mechanism for preemptively asking for a group of permissions is that it means an app (app developer) needs to provide some kind of manifest beforehand, and window.ipfs proxy has to take care of parsing that manifest before app executes any real IPFS API calls.

To implement it, we would end up with something along these lines:

Dapp asking for a group of permissions

1. an app submits a manifest (list of ipfs.* method names) to a fake API,
   for example at window.ipfs.proxy.acl.whitelist(['id','files.write'])
2. a dialog is displayed to the user, listing all apis that app wants access to
3. [if user clicked Allow] window.ipfs allows access to apis from manifest without any further dialogs windows (pre-populates the whitelist)

It should be optional thing, meaning if app does not register manifest, it will still work as it does right now (a separate dialog for every API method it calls for the first time).

I don't like the smell of fake API, but as long we put it behind something like window.ipfs.proxy.* namespace, it should be acceptable and self-describing.

cc @alanshaw, @olizilla – thoughts?

[lidel]

(posing some updated notes that expand on the topic and provide basis for further discussion)

Exposing IPFS API on-demand in fingerprint-resistant way

After some time in the wild, we've identified some challenges that come with injecting window.ipfs by default on every page:

1. most of pages do not use it, but i) content script is big and ii) window attributes can be used for fingerprinting
2. dapps/pages that use it trigger multiple ACL dialogs that require user to accept every permission by hand, or give a blanket permission to all APIs
3. dapp developers are unable to ask for ACL whitelist for multiple APIs at once

We are thinking about characteristics of better schemes for exposing the IPFS API:

• exposing the IPFS API without compromising user's privacy
• low overhead, no expensive content scripts with opening ports by default
• It should work on-demand, where dapp developer specifies a list of APIs they need access at a time
  • avoids too many dialog windows by showing single dialog per bulk request (Refine security and UX constraints for window.ipfs #454 (comment))
• It should support updates of already existing ACLs, to enable developers to create educational pre-permission overlays (prior art from iOS)

A relevant scheme proposed by @Gozala:

• Using content script that would not add an API but rather await for a page / dapp to request it something like: document.dispatchEvent(new CustomEvent({…})))
• Once page does such a request, prompt user to get a consent.
• Once and if user gives permission, provide that custom API (possibly by dispatching CustomEvent containing that API)

Open problem with on-demand/await approach

• Dapps can't instantly check for potential availability of IPFS API: it needs to send an explicit request and await for response that may never come
  • this introduces a risk of slowing down dapp startup: how long should dapp wait for event with API from browser extension until it falls back to things like spawning own js-ipfs node?

[lidel]

Highly relevant development on window.web3 front:

On November 2nd, MetaMask and other dapp browsers will stop automatically injecting web3. Instead, dapps should request access using a new postMessage API.

We plan to release this breaking change on November 2nd, 2018, to commemorate the EIP proposing this change, EIP-1102

Source: medium.com/metamask

Not a big surprise, we've been thinking about doing something similar in this very issue.
MetaMask officially deprecating window interface is a strong signal that is the right direction.

This means window.ipfs in current form is switching into maintenance mode, and we will look into ways we can deprecate window.ipfs and move to something like postMessage API.

Note to self: MetaMask and IPFS are often used one the same websites. To make things easier for web developers, we should try to follow conventions established by their implementation of postMessage API where possible and change them only if it does not translate well to our needs.

[lidel]

Thank you all for the feedback about window.ipfs. We've gathered all the suggestions and now have a much better idea what could be improved. We are going to make it much better in Q4.

Future improvements and "window.ipfs 2.0" ideas from my previous comment
are now tracked in Meta: window.ipfs 2.0.