A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

[Proposal] Origin Isolation


Explainer: https://mikewest.github.io/isolation/explainer.html


Authors of security-critical applications want the web’s low-friction install process, its linkability, and its cross-platform nature, but are understandably nervous about hosting very powerful applications on the web alongside malicious content that can attack in any number of ways. Chrome Apps used to be an attractive choice for building security-critical applications, since Chrome Apps are cross-platform (across any desktop platform) and a somewhat lower-friction install process than a native app, while offering a greater degree of isolation than a normal web app gets. (For example, the browser prevents regular web content from initiating a navigation to a Chrome App URL.) However, Chrome Apps are deprecated in favor of the open web, and, indeed, it would be nice for security-critical applications to be able to run in any browser with the degree of isolation that they desire.

This document proposes an “Isolate-Me” concept, in which an origin can request to be isolated from other web content. Developers responsible for security-critical web applications can choose to trade away some of the features of being on the open web (such as full linkability) in exchange for better protection from maliciousness.

The explainer doc linked above outlines the threat model we’d like to address. We’re open to feedback on the strawman proposals about ways to address the issues.


This seems like a good proposal.

However, I think that the scope of security vulnerabilities and attacks on the web (both now and ones in the future) may be too vast for a proposal like this to cover.

The current APIs that we have have come a long way from what they use to be are being iterated on to prevent things like XSS attacks form injections. Granted they are not yet perfect, but very-important-bank.com can take measures to prevent their site from being hacked (i.e. sanitizing form data, using https vs http, sending appropriate headers, authenticating properly, etc), . In addition to that, many security vulnerabilities can easily be prevented by very-important-bank.com having knowledgeable and experienced engineers, especially if they are “very important” :slight_smile: .

Also, security vulnerabilities are not always initiated from a browser (anything that is capable of requesting urls essentially can hit an endpoint served, for instance), so each site will still need to take extra precautions. Unless I missed something, this proposal doesn’t seem to address that. But even still, very-important-bank.com is going to still need to invest in the knowledge on how to prevent security vulnerabilities on their own (is this what we’re trying to avoid with this proposal?)


Discussed this briefly with folks at TPAC: minutes at https://www.w3.org/2016/09/21-isolation-minutes.html.