The article can be further improved by given more examples of capabilities from CapROS, EROS and Coyotos systems. What objects can those capabilities designate? Which operations do those capabilities permit their holder to perform with designated objects? Kosik 05:17, 10 July 2009 (CDT)
It seems the article describes an object-capability as though it is the only sort. I understand it is the type of capability used in E and such, but other sorts are used for security.
- Password Capabilities (SPKI, Certificates) do not need to designate objects
- Object Capabilities
Further, capability doesn't imply unforgeable unless you're talking about secure capabilities, and capability-based security.
You are right. Some capabilities are indeed unforgeable and some are merly hardly guessable. Cannot these two different terms:
- hardly unguessable
be contracted to some single adjective? Using the term "unforgeable or hardly unguessable" is awkward. Kosik 10:59, 10 July 2009 (CDT)
I'm afraid you didn't grok. I mean to say that capabilities may be very forgeable and guessable. They [the forgeable and guessable capabilities] simply aren't secure capabilities, or suitable for capability-based security. And the page still has a heavily object-capability bias.
Concerning object-capability bias, see my suggestion at the top of the page. More example are needed and can be added. I am just not qualified to give them.
It is possible to demonstrate that if you say "capabilities are very forgeable and guessable" you are wrong.
Kosik 11:51, 10 July 2009 (CDT)
Please demonstrate, then. Demonstrate that "Capability" implies "Secure capability" in global vernacular and I'll be happy to recant. But I suspect you're not qualified to do that, either.
Here is a non-trivial example. You can try to explain me how it would be possible for an untrusted sandboxed subsystem to forge or guess arbitrary capabilities?
Similar examples can be also shown in any object-capability programming language one chooses to use. I may try to show some code in E with a similar point. I am not qualified to show any examples showing a similar point in capability-based operating systems but I think on cap-talk there are such people.
Kosik 13:16, 10 July 2009 (CDT)
You've got your logic backwards, Kosik. I'm asserting that not all capabilities are secure, not that all (and 'arbitrary') capabilities are insecure.
What do you mean by "secure capability"?
Kosik 14:55, 10 July 2009 (CDT)
A secure capability is any power to perform an operation that is available to a system but unavailable (not merely forbidden) to a subject acting within that system.
I do not understand the definition:
- "A secure capability is any power to perform an operation that is available to a system but unavailable (not merely forbidden) to a subject acting within that system."
Can you please give some examples of secure capabilities? Something from real systems.
Kosik 07:41, 11 July 2009 (CDT)
There is only one acceptable interpretation of the word "capability" on this wiki and its definition coincides with Dmbarbour's notion of a secure capability. Insecure capabilities do not exist in the world of capability-based security and, hence, have no place on this wiki except under a discussion of "other uses of the word capability", which would also be the place to discuss e.g. UNIX capabilities which are not capabilities in the sense used on this wiki either. --Toby.murray 07:37, 13 July 2009 (CDT)
If it were up to me, I would use the word designation instead of token and the phrase it designates rather then it identifies.
The word token is tricky.
The verb to identify somehow evokes unique naming and that is not what is happening.
But this is a minor issue.
Kosik 09:51, 15 July 2009 (CDT)