Talk:Object-capability model

message: To do:
* Add etymology to introduction [done 2007-01-06T22:38]
** The name comes from recognition of the fact that "pure" object-oriented programming constitutes the capability-based security model. [done 2007-01-06T22:38]
** Touted advantages of objects (encapsulation, modularity) are precisely what we want for security (privilege separation, least privilege). [done 2007-01-06T22:38]
* Section: Advantages of object-capabilities
** No such thing as ambient authority (explain what that is)
** Only connectivity begets connectivity
** Show the Granovetter diagram!
** No fixed set of operations (read, write, etc.); everything is invocation
** Section: Combining designation and authority
*** Solving Confused Deputy
* Section: Relationship to object-oriented programming
** references are called "pointers" Pointers often imply pointer artimetric which is forbidden in object capabilities systems. Also Java documentation uses the word reference instead of pointer --Zarutian (talk) 03:20, 10 September 2008 (UTC)
thread_title:  To do 

message: * Synergy (can + can opener => contents)
* sealers/unsealers
* factory pattern
* membrane pattern (probably doesn't belong on front page) Would require introduction to revocable forwarders --Zarutian (talk) 03:24, 10 September 2008 (UTC)
thread_title:  A few additional topics 

message: So far this page is pretty abstract.  I think the first subsection after the introduction should give a practical example.
— Ka-Ping Yee 23:59, 6 January 2007 (UTC)
thread_title:  Concrete example 

message: A request from Mark Miller (erights):
* This article has suffered some from reversion wars, where some anonymous contributors revert some editorial revisions of other anonymous contributors, back and forth. I have done this myself. So that discussion can replace further reversion wars, I ask that all potentially controversial edits to this article be done after logging in, so disagreements can be more directly discussed. Hereafter, I will do so as well. 
* Question: Is there any way to put a wikipedia article into a state where such login is required in order to edit? --Mark S. Miller (talk) 07:54, 6 July 2009 (UTC)
thread_title:  A request from Mark Miller (erights) 

message: The text below was deleted by a wikepdia editor
:There is a controversy as to whether to use the terminology "address" or "reference" for the capability to send a message to an Actor/Object/Resource.  The following arguments have been made in favor of using "address":
:*Address is a term that has been traditionally been used for providing the capability to deliver a message as in "network address" and "email address".  
:*The memory address an Actor/Object can be used to invoke it.  Such memory addresses can be protected against forgery by the use of tagged architecture and by the use virtual machines such as Java Virtual Machine and Common Language Runtime.
:The following arguments have been made in favor of using "reference":
:*Reference is a term that has been used in some programming languages for a value that enables a program to directly access the particular data item, such as a variable or a record, in the computer's memory (e.g. "ref" in Algol 68 and "&" in C and C++). The reference is said to refer to the data item, and accessing that data is called dereferencing the reference. 
:*References in some programming languages cannot be synthesized or forged. For example pointer arithmetic is sometimes not allowed on references.  Also, in some programming languages (e.g. Algol 68 but not C and C++) integers cannot be converted into references.
:Both "addresses" and "references" have some limitations:
:*Addresses need to be distinguished between those that are just plain text like "billg@microsoft.com" and those that are unforgeable (unguessable) Actor addresses.  A text address like "billg@microsoft.com" does not by itself provide the means to send a message:  the internet address of a mail server is needed in addition.  Also Actor addresses need to be distinguished from addresses on current stock hardware (e.g. X86)  that allow reading, writing, and executing the contents at the memory address.
:*References need to be distinguished between those in current programming languages that typically allow assignment to change what is referenced and the newer invokable-only references discussed in this article that can be used only to send messages.
It seems to me that the argument above for the use of "address" is preferable to the one for "reference."--171.66.82.181 (talk) 16:50, 6 July 2009 (UTC)
thread_title:  Addresses versus References Controversy 

message: The following was deleted from the article:
:It is important to note that both the address and message are required.  Having just an address may not be sufficient because the sender may not be able to construct a workable message.  Likewise, having just a message may not be sufficient because it may not be possible to construct an address that will work.  For example, a web-key  may be needed.  Also the Actor at an address that receives a message retains the ability to decide what to do.
The above material has important information that should be restored.--171.66.82.181 (talk) 17:58, 6 July 2009 (UTC)
thread_title:  Both a (typically unguessable) address and  (often unguessable) message are necessary but not sufficient to perform an operation 

message: Below is some material that can be used in explaining the relationship of Object-capability model and the Actor model:
Most of the object-capability model was first formalized as the Actor model of concurrent computation. However, there are some differences including the following:
:*The Actor model prefers to use the terminology "address" for where to send a message instead of the term "reference" which has been preferred by some object-capability researchers. 
:*Being readily applicable to cloud computing (where unforgeable references cannot be implemented), the Actor model allows the use of unguessable addresses interchangeably with local computer unforgeable references.   (For the purposes of the Laws for Actors, if any information about an unguessable address is leaked, then the whole address is leaked.)  Because the Actor Model allows this use of unguessable address, it is not an Object Capability model.  Conversely, because the Object Capability Model does not allow this use of unguessable addresses, it is not an Actor Model.  
:*Object-capability systems differ from the Actor model as follows: 
::*concurrency:  The Actor Model uses message passing for all aspects of concurrency so that the thread pools, locks, queues, cores, etc. used in its implementation are not exposed.
::*storage management:  The Actor Model assumes real-time garbage collection of all Actors (preferably with no pauses) including futures.
::*eq:  The Actor Model allows testing two Actor addresses (perhaps obtained from different sources) to determine if they are the same. 
::*typing:  The Actor Model allows the implementation of programming languages that allow optional typing, e.g., ActorScript.
::*primitiveness of messages:  The Actor model allows (binary) XML and JSON to be used as primitive messages.
::*ordering of message arrival:  The Actor model posits an arrival order on messages sent to a serialized Actor.
:* The Actor model requires that loaders, evaluators, etc. obey the laws for Actors.  On the other hand, the object-capability model requires a loader (eval, exec) having the property of _loader isolation_. A loader loads data describing behavior (code, script, lambda expression) together with an initial state (c-list, environment, instance variable frame, acquaintances) to create a new object. A loader obeys _loader isolation_ if the new object's only initial references are from the explicitly provided state, with no implicit grants by the loader itself.  The Java ClassLoader violates loader isolation, making confinement of unexamined loaded code impossible.
--171.66.85.160 (talk) 20:56, 6 July 2009 (UTC)
replies: text: ^^^^^ Strange message as said Internet Protocol version 4 address belongs to Stanford Univeristy and has most likely been reassigned to someone else, special if that time period is taken into account. Obj-cap model isnt based on the Actor model as the latter came into being much later. More likely is that the Actor model was somewhat influenced by what we now call obj-cap model rahter than the other way around. (Specially the question if 'names' in Actor model are protected or not.)  Zarutian (talk) 02:45, 1 January 2014 (UTC)
thread_title:  Relationship of the Object-capability model and the Actor model 

message: I support a merge of both this page (Object-capability model) and Capability-based security with the RBAC article, which appears to be more abstract/theoretical/clean in its description. RBAC could benefit from the implmentation list here. prat (talk) 22:57, 6 December 2015 (UTC)
replies: text: Care to explain your reasoning? prat (talk) 23:29, 6 December 2015 (UTC)
replies: text: Please see http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf, which describes in detail how capability-based security differs from identity-based access control mechanisms. RBAC is a mechanism for managing the mapping from identities to permissions; it is still identity-based, which makes it fundamentally different from capability-based security. Kenton Varda (talk) 01:03, 7 December 2015 (UTC)

text: Disagree, sorry. "role-based access control ... is an approach to restricting system access to authorized users." It is used in various types of software and with various techniques. Different from this, this article "describes a transferable right to perform one (or more) operations on a given object". An object is not a role, and the two subjects are different in conceptual, systematic and practical perspective. Then again, Capability-based security is a special software technique that may or may not use one of the other two techniques. So it really makes sense to have different WP articles for these three topics. Or, if we imagine one article comprising them all, we would happily separate them. --Bernd.Brincken (talk) 10:46, 20 January 2017 (UTC)
thread_title:  Merge proposals 

message: After reading through the comments, there was no support for the proposal to merge the articles, but several arguments against. So we can close this proposal and remove the template from the three articles. --Bernd.Brincken (talk) 10:51, 20 January 2017 (UTC)
thread_title:  Merge proposal declined