From: David Wagner <>
Date: Thu, 5 Dec 2002 16:25:26 -0800 (PST)
Subject: [e-lang] "Capability Myths Demolished" (was: Software security workshop)

Tyler Close  wrote:
>On Wednesday 04 December 2002 18:17, David Wagner wrote:
>> At risk of prolonging this longer than necessary,
>> how about "true capabilities" vs. "Lampson-style capabilities",
>> when one needs to make a distinction?
>I think we now have more than enough evidence on the table to
>prove that there is no such thing as a "Lampson-style capability".

Of course there is such a thing as a "Lampson-style capability".  I think
you mean that noone builds systems this way.  Maybe so, but so what? 
Why should it be relevant? tyler

Oh dear.  I think somehow I've failed again to convey my point.  I'm a
little depressed by this, but since I'm stubborn, may I try again? tyler 

Those of us here on this group have a concept of the "wrong" way to do
capabilities, namely, make them ambient.   You're suggesting that this
concept should remain nameless.  But I say: If we'd like to criticize
this concept, then it would help to have an unambiguous name to use when
referring to this concept.  And, if we'd like to propose a better concept
(say, E-style capabilities), it would help to have an unambiguous name
to use when referring to our proposed replacement.  In either case, it
behooves us to pick names that won't cause confusion amongst our target
audience.  And the word "capabilities" does not suffice on its own;
it's going to cause confusion. markm

>Unless there is an actual thing to be referred to by the name
>"Lampson-style capability", there is no sense in the name.

This is plainly wrong.  If we want to criticize it, it helps to name it.
What we can't name, we can't critique. 

>You hold a position of respect within the security community. I
>think it would be useful for you to take a position on this issue.

I don't know enough about the history to have a position on the history. 
In any case, I'd be delighted if someone were to write a paper making
the case for (E-style) capabilities, so that I can point others to the
paper, use the paper as a teaching aid, and so on.  I'm probably not the
one to write such a paper, but I'd be happy to help figuring out how to
make as convincing a case as possible. tyler

>I see a third strategy: running code and direct criticism. This is
>the strategy we have been pursuing to date and I think we should
>stick to it.

Well, speaking as an outsider, my sense is that E has been doing a good
job of building running code,  but maybe hasn't been quite as effective at
communicating to the security community the problems with Lampson-style
capabilities (if you'll permit me to use that term) and the advantages
of E-style capabilities.  The latter is probably a harder problem, and
there are good reasons for this to be the case.  I'm not trying to place
blame here -- rather, I'd like to try to suggest constructive directions
for achieving this goal.

I'd especially like to point out that merely having good ideas or merely
building an artifact is not enough to change the security community's 
viewpoints; somehow those good ideas and knowledge gained have to be
communicated to the security community if the security community's
viewpoint is to change.

Maybe I can diagnose the problem here.  Let's suppose the security
community has come to the wrong conclusion here.   (That's fair from clear,
but let's assume it for the moment.)  What should we do?  One response is
to say that the security community ought to figure this out on its own,
and if it doesn't, well, write off the security community.  However,
whether this approach will be successful is rather iffy.

I think it's better to realize that the security community is composed of
smart people who are, by and large,  open to convincing arguments contrary
to their current beliefs, if someone comes forward with those convincing
arguments.  But nothing can happen until someone comes forward with that
argument in the first place.  If those arguments are not communicated
clearly to the security community, we can't exactly expect security
researchers to read our minds, can we?

This is how science progresses.   Science doesn't progress on its own;
it only progresses when people publish and defend disruptive new ideas,
and when those ideas stand the test of time and reason.

In other words, I'm your ally.   I think there may be some good ideas here,
and I'd like to see these good ideas submitted to the marketplace of ideas
in the academic arena.  If you take all those who aren't already 100%
persuaded that (E-style) capabilities are the One True Way, I'm probably
about as sympathetic to your goals as anyone you'll find.  But until the
good ideas are communicated and backed up in a way understandable to the
typical security researcher, I can't help; it's in someone else's hands.
(That's ok, as long as you realize why I can't help; don't assume I
don't want to help.)

>Given that there has been 30 years of "bogosity" surrounding
>capabilities, it is likely necessary that every paper that is
>actually about capabilities contain a footnote about the Lampson
>error. This should be sufficient to avoid confusion, without the
>need to invent a history.

Well, I'm not sure this is a workable approach on its own.  This issue
requires more than a footnote to do justice to.  It needs a whole paper. 
It needs a paper that will be perceived as fair and even-handed.
It needs a paper written in a way that the security community can
understand (and that means a minimum of unfamiliar capabilities jargon).
It needs a paper that presents the argument and leaves out the religion.

Once that paper is written,  it is reasonable to ask people to mention the
issue in a footnote and refer readers to that paper for a more thorough
treatment, but someone does need to write *and publish* that paper.

>The goal is to get capabilities deployed.

Ok, fair enough.  This is a different goal from convincing the security
community.   I can see why it's reasonable to think that maybe the methods
needed are different for these two goals.

I personally suspect the security community could be your ally in
deployment,  if the security community could be persuaded of the value of
(E-style) capabilities, but this is merely a personal opinion, colored
by personal prejudices, and I could well be wrong.  You're in a better
position than I to know what will work, so I'll try not to second-guess
your preferred strategy for achieving your goals.
e-lang mailing list