> 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?
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
