Skip to content

Origin Policy in ÐWeb

Jump to bottom
Irakli Gozalishvili edited this page Aug 15, 2018 · 1 revision

Origin Policy is fundamental mechanism browsers use to control interactions between two different origins. An origin is defined by the scheme, host, and port of a URL. Generally speaking, documents from different origins are isolated from each other and interactions between them is restricted. Interactions can be grouped into following categories:

Network access

  • Cross-origin writes are typically allowed. Examples are links, redirects and form submissions.

  • Cross-origin embedding is typically allowed.

    • JavaScript with <script src="..."></script>. Error messages for syntax errors are only available for same-origin scripts.
    • CSS with <link rel="stylesheet" href="...">. Due to the relaxed syntax rules of CSS, cross-origin CSS requires a correct Content-Type header. Restrictions vary by browser: IE, Firefox, Chrome, Safari (scroll down to CVE-2010-0051) and Opera.
    • Images with <img>. Supported image formats include PNG, JPEG, GIF, BMP, SVG, ... Media files with <video> and <audio>.
    • Plug-ins with <object>, <embed> and <applet>.
    • Fonts with @font-face. Some browsers allow cross-origin fonts, others require same-origin fonts.
    • Anything with <frame> and <iframe>. A site can use the X-Frame-Options header to prevent this form of cross-origin interaction

  • Cross-origin reads are typically not allowed, but origin owner can enabled through CORS.

    Read access is often leaked by embedding. For example, you can read the width and height of an embedded image, the actions of an embedded script, or the availability of an embedded resource.

Script API access

Documents with a same origin can interact directly across <iframe> / window.opener but are limited to interactions via message passing using window.postMessage otherwise.

Data storage access

Access to data stored in the browser such as localStorage and IndexedDB are separated by origin. Each origin gets its own separate storage and quota. JS in one origin cannot read or write to the storage belonging to another origin.

Cookies use a separate definition of origins. A page can set a cookie for its own domain or any parent domain, as long as the parent domain is not a public suffix.

ÐWeb Protocols

As of this writing Origin Policy has being problematic in ÐWeb space. No browser (except Beaker) supports ÐWeb network protocol natively so ÐWeb content is often delivered through gateways like http://gateway.ipfs.io/, https://viewer.scuttlebot.io/, https://dat.land/ therefor all content ends up sharing same origin.

Note: Protocol implementers were hoping that browsers would implement support for Suborigins specification that would mitigate this issue, but so far no browser does.

Dat

In dat protocol URLs consist of scheme dat and unique identifier (public key) that is persistant pointer to mutable dataset that only author (private key owner) can update. Beaker browser uses scheme and the that unique identifier as on origin which maps directly to semantics in HTTP(S).

IPFS

In IPFS all resources are content addressible. URLs consist of scheme ipfs and hash of the content. On one hand that implies that each resource will end up with a different origin, but on the other directory of fires also has it's hash and therefor scheme and hash combination still maps fairly well to the way browsers define Origin Policy.

Note: In IPFS if you were to publish directory with two files:

  • index.html
  • image.png

Each file would have it's own IPFS address like:

  • ipfs://${index_html_hash}
  • ipfs://${image_png_hash}

But also directory will get own IPFS address and individual files relative addresses to it:

  • ipfs://{dir_hash}
  • ipfs://{dir_hash}/index.html
  • ipfs://{dir_hash}/image.png

Applications would need use relative URLs in order to share origin.

In IPFS mutable namespace is possible through ipns protocol where unique identifier (public key) is mapped to an ipfs resource than only author (private key owner) can update. Combination of URL scheme ipns and a unique identifier (public key) can be used as on origin which maps well with browsers definition of Origin Policy.

libdweb

Custom network protocols implemented using libdweb define origin as URL scheme and hostname. Later is either unique identifier (public key) representing mutable dataset or content hash which enables network protocol authors to provide to use same isolation mechanism to the content publishers as currently available on the web.

Open issues

CORS

Currently on the web CORS HTTP headers can be used to relax Origin Policy for specific content. Since popular ÐWeb Protocols there is no notion headers making content from other origin readable is an open issue.

Cross Protocol Policy

Currently web supports only HTTP and it's derived HTTPS protocol and defines interactions across them in the secure contexts specification. Introducing new network protocols like IPFS or Dat begs the question of what are the interactions between all these protocols.

Note: In the context of libdweb we've decided to forbid any kind of cross-protocol interactions.

Clone this wiki locally