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. -kg On Fri, Mar 8, 2013 at 2:28 PM, Kevin Reid <kpr...@google.com> wrote: > On Fri, Mar 8, 2013 at 2:13 PM, Kevin Gadd <kevin.g...@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. > -- -kg _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
