Safe, Closure-free, Serializable functions

François REMY at
Wed Sep 25 19:11:35 PDT 2013

> Hi François, your goals here have a 
> tremendous overlap with SES. In what
> ways is SES not satisfactory for
> these purposes?

Sorry for the late reply, I did take some time investigating SES and the implications. Basically, it seems SES provide the required guards in this case (untouched + read-only globals, direct eval only). I'm not quite sure it has this notion of "stateless", however, that is required to be able to use the function safely.

What I mean by that is that the function should not be able to know in any way if it has been called before, or cloned, or anything. I'm pretty sure that SES does not give you that (but you can of course use it in a certain way that will guarantee you that).

The second thing I'm not sure SES provide you is the "everything here is wiped after the function returns" thing. By deep-cloning every object before any operation involving a host object, we create a layer that make sure the safe execution context cannot pollute in any way the parent context (for example via an object prototype yielding the Object.prototype inside the sandbox, or via a function and its scope).

|    function __SES_CODE__() {
|        var x = {value:0};
|        return function() { return x.value++; }
|    }
|    // in this case, the return value in my proposal would be null
|    // because we can't clone the function without leaking
|    // some of the internal objects of the function.
|    // 
|    // however "return function() as serializable { return 0; }"
|    // would have been ok since we can clone the function.

The final remark is that SES seems to be a JavaScript-based sandbox. To fulfill my needs, I need a browser to be able to accept a JS function and know this function can be executed into a sandbox. 

|    SomeWebAnim.timingFunction = alert; // should throw, we cannot accept this because we can't report the error after

This means the sandbox has to be implemented in C++ because the browser itself does not trust JavaScript to enforce its security.

In conclusion, I believe a browser-implemented SES with a particular membrane deep-cloning/nulling outgoing values to prevent any insider object to reach the calling code is exactly what my proposal was all about, it's great to see some people did already work making sure the details would be right.

In my proposal, the "function() as serializable { ... }" syntax is nothing more than a way to create a stateless function that is meant to be executed in such a SES environment, and flagged as such. We could imagine any syntax for that, but I think eval'ing the source code of a function to recreate it is not what we should advocate for this use case.

Do my comments make sense to you? 		 	   		  

More information about the es-discuss mailing list