a future caller alternative ?

Kevin Gadd kevin.gadd at gmail.com
Fri Mar 8 14:38:22 PST 2013

Is this 'references constitute permissions' design philosophy written
up on the wiki somewhere so I can understand the motivations behind
it? It feels a dramatic divergence from the origin-based security
model, and it's complex enough in practice that I assume I won't be
able to participate in any discussion involving security unless I
thoroughly understand your motivations in advocating this model and
using it to justify the removal of features.

Re: stack inspection, I'm aware of it being used in scenarios other
than Java. Is there some conclusive proof out there that stack
inspection is fundamentally unworkable, or is it merely just
intrinsically flawed as exposed in Java? I would not leap from the
latter to the former, but I'm also not a CS researcher. My goal here
was merely to list out real world use cases for stack walking that I
have encountered in real applications, some of which can't be easily
implemented without it.


On Fri, Mar 8, 2013 at 2:28 PM, Kevin Reid <kpreid at google.com> wrote:
> 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.


More information about the es-discuss mailing list