[cap-talk] Understanding capabilities in a web-desktop setting

[Luke A. Guest]

On Fri, 2008-08-08 at 11:57 -0400, Kevin Reid wrote:
> On Aug 8, 2008, at 10:56, Luke A. Guest wrote:
> 
> > 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?
> 
> Basically: You put the URL in your bookmarks.
> 
> If you can't do that (let's say you're using a reliable-but-not-yours  
> computer), then use a password to access a web site which stores the  
> bookmarks for you -- possibly, but not necessarily, the same site as  
> generated the original URLs.

Ok, but there are some you might type in, i.e. an url mentioned on tv.

What about url's that aren't running on capability enabled
server/os/whatever? e.g. www.google.co.uk, will I still be able to view
the site or would the OS then complain that it can't use it due to
security issues?

> 4. The editor's window's "save" command is managed by its powerbox (a  
> component  provided by the capability desktop system) -- the editor  
> gets write authority when you use that command, and at no other time.

Whatever a powerbox is?

> > 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)?
> 
> You supply a password. This gives you access to your shell, which is  
> just a collection of capabilities stored for you, held by a program  
> providing the UI for you to interact with them.
> 
> You might notice that this is similar to the bookmark-storing tool  
> above. They are exactly the same thing, in different media.
> 
> > 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.
> 
> It's sort of the other way around. You log in, which gives you access  
> to the shell, which stores a list (more likely, a directory tree) of  
> capabilities. There is no fundamental concept of a user; it is just a  
> convenient-for-humans arrangement of capabilities.

You would need some sort of user abstraction, surely, even if it's just
to allow the admin to differentiate between them??

> > 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?
> 
> Yes/no dialog boxes, besides being a usability problem, are against  
> the capability spirit, which as I put it is: do not have special  
> checks, make disallowed actions *impossible to express*.
> 
> Don't take a request for X and put up a dialog box asking the user to  
> grant X; *don't let the requester know X exists*. Don't put it in the  
> requester's namespace, until the user does.

Ok.

Luke.