[cap-talk] "Ambient capability"

[Sandro Magi]

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 think "ambient" in "ambient capability" actually refers to mobile
ambients [1], 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.

For instance, Alice ML [2] provides infrastructure for managing
references to local primitives objects and services so they can be
either rebound, or perhaps allow proxied remote access when code is
loaded and unloaded.

I'm not sure object-capabilities have anything specific to say about
this, at least there's no specific terminology I'm aware of. I believe
MarkM's thesis deals with code loading, so perhaps there is something
more specific in there.

Assuming I'm right, I'm not sure ambient capability is a good term given
the understandable confusion with ambient authority.

Sandro

[1] http://en.wikipedia.org/wiki/Ambient_calculus
[2] http://www.ps.uni-sb.de/alice/

David-Sarah Hopwood wrote:
> Kevin Reid wrote:
>> On Jul 11, 2009, at 0:38, David-Sarah Hopwood wrote:
>>> Kevin Reid wrote:
>>>> Someone just wrote this page on the erights.org wiki:
>>>>
>>>>   http://wiki.erights.org/wiki/Ambient_capability
>>>>
>>>> I've never seen this term before and the description feels a little
>>>> off. Would the scholars and taxonomists of cap-talk please review/ 
>>>> edit this article?
>>> I don't understand what this page is trying to say either. The term
>>> "capability" should be reserved for an actual capability (first-class
>>> value that combines an object designator and authority to that  
>>> object); this page seems to be using it differently.
>>>
>>> At first sight, having permissions vary "by virtue of context" seems
>>> like an antipattern in any capability system.
>> Further info: User:Dmbarbour, the author of this page, also wrote a  
>> definition of "Object capability". They claim to be a scholar of  
>> capabilities. They have been somewhat antagonized by User:Kosik.
>>
>> I am concerned about a shortage of viewpoints from the wider cap-talk  
>> community.
>>
>> Any of you with time, please review these pages and their histories  
>> (especially the editing of [[Object capability]]) and contribute.
>>
>> http://wiki.erights.org/wiki/Talk:Object_capability
>> http://wiki.erights.org/w/index.php?title=Object_capability&action=history
> 
> The definition added by User:Dmbarbour was:
> 
> # For [http://en.wikipedia.org/wiki/Object-capability_model
> # object-capability model security], object capabilities are secured
> # by making them unforgeable (often via type system) or very difficult
> # to guess (necessary for distributed objects).
> 
> This is incorrect; "very difficult to guess" is not sufficient for an
> object-capability (by definition; see MarkM's thesis, which introduced
> the term specifically in order to distinguish "unforgeable" from
> "difficult to guess"). Much of the rest of the text added by Dmbarbour
> and removed by User:Kosik in
> <http://wiki.erights.org/w/index.php?title=Object_capability&diff=3516&oldid=3506>,
> was also nonsensical or confusing. I might have made a similar edit,
> and I agree with pretty much everything Kosik says in the Talk pages.
> 
> I do appreciate your implied concern about the tone of responses to
> new contributors. But it really does not help to let clearly incorrect
> definitions stand, just to avoid the potential of antagonising such
> contributors.
> 
>> http://wiki.erights.org/wiki/Capability
>> http://wiki.erights.org/wiki/Talk:Capability
>