a future caller alternative ?
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...
More information about the es-discuss