a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 11 17:56:55 PDT 2013

if I do not return that function explicitly and since I own that function
being the one that put a `caller` inside it where is exactly the problem
... once again?

I would agree 100% if there was a global way to retrieve the currently
invoked function but caller, is even more secure than call, apply, and
bind, 'cause it cannot be overwritten in a meaningful way ( ok, it could
probably deleting the descriptor and putting it back later on )

If I've passed that object I could also argue that object should not be
modified until I decide. There's no mechanism to drop a temporarily frozen
state because I've sent the object I trust to another function.

Moreover, if I created the function that uses .caller is because I own that
function and I put it publicly accessible and maybe I want to know who's
invoking it and how ... is like baking a pie asking you to let me know when
you want to eat it because you know what ? maybe I can throw if the action
is eat() instead of throw() when the context expiration date is expired,
you know what I mean? I've created that bloody pie, who better than me can
decide or suggest when and how to use it?

If you call unknown functions inside your code, the fact there is a caller
is actually the last problem you might have, isn't it?

Also, if that is the **real** problem, you can maybe just
Function('m','return m()')(method) so that caller would be null, right ?

But I understand there's no way caller is gonna be back, even if reasons
aren't in my opinion, valid enough.


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

> On Mon, Mar 11, 2013 at 7:57 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>> On Mon, Mar 11, 2013 at 3:39 PM, Dean Landolt <dean at deanlandolt.com>wrote:
>>> 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.
>> I wonder how would you access the `this` reference using `caller` from
>> somewhere else, exactly, 'cause more I think about above sentence, the more
>> I realize I really do not understand what are you talking about ...
>> (function test() {
>>   function what() {
>>     alert(what.caller);
>>   }
>>   what();
>> }());
>> So I've got `test` there, now what about leaking `this` ... how ?
> The leakage is that caller is a reference -- having that reference gives
> you the *capability *to follow any further references on its object
> graph. This reference wasn't explicitly handed out (as is always the case
> with this-binding in call, apply and bind) -- it was just *leaked* out by
> the simple fact that the function was called. It's very possible the caller
> has all kinds of powers you didn't intend to expose to the callee -- these
> powers have been leaked. It's really not complex -- this is an inherent,
> unpluggable leak. And since OCap is now *the* security model of es, there
> really no sense in trying to revive caller -- it's gone for good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130311/e6ee4a7c/attachment.html>

More information about the es-discuss mailing list