- From: David Bruant <bruant.d@gmail.com>
- Date: Thu, 23 Jan 2014 12:32:15 +0100
- 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