a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 11 14:51:39 PDT 2013


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.

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.

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?

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130311/67ae2d9b/attachment-0001.html>


More information about the es-discuss mailing list