Monday, November 12th, 2007

Capability JavaScript: JavaScript isn’t Caja

Category: JavaScript, Security

We talked about the new Google Caja project which tries to make JavaScript safer by processing it and putting it in namespace sandboxes.

Now, Ben Laurie of Google comes out and talks about it. There is a spec:

Using Caja, web apps can safely allow scripts in third party content. The computer industry has only one significant success enabling documents to carry active content safely: scripts in web pages. Normal users regularly browse untrusted sites with Javascript turned on. Modulo browser bugs and phishing, they mostly remain safe. But even though web apps build on this success, they fail to provide its power. Web apps generally remove scripts from third party content, reducing content to passive data. Examples include webmail, groups, blogs, chat, docs and spreadsheets, wikis, and more; whether from Google, Yahoo, Microsoft, HP, Wikipedia, or others. Were scripts in an object-capability language, web apps could provide active content safely, simply, and flexibly. Surprisingly, this is possible within existing web standards. Caja represents our discovery that a subset of Javascript is an object-capability language.

In Ben’s words:

I’ve been running a team at Google for a while now, implementing capabilities in Javascript. Fans of this blog will remember that long ago I did a thing called CaPerl. The idea in CaPerl was to compile a slightly modified version of Perl into Perl, enforcing capability security in the process.

Caja follows a similar path, except rather than modify Javascript, we restrict it to a large subset. This means that a Caja program will run without modification on a standard Javascript interpreter – though it won’t be secure, of course! When it is compiled then, like CaPerl, the result is standard Javascript that enforces capability security. What does this mean? It means that Web apps can embed untrusted third party code without concern that it might compromise either the application’s or the user’s security.

Caja will be open source, under the Apache License. We’re still debating whether we will drop our existing code for this as a starting point, or whether we want to take a different approach, but in any case, there’s plenty to be done.

Although the site has been up for a while, I was reluctant to talk about it until there was some way for you to be involved. Now there is – we have a public mailing list. Come along, read the docs (particularly the Halloween version of the spec) and join in the discussions. I’m very excited about this project and the involvement of some world class capability experts, including Mark Miller (of E fame) who is a full-time member of the Caja development team.

Posted by Dion Almaer at 8:09 am

3.3 rating from 17 votes


Comments feed TrackBack URI

Really doesn’t look like CaPerl is more than syntactic sugar over what perl’s standard Safe module provides, at the module level.

Good to see sandboxing coming to javascript, but I wonder how much more we can get out of the current browser implementation of javascript without needing better/more browser support for some of these things.

Comment by Andy — November 12, 2007

I’m meeting with Mark Miller of the Caja team today, and we’re already talking via the about how ES4 might fix two mistakes from the standardization of ES1 back in 1996-7 (readonly props silently fail to update when set; delete on don’t-delete and missing properties does not throw, and has confusing boolean results in the missing direct property case), plus change strict-mode eval and with runtime semantics, to support Caja’s security properties directly. Stay tuned on the es4-discuss list.


Comment by Brendan Eich — November 15, 2007

Leave a comment

You must be logged in to post a comment.