a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 11 16:49:21 PDT 2013


I've asked if there is anything discussed able to replace caller, this is
the topic, and nothing came out.

Now you are saying that ES6 and ES7 has same power, but before you or
somebody else said that's not the case.

The `this` reference has not mentioned at all as a "main problem" so I
might misunderstand your statement.

At the end of the day there is no answer here but of course that would be
me not understanding it ... that's easy

Thanks





On Mon, Mar 11, 2013 at 3:39 PM, Dean Landolt <dean at deanlandolt.com> wrote:

>
>
>
> 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/de518daa/attachment-0001.html>


More information about the es-discuss mailing list