[cap-talk] Avoid overconfidence (was: Any hope in RSA 2008?)

Ivan Krstić krstic at solarsail.hcs.harvard.edu
Tue Apr 8 03:15:51 CDT 2008


On Apr 5, 2008, at 11:00 AM, Mark Miller wrote:
> As I read this thread, I worry that we may drown by filling the boat
> with our own kool-aid. Let's please not get overconfident. [...]
> Bottom line: Capabilities today can make a system's security much more
> robust against its own bugs. (Part 4 of my thesis, "Emergent
> Robustness", explains what I mean in more depth.) But beyond this, we
> should avoid making stronger claims, or sounding like we're making
> stronger claims.

Thanks for providing a voice of reason, Mark. Sometimes this list can  
sound outright delusional. In the "what sparked interest in  
capabilities" thread about a month ago, I wrote at the end of my  
message:

"The challenges for this community appear to be producing:

1. real-world systems that solve real-world problems in convincingly
   superior ways than mainstream alternatives, and

2. explanations of their beliefs and ideas that are widely-accessible,
   well-written, and compelling. I can't point everyone who asks me
   about capabilities to MarkM's thesis, and I don't know what else
   to point them to."

Moping about capabilities being ignored by research and industry is  
misplaced energy, and when coupled with implicit and relatively  
unsupported claims of the supposed superiority of the approach, it  
just all looks foolish. Neither researchers nor security product  
designers are idiots. If you show them your approach is good, they'll  
listen. Yet forty years after people started looking into capability  
systems, there still exist neither excellent written materials on the  
subject nor compelling real-world demonstrations of their superiority  
to alternatives. This means that the people who are championing this  
approach simply aren't doing a good job, and the fact they're being  
ignored is largely their own doing.

Not to pick on Jed in particular, but since he's one of the most vocal  
list members and also tends to write relatively elaborate and frequent  
messages, how about a challenge: Jed, stop posting to cap-talk for a  
few weeks and channel the energy into writing a 3-5 page capabilities  
primer that a programmer can pick up without prior exposure to the  
ideas, and go "wow, this makes a lot of sense". Mercilessly write,  
edit and rewrite until you have something that's deathly efficient in  
delivering the message and a gripping read. I suggest focusing on  
Tahoe's use of capabilities as an example, since it's a _real-world,  
working system_ that derives benefits from the use of capabilities and  
whose source is publicly available. In fact, if the whole document  
began as a case study of how and why capabilities are used in Tahoe,  
it could be a great read. Cap-talk can have a pass at commenting on  
the final document, and I'll offer proofreading and edits as well as  
posting it on a website which gets tens of thousands of unique readers  
a month, many quite technical.

The challenge applies to whichever reader(s) of the list wish to pick  
it up. What say you?

--
Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org




More information about the cap-talk mailing list