Links

Firstly, Paypal are using Caja to protect their customers from errors or evilness in gadgets. There are also some performance hints here.

Secondly, my esteemed colleague, Jasvir Nagra, has put together a really nice playground for Caja. Have a go, it’s pretty.

That is all.

Now that we’ve deployed the most successful capability language ever, it’s time to start thinking about the rest of the stack, and one end of that stack is the operating system.

Luckily, thinking in this area has been going on a long time – indeed, capabilities were invented in the context of the OS, though for a long time were thought to be the exclusive domain of specialised hardware. Some of that hardware ended up being extremely widely deployed, too, so don’t think this is the stuff of lab experiments only. Sadly, though, despite the hardware supported capabilities, these were not generally exposed up to the level of the kernel/userland interface; they were thought to be useful only within the kernel (with one notable, but not very well known or widely used, exception),

However, more recently it has been realised that capabilities are not only useful in userland, but also can be implemented on top of commodity hardware, resulting in a crop of new capability operating systems. But these still suffer from the problems that traditional capability languages have suffered from: they need the world to be completely reinvented before you can use them. Because the capability paradigm is fundamentally different from the ambient authority ACL-based world we live in, no existing software can fully enjoy the benefits of capabilities without at least some rewriting.

So, the interesting research question has now become: how can we move toward this world without having to rewrite everything on day one? Some progress has been made with mapping POSIX onto capabilities. Heading in a completely different direction is the idea of running existing OSes as guests on a capability system. Yet another approach is to apply capabilities to more restricted domains: one that I have been involved in is the idea of hosting untrusted software “in the cloud”, in the same vein as Google App Engine. Because this software is all new, changing the way it has to work is not a big deal.

But the thing that interests me most is the work being done on FreeBSD, which allows capability-based code to coexist with (or even be contained within) existing POSIX code. This provides a genuine, believably workable, migration path from existing systems to a brave new capability world. We can move one application (or even one library) at a time, without breaking anything. Which is why I am pleased to be able to say I am involved in this work, too. What’s even better is this work is by no means specific to FreeBSD – the same principles could be applied to any POSIX system (so Linux and Mac OS X would be good targets). Just as we have seen success with Caja it seems to me that this route can deliver success at the OS level, because it allows a gradual, piecemeal migration.

Unusually for me, I have not interrupted my narrative flow by naming or saying too much directly about the various things I link to – however, I appreciate that following links in the middle of reading can get distracting, so here are many of the links again with some explanation…

Caja: a capability version of Javascript. I have written about it before.

CAP computer: the project that invented capabilities.

IBM System/38: more capability hardware.

AS/400: derived from the System/38. Although this had capabilities, they were not exposed to userland. Very widely used commercially.

KeyKOS: a commercial capability operating system.

Amoeba: an experimental capability system – like Caja, it tends to advertise its other virtues rather than describing itself as a capability system.

EROS: another experimental capability OS – originally intended to provide robustness, not security. The first to run on a standard PC.

CapROS: when EROS was discontinued, it lived on as CapROS. Google has recently sponsored the development of a web-hosting experiment on top of CapROS.

Coyotos: by the original designer of EROS. Now also discontinued (can you spot a trend here?).

Plash: the Principle of Least Authority Shell. This shell runs on Linux, figures out from the command line what any particular invocation of an executable should have access to, creates a sandbox with access to only those things, then maps POSIX calls onto the sandboxed things.

L4: a modern capability-based microkernel.

L4Linux: Linux running on top of L4. Although this is nice for things like driver isolation, it seems like the wrong direction because it does not assist with exposing capabilities to userland.

FreeBSD Capsicum: a capability mode for FreeBSD. Whole executables can opt in to this mode, coexisting with POSIX binaries. Even more interestingly, libraries can spawn off capability-mode subprocesses whilst effectively remaining in POSIX mode themselves. This allows the transparent implementation of privilege separation. This project has also been sponsored by Google.

If you’ve been living in a box for the last couple of years, you might not know that Caja is an open source project I am involved in at Google to make the web safer. Specifically, it allows untrusted Javascript, HTML and CSS to be sandboxed in a very fine-grained way. For example, the untrusted content can be limited to a subset of the whole DOM, primordial objects can be replaced or removed, properties of objects can be protected (from read, write or execution) and any method can be removed, replaced or attenuated. Yet it is still possible to write fully-featured Javascript applications in Caja. And, as a bonus, Caja hides the differences between browsers – any code you write will Just Work on any supported browser.

Caja has long been used by Yahoo!, ironically, to protect users from malicious gadgets on their Application Platform but until recently has been a bit of a poor relative at Google. So, I’m pleased to report that it is now in use to protect Orkut users.

Because Caja is open source, we don’t necessarily find out when people use it: do you know of someone using Caja? Leave a comment!

One of the hardest parts about using Caja (which, by the way, is now far and away the most successful capability project ever) is debugging. Because of the transforms Caja must do to render your code safe, even something simple like

x.a = y.b + z.c();

becomes

$v.s($v.ro(‘x’), ‘a’, $v.r($v.ro(‘y’), ‘b’) + $v.cm($v.ro(‘z’), ‘c’, [ ]));

if we ignore all the wrapping code that is generated. Whilst you can certainly get used to reading this and translating it back into your original source in your head, so you can use, say, Firebug to debug, it’s pretty painful at best.

So I was pleased to see that the Closure Inspector now supports Caja debugging.

By the way, if you want to play with Caja, it’s now easier than ever, using the new Appspot-based Caja Playground.

Here’s a nice (and brief) article about developing for the Yahoo! Application Platform, and, in the process, covering some of the benefits and gotchas of Caja.

Caja enforces the W3C standards for JavaScript, HTML, and CSS, regardless of browser (!).
Yes, you read correctly, if your code cajoles, it will run in Firefox and IE. This is amazing and its value cannot be overestimated.

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.

Yahoo! yesterday launched their new development platform for My Yahoo! and Yahoo! Mail, which uses Caja to protect users from malicious gadgets. This means Caja suddenly got 275,000,000 users. Wow! I guess this makes Caja the most widely used capability language ever.

But what I’m most excited about is that there’s virtually no mention of Caja at all. Why? Because Caja gives you security without getting in your way – the fact that end users don’t need to know about it all – and even developers hardly have to care – is a great success for Caja.

I’m very excited that Yahoo! have launched their gadget platforms, including an OpenSocial platform. Why am I excited? Because Yahoo! require all gadgets to use Caja so that they can be sure the gadgets behave themselves without review. Caja allows the container (i.e. Yahoo!’s platform, in this case) to completely confine the untrusted Javascript (i.e. the gadget, in this case), only allowing it to perform “safe” operations. All other platforms either have to manually review gadgets or take the risk that the gadgets will do something evil to their users.