On Thu, Feb 2, 2012 at 12:51 AM, David Bruant <[email protected]> wrote: > Le 02/02/2012 00:02, John J Barton a écrit : > >> On Wed, Feb 1, 2012 at 2:41 PM, David Bruant<[email protected]> wrote: >>> > Things are not that easy. Trust can be partial sometimes. In some cases, the > "attacker" is an ad provider. You want it to be able to display the ad > (because you need money to pay for food), but not allow the ad script to > mess with the rest of your page (because there might be other ads providers > in the same page and they give you money too!). > > Another example: I heard that MDN wishes people to be able to send their > applications so they can test web technologies quickly (very much like > W3Schools's tryit [1]). This is possible securely without iframes within a > CSP-enabled browser. > > What I want is to load a potentially untrusted script and grant it the > authority to do its job and nothing more. In some places, they call this > "applying POLA" (Principle Of Least Authority), because you provide to some > script the least authority it needs to do its job.
Thanks for these use-cases. In my opinion they support my point: these uses cases are not compelling. They do not justify the huge overall cost of supporting security in the way you outline. In both cases the API seen by the included page is not larger than the API of a normal web page. So an iframe is just the right match to the problem. I'm not saying we can't do better, I am claiming that the impact of adding security features to the programming language is not (yet?) justified. There are better solutions based on iframes that do not require such large investments. In particular, systems like q-comm allow controlled API access between isolated JS environments. jjb > > David > > [1] http://www.w3schools.com/js/tryit.asp?filename=tryjs_events > [2] http://en.wikipedia.org/wiki/Principle_of_least_privilege _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
