Hi François, your goals here have a tremendous overlap with SES. In what ways is SES not satisfactory for these purposes?
The best short-but-accurate summary of SES, sufficient for this question, is <http://research.google.com/pubs/pub40673.html> section 2.3. SES does not remove eval and Function, but rather replaces them with confining equivalents which should be better for your purposes. You can get SES from either <`` https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/> or <https://code.google.com/p/es-lab/source/browse/trunk/src/ses/>. The security of SES is analysed at < http://theory.stanford.edu/~ataly/Papers/sp11.pdf>. On Wed, Sep 25, 2013 at 4:29 PM, François REMY < [email protected]> wrote: > Hi, > > TLDR ==> The web needs a way to express executable code that does not rely > on its parent context, is guaranteed to be side-effect-free, and can be > executed safely anywhere (even in a different thread/worker/window/device, > or as callback for browser code being executed while the DOM is not ready > to be accessed) > > > It's been some time I've been working on this idea of a Closure-free, > Serializable function. This kind of function would have no access to the > parent closures they are defined in, and only limited (read-only) access to > the enclosing environment (read-only Math, Object, Array, others...). > > To the difference of other functions, those objects would not be affected > by the JavaScript running elsewhere on the page, so in this closure-free > function, Array.prototype.slice is guaranteed to be the native slice > function, not some kind of polyfill or replaced function. > > | function sort(array) as serializable { > | Array.prototype.sort.call(array); > | } > > | function sqrt(number) as serializable { > | return Math.sqrt(number); > | } > > | function __BAD_CODE__() as serializable { > | return new XMLHttpRequest(); // xhr not defined in ES6 > | } > > Trying to export a global variable or modify any of the host > environment-defined objects would fail. > > | function __BAD_CODE__(number) as serializable { > | globalNumber = number; // cannot write into the global object > | } > > | function __BAD_CODE__() as serializable { > | Object.prototype.doSomething=function() {}; // cannot write into > the native objects > | } > > It's also important to note that any Object or Array created inside this > context will be passed to the calling context by deep-cloning (or by > replacing the "safe" Math object by the host Math object of the calling > code in the case of environmental objects). Objects that can't be cloned > (non-serializable functions, for example) are just transformed into null. > We could also maybe use the idea of a proxy though deep-cloning seems safer. > > This makes sure it's impossible to leak the "safe" objects to the calling > context in any way (ie: the calling code can leak anything to the called > code, but not the reverse). > > | var RealSin = Math.sin; > | Math.sin=function() {}; > | > | function giveMeMath() as serializable { > | return [Math, Math.sin]; > | } > | > | var [m,s] = giveMeMath(); > | // s === RealSin > | // m === Math > | // m.sin !== RealSin > | > | // note that another possibility here > | // would be to have giveMeMath return [null,null] > | // (ie: consider host objects unserializable) > > To be honest, those functions are not really meant to expose new objects: > even if they need some internally, they should just keep them internally > and avoid distributing them. The deep-cloning algorithm is just there for > the cases where you want to return multiple values at the end of a > function, or when you need an options object. > > Still, the fact they run in a "safe" environment makes them a good > candidate for further optimization and inlining, so we may end up seeing > codes written as serializable to benefit from performance boost and safety > from external attacks. > > | function Point(x,y) as serializable { > | x = +x; > | y = +y; > | return { > | x:x, > | y:y, > | r: Math.sqrt(x*x+y*y), > | t: Math.atan(x,y) > | }; > | } > > The arguments, however, could be any object, and those act totally > normally. If an object is given as argument to the function that is an > Object, the function can access the "real" Object.prototype by using > Object.getPrototypeOf(...). > > | window.newXHR = function newXHR(window) as serializable { > | return new this.XMLHttpRequest(); > | } > | > | var xhr = window.newXHR(); > > However, it's also possible for the calling code not to give such > information by passing only primitive values like string and numbers. I > believe this is the most likely usage of this kind of function, at least > from the web platform point of view. > > > > The good thing about those functions, is that they can safely be sent over > the wires to another thread, or to another web page, because they do not > possibly rely on any state or context. > > Formalizing those functions is also an important step towards enabling JS > code to run safely deeper into the browser stack, by avoiding any possible > use of objects that are not supposed to be interacted with at a given time > (the calling code can control exactly what the called function has access > to). > > A possible use case would be to defined arbitrary timing function for > animations: > > | function x2(x) as serializable { return x*x; } > | > | // this is safe because SomeWebAnim knows he will call the function > only with numbers, so the code cannot access the DOM while it's still > being computed, or because the DOM actually lives in another thread than > the animation code. > | SomeWebAnim.timingFunction = x2; > > > > Is there some interest from anyone else in formalizing this for a future > version of EcmaScript? Or any comment? > Francois > > > > PS: for the purposes of safety, we may want to disallow "eval" and > "Function" inside this environment to make sure the code can be compiled > ahead of time in all cases, and not force the usage of an interpreter. this > could also be let to the choice of the author but be exposed as a slightly > different concept (ie: compilable + serializable vs serializable only). > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
