[go: nahoru, domu]
Skip to content

Latest commit

 

History

History
137 lines (87 loc) · 5.73 KB

2017-10-02--lab-week-discussions-on-ipfs-in-browser-extension.md

File metadata and controls

137 lines (87 loc) · 5.73 KB
Raw

Roadblocks for IPFS in Browser Extension

This memo is a summary of various conversations we had during Lab Week for Q4 2017, starting with unconf session on Monday.

TL;DR

  • Right now, ipfs-companion requires external daemon and just pretends to support ipfs://, dweb: protocols,
  • we've identified Three Problems that need to be solved to have IPFS running natively in browser extension,
  • creation of Programmable Protocol Handler API would solve all of them.

Identified Problems

Problem #1: Inability to Inject HTTP Responses by WebExtension

It is possible to run js-ipfs node in extensions background page, but when it comes to major players in browser space we are missing WebExtension API that "enables the extension to satisfy hijacked HTTP request by injecting response read by js-ipfs".

As of now (2017) browser.webRequest API makes it possible to:

  • cancel the request in onBeforeRequest, onBeforeSendHeaders and onAuthRequired
  • redirect the request in onBeforeRequest, onHeadersReceived
  • modify request headers in onBeforeSendHeaders
  • modify response headers in onHeadersReceived
  • supply authentication credentials in onAuthRequired

What is missing are means of providing response payload instead of redirection in onBeforeRequest step of request life cycle.

Problem #2: Inability to Control How Origin Is Calculated

Web security model relies on Same-origin policy.

This introduces two major inconveniences for websites loaded via IPFS2HTTP gateways (serving content from /ipfs/ and /ipns/ paths):

  • every IPFS gateway has different Origin, making it impossible for a user to persist state while switching gateways
  • an Origin of a single gateway is shared by all sites loaded from it, making it impossible to write secure web apps

Some people solve this by creating artificial subdomains that have URL-safe CID in them ($cid.ipfs.dweb.link). A subdomain provides separate Origin and creates an isolated security context.

Unfortunately, this is not possible for a gateway running on 127.0.0.1.

Problem #3: Inability to Control Address in Location Bar

This is a major UX issue.

We should have:

dweb:/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

instead of:

http://127.0.0.1:8080/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

Possible Solutions

Temporary Hacks and Partial Workarounds

Problem #1 might be (partially) solved with:

Creative Use of Service Worker

We could have js-ipfs running inside of a Service Worker acting as a 'proxy' for HTTP requests to the public gateway.

See demo and PoC at IPFS runs as a Service Worker.

  • Good:
    • service worker can inject responses for a host it was installed from
    • if we provide Service Worker for the public gateway, and browser extension redirects everything to public gateway, then we are able to handle all IPFS requests
    • transparent for the end user
  • Bad
    • a user needs to visit regular HTTP site to install Service Worker
    • if we want to solve #2 we need to have separate service worker for every gateway/root CID
    • no connection closing + global Service Worker = memory leaks
    • does not address #3

Extending webRequest API to Support Response Injection

In theory, extending existing browser.webRequest APIs to support response generation (e.g. from within onBeforeRequest hook) would enable us to hijack requests and respond with data read via js-ipfs.

There is a very low probability that such API change will happen, these APIs were designed this way with certain security constraints in mind.

Even if it would happen, it would not address problems #2 and #3.

New, Native, Programmable Protocol Handler API for WebExtensions

What we really need is a new WebExtension API that lets us define a programmable protocol handler.

Such API should enable browser extension to do three things:

  1. Respond to dweb: requests with actual payload (no redirect to HTTP).

    To be more specific, WebExtension should be able to provide function that takes a URI and returns new Response(data, headers)

  2. Control how Origin is calculated.

    In case of /ipfs/$cid, every CID would have its own Origin.

  3. Display and support use of dweb: address in GUI (location bar, bookmarks, etc)

    This would not only improve user experience but also enable us to use dweb: links by default.

The good news is that creation of such API was already proposed in Bug 1271553: Add ability to implement programmable custom protocol handler.

The bad news is that it won't happen this year, as most of the engineering efforts at Mozilla are focused on Firefox Quantum release.

Still, this is the best way to solve our Three Problems.

We should advocate creation of such API, as it would not only enable us to do great things with IPFS browser extension, but could enable Firefox to become an application platform.