a future caller alternative ?

Kevin Reid kpreid at google.com
Fri Mar 8 14:28:18 PST 2013

On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> 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

The problem is exposing the ability to invoke the function. Not
'privileged' information, but 'privileged' operations.

> 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.

Java tried stack inspection. It has failed. It has been responsible for
quite a few vulnerabilities (of the sort which allow Java applets to break
their sandbox) and does not compose well.

> 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.

References constitute permissions. To have a reference to a function is to
be able to invoke it is to have the permission.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130308/4ba41850/attachment-0001.html>

More information about the es-discuss mailing list