[cap-talk] Capability-based Projects - theory vs. practice

[Dean Tribble]

On 8/11/07, Mark Miller <erights at gmail.com> wrote:
>
> Suggestion: Would anyone like to start a capability history page at
> wikipedia, or at least <http://wiki.erights.org>? Then we'd have a
> place to accumulate refinements like the observations below.


Wikipedia would be a much better place. I'll start one when I'm back at my
computer tomorrow if it's not already up.

> I think that the FCP system (Flat Concurrent Prolog, by Udi Shapiro and
> the
> > Weizmann Institute) was a capability-based system.
>
> As a programming language, FCP is indeed an ocap system. But the Logix ...
> ...did realize and utilize the ocap nature of FCP. But I'm not sure. I
> don't remember the name of the company.


Ubiq.

> Janus and other
> > concurrent constraint systems by Vijay Saraswat in the FCP tradition
> were
> > also capability systems.
>
> > 1986: Vulcan Project - Ken Kahn (and MarkM and me and others) @ Xerox
> PARC
> > An actor language layered on FCP.
>
> Janus, Vulcan, and all the other variants that emerged from the Vulcan
> project were true ocap systems.
>
> > Joule started in 1988 or early 1989.
>
> That's about right, but I don't know precisely when Joule started.


I'll dig up my notes.  Since it inspired the Xanadu promise system, it was
before that :)

> ToonTalk, by Ken Kahn, is actually a capability system, in spite of being
> a
> > programming environment for children. I think it started around 1994.
>
> Again, I don't know precisely when it started, but that seems right.
> Everything else you say is correct.
>

Is Ken on the list?  Ken?

> 1994: Corbamite - Agorics/SunLabs
> > This was a C++ system vaguely related to Corba, but using
> capabilities.  The
> > actual network security enforcement was never implemented, but the
> > components were all designed following that approach.  It was the second
> > attempt to apply Joule insights to a sequential programming system
> (Promises
> > in Xanadu was the first), and contributed a lot to later E designs.
>
> This went by several names, of which Corbamite was one of the shortest
> lived. When I refer back to this project, I say "WebMart", by which I


Interesting.  I think of them as separate projects :). I think that's
because the name, technology, and applications changed at the same time,
even though the approach was roughly the same.

include both the C++/Tclio incarnation and the later Java-based
> incarnation. Only the earlier incarnation did local language caps
> (Tclio was sorta a capability taming of Tcl). The latter's Java was
> coded as if we had something like Joe-E, which we never did, so really
> it was only a distributed cap system. Except...


The additional Joe-E rules help wiht additional security and reliability
issues, but the design of all the underlying abstractions (e.g., for
bidding, money, etc.) followed ocap principles and had ocap advantages
because it adhered to those rules (e.g., a cheating program could not steal
money from a component that followed the rules). There was also some ocap
work to enable secure cooperation among independent applets.

All of the above projects created a captp-like layer which would have
> given distributed cap security *if* it were layered on a vattp-like
> link encryption layer. The first system in this family to actually do
> the hard and crucial work to integrate the crypto was Original-E at
> Electric Communities, thanks to the heroic crypto work of Bill Frantz.
> Because of export controls, the distributed security of open source E
> was separately due to the heroic work of Tyler Close (living on
> Anguilla at the time).


All that sounds right.  For the point of view of listing ocap projects and
systems, however, I think it qualifies.  These systems were consciously
designed following and developing new ocap patterns, and layered on systems
such that the security assumptions and gaps were reasonably well
understood.  The network enforcement used admonition (you will be fired if
you cheat) but that too has its place.

> 1995: GuardOS - Agorics
> > This is/was a KeyKOS derivative for Sparc and eventually other
> platforms.
> > It got to the point of emulating enough Solaris to host Java and let us
> > experiment with running Agorics' Java applications on it.
>
> You and others on this list know much more about this one than I do.
>
> As we've seen from earlier discussions on cap-talk, persistence was
> also a frequent blind spot of ocap efforts. WebMart, Toontalk, and
> GuardOS had it. I'm not sure which of the others above did.


That doesn't make them not ocap efforts. Joule was working towards
persistence when Java blindsided it :).

Oh.  Is Waterken on the list?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070811/262d6845/attachment-0001.html