<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">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).<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>--Oliver</div><div><br><div><div>On Nov 16, 2012, at 3:56 PM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com">andrea.giammarchi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">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.<div>
<br></div><div>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.</div>
<div><br></div><div>br</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 3:52 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div class="im"><div>On Nov 16, 2012, at 3:38 PM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:</div>
<br><blockquote type="cite">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 :-) )</blockquote>
<div><br></div></div><div>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.</div>
<span class="HOEnZb"><font color="#888888"><div><br></div><div>--Oliver</div></font></span><div><div class="h5"><br><blockquote type="cite"><div class="gmail_extra">
<br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 3:32 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com" target="_blank">oliver@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div style="word-wrap:break-word">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.<div>

<br></div><div>To put it another way, if the Function constructors behaviour was dependent on the strictness of its caller, i would expect:</div><div>document.write("<script>/*code here*/</"+"script>");<br>

<div><br></div><div>to produce an script element that was already in strict mode.</div><div><br></div><div>You really need to read the spec, as you seem to be misunderstanding some very fundamental concepts.</div><span><font color="#888888"><div>

<br></div><div>--Oliver</div></font></span><div><br><div><div><div>On Nov 16, 2012, at 3:19 PM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:</div>

<br></div><blockquote type="cite"><div>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.<div>


Said that, I believe this is a bug in every browser. (Webkit, FF, Chrome suffering)<div><br></div><div>Please do not fix, thanks :-)</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Nov 16, 2012 at 2:50 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">love this answer, thanks!<div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Fri, Nov 16, 2012 at 2:47 PM, Jeff Walden <span dir="ltr"><<a href="mailto:jwalden+es@mit.edu" target="_blank">jwalden+es@mit.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 11/16/2012 02:37 PM, Andrea Giammarchi wrote:<br>
> what I am saying: arguments won't disappear in 5+ years, neither will caller ... is my crystal ball correct?<br>
<br>
</div>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.<br>
<span><font color="#888888"><br>
Jeff<br>
</font></span></blockquote></div><br></div>
</div></blockquote></div><br></div></div><div>
_______________________________________________<br>es-discuss mailing list<br><a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br><a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>

</div></blockquote></div><br></div></div></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div>
</blockquote></div><br></div></body></html>