[cap-talk] "Ambient capability"
toby.murray at comlab.ox.ac.uk
Mon Jul 13 12:09:14 EDT 2009
On Mon, 2009-07-13 at 11:47 -0400, Sandro Magi wrote:
> Assuming it's the same individual, dmbarbour is a frequent contributor
> to LtU, and he generally seems fairly knowledgeable on programming
> language issues, including object capabilities.
> In reading the article and the talk, I suspect the disconnect arises
> simply because the programming language literature has a more precise
> set of names for certain notions that capabilities are simply agnostic to.
I also suspect we have a more precise meaning with some of the
terminology we use. In particular, Dmbarbour's use of the word
"capability" appears to be more inline with the everyday use of the term
along the lines of "ability" or "power".
Some of the discussion on the erights wiki has involved making
distinctions between "secure" and "insecure" capabilities, namely ones
that cannot and can be forged respectively. In this sense, there is no
such thing as an insecure capability in a capability-based system,
including all object-capability systems.
My personal preference is that words like "capability" should be used
on the erights wiki in the precise sense in which they are understood
within the domain to which the erights wiki pertains -- namely
> I think "ambient" in "ambient capability" actually refers to mobile
> ambients , and that dmbarbour is trying to describe ways in which the
> local capabilities of migrating code can be either proxied or rebound
> based on a program-specific policy.
There probably should be some policy discussion regarding the "focus" of
the erights wiki. Is it focused mostly on:
- Object-capability security?
- Capability-based security?
- Programming-language-based security?
This naturally determines how words like "ambient" and "capability" that
have different meanings in different disciplines (e.g. capability-based
security versus programming language theory versus programming language
security etc.) should be interpreted on that wiki and whose (i.e. which
community's) definitions should take precedence.
More information about the cap-talk