a future caller alternative ?

Kevin Gadd kevin.gadd at gmail.com
Fri Mar 8 14:13:27 PST 2013

The Error.stack strawman is a great start at making Error.stack's
contents machine-readable, but doesn't remotely approach being a
solution for use cases previously addressed by Function.caller.

I don't really understand the security argument in this case. Being
able to identify the particular function at offset N in the stack
shouldn't expose any privileged information, unless you're somehow
assuming that this would expose locals or closed-over values... it's
not my understanding that this was the case originally with caller and
I don't know off hand of any use cases that would address other than
debugger use cases (Which, as you mention, are best addressed by a
debugging API). If anything, being able to cheaply and reliably walk
the stack to - for example - identify your caller would allow you to
implement some interesting security patterns in your own code, if for
some reason you were trying to do sandboxing and code access security
in pure JS. If specified correctly you could make it possible to walk
the stack and ensure that the information you're getting isn't being
spoofed, which would allow you to reliably limit callers of a given
'protected' function to a fixed whitelist of trusted functions,
something you can't do by parsing a dead stack trace.

Error.stack is also a terrible choice for any scenario where you want
adequate performance. I don't expect stackwalking to ever be *fast*,
but there's a huge difference between 'give me the identity of my
caller' and 'turn the entire call stack into a string, and also,
construct an exception instance since that's how I'm getting the

I agree with Andrea that the loss of caller in strict mode was painful
and it would be troublesome if that feature set is gone forever. It's
one of the reasons I periodically consider ceasing to generate
strict-mode code in my compiler.

A key point I want to make here: Debugging is not the only reason
people will want to walk the stack. It is possibly the best and most
common reason, but in the wild I regularly encounter applications that
use limited forms of stack-walking for other purposes: Code access
security, metaprogramming, logging, etc. These are all reasonable use
cases, and in particular I think code access security and detailed
logging are both use cases that one could argue should deliver
reasonable performance as well, unless your goal is to instead handle
those use cases entirely with special features baked into the language
or libraries.

Apologies if I've missed some huge design philosophy underpinning the
design of ES6/ES7 re: security/sandboxing; I also don't really
know/understand how Caja fits into the picture.


On Fri, Mar 8, 2013 at 1:49 PM, Mark S. Miller <erights at google.com> wrote:
> On Fri, Mar 8, 2013 at 1:32 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
>> I'd love to see caller dead **only** after a well engineered solution take
>> its place and is widely adopted, which is the reason I've asked about this
>> future solution I've never seen discussed here.
>> So, the question is: is there any plan to discuss, to put in agenda, to
>> bring, a "caller" alternative to ES.next ?
> There are several JSON RPC debugging APIs for remote debugging of JS
> processes. There is even some convergence among them. I have not followed
> these developments for a good long while, but when I did it seemed ripe for
> codification into a standard. I think this would be a wonderful thing to
> see, and could lead to platform independent portable debuggers for JS, much
> as Java Platform Debugger Architecture (JPDA) has done for Java. I do *not*
> think this should be part of ES.next in the sense of being incorporated into
> a future version of Ecma 262. Rather, I think it should be on a separate
> tc39 track, in the same sense that the i18n effort is.
> Outside of a debugging API, access to the live stack is a security hole,
> much as is access to the state encapsulated in a closure. As for access to
> data representing a dead snapshot of a stack, there's
> <http://wiki.ecmascript.org/doku.php?id=strawman:error_stack>, which is a
> good start. As that page notes, we should still be concerned about the
> information leak, but we can handle that well by hiding the access in a
> WeakMap. See the API at
> <https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/debug.js>.
>> Thanks
>> On Fri, Mar 8, 2013 at 1:25 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:
>>> The way caller is a single attribute of the function object arguably
>>> makes it useless for authoring reusable code: it breaks in the presence of
>>> reentrance, and requires you to keep an accessible reference to every
>>> function that might want to know its caller, exposing you to leaks and
>>> making closures harder to use in such scenarios.
>>> The problems it's intended to solve are important, but it's a really poor
>>> solution to them. I'd love to see caller dead for good and a well engineered
>>> solution take its place.
>>> -kg (mobile)
>>> Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
>>>> I wonder if there's any discussion about it for ES.next
>>>> while callee has always been kinda pointless in my opinion, caller
>>>> property is not replaceable at all.
>>>> Internally, for scope lookup reasons, the caller is always passed
>>>> somehow, except, I guess, where there's no caller access and the function is
>>>> optimized thanks to absent outer scope look up.
>>>> Why caller? Because there's no other way to understand which method
>>>> invoked a getter, as the very most basic example.
>>>> var obj = Object.defineProperty({}, "caller", {get: function get(){
>>>>   return get.caller;
>>>> }});
>>>> obj.method = function method() {
>>>>   alert(this.caller === method);
>>>> };
>>>> This opens doors to debuggers (introspection) and APIs magic quite a
>>>> lot.
>>>> 2 extra points:
>>>>   1) I have not even mentioned arguments, which is not mandatory for
>>>> caller
>>>>   2) I haven't used callee and I don't care about callee
>>>> Last, but not least, the more I think about the inability to switch
>>>> "strict mode" in the wild the more patterns from ES3 injected into ES.next
>>>> come up in my mind.
>>>> Thanks for any sort of response
>>>> ________________________________
>>>> 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
> --
>     Cheers,
>     --MarkM


More information about the es-discuss mailing list