How to ensure that your script runs first in a webpage

Mark S. Miller erights at
Fri Feb 3 19:42:39 PST 2012

On Fri, Feb 3, 2012 at 4:14 PM, John J Barton
<johnjbarton at>wrote:

> On Fri, Feb 3, 2012 at 3:14 PM, David Bruant <bruant.d at> wrote:

> You might take a look at q-comm. A little bit of JS wrapper code and
> you have RPC calls. The only real difference is that the these calls
> will be async, but that is probably what you want for untrusted code
> anyway.

Sometimes yes, sometimes no. Now that we have SES[1], we can easily support
the cases where an asynchrony boundary in inappropriate. For example, say
you wish wish to load some third party library in order to make use of some
of its features. But the features you want to use do not require access to
the real DOM, XHR, or cookies. You can now load the library, give it what
you think it should have an no more, and if it still works (many do), you
can proceed to use it without entrusting it with access to those resources.

> >
> >>> However, being able to load the
> >>> code in the same frame ("vat" as said in the concurrency strawman)
> would
> >>> certainly yield better performance.
> >> I thought this way as well only a few months ago. But the Chrome
> >> multi-process architecture convinced me to reconsider. Integration
> >> calls, the kind of API a security barrier can support, are just not
> >> performance sensitive by design.
> > It's an overhead anyway. Maybe constant, maybe small, but that's an
> > overhead.
> Sure, but your eval/lexical environment is overhead also.

Please measure it across browsers. I think you'll find the overhead is
pleasingly small. The reason is that *SES does not translate the untrusted
code* in order to confine it. Since it is not translated, it runs at
essentially full speed. (Though see[2].)

> >
> >> And JSON messaging performs very well.
> > It requires a copy. Maybe it's not big, but it's an overhead you can
> > avoid as well.

Care to benchmark a JSON postMessage between address spaces vs a direct
method invocation among objects sharing a heap?

> Considering the 2-argument eval example from above, you could define a
> > 'document' property is the second argument and this document (what the
> > eval code gets when it asks for the "document" variable) could be an
> > emulation of an HTMLDocument, but forward all (relevant) calls
> > (appendChild...) to a given element you've chosen.
> >
> > It seems it could be easily implemented.

Hi David, SES implements essentially your two argument eval, but instead of

    eval(codeInString, {localStorage:oneSlotLocalStorage});

you'd say

    var imports = cajaVM.makeImports();
    cajaVM.copyToImports(imports, {localStorage:oneSlotLocalStorage});

As for your suggestion of providing a virtual document as the binding of
"document" seen by untrusted code, that is precisely how Caja uses SES. The
Caja wrapping and virtualization of the browser API (especially the DOM) is
known as Domado[3].

> I'd guess not, but overall I think the restricted eval or similar
> system sounds interesting to explore.

Please do! It works.

[1] <
 <=== this one is new



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list