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

[Jed Donnelley]

On 2/29/2008 3:08 PM, Jonathan S. Shapiro wrote:
> On Fri, 2008-02-29 at 14:44 -0800, Jed Donnelley wrote:
>> On 2/29/2008 9:49 AM, Jonathan S. Shapiro wrote:
>>> On Fri, 2008-02-29 at 09:27 -0800, Jed Donnelley wrote:
>>>> At 06:18 AM 2/29/2008, Jonathan S. Shapiro wrote:
>>> The net effect of this is that the application is oblivious to the fact
>>> that it runs within a capability environment, and no "caplib" is
>>> required. A major point of PLASH is that application re-engineering is
>>> not required.
>> How do I run "chmod" under PLASH?
> 
> Toby has used it, so I suspect he is better able to answer this than I
> am, but here is my guess. Chmod behaves in the usual way, but its effect
> does not survive the exit of the application unless the PLASH power box
> agrees. Since the name space visible to the application is not shared
> with any other application, the presence of a chmod'd file doesn't
> hazard third-party applications.

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.

> The more interesting case would be chmod involving setuid. I suspect
> that this is simply rejected, or that allowable setuid/setgid is
> configurable through the power box, but I do not know.

My reason for mentioning chmod is as representative of the
Unix/POSIX sharing model.  I don't believe that such a model
is appropriate for an underlying capability infrastructure.
I believe that capabilities provide an different model for
sharing and that to effectively provide the additional value
that a capability platform can provide one would need to go
beyond POSIX semantics.

>> PLASH would seem to provide
>> no interface to the underlying capability infrastructure, specifically
>> for delegation (sharing) of authority.  That is where I was suggesting
>> that something like "caplib" could be needed - if we had enough
>> of an underlying capability infrastructure to make it worthwhile.
>> At least capability manipulation could have an agreed upon API.
> 
> I suspect the mechanism for this in PLASH would be some variant of
> link(2), wherein the application first constructs the object in its
> private name space and then links it into a public name space subject to
> consent of the power box. Recall that PLASH is limited to the set of
> objects supported by UNIX (basically files and directories), so this
> would seem to be the "natural" (least unnatural?) method of publication.

Which is directly to my point.  Link might be the "least unnatural",
but it doesn't provide the same semantic model.  The idea of link
in POSIX is just to change the way names work, not access control.
The capability access control model is distinct and more suitable
for distributed applications.  Unless that capability model is
made available through the API and to the users, then I don't see
much value in building/supporting an underlying capability
platform.

>> Hmmm.  What about the issue of "third party" software?  It has
>> generally been when significant amounts of software started being
>> developed for a platform (e.g. the PC, Mac, Unix) that the issue
>> of the API becomes significant.  Are the software developers
>> all working still to support a single vendor at this point?
> 
> To date, there exists essentially zero third-party software for cell
> phones. What there is generally turns out to be replacements for things
> like the browser or the email reader that comply more fully with
> external standards.
> 
> 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.  Develop the
platform more and you may find that software developers will want
something more standard, in fact you may find that what they want
is something that they can readily get programmers for like
Windows or Unix...

> Ignoring javascript, All of the software that you will ever use on your
> cell phone ships with the phone, and all of the data manipulated by
> those applications divides neatly into:
> 
>   1. Externally stored data in a standard format or accessed through
>      a standard protocol.
> 
>   2. Externally stored, non-migratable data accessed through a
>      proprietary and undisclosed protocol. Some cell phone email
>      accounts meet this description (and are therefore useless to me).
> 
>   3. Locally stored, non-migratable data in a proprietary format.
> 
> By "non-migratable", I mean that you need to go through sufficient
> contortions that nobody bothers. There do exist address book transfer
> programs, but I don't know anybody who has actually bought one.
> 
> All of the cell phone "applications" are being delivered by WAP or by
> HTML, mainly because the vendors failed to implement *any* internal
> security mechanisms on these platforms, and cannot accept the risks
> associated with wide access to the development SDKs. Also because the
> phone vendors are trying to get a chunk of change from the developer,
> and for most developers it just hasn't been worth the bother.
> 
> Things like OpenMoku may start to slowly tip the balance over time.
> Perhaps too early to tell.

Makes sense to me.  As you say time will tell.

>> While the above may not be GNU applications, I agree with Toby that:
>>
>> On 2/29/2008 10:03 AM, Toby Murray (in response to above) wrote:
>>  > These applications all depend on the standard POSIX interfaces.
> 
> On cell phones this is not true, because to first order no POSIX cell
> phones exist.

Not yet.  As above, time will tell.

> 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?

> 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".  I'd like, right now to share with you access to a
video that I have on my computer.  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.

I'd like to be able to just copy a link to that video and
put it RIGHT HERE for you Jonathan.  When you receive my
email, you can click on it and view it.

I'd like to be able to create a "folder" (directory) on
my computer that I can share with you as THIS FOLDER.  You
pull it out of this email and then any time I want to
share anything with you (or a 'group' that I might set
up) I can put that "thing" (think files or other directories)
into that "FOLDER" above.

That's a model that I believe your Dad can understand.  It's
a model that I believe has wide applicability, including
on the Web.  Its the basic capability model.  This email
is a message, if it was a "capability" email I could put
references to objects into it as "capabilities".

To provide such a facility (my vision/dream for over
35 years now) I believe there will have to be some visibility
at the application programming interface level.  Not much
perhaps, but still some so that the capabilities can be
made available at the user interface which, we seem to
agree, is where its really most needed.

--Jed  http://www.webstart.com/jed/