What is needed to extend browsers with p2p protocols.

[olizilla]

We should be able to resolve p2p schemes from our browsers address bar. dweb links should work. We should be able to host websites on IPFS and browse them via their root hash. Same for Dat addresses.

We need to demonstrate the value of a new protocol before we can hope to get native support for it in browsers. We'd like to use the WebExtensions apis to show how users can benefit from these new protocols, but there are some missing pieces.

The first thing we need is to be able to register a protocol handler that is invoked when the browser is asked to fetch a URI that matches the new scheme, and can return the response for the browser to render. Right now our only option is to hook into all requests, and optionally redirect them to a different http url. We want to fetch verifiable content from our nearest peers via new protocols. To enable that, browsers must be able to delegate the details of how a resource is retrieved to a WebExtension.

Browsers are not passive content explorers. They are sandboxes for remote code execution. There is a large and ongoing investment from implementors and standards groups to ensure that there is a considered security model for our interactions on the centralised web. A WebExtension that implements a p2p protocol will need apis that let it return responses and provide a context for that response that maps the nuances of the new protocol to existing web security concepts.

Consider a resources Origin:

Origins are the fundamental currency of the Web's security model. Two actors in the Web platform that share an origin are assumed to trust each other and to have the same authority. Actors with differing origins are considered potentially hostile versus each other, and are isolated from each other to varying degrees.

• https://html.spec.whatwg.org/multipage/origin.html#origin

IPFS uses content-addressing to peers to ask the network for a resource without specifying an authority or location as the provider. You ask the network for what you want rather than where you want. Content can be provided by any peer that has it. The IPFS WebExtension would need to be able to catch a request for a dweb:/ipfs/QmExampleHash/foo/bar/main.js style URI, fetch the content from some peers, and pass the response to the browser along with a context that defines the origin for that content as being it's content identifier (CID)/ipfs/QmExampleHash. An IPFS CID serves as a useful equivalent to an authority for the purposes of defining the scope of what resources share a origin style trust scope. All paths beneath a CID are cryptographically known to have been deliberately bundled together.

At this point browsers have no specific insights into the nuances of any new p2p protocol, but to usefully support their adoption, they will need to provide a mechanism for their WebExtensions to inform them of the origin value that should be used for a given response. The browser will have to trust that the web extension has implemented a sensible mapping for the concept. This leap of faith may take some convincing, but is a necessary step if we are to enable people to share content in new ways.

Of note, an origin is either

• A scheme, host, and port of the parsed "network scheme" URL, one of [http, https, ftp] spec.
• or an opaque origin, a unique implementation specific identifier for a non-network url e.g. a data: url

If we can get hash style addresses to be treated as opaque origins with stable identifiers per CID, that could offer a less complicated path for implementors.

Then consider Secure Contexts

A secure context is a Window or Worker for which there is reasonable confidence that the content has been delivered securely (via HTTPS/TLS), and for which the potential for communication with contexts that are not secure is limited. Many Web APIs and features are only accessible in a secure context. 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.

• https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts

The most obvious of the requirements discussed here is that application code with access to sensitive or private data be delivered confidentially over authenticated channels that guarantee data integrity. Delivering code securely cannot ensure that an application will always meet a user’s security and privacy requirements, but it is a necessary precondition.

• https://w3c.github.io/webappsec-secure-contexts/

To ensure the integrity of responses that come from an authority, browser mark responses served over an https encrypted channel with a valid TLS cetificate and the centralised chain of trust behind it.

Without the blessing of a SecureContext, content loaded via new protocols doesn't get access to new apis like WebCrypto #8 and going forwards, Firefox is demanding SecureContexts for all new apis https://blog.mozilla.org/security/2018/01/15/secure-contexts-everywhere/

To function as a p2p protocol each implementor will have to find a mechanism to be able to retrieve content from peers without relying on trust for the integrity of the responses. Cryptography is the obvious candidate here. IPFS and WebTorrent will request resource by the hash of their content, and will verify the integrity of the response as a fundamental part of the protocol. It would be reasonable to allow them access to the WebCrypto apis to do that, and a WebExtension will need to be able to hint to the browser that the response it is handing over should be considered a Secure Context if by the nature of the protocol it is not susceptible to MITM attacks and can prove the integrity of each resource.

To be continued... on the next episode... WebRTC vs a TCP/UDP sockets api, and WebCrypto streaming vs Userland WASM Crypto.

[olizilla]

[alanshaw]

This is awesome!

An IPFS CID serves as a useful equivalent to an authority for the purposes of defining the scope of what resources share a origin style trust scope.

I'm finding this sentence hard to understand. I think I know what you mean but it could do with a re-wording!

[olizilla]

Super interesting discussion happening about this on mozilla/libdweb#2