On Fri, Dec 30, 2011 at 3:53 AM, David Bruant <[email protected]> wrote:
> Le 30/12/2011 02:28, John J Barton a écrit : > > On Thu, Dec 29, 2011 at 5:11 PM, David Bruant <[email protected]> wrote: > >> Le 30/12/2011 01:00, Lasse Reichstein a écrit : >> > On Thu, Dec 29, 2011 at 8:41 PM, Mark S. Miller <[email protected]> >> wrote: >> I've been thinking about this "run first" idea for some time. Since on a >> webpage, security seems to depend on your ability to run code first, it >> would be interesting if there was a way to ensure that some code >> (preferably defensive) is run before *any* other code. Though I find >> this interesting, I'm still not sure whether this would be a good or bad >> idea. I'm also clueless on how it would look like. >> Creative ideas welcome. >> > > The browser runs first: what can't it do that you want to support? > > I was thinking of the case of XSS for instance where your code is in > competition with unexpected and malicious code. > How did this competition begin? A use case for JS security environment is loading app components cross-site. The other site is 'trusted' in that you believe it has code helpful to the user. But you want to limit its control, for reliability rather than security in the normal sense. Is this what you have in mind? > What I've said before applies and even against an XSS attack, you can > prevent cookie theft as long as you run first. > I can't see a way for the browser to enforce that trusted code run before > untrusted code. > What causes 'untrusted' code to run at all? You must be doing something to cause the browser to load code outside of normal methods. That 'cause' is running first. To put this another way, what ever runs first *is* the trusted code. jjb > > > David >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
