<br><br><div class="gmail_quote">On Mon, Mar 2, 2009 at 9:23 PM, James A. Donald <span dir="ltr"><<a href="mailto:jamesd@echeque.com">jamesd@echeque.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Do people think that this description of capabilities makes sense? I<br>
solicit criticism.<br></blockquote><div><br>I'll admit to being critical of the 'object-capability system' bias. To me, a capability is any tight coupling of authority and ability that can be granted, delegated, or transferred independently (that is, without also needing to grant, transfer, or delegate a larger authority or ability). SPKI capabilities and other password capability systems can, and should, qualify as capabilities. They are of particular interest to "offline" designs, rights escalation, and exclusive transfer. <br>
<br>Where you use 'capability', I'd use 'object capability'. They have the advantage of being very efficient, and a disadvantage of being weak against network disruption (when dealing with distributed object caps).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
A capability is an object, object in the sense of "object oriented<br>
language", that combines unforgeable designation with permission - it is<br>
an object that enables an entity to do something, to do something to or<br>
with a very specific thing, the thing designated.<br></blockquote><div><br>What does 'unforgeable' mean? If I can guess at 160-bit numbers and eventually obtain a capability in a distributed system, was that 'unforgeable' or just 'difficult to forge'? To me, 'unforgeable' means 'impossible to forge', which physically cannot apply to delegable and transferable capabilities in a distributed system. All we can do is make forgery arbitrarily, and cryptographically, difficult - and then mount a more active defense to detect likely forgeries.<br>
<br>And regarding "object" and reference to "object oriented language" - that's poorly defined. You'd need to eliminate issues of, say, examining references to the caller or the call-stack as is performed in Common Lisp for its condition-reset mechanism. You'll also face issues that in most object languages, you have capabilities to do stuff even without object refs. You'll further face issues that many OO languages lack any sort of protection against viewing their guts, such that they cannot grant capability to JUST do a specific thing - they grant the whole gamut of implementation. <br>
<br>And then there is "enables". You could create an unforgeable reference to an object that opens a file... but if that capability is part of the environment ('ambient'), then anyone to whom you passed the object isn't getting any new capabilities... they're just getting a helper object.<br>
<br>Besides, you should define 'capability' first, then explain why 'objects' can (under certain constraints) be such fine examples of them. That would help eliminate the object-capability bias, and force you to reduce conceptual dependency on ill-defined concepts.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
But since a capability grants permission it in practice is also a<br>
communications channel, or the ability to open a communications channel,<br>
between two entities - thus for example a file handle is a<br>
communications channel between some program, and the highly privileged<br>
operating system software that has block level read/write access to the<br>
disk.<br></blockquote><div><br>That does not seem to follow. Since when does permission "in practice" also determine ability? If you had permission from Mr. Obama to fly me to the moon (and let me dance among the stars... though I'd prefer to avoid metaphor) could you do so?<br>
<br>No, capability *grants ability*. That's the reason it includes a communications channel or the ability to open one. Ability isn't a feature of permission. Ability AND 'permission' are both features of capability. If you grant one decoupled from granting the other, you did not grant a capability. Granting ability without authority is just dangerous, since then you need to control use of the ability by other mechanisms (usually 'trust' and more active detection + rectification). Granting authority without ability is often futile, though it does work at times as an element of rights escalation.<br>
</div>Anyhow, that's my criticism. I'm reluctant to mention it to a forum that is so object-capability biased and that doesn't bother rectifying distributed-system capabilities with misleading phrases like 'unforgeable' despite the clear examples in Pluribus. Last time I said even suggested that capability might allow for more than object capability, I received confusion from many and attacks from a subset of that many. I doubt expressing my opinion is worth that trouble, but I'll take that risk this one more time.<br>
<br>Dave<br><br></div>-- <br>hubris and humility compose<br>perfectionism, paralysis, a curse<br><br>