> Once again, exposing the actual arguments, receiver and function > object references is a security issue and completely out of scope for > this. This is not related to cross domain access but related to object > capabilities.
Erik how do you reconcile this with the fact that this information can already be obtained in most production browsers via stack walking? Also, forgive my ignorance, but is it an explicit goal of the JavaScript language that two scripts in a web page from the same domain must not be able to discover each other's runtime arguments? On Fri, Jun 8, 2012 at 3:50 PM, Erik Arvidsson <erik.arvids...@gmail.com> wrote: > On Fri, Jun 8, 2012 at 3:25 PM, Brandon Benvie > <bran...@brandonbenvie.com> wrote: >> You can get the arguments. Here's an example of getting more info out of a >> try..catch: https://gist.github.com/2898384 >> >> Which results in error.stack being an array of objects like (function, >> arguments, and receiver are actual function/array/object) >> >> { >> function: <function>, >> name: "InjectedScript._evaluateOn", >> inferredName: "_evaluateOn", >> arguments: <Array[5]>, >> invocationType: "call", >> receiver: <receiver>, >> inferredType: "Object", >> origin: undefined, >> column: 33, >> line: 343, >> position: 12853, >> type: "file" >> }; > > Once again, exposing the actual arguments, receiver and function > object references is a security issue and completely out of scope for > this. This is not related to cross domain access but related to object > capabilities. > > Here is an example of when this would be a security issue: > > function foo(secret) { > 'use strict'; > thirdPartyFunction(); > } > > ... > > function thirdPartyFunction() { > getStackTrace(new Error)[1].arguments[0]; // oops I just leaked the secret. > } > > Any proposal that exposes argument values and/or object references are > dead on arrival. > > -- > erik _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
