On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd <[email protected]> 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.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
