Discuss
  • Isolated worlds (was Re: Module isolation)

Isolated worlds (was Re: Module isolation)

# Adam Barth (15 years ago)

[Re-sending now that I've subscribed with this address]

I haven't been following this module discussion very closely, but these recent comments sound related to something we've been playing around with in WebKit. We have a mechanism (called an "isolated world") that lets multiple JavaScript contexts share access to the same DOM without ever exchanging JavaScript pointers with each other. Essentially:

  1. Each world gets it's own global object, complete with independent, mutable built-in objects.
  2. Each world gets it's own set of (mutable) DOM wrappers.

For those not familiar with the details of browser implementations, JavaScript DOM objects are usually implemented as wrapper objects around the "native" object, implemented in C++. Because each isolated world gets its own wrappers, the usual one-to-one relation between the native objects and it's wrapper is replaced with a one-to-many relation.

This trick works nicely because DOM is a language-neutral interface. Just like you can have Python and JavaScript bindings for the DOM, isolated worlds essentially lets you have JavaScriptA and JavaScriptB bindings. The key invariant is that two worlds never exchange JavaScript pointers (which you can think of as object-capabilities, if you like), just like Python and JavaScript would never exchange pointers if they interacted with the same DOM objects.

I'm not sure this mechanism is directly applicable to future versions of ECMAScript because we're able to implement it just fine using ES5. However, it might be an approach worth considering in designing a module system for ECMAScript.

Adam

# Kevin Curtis (15 years ago)

Adam,

The 'isolated world' concept looks very interesting. But how is an "isolated world" accessed - is there an ES api:

evalCodeInIsolatedWorld("... ES source code ...");

Is there an web page you can point me to?

Isolated worlds point to the same underlying native DOM objects - so that DOM changes made in isolated world 'A' will be visible in isolated world 'B'

  • even if the DOM wrappers have been tweaked in 'B'. Is there a way to only make part of the native DOM tree accessible to a isolated world?

Thanks.

# Adam Barth (15 years ago)

On Mon, Jan 11, 2010 at 11:12 PM, Kevin Curtis <kevinc1846 at googlemail.com> wrote:

The 'isolated world' concept looks very interesting. But how is an "isolated world" accessed - is there an ES api: evalCodeInIsolatedWorld("... ES source code ..."); Is there an web page you can point me to?

Not exactly. They're used by the extension system for content scripts:

code.google.com/chrome/extensions/content_scripts.html#execution-environment

Essentially, they help protect an extension's content script from getting confused by the page manipulating it's JavaScript environment.

Isolated worlds point to the same underlying native DOM objects - so that DOM changes made in isolated world 'A' will be visible in isolated world 'B'

Yes.

  • even if the DOM wrappers have been tweaked in 'B'.

That's right. The properties of the DOM objects captured by the various DOM Core, etc, specs are identical in the two worlds.

Is there a way to only make part of the native DOM tree accessible to a isolated world?

Not in our current implementation, but you could imagine doing that in the future. For the content scripts application, the content script has strictly greater privileges than the page it's running on. One way to think about that is that code in the isolated world can add a <script> tag to the document, which runs on the main world, just like

what would happen if Python interacting with the DOM added a <script>

tag.

Adam

# Kevin Curtis (15 years ago)

Isolated worlds could be useful for Secure EcmaScript (SES). That is SES could have a "world" with primordials and DOM bindings/wrappers configured for security. There would be no interaction between scripts in the "application/ecmascript" and "application/ses" worlds. e.g.

<html><head> <script type="application/ses"> window.x = 4; </script>

<script type="application/ecmascript"> if (window.x == 4) { alert("Cannot be true -- window.x was set in the SES isolated world!!!"); } </script> </head> ...

Of course, changes to the underlying 'native' DOM would be visible between the EcmaScript and SES worlds. A div added to the DOM in the EcmaScript world would be visible in the SES world.