Capabilities by any other name

Marc Stiegler marcs@skyhunter.com
Tue, 9 Nov 1999 15:32:50 -0700


We've tried to find a good name for this stuff so many times, sigh...but hal
has stimulated my juices again, how about (after introducing "capability
based security", and "capability" in whatever document is being written)
calling them "secure caps", wherein "cap" is the abbreviation for
capability?

In order to "try out" this proposal, I have written the following short
discussion of another topic we touched recently, using this terminology:

On the earlier issue of persuading people that secure caps are better than
the ordinary security ideas rumbling around today, the best example of
changing the behavior of the entire programming community that I know of is
the destruction of the Goto statement, which to the best of my knowledge
started with Djikstra's "Goto Considered Harmful". Djikstra's article did
not destroy the Goto statement. No persuasive argument made by valiant
members of the Anti-Goto Faction destroyed the Goto statement. What finally
destroyed the Goto statement was the advent of languages in which the Goto
statement was superfluous because the language developers had invented
better, safer, and above all easier (above all easier, I cannot say that
loud enough in email, "if you want someone to do something the right way,
you must first make the right way the easy way"), expressions for every
legitimate purpose served by Goto. In the days of that terrible campaign (in
which I was one of the wild eyed rebels leading the Anti Goto charge), only
very tiny numbers of people were ever converted by force of argument.
Indeed, in some sense we never actually "won": what we did in the end was,
we made a world in which no one ever bothered any more to ask the question.

Secure caps can really only beat things like ACLs using the same strategy.
Invade the world with languages that are better for distributed secure
computation in which the question doesn't arise because the "right" answers
are obvious.

E does this to both threads and ACLs: when writing in E, you never think
about threads, you never ponder "gee, if only I had a thread mechanism", you
just do it in the obvious way with promises. When contemplating security
issues, you never think about ACLs, you just look at the track left by all
the important-object references, which are, of course, the caps we need to
secure, to see if any of them leak out.

So if we can arrange for languages like E and Joule to become
next-generation winners of the language wars (not because they implement
secure caps, not because they implement promises, but because they make it
easy to quickly write understandable distributed secure software), we win.
Until languages like E and Joule start winning thse wars, though, we will
lose.

--marcs


----- Original Message -----
From: <hal@finney.org>
To: <e-lang@eros-os.org>
Sent: Tuesday, November 09, 1999 11:38 AM
Subject: Re: Capabilities by any other name


> Maybe you could do like Drexler did when "nanotechnology" began to be
> used for anything smaller than microtech.  He started using "molecular
> nanotechnology" to try to indicate that it meant building things at the
> molecular level.
>
> You could add a word to "capabilities" to specify your particular
> type, then elide it as you got into the discussions.  I don't know the
> technology very well, but maybe "reference capabilities" (or "capability
> references") or some such...
>
> Hal
>