[E-Lang] Other languages with secure capabilities

Mark S. Miller markm@caplet.com
Tue, 08 May 2001 23:01:50 -0700

At 07:46 AM Tuesday 5/8/01, Marc Stiegler wrote:
> > I just think all these groups should be interacting more than they 
> appear to
> > be doing.
>Markm can correct anything I write here, but in an effort to keep him
>focused on com, I will reply:

Thanks.  It's often quicker to correct a reply than it is to reply.

>Markm had an extensive series of discussions with the Oz/Mozart people a
>while back, which is why they are so well informed about E, and I believe
>this is a reason their approach looks so much like E's, because they were
>just starting to think about distributed security when markm informed them
>about how to do it.

What discussions there were took place on the e-lang list.  While they were
mutually informative, they were hardly extensive.  If they are now well
informed about E, I suspect it is at least as much to the credit of the web
site, Walnut, conversations with Ken, and E itself as a tool for learning E,
as to our prior discussions.

OZ, like E, traces its ancestry back to (among other things) Hewitt's Actors
circa 1973, which was an independent discovery of capability security
principles, explicitly in the context of decentralized computing without
central administration or authority.  Hewitt's capabilities were the first
to be explored in a language context, and were explicitly based on the
lambda calculus.  So maybe they got the foundational issues from me, but I
got them from our common ancestor.  Hewitt truly is the wizard of Oz, and
indeed of most of what's good in modern programming languages.  (Scheme is a
result of picking up half the good ideas in Actors, while missing the other
half.  Most good modern languages descend from Scheme.)

Also in the mid 70s, Norm Hardy, studying Hydra & Algol 68, independently
connected capabilities and lambda calculus in inventing the Gnosis
architecture, later renamed KeyKOS.  Most of the modern understanding of
capability patterns, and of how to think about capabilities, descends
directly from KeyKOS.

Rees' thesis on W7 is probably the best ever explanation of the relationship
between capabilities and the lambda calculus.

So, in light of MarcS's reply, I want to make it clear that I invented very
little here.  I stand on many shoulders, but regarding security the biggest
shoulders are Actors and KeyKOS.  My main contributions are as a polemicist,
a synthesist, and an engineer.

>Markm is (at least was a while ago) comparably informed
>about Oz/Mozart.

(Cough cough choke choke, blushing with embarrassment.)  I made a brave
start once into the various Oz teaching materials, but I got distracted.
Too many things to pay attention to.  In any case, I would certainly like to
understand Oz well.

>One of the big differences between E and Mozart is E's
>marketing orientation, which leads to decisions such as using a C/C++
>syntax. Mozart is, as nearly as I can tell, an academic language for
>academics (at least one of the guys working on it expressed an attitude that
>lines up with this assessment pretty exactly, others on the project may have
>grander hopes, though there was no indication of it in the decisions they
>were making).

This was my impression as well.  But this doesn't change my sense that
there's much we can all learn from each other.  Many of the previous systems
E has learned the most from were also "academic" languages in this sense.

>The simplification configurations with trusted nodes and untrusted networks
>is an interesting twist, but I do not find it compelling for E at this time.
>In the course of my E development, I have come to be a tremendous believer
>in POLA, even for parts of the system that could nominally all be declared
>TCB. POLA is not just a good security idea, it is a good modular software
>development idea.

I quite agree.  I'll go further.  If you allow yourself the shortcut of
sometimes assuming mutually trusting nodes, you'll find it much harder to
make yourself think about the issues raised by mutually suspicious nodes.
Whereas if you engineer for the mutually suspicious case only, your
solutions will be more elegant as well as more widely applicable.  As Polya
(Mr "How to Solve It") says, "Sometimes it's easier to solve the harder

So back to

Ken wrote:
> > I just think all these groups should be interacting more than they 
> appear to
> > be doing.

I quite agree.  We've had Oz folks participate on e-lang before, and they
are always welcome.  Historically, we've made some effort to explain to them
what we were doing wrt security, and it seems to have paid off.  I'd love to
see them post an explanation of their approach and how it compares to ours.

Any other suggestions for how to proceed?

Btw, to whom should I send an invitation to put Oz on the Capability
Security WebRing?