Control how content origin is determined

olizilla commented 6 years ago

Content addressing replaces the notion of a content "origin" with a trustless, p2p integrity checking, so you can reliably fetch content from any and all peers that have it. Domains as the content origin are a core assumption used in the browser security model. We need to define how Origin should be calculated for originless content addressed uris.

Distilled needs are:

A) Ability to register custom protocol handler (to make this example generic let's call it "foo://")

B) Opening "foo://origin/path/to/resource" loads HTTP(S) resource from "https://httpgateway/foo/origin/path/to/resource" but with two caveats:
B.1) "origin" as the Origin (this is crucial, so that cookies, local storage
    etc is the same no matter which "httpgateway" is used).

   Ideally, it would be great if we could specify which URL segments
    are used for Origin computation, for example:

    Opening "bar://originprefix/origin/path/to/resource" loads HTTP(S) resource
    from "https://httpgateway/bar/originprefix/origin/path/to/resource"
    with "originprefix/origin" as Origin.
B.2) Keeping canonical "foo://origin/path/to/resource" in Location Bar (hiding underlying HTTP transport for improved user experience)

In short, keeping canonical address in Location Bar together with programmable Origin calculation would enable us to extend Firefox with new protocols in a way that provides great UX and is compatible with Origin-based security model.

olizilla commented 6 years ago

notes to self

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

An origin is either

A scheme, host, and port of the parsed "network scheme" URL, one of [http, https, ftp] spec.
An opaque origin, a unique implementation specific identifier for a non-network url e.g. a data: url
If we can get hash based addresses to be treated as opaque origins with stable identifiers per hash, that'd work. That might be easier than getting them added to the list of network scheme urls.

Suborigin

Suborigins, in fact, do not provide any new authority to resources. Suborigins simply provide an additional way to construct Origins. That is, Suborigins do not supercede Origins or provide any additional authority above Origins. From the user agent’s perspective, two resources in different Suborigins are simply in different Origins, and the relationship between the two resources should be the same as any other two differing origins as described in HTML Standard §origin and [RFC6454].

https://w3c.github.io/webappsec-suborigins/#suborigins-vs-origins

Suborigins let the content source specify an additional level of isolation in addition to the current origin. A suborigin is the origin plus an suborigin header.
This would be useful for an ipfs gateway to re-host hashes for peers, but isolate each one per hash, rather than allowing each to share the sandbox of the gateway itself.
Workaround: Hostname safe HTTP content addressing - https://github.com/neocities/hshca
- Share content hash as base32 encoded subdomain.

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/

Related to origin but a separate issue, it would be appropriate to flag content-addressed files as a Secure Context, as their content can be validated from their address, an essential property of content-addressing. The browser would have to trust that the provider (e.g ipfs daemon) has ensured that the content received was valid before passing it on.

Without he 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/

lidel commented 6 years ago

Initial draft was merged with #17, some remaining questions extracted from that PR:

Suborigins:

It's be worth thinking about if sub-origin for gateways should be a separate issue.

Programmable Origin:

What would the api for this look like? How would a WebExtension inform the browser what the Origin is for the content and that it should be considered a Secure Context?

olizilla commented 6 years ago

https://github.com/mozilla/libdweb/issues/2

arewedistributedyet / arewedistributedyet