Links

Ben Laurie blathering


Whoops!

Never moderate your comments before you’ve woken up. I accidentally marked two perfectly legitimate comments as spam this morning, and it seems WP doesn’t let you get them back…

So, here they are. First from James A. Donald

That is a million fold increase in the number of users of capability systems.

I would like to see a capability vm that runs good old fashioned C++, wherein the only access that code has to the larger world outside the vm is by objects corresponding to data streams – which is in fact very close to he way that vms work right now.

You should look at Native Client.

Secondly, from Julien Couvreur

Congrats! That is great to hear.
I was wondering: has there been any discussion to have a sub-set of javascript (such as Caja) directly supported (and enforced) by the browser? You could probably have a backward compatible and failsafe solution where server-side validation is applied if the browser isn’t trusted?

In fact, partly spurred on by the existence of Caja, and particularly through the hard work of Mark Miller, Caja’s language expert, the ECMAScript committee has been working on the catchily named “ECMAScript 3.1 Strict” which is pretty much the same language as Caja. I assume that this will, one day, get native support.

2 Comments

  1. > “ECMAScript 3.1 Strict” which is pretty much the same language as Caja.
    (“ECMAScript 3.1 Strict” is “ES3.1-strict” below)

    Just to clarify: “Caja” names our overall capability-based system for sanitizing all the components of web content, including html, css, the browser/dom api, and JavaScript. To sanitize JavaScript, we had to address two conflicting requirements: 1) support the writing of new code that can make use of the new security properties, to facility safe cooperation among mutually suspicious entities. 2) Support enough of legacy JavaScript to enable most old code to run with only minor adaptations.

    We finally realized we could not solve both problems well with one language. Instead, we built two layers:

    * Cajita, to solve problem #1, is a true object-capability language. It is also a small subset of EcmaScript 3.1-strict, retaining only the good parts. For new code, it is a much better language than JavaScript. On browsers that support ES3.1-strict directly, Cajita will have a trivial translation with virtually no overhead. Most important: On these browsers, even uncajoled code, when given access to a Cajita object (for example, cross-frame), will not be able to violate the integrity of that Cajita object.

    * Valija, to solve #2, includes virtually all of ES3.1-strict except eval(). Valija translates to Cajita, and the Valija runtime library is written in Cajita. So on browsers that support ES3.1-strict directly, Valija will in effect emulate multiple virtual ES3.1-strict “machines” on one actual ES3.1-strict page. This virtualization will still have some overhead. At the last EcmaScript meeting, we started exploring ways that ES3.1-strict’s successor, EcmaScript-Harmony, could better facilitate low overhead safe self-virtualization.

    Comment by Mark S. Miller — 17 Dec 2008 @ 18:54

  2. I am not sure if this is expected, but your Blog posts are no longer being updated / mirrored to Shmoo.

    Tom

    Comment by Tom — 18 Dec 2008 @ 18:29

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress