Talk:Ambient capability

From Erights

I have never heard of this term. Why do we need it? Isn't the term ambient authority sufficient? Can you give some example of things you (the author) consider as an example of ambient capability? Are there some examples of ambient capabilities that are somehow different from ambient authority? Kosik 01:19, 10 July 2009 (CDT)

Ambient authority doesn't apply unless permissions are enforced in denying an operation. The two are barely even related. Ambient authority is not sufficient or appropriate as terminology to properly discuss the circumstances surrounding distribution and mobility.

Consider an object that accesses the following:

• a keyboard
• a monitor
• current local time via a clock
• random number generator
• a HTTP cache
• a Domain Name Service
• a timer (10 Hz event)
• hooking into Data Distribution Service (a distributed publish/subscribe)
• local memory allocations (i.e. to allocate values)

These capabilities are ALL ambient, at least initially. Access to each of them is highly contingent on context. It takes much work to create a common namespace that would let one machine have access to the monitor or keyboard on another machine.

But consider:

• An object-capability system (OS or language) is likely to wrap access to the keyboard and monitor into objects with secure (unforgeable) designations. If the above object is mobilized, the keyboard and monitor objects designate the keyboard and monitor on the original host, thus causing messages to cross the network. That's the desired behavior... keyboard and monitor are reasonably 'unique' ambients (though one might transparently replace the keyboard or monitor), so fit reasonably well into the object capability system.
• Access to a clock, random number generator is more questionable. object-capability languages can go either way: allow access as new language primitives, in which case the 'current local time' is ambient to programs written in that language (and refers to the time on the host). Or wrap these into objects, in which case once object is mobilized it will need to send messages across the network for each request to the current local time. Sending requests for random numbers across the network is wasteful, at the very least. Accessing a clock across a network introduces variation in latency.
• access to HTTP cache and Domain Name Service across a network after mobilization is pointless, but also demonstrate that there's no feasible way for object-capability languages to possibly provide all the desired ambient capabilities AS object capabilities after a mobilization.
• Access to the 10 Hz event and DDS adds an extra challenges: having subscribed to these locally requires handing object-capabilities to other objects on the local system in order to subscribe and later unsubscribe. When mobilizing, however, having a 10 Hz event or DDS updates cross the network is problematic: those services can easily be provided locally for much higher performance, reliability, consistent latency, and quality of service. This suggests some first-class support for subscriptions (and later unsubscribe) to ambients is necessary to deal with certain distribution issues.
• Most object-capability languages simply make allocations from local memory into 'primitives' making them ambient to the program, but there is always talk of wrapping memory resources into capabilities in order to handle quotas and such. After a mobilization, the 'primitives' approach means that the object will allocate any new objects on the remote machine, whereas if memory is wrapped into quota caps then one will be allocating memory on its original host. This suggests, at the very least, that quotas need to be handled differently if object-capabilities are to be networked.

Object-capability languages + distribution or mobility benefits considerably from first-class support for ambient capabilities. But to discuss such possibilities requires that one first understand terminology such as ambient capability.

Usefully, ambient capabilities - even 10 Hz events and DDS and HTTP cache and DNS - can be reified. But one needs to explicitly recognize such ambient capabilities as being distinct from object capabilities.

May I choose single of your points? You say that access to a local time via a clock is an "ambient capability". This is false in case of Tamed Pict. Untrusted sandboxed subsystems do not have such an "ambient capability". What kind of "ambient capabilities" have untrusted sandboxed subsystems written in Tamed Pict? What kind of "ambient capabilities" do have untrusted sandboxed subsystems written in E?

Other points are also false but that is beyond the scope now until you show a single "ambient capability".

Kosik 13:35, 10 July 2009 (CDT)

I said that "local time via a clock is an ambient capability, at least initially". I.e. at the hardware/OS/abstract-machine/LAN level. I then go on to explain options available to a secure capability-system (like a capability OS or object-capability languages) for securing these capabilities. Two options were explicitly mentioned:

• wrap the ambient capability to the local time via a clock in an 'object' with a secure object capability. This has certain implications when comes time to mobilize objects (i.e. for load-balancing, disruption tolerance, etc.)
• or allow access to local time as a language primitive, which tends to add excessive authority to the language.

There are many more options, of course. Infinitely many. Two more are:

• One can create a 'major domo' object that provides a set of factories for certain local capabilities to 'guests', who must take advantage of them. The factories and the rest of the system is secure and thus provide a sandbox (up to primitive caps, such as memory allocation in many languages).
• One can reify the notion of an 'ambient', thus producing ambient objects that have the same semantics everywhere but different implementations. One may then provide something similar to object capability to these reified ambients through factories rather than as language primitives, and these access to these ambients will implicitly follow objects as they are distributed.

Tamed Pict just happens to choose one option among many: it uses the 'major domo' option to provide access to local time and various other features. The 'major domo' seems to be expressed by importing some 'trusted' modules, which provide those capabilities to the guest via automatic construction of various hooks. Unfortunately, this sandbox approach has many flaws for transparent distribution:

• the provided capability isn't tuned to the guest, which means it provides excessive authority for some guests and insufficient authority for others
• if the major-domo doesn't provide a necessary capability, the guest cannot transparently continue using the remote capability to ensure the guest has the exact same capability before and after mobilization.
• active interactions with these ambients (e.g. subscriptions) are not maintained and must be rebuilt by the guest after each mobilization, pretty much utterly destroying transparency

Transparent distribution, especially automatic distribution, especially of the first-class sort, is useful for: redundancy and self-healing, load-balancing, latency and bandwidth optimizations, improved quality-of-service, and disruption tolerance.

ambient authority is not ambient capability. A secure ambient capability must not be denied or lost simply because one is mobilized to a new sandbox. ambient authority will 'grant' or 'deny' permissions. It is effectively expressed by granting a set of factories to the guest - the guest may only behave within the limits of those factories. By comparison ambient capability is effectively expressed by ensuring the guest has the exact same set of capabilities both before and after a mobilization - but only up to semantics, allowing (and sometimes requiring) for the guest to automatically take advantage of the local HTTP cache, local random number generator, local timers, etc. Unlike objects, ambients have poorly defined boundaries. --Dmbarbour 15:57, 10 July 2009

It sounds to me like these "ambients" that you describe just above are singleton una; for example, the LocatorUnum in CapTP, which to any object holding it grants the authority to convert bits into object-capabilities to any object reachable over CapTP. Similarly, access to a clock (in the sense of "what time is it now?") is universal -- real time is the same no matter what machine or process you're in. Does this fit the concept you're describing? --Kevin Reid 19:58, 10 July 2009 (CDT)

The Unum Pattern is certainly related. It is clearly aimed to reify universals or ambients, working around some of the problems of object identity. It's incomplete, though... it doesn't handle domain-of-presence (context) and it doesn't handle reverse direction interactions (e.g. subscriptions to a 10 Hz signal). Thanks for pointing it out. -- 198.253.49.6 21:11, 10 July 2009 (CDT)

I do not understand the definition:

"Ambient capability describes constraint and provision of operations by virtue of context."

Can you please give some examples of ambient capabilities? Kosik 01:23, 11 July 2009 (CDT)

Dmbarbour,

I have deleted your text (although it can still be found in the history). If you want to discuss it, please:

• either contact me personally (kosik at fiit.stuba.sk)
• or, better, join cap-talk mailing list.

Best regards.

Kosik 07:00, 13 July 2009 (CDT)

I suspect that "ambient capability" and "capability" as used by Dmbarbour is best interpreted to mean "ability". I suspect that Dmbarbour is using the word "capability" in its everyday, informal sense. For example, an everyday definition of the word "capability" is "The power or ability to generate an outcome." In this sense it is more similar to "authority" and "permission" than to the specialised use of "capability" that can found on this wiki.

Understood in those terms, Dmbarbour's definitions of Capability, Object-Capability and Ambient Capability make some sense. However, I would argue that none of them should remain in their current form on this wiki. The reason is that the word "capability" has a very specific meaning here that is not equivalent to its use in everyday language. Keeping pages and definitions that fail to recognise this specific meaning is confusing to users who are trying to learn the terminology of capability-based security.

For example, in capability-based security there is no such thing as an "insecure" capability. Talking about such things is unhelpful because it conflates two different and separate definitions of "capability".

I expect that Dmbarbour probably has a lot of good to contribute to discussions of capability-based security. I'd encourage him/her to join cap-talk or e-lang to discuss these ideas. I'd also strongly urge him/her not to take the positions that Kosic and I have taken here as anything personal or disparaging against him/her or his/her understanding of capability-based security, but merely as a sign that certain words have very specific definitions within the community of people that Dmbarbour has recently joined (welcome!) and that these definitions must be adhered to for meaningful discussion (and communication with the outside world) to take place. --Toby.murray 07:35, 13 July 2009 (CDT)