[cap-talk] Understanding capabilities in a web-desktop setting
naasking at higherlogics.com
Fri Aug 8 10:32:57 CDT 2008
Luke A. Guest wrote:
> On Tue, 2008-08-05 at 10:41 +0100, Toby Murray wrote:
> I take it you mean that other pieces of software can't guess the URL?
> If an capability URL has a large random string in there, you'll never
> get users to use capability systems; I know I wouldn't want to try and
> type in one of these URL's, or am I missing something?
Why would you be typing it in? How often do you really type in URLs
nowadays without assistance, like auto-complete or bookmarks?
For instance, here's a link to a wiki:
In it, you'll find a capability to edit the comments section:
This capability is embedded in a link on a page I bookmarked, so there's
need for me to remember it or type it in.
The random string in the query part of the URL constitutes the
unguessable identifier which is mapped by the server to an underlying
persistent object. This URL is unforgeable, and the possession of this
URL is a necessary and sufficient condition for accessing the
server-side object named by the URL. That makes it a capability.
> No, someone needs to write an idiots guide to capability systems without
> formal notation to get people to understand this stuff.
There are many introductions to capabilities without any formal
notation.  is where I started years ago. If you consider a capability
a key, like your car keys, but a key that can be easily copied (like
embedding the above URL in this e-mail), that's a good place to start.
Just keep in mind that there are capabilities with even stronger
security properties than "capabilities as keys".
If you're a programmer, then a capability as an object reference is an
even stronger capability than a key.
> My interest lies in OSes and providing a better security mechanism
> within one. So a few related questions here would be:
> 1) What would be the process of logging on to a capability OS (assuming
> desktop or multi-user system rather than embedded)?
Any authentication method is usable in this context, with all the same
weaknesses as in ACL systems. I described a more capability-like
technique elsewhere . I believe this method may have been discussed
on this list in the past.
> 2) How does a user get these capabilities? I can only assume there would
> be the concept of a user and they would have a list of capabilities.
There is no concept of a "user" per se, there are only objects. One of
those objects could of course model a "user" as in conventional systems.
For the above wiki, there are no users, there are only page objects and
editor objects on the server. I hold the URLs/capabilities to all of the
editor objects, and I've publicly exposed only a few page objects. One
of those page objects embeds an editor object, so people on this list
now have access to one of the editor objects.
How would you gain access to the numerous other editor objects without
me granting you access, or compromising the server?
> 3) What would happen if you tried to access a website, would it bring up
> a ton of dialog boxes asking for permission, i.e. the Vista problem?
For the wiki, there are no authorization questions posed to the user.
All authorizations are implicit by following the reference graph (the
graph of links). So it is with capability operating systems.
More information about the cap-talk