a future caller alternative ?

Dean Landolt dean at deanlandolt.com
Mon Mar 11 15:39:37 PDT 2013

On Mon, Mar 11, 2013 at 5:51 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> 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 <kpreid at google.com> wrote:
>> On Mon, Mar 11, 2013 at 12:56 PM, Brandon Benvie <bbenvie at mozilla.com>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
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130311/b0a9e754/attachment.html>

More information about the es-discuss mailing list