a future caller alternative ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Mon Mar 11 18:31:52 PDT 2013

apparently only Chrome fails here addressing the caller in advance  ...
 Safari and Firefox get this right:

function withoutACaller(method, context, args) {
    window = Function('return this')(),
    documentElement = document.documentElement,
    script = document.createElement('script'),
    uid = '__withoutACaller' + Math.random(),
  window[uid] = [method, context, args];
  script.text = [
    "window['" + uid + "']"
  result = window[uid];
  delete window[uid];
  if (result instanceof Array && result.length == 4) {
    throw result[3];
  return result;

(function TEST(){
  alert(withoutACaller(function test(a, b, c) {
    alert(test.caller); // withoutACaller in Chrome
    return a + b + c;
  }, {}, [1, 2, 3]));

On Mon, Mar 11, 2013 at 6:07 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> OK, this won't work Function('m','return m()')(method) ... but I wondr if
> the key is there, in anonymous functions, that could be specced being
> anonymous, won't be leak caller and arguments or anything ... no idea, but
> I think the solution could be different, imho.
> On Mon, Mar 11, 2013 at 5:56 PM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>> 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.
>> br
>> 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/693075f4/attachment.html>

More information about the es-discuss mailing list