From: Mark Miller <markm@caplet.com>
Replying To: Tyler Close <tyler@waterken.com>
Date: Tue, 03 Dec 2002 20:50:37 -0800
Subject: Re: [e-lang] "Capability Myths Demolished" (was: Software security workshop)

First, I wholeheartedly agree with Tyler on the facts: tyler 

At 05:30 PM 12/3/2002 Tuesday, Tyler Close wrote:
>The term
>"C-list" identifies a mechanism that predates the Lampson paper. A
>C-list is used to implement capabilities that have the same
>properties as "E-style capabilities". There is nothing new or
>different about the security properties that E capabilities
>provide. A capability has always been a combination of
>authorization and designation.
>[...]
>There are a number of operating systems, predating the Lampson
>paper, that implemented capabilities. 
>[...]
>As MarkM has often and pointedly said, there is nothing new about
>the security principles behind E. They come from a long line of
>prior work. [...]

Absolutely. I would be horrified if they become known as "E-style 
capabilities".  None of the security principles of E are novel until you get 
to auditors. My contributions are as a popularizer and engineer much more 
than as an inventor. 

But now I have to mostly agree with David on tactics.   When I grabbed the 
domain name "erights.org", I imagined reviving these old ideas under the 
term "electronic right" or "eright". However, it was just too difficult to 
write using that convention, because our writing needs to keep us connected 
to our proud history. I think the same would apply to any wholly new coinage.

However, if a good excuse for a distinction could be found, I think 
"<adjective>-capability", for some appropriate adjective,  would satisfy 
David's tactical issue while keeping us connected to our history. shap

In looking for a distinction, we also need to ask which history we're trying 
to stay connected to.  The really great and ground-breaking capability 
systems I care most about are Actors and KeyKOS. Most everyone who is 
passionate about capabilities today learned them from Norm or from someone 
(like Jonathan and myself) who learned them from Norm.  What do Actors, 
KeyKOS, and the capability systems descended from them have in common that 
the other don't?  Actors and KeyKOS were both designed around a deep 
appreciation of the lambda calculus, and the systems descended from them all 
have a strong lambda nature.  Lambda calculus puts designational issues in 
the foreground, and so puts the conversation back on the right track.

So I propose we speak of what we're doing as "lambda-capabilities". 

Reaching further back in our history,  we could include Hydra and Cap while 
still excluding Dennis and Van Horn by speaking of "invocation-capabilities" 
as distinct from the original "memory-capabilities".  I could imagine also 
speaking of "Granovetter-capabilities", to mean those having the diagrammed 
properties, as opposed to "Lampson-capabilities", which don't. tyler

I have also been known to write on occasion "The Actor/Capability model".   
But I still like "lambda-capabilities" best, as, sad to say, even fewer 
people know about Actors than about capabilities.

In any case,  I would want to bounce any such proposal around for a good long 
while before actually trying to make a shift in our writing or doing a 
search/replace over our web sites.


----------------------------------------
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM

_______________________________________________
e-lang mailing list
e-lang@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/e-lang