Sstrict mode isn't meant to make JS secure (it just isn't possible to do so in a non-break-the-web way, that's why SES exists and isn't just folded into the language).
Strict mode tries to remove as many foot guns as possible, and make as many probable errors fail as early as possible in an attempt to rectify old bugs from the early days of JS (accidental creation of globals, bizzaro behaviour when assigning to arguments, etc). Killing off with() had significant security benefits, but the bigger win is that with() has really crazy that makes it impossible to reason about code in any meaningful way. SES on the other hand sets things up so that you can include untrusted 3rd party content in verifiably safe ways, something that strict mode does nothing to address. Strict mode helps SES a lot by making it possible to have essentially static control over all the otherwise unsafe things that can be done normally. --Oliver On Nov 16, 2012, at 3:56 PM, Andrea Giammarchi <[email protected]> wrote: > sure, but I believe Mark did before me and SES fixed this issue indeed. I > understand it's different behind the scene, I don't understand why "use > strict" , which aim is to make code more secure, better, faster, can be > easily deactivated like that. I am talking about 3rd parts libraries that > could decide to run **non strict** inside whatever "use strict" environment > due that Function/(1,eval) door. > > If this is not risky then I am missing what is this "use strict" about since > there were already linters to tell us what's good and what's not on code > level, I am sorry if I don't understand. > > br > > > On Fri, Nov 16, 2012 at 3:52 PM, Oliver Hunt <[email protected]> wrote: > > On Nov 16, 2012, at 3:38 PM, Andrea Giammarchi <[email protected]> > wrote: > >> you hear Mark? drop that SES solution. Is good to evaluate in the same scope >> and context with a directive disabled inline and please read specs! ( sorry >> I could not resist but Oliver you are fun, I am going to read specs now :-) ) > > I'm not sure where you got that from, if you felt I was being offensive I > apologise, but I'm serious, you need to read the spec; There are very real, > and very important semantic differences between using eval as an operator, > and calling any other function. Likewise there are very important > behavioural differences between accessing the arguments value inside a > function body, and accessing the caller property of a function object. There > are major semantic differences between the concepts of a function object, a > function's environment record, and the function code itself. To meaningfully > discuss the behaviour and semantics of these things (and their interactions > with strict mode) you need to understand all of these concepts and how they > relate. > > --Oliver > >> >> >> On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt <[email protected]> wrote: >> I don't think you understand the semantics here -- the Function constructor >> is defined as taking a string (ignoring the parameters for now) and >> returning a function as though the function was defined in the global scope. >> No functions change behaviour based on the strictness of their caller. The >> only way to make a string execute as javascript inside the scope of another >> function is to use the eval _operator_. These are fundamentally different >> concepts. >> >> To put it another way, if the Function constructors behaviour was dependent >> on the strictness of its caller, i would expect: >> document.write("<script>/*code here*/</"+"script>"); >> >> to produce an script element that was already in strict mode. >> >> You really need to read the spec, as you seem to be misunderstanding some >> very fundamental concepts. >> >> --Oliver >> >> On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi <[email protected]> >> wrote: >> >>> back in the topic ... about evaluation: Function('return this')(); returns >>> the global object with or without use strict around. This is actually nice, >>> since this one was a security problem introduced when somebody decided that >>> `this` without an explicit context should have been undefined. Now it is >>> possible to retrieve the global object as long as Function is the original >>> constructor. >>> Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome >>> suffering) >>> >>> Please do not fix, thanks :-) >>> >>> >>> On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi >>> <[email protected]> wrote: >>> love this answer, thanks! >>> >>> >>> On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden <[email protected]> wrote: >>> On 11/16/2012 02:37 PM, Andrea Giammarchi wrote: >>> > what I am saying: arguments won't disappear in 5+ years, neither will >>> > caller ... is my crystal ball correct? >>> >>> It's not necessary for these things to disappear completely for us to >>> derive value from these decisions. It's only necessary for good code, that >>> wants to be performant, to not use them. >>> >>> Jeff >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >> >> > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
