[cap-talk] A better reference for the "capabilities propagate too easily" argument

[David Hopwood]

Jed Donnelley wrote:
> At 09:12 AM 7/31/2007, Mark Miller wrote:
>> On 7/30/07, Jed Donnelley <capability at webstart.com> wrote:
>> ...
>>> After that time (say 1987) I know of no designs initiated
>>> using capability access control until the attempt to
>>> revive some of the KeyKOS concepts in EROS.  When did
>>> that work start?  Late 1990s?  Perhaps others can help
>>> me out with references to capability based design work
>>> that did start during this time period (1986 - 1996?)?
>> Eden (85) / Emerald (87)
>> W7 (95).
>> J-Kernel (99)
>>
>> Ancestors of E: Vulcan, Agorics papers (86-88), Trusty Scheme at
>> Autodesk (90?). Joule (90-96?), Webmart (93?), Original-E (95-98).
>>
>> I'm much less familiar with OS-based work,
> 
> Does that suggest that none of the above is OS work?  Certainly
> the 1995 date on the W7 work falls right near the middle of
> what I was claiming as a low.  Looking at the discussion of
> W7 in your thesis it appears W7 is strictly language level
> work.  Even the work on Secure Network Objects seems to
> be couched in a language context, though it certainly seems
> to me to qualify as a network capability mechanism.  It's
> almost as if by hiding under the language umbrella capability
> work could still be done.

My impression is more that language folks never paid much attention
to the criticisms of capabilities in the OS context. After all, for
capabilities to work at all at the language level, the language must
rely on free copying of capabilities for parameter passing.

>> What about Grasshopper
> 
> Looks very interesting.  I wasn't aware of Grasshopper before.  Also not
> in the US, but still seems to be an unabashedly capability system.

The papers on Grasshopper published at the time (at least the ones I
was aware of) never really brought out that it was a capability system;
as far as I remember they were all very much focussed on the
implementation of, and motivation for, orthogonal persistence.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>