[E-Lang] 30 Years Wandering in the Desert

[Mark S. Miller]

At 08:28 AM Friday 2/2/01, David Wagner wrote:
>As for the rest, I understand the purpose and value of combining
>designation and authority, and I agree that it seems to be a nice
>benefit.  I'd like to understand, though, whether I can obtain some
>of this benefit without requiring a radical change to a new type-safe
>programming language, operating system, and so on ... especially the
>language part, because I'm a little skeptical on whether type-safe
>languages can provide the level of assurance I'd like.  That's why
>I'm asking these questions: Not because I have a special aversion
>to E or to capabilities, but because I'd to understand what the
>benefits are, where they're coming from, and whether it's possible
>to reap *partial* benefits with a less radical change to the way I
>program.  In other words, can I pay only some of the cost and get
>some of the benefits back?

[Emphasis added]

This is a new question for this list, and is certainly a question worth 
asking.  Harking back to our earlier discussion of the purpose of the e-lang 
list, it is certainly within the broad purpose of this list to discuss your 
question if others here wish to discuss it with you.

However, as many people on this list have built or are building real 
capability systems in order to reap the *full* benefits (Gnosis/KeyKOS, 
EROS, FCP/Vulcan, Janus, Toontalk, W7, Joule, E, Droplets, E-Speak2.2), and 
since this particular list is centered on one of these, I for one find it 
hard to care much about your "partial benefits" question.  I wouldn't be 
surprised if others on this list feel likewise.  Although it's within the 
purpose of the list, it's fair to say it's outside our focus.

Outside this list, the question isn't new.  There have been various attempt 
to borrow some of the properties of capabilities and splice them into 
various other architecture, such as "Posix Capabilities" and the Java 2 
security architecture.  Both of these use the term "capabilities" for 
non-capabilities, which is confusing, but they do so because they borrow 
some elements from capabilities in order to reap partial benefits.  These 
have been strongly criticized by members of this list (either on this list 
or elsewhere) for being inferior to pure capability systems.  To my 
knowledge, our criticisms didn't claim there were no partial benefits.  If 
the results are still strictly inferior to pure capabilities, why should we 
care? 

The only reason I can think of, which is compatible with what you say above, 
is legacy compatibility.  (In a future email, hopefully soon, I'll explain a 
different perspective on the legacy question (embodied in several of the 
capability systems I listed) that also reap *partial* benefits, but not in 
the way you mean.)

Capabilities and capability advocates have spent 30 odd years wandering in 
the desert because of widely believed misunderstandings about "what 
capabilities couldn't do", as in the Bobert..Gong..Wallach claim that 
capabilities were *weaker* on preventing delegation than ACLs(!) (and they 
didn't mean the valid case identified by Ralph Hartley), or the claim that 
capability implementations were inherently less efficient (!!).  Many of us 
feel we're on the verge of entering the promised land of general acceptance 
that pure capabilities are simply better than the alternatives.  Many of the 
arguments on this list, including many sub-threads of the current 
discussion, may well challenge that assertion, so, for me at least, these 
seem like the arguments worth having:



* The discussion Ralph Hartley started resulted in a clear refutation of the 
strong form of this assertion.  This makes it all the more plausible that 
the assertion fails in other ways.  Let's find 'em!

* Chris Skalka has proposed to create a pure stack introspection & ACL 
language, enabling us to reason about this architecture outside of the 
happenstance of Java's confusing mishmash of elements.  I took Chris to be 
proposing the question of whether this may have benefits absent from pure 
capability languages.

* Scott Smith has proposed stack introspection + capabilities, and is 
clearly proposing the question of whether the result has benefits over pure 
capabilities.  Otherwise, why add a new mechanism not buildable from pure 
capabilities?

* Your claim (based on the Lampson paper) that capabilities and ACLs are 
semantically equivalent, and the only difference is choice of data 
structure.  While you seem to have backed down from using these definitions, 
this leaves us with the new question of...

* What definition of "capability" and "ACL" are we using anyway?  Jonathan & 
I have repeatedly repudiated the Lampson definitions, but you keep taking 
Lampson definitions as definitive.  Yes, it's "only terminology", but we 
gotta clear this up.

* Jonathan's discussion of "compartments" (whether in support of MLS or not) 
seems to me like a serious challenge, though I have yet to grok it in its 
fullness.

* And most immediately relevant, the evolution of MarcS's summary attempting 
to pull out a reusable consensus from the discussion-investment we've made 
to date.  This may be our fastest route out of the desert.



In summary, I can get enthused about arguing whether existing or proposed 
security architectures may have benefits that capabilities lack (even if 
they are inferior on other grounds), or arguing whether some non-capability 
architecture has all the benefits that capabilities have. But, when so many 
of us are actually building pure capability architectures, I just can't get 
enthused to evaluate architectures less broken than the legacy, when their 
advocates admit these architectures are strictly inferior to pure capabilities.


        Cheers,
        --MarkM