How to ensure that your script runs first in a webpage
John J Barton
johnjbarton at johnjbarton.com
Fri Feb 3 07:36:46 PST 2012
On Thu, Feb 2, 2012 at 12:51 AM, David Bruant <bruant.d at gmail.com> wrote:
> Le 02/02/2012 00:02, John J Barton a écrit :
>> On Wed, Feb 1, 2012 at 2:41 PM, David Bruant<bruant.d at gmail.com> 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 ). 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
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.
>  http://www.w3schools.com/js/tryit.asp?filename=tryjs_events
>  http://en.wikipedia.org/wiki/Principle_of_least_privilege
More information about the es-discuss