[cap-talk] Applications for a capability platform - PLASH discussion

[Jonathan S. Shapiro]

On Fri, 2008-02-29 at 17:03 -0800, Jed Donnelley wrote:
> If the above were the case then I think we can agree that the
> semantics of chmod would not be supported.  The main point of
> chmod is to make a permanent change in the access control
> metadata that either enables more sharing or less.

Yes and no.

First, PLASH incorporates mechanisms that accomplish more of this
semantics than I described.

But more importantly, there is an enormous gap between the de jure
semantics of POSIX and the de facto semantic requirements of POSIX
applications. For example: in practice, the overwhelming majority of
calls to chmod are permission *downgrades*.

It isn't the objective of PLASH to faithfully reproduce the de jure
POSIX semantics. The objective of PLASH is to reproduce the de facto
requirements sufficiently well that ordinary applications will, in
practice, execute.

> > I am aware that exceptions to this statement exist. By "zero", I mean
> > "zero applications having measurable market share".
> 
> The above is what I expected from my more limited knowledge.  That
> seems to suggest that there is, as yet, no appreciable value in
> a shared API for the cell phone software platform.

I think that is very hard to measure. It is possible that, were an open
API to exist tomorrow, a large latent demand would thereby be revealed.


> > As to your comment about "capabilities visible at the API", I think
> > that's silly. The driving issue is capabilities visible at the UI.
> 
> Interesting.  While I agree that the driving issue is capabilities
> visible at the user interface, I don't know how you can supply
> capabilities at the user interface without first providing then
> through the application programming interface.  The UI sits on top
> of the API does it not?

Certainly. My point was that until you can articulate a motivating use
case at the UI layer, any development effort on a capability API is both
wishful and speculative.

> > Find me an application where that is well-motivated in the eyes
> > of my Dad and then we can discuss whether or not a cap
> > manipulation library is called for.
> 
> Any sort of sharing between people or between people and computer
> "domains".

Perhaps. But it appears to be the character of embedded devices that
sharing is pretty limited today. That's a barrier whose resolution might
redefine the character of portable embedded devices. Or not. Hard to
know without doing it.

One thing does seem pretty clear, which is that sharing of this sort
will be based on a distributed, unprotected capability model. The
challenge from the user perspective will be managing durability
contracts.


>   I'd like, right now to share with you access to a
> video that I have on my computer.

If it's a video of you doing something unmentionable, please don't send
me the capability. :-)

>   If that video was right now
> on YouTube, no problem, I could just share a URL with you.
> Of course at that point the video would be visible to the
> world - which may not be what I really want.

Yes. This is the problem that portable embedded devices need to address.
My cell phone is never going to serve you a video reliably, if only
because of available bandwidth variations. This means that we move
fundamentally to a storage server based architecture, and then we run
into all of the problems of hard-to-authenticate distributed network
capabilities.

> I'd like to be able to create a "folder" (directory) on
> my computer that I can share with you as THIS FOLDER.

A bit of thought will convince you that you will not, because of latency
and consistency issues. I think I understand what you are after. I'm
only trying to point out that the semantics of a local folder cannot be
reproduce in an intermittently connected environment having highly
variable bandwidth. The differences in behavior are observable enough to
warrant some metaphor that is not "folder".

> That's a model that I believe your Dad can understand.

Probably not. The consistency disparities between "shared,
intermittently-connected namespace with strange consistency properties"
and "folder" is more than large enough to completely bewilder him. It's
a deceptively hard UI and user conception problem.



shap