November 11, 2007

Oddly good news week: Google announces a Caps library for Javascript

Capabilities is one of the few bright spots in theoretical computing. In Internet software terms, caps can be simply implemented as nymous public/private keys (that is, ones without all that PKI baggage). The long and deep tradition of capabilities is unchallenged seriously in the theory literature.

It is heavily challenged in the practical world in two respects: the (human) language is opaque and the ideas are simply not widely deployed. Consider this personal example: I spent many years trying to figure out what caps really was, only to eventually discover that it was what I was doing all along with nymous keys. The same thing happens to most senior FC architects and systems developments, as they end up re-inventing caps without knowing it: SSH, Skype, Lynn's x95.9, and Hushmail all have travelled the same path as Gary Howland's nymous design. There's no patent on this stuff, but maybe there should have been, to knock over the ivory tower.

These real world examples only head in the direction of caps, as they work with existing tools, whereas capabilities is a top-down discipline. Now Ben Laurie has announced that Google has a project to create a Caps approach for Javascript (hat tip to JPM, JQ, EC and RAH :).

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 also means box in Spanish which is a nice cross-over as capabilities is like the old sandbox ideas of Java applet days. What does this mean, other than the above?

We could also point to the Microsoft project Cardspace (was/is now Inforcard) and claim parallels, as that, at a simplistic level, implements a box for caps as well. Also, the HP research labs have a constellation of caps fans, but it is not clear to me what application channel exists for their work.

There are then at least two of the major financed developers pursuing a path guided by theoretical work in secure programming.

What's up with Sun, Mozilla, Apple, and the application houses, you may well ask! Well, I would say that there is a big difference in views of security. The first-mentioned group, a few tiny isolated teams within behemoths, are pursuing designs, architectures and engineering that is guided by the best of our current knowledge. Practically everyone else believes that security is about fixing bugs after pushing out the latest competitive feature (something I myself promote from time to time).

Take Sun (for example, as today's whipping boy, rather than Apple or Mozo or the rest of Microsoft, etc).

They fix all their security bugs, and we are all very grateful for that. However, their overall Java suite becomes more complex as time goes on, and has had no or few changes in the direction of security. Specifically, they've ignored the rather pointed help provided by the caps school (c.f., E, etc). You can see this in J2EE, which is a melting pot of packages and add-ons, so any security it achieves is limited to what we might called bank-level or medium-grade security: only secure if everything else is secure. (Still no IPC on the platform? Crypto still out of control of the application?)

Which all creates 3 views;

  1. low security, which is characterised by the coolness world of PHP and Linux: shove any package in and smoke it.
  2. medium security, characterised by banks deploying huge numbers of enterprise apps that are all at some point secure as long as the bits around them are secure.
  3. high security, where the applications are engineered for security, from ground up.

The Internet as a whole is stalled at the 2nd level, and everyone is madly busy fixing security bugs and deploying tools with the word "security" in them. Breaking through the glass ceiling and getting up to high security requires deep changes, and any sign of life in that direction is welcome. Well done Google.

Posted by iang at November 11, 2007 09:51 AM | TrackBack
Comments

some capability based trivia ... repeated here
http://www.garlic.com/~lynn/2007s.html#17

some earlier work on capability based infrastructure was the Gnosis done starting in the 70s by Tymshare. Tymshare had a vm370-based commercial, online timesharing system
http://www.garlic.com/~lynn/subtopic.html#timeshare

When Tymshare was bought by M/D, Gnosis was spun off as KeyKOS (disclaimer, I was brought in to audit Gnosis as part of the spin-off) Other trivia, M/D sold off Tymshare's TYMNET to B/T.

KeyKOS Documentation webpage
http://www.agorics.com/Library/keykosindex.html

other efforts that grew out of KeyKOS:

EROS: The Extremely Reliable Operating System
http://www.eros-os.org/

CapROS: The Capability-based Reliable Operating System
http://www.capros.org/

which has this reference back to KeyKOS
http://www.cis.upenn.edu/~KeyKOS/

The Coyotos Secure Operating System
http://www.coyotos.org/

from Coyotos history page ...

Coyotos is the successor to the EROS system, which is in turn the successor to the KeyKOS system. Since the system inherits 30 years of prior research and development history, it seems appropriate to briefly describe some of that history and the prople who contributed to it.

... snip ...

more from Coyotos history page ...

My own contact with this work came in 1990. As a co-founder of HaL computer systems, I became involved in evaluating various operating system platforms for use by HaL. In 1990, UNIX robustness wasn't great, and we hoped to find something that would be largely operator free and highly robust. Key Logic made a presentation to us about KeyKOS. For reasons that were largely political, HaL decided not to gamble on KeyKOS, but I became convinced that KeyKOS offered something worthwhile.

... snip ...

for other trivia, the "H" in "HaL" had been head of the austin workstation division (in an earlier life, for a time, I had been his only direct report) and the "L" had come from SUN.

there use to be a joke in the valley that there were only 200 people in the business ... they kept moving around, so it just appeared like there were more.

Posted by: Lynn Wheeler at November 11, 2007 11:03 AM

Caja also refers to cashboxes.

Caja chica = petty cash
Caja fuerte = safe
Caja registradora = cash register

Posted by: Hasan at November 12, 2007 11:18 AM

Glad to hear everyone is heading in the same general direction.

Posted by: Jim at November 13, 2007 10:12 AM

seems like even Second Life into that ;)
https://wiki.secondlife.com/wiki/Capabilities

Posted by: A.T. at November 23, 2007 08:23 PM
Post a comment









Remember personal info?






Hit preview to see your comment as it would be displayed.