On Mon, Mar 11, 2013 at 5:51 PM, Andrea Giammarchi < [email protected]> wrote:
> the outer `with` statement ... you see my point? we are dropping powerful > features in order to make JavaScript the toy we all think is since ever, > isn't it .... fear driven features, SES I've never personally used, things > that any other general purpose language will leave/consider and then > eventually tell developers how to or how to not use them as linter has done > until now. > I can barely grok any of this but it smells unnecessarily trollish :-/ > Once JS will be not flexible, not dynamic, not powerful and with > introspection possibilities, not JS anymore, I think we can also chose a > new name for the language. > With all of the introspective goodness coming in es6 and es7 this statement is ludicrous. > Bear in mind, AFAIK I am the first one that suggested to freeze the > global: > http://webreflection.blogspot.de/2012/08/a-safer-js-environment.html > > and it was discussed here too but again, if I know what my code is doing, > why you or your SES should be able to not let me do things the way I'd like > to. > > As summary: the reason for dropping `caller` is privileged access but > apply, bind, and call have same weakness/privilege/power ... why are these > allowed? > This statement suggests you don't understand the arguments against caller. It should be obvious that it's not the same thing as apply, bind, or call -- in each of the latter forms you're explicitly handing out the `this` reference capability. There's clearly no capability leak as with caller. > Why cannot be `caller` back (humans can be wrong and hopefully fix, > right?) and update specs so that Object.freeze(callback) or any other > meaningful method will cause that behavior **when meant/needed** ? > > Minifiers, most of them, drop 'use strict' so 90% of code is still not > strict in production so I believe is not too late. > > Best Regards > > > > On Mon, Mar 11, 2013 at 1:51 PM, Kevin Reid <[email protected]> wrote: > >> On Mon, Mar 11, 2013 at 12:56 PM, Brandon Benvie <[email protected]>wrote: >> >>> On 3/11/2013 12:41 PM, Kevin Reid wrote: >>> >>> Yes, taking care of all those things is necessary as well. ES5 provides >>> us the tools to do so: Object.freeze(). If you recursively freeze all >>> standard global objects then all of the issues you mention are handled. >>> Secure ECMAScript (SES), developed by Mark Miller, does this; it provides >>> an execution environment which _is_ secure (given a sufficiently conformant >>> ES5 implementation). >>> >>> >>> I would note, however, that it looks like at, least in browsers, >>> freezing the window or even any single property on it will no longer be an >>> option in the future. I believe the technique used by SES (correct me if >>> I'm wrong) is using is more complex than simply freezing the window (though >>> I believe it does freeze every property recursively from there). >>> >> >> Right. We construct an object which has the bindings specified by ES5 >> (Object, Array, parseInt, ...), but not the DOM (document, window, >> HTMLElement...). Actual access to the DOM by untrusted code is done with >> intermediation and is not part of SES per se. Trying to turn window itself >> into a sandbox is a non-starter. >> >> >>> Something like shadowing all whitelisted global names and preventing any >>> kind of direct access to the window object at all. This requires some >>> amount of source code sandboxing to accomplish. >>> >> >> The minimal solution is to (conservatively) find all (potential) free >> variables in the source code and bind them, which we currently do using an >> outer 'with' statement (in order to be able to intercept accesses using >> accessor properties, for best emulation of legacy global-variable >> semantics). >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
