W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2014

Re: Sub-origins

From: David Bruant <bruant.d@gmail.com>
Date: Thu, 23 Jan 2014 12:32:15 +0100
Message-ID: <52E0FDBF.5040006@gmail.com>
To: Daniel Veditz <dveditz@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi,

Sorry for super-late feedback.
I strongly recommend watching the first 7-8 minutes of 
http://www.infoq.com/presentations/Secure-Distributed-Programming
In my opinion, sub-origins are one more step in identity-based access 
control. It has the exact same problems than origins, but at a finer 
level of control.

 From what I read of the initial blog post, *everything* described can 
be implemented *today* using Caja [1]. Granted, Caja is not engineered 
for performance and has a cost.
ECMAScript 6 introduces the Module Loader API [2] which will allow the 
exact same form of confinment Caja allows, at close enough to no cost.

I believe that for the sake of all use cases described so far, adding a 
new browser primitive is not necessary, because what we need is already 
available (Caja) and will be in available in a standardized form in the 
future. I believe we do not need sub-origins.

David

[1] https://developers.google.com/caja/
[2] (page slightly outdated in the details, but has the relevant 
information overall) 
http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders

Le 04/08/2013 01:49, Daniel Veditz a écrit :
> Joel Weinberger (@metromoxie) wrote a blog post about potentially adding
> a suborigin feature to the web to help sprawling web domains
> compartmentalize different parts of a site from each other. Seems
> relevant to what we're doing in this WG, and CSP is even mentioned as a
> possible carrier for the suborigin.
>
> http://blog.joelweinberger.us/2013/08/suborigins-for-privilege-separation-in.html
>
> -Dan Veditz
>
Received on Thursday, 23 January 2014 11:32:45 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC