[cap-talk] What are caps good for?

[Ben Laurie]

zooko at zooko.com wrote:
> Ever since I saw Marc Stiegler's demo of CapDesk at the O'Reilly Emerging
> Technologies Conference in 2002 [1], I stopped being excited about
> capabilities.  Instead, I became excited about *whatever technology* could be
> used to implement the functionality that MarcS demoed.  If some ACL-based
> technology could do that, then I would be excited about it.  If it turns out
> that no real capability system can enforce various kinds of confinement [2],
> but that it can still implement MarcS's demo, then I'm still excited about it.
> 
> In that demo, MarcS downloaded a text-editor caplet from "texteditors-R-us.ru",
> and used it to edit a precious file, by clicking "File -> Open" and specifying
> which file to load.  After changing some of the contents of the file, he
> clicked "File -> Save As" and specified the filename under which to save it.
> The text-editor caplet was prevented by CapDesk from reading any files other
> than the one that the user specified in "File -> Open", and it was prevented
> from writing to any files other than the one that the user specified in "File
> -> Save As".  All of this is possible without Lampson confinement [*].

This is my favourite example of why capabilities are cool, and the 
uninitiated love it. However, whenever I mention it to someone that 
needs persuading to support capabilities (rather than someone who might 
be a user of them), they say "yeah, heard that before, tell me something 
new", as if this were unimportant. I find that very depressing.

> Now MarcS also demoed something that isn't possible without some confinement,
> specifically that CapDesk prevented the caplet from leaking the contents of the
> file out to the authors of the caplet.  This might not be possible in practice
> (or it might),

Only in a fantastically restricted subset of applications.

However, it did recently occur to me that a non-networked component of a 
notary might be restrictable in this way (i.e. the part with the private 
key that does the signing). If the data were sent encrypted, then this 
would actually be useful. One slight snag is that you could prevent the 
leak by just sending a hash in the first place, but I guess we can 
probably think of a use case for this version.

> but in any case the demo is compelling to me even without that
> feature.

Quite so.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff