Erights - User contributions [en]

Capability

Kosik — Mon, 16 Jul 2012 13:33:14 GMT

Kosik: /* Examples */

== Definition ==

A ''capability'' is a token that identifies an [[subject, object, operation and permission|object]] and provides its holder with the [[subject, object, operation and permission|permission]] to operate on the object it identifies. Capabilities must either be totally unforgeable or infeasible to forge by being ''sparse''.

== Examples ==
Some examples of unforgeable capabilities:
* Designations of objects in the [[E language]]. Those who hold these capabilities have the permission to invoke any method supported by the designated object.
* Designations of functions and procedures in [[Emily]]. Those who hold these capabilities have the permission to call designated functions or procedures.
* Capabilities held by a process in [[capability operating system]]s.
* POSIX file descriptors.
Some examples of sparse capabilities (sometimes called password capabilities):
* Designations of remote objects in E, such as <code>captp://*orwqphzlugjwqj2wozz7tmg47ime466j@74.125.87.147:55189/oa6vn5whhapylswhzesdlqh5ppmjkcrq.</code> Those who hold these capabilities have the permission to invoke any method supported by the designated object.
* Private URLs where having the URL is necessary and sufficient to use the resource. Common examples are:
** "Confirm your e-mail address" links for website account registrations, mailing list subscriptions or opt-outs, e.g. <code><nowiki>http://drupal.cbreurope.sk/civicrm/mailing/optout?reset=1&jid=XX&qid=XXXXX&h=XXXXXXXXXXXXXXXX&confirm=1</nowiki></code>
** Shared private documents such as in Google Docs, Google Maps, [http://picasa.google.com Picasa] albums, [http://www.doodle.com Doodle] schedulers.
* Designation of file-system sub-trees in [[MinorFs]], such as <code>/mnt/minorfs/cap/3d5d3efbf73bb711e7a47f82a44f471fcf77c70e/</code>
* URL links to Bitcoin [http://blog.maschinenraum.tk/2012/07/15/bitcoin-vending-machine-exchange-euro-coins-for-bitcoin-wallets/btc-vending-machine-3 wallets].

An [[Unum]] can be also considered as a capability to a (replicated) object in a similar way as file descriptors of transparently replicated files by RAID are still regarded as file descriptors.

== URLs as capabilities ==

As noted above, URLs are often used as capabilities in practice, especially when sent over e-mail. Some explicitly capability-structured systems, such as [[Tahoe-LAFS]], use capability URLs.

A hazard to using capability URLs directly in a web browser is that many browser extensions or options may transmit URLs to a third-party server. In the worst case, this may make those URLs public. However, there is some mitigation:
* The fragment part of a URL reference (<code>#id</code>) is not transmitted. If the browser supports executing JavaScript, then the capability can be placed in the fragment and transmitted only under script control, not as part of a URL.
* The query string part (<code>?foo=bar</code>) is often not transmitted. (Citation needed on this one!)

== See also ==

See [http://www.eros-os.org/essays/capintro.html What is a Capability, Anyway?] for a partisan explanation of what capabilities actually are.

See also [http://www.erights.org/elib/capability/overview.html Overview: Capability Computation]

{{stub}}

Capability

Kosik — Fri, 15 Apr 2011 20:04:26 GMT

Kosik: added another example of sparse capability (opt-outs from "newsletters")

Capability

Kosik — Fri, 15 Apr 2011 15:22:51 GMT

Kosik: Added note concerning unums.

Capability

Kosik — Fri, 15 Apr 2011 15:16:24 GMT

Kosik:

Capability

Kosik — Fri, 15 Apr 2011 15:13:31 GMT

Kosik: I have removed the "XXX improve this section". This is redundant note. The page is already marked as a stub.

Capability

Kosik — Fri, 15 Apr 2011 15:12:19 GMT

Kosik: Controversy concerning sparse vs. password capabilities is settled. These terms are synonyms. I have removed XXX question.

Object-capability languages

Kosik — Fri, 15 Apr 2011 14:05:54 GMT

Kosik: retrofitted pict --> tamed pict

== Independent or Prior Objcap Languages ==

Dynamic
* [http://www.erights.org/history/morris73.pdf Gedanken]
* [http://www.erights.org/history/actors.html Actors]
* [http://portal.acm.org/ft_gateway.cfm?id=323739&type=pdf Vulcan],
* [http://www.agorics.com/Library/joule.html Joule]
* [http://mumble.net/~jar/pubs/secureos/ W7]
* [http://plash.beasts.org Plash]
* [http://prog.vub.ac.be/amop/ AmbientTalk]
* [http://newspeaklanguage.org/ Newspeak]
* [http://evlan.org/ Evlan] (Possibly statically typed in future editions)

Static
* [http://portal.acm.org/citation.cfm?doid=323627.323646 Eden, Emerald]
* [http://citeseer.ist.psu.edu/279442.html J-Kernel]
* [http://www.bitc-lang.org/ BitC]
* [https://docs.google.com/document/d/1bOwopBgJWgzroObINBmopy1Gjy2OoXx_BdOSR94ydQQ/edit?hl=en# Heftza]

== Related to '''''E''''' ==
{|
|+Relationships of '''''E''''' and other languages
! Base language !! '''''E''''' Implementation !! Adapted to objcaps
|-
| [http://java.sun.com Java] || [http://erights.org/download/ E-on-Java] || [[Joe-E]] [http://waterken.sourceforge.net/ Waterken] [http://asyncobjects.sourceforge.net/ AsyncObjects]
|-
| [http://www.mozart-oz.org/ Mozart/Oz] || || [http://www.info.ucl.ac.be/people/PVR/oze.pdf Oz-E]
|-
| C/C++ || [http://erights.org/e-impls/e-on-c/index.html MC] [http://washort.twistedmatrix.com/2008/07/ecru-c-runtime-for-e.html Ecru] ||
|-
| [http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html Smallcaps] || [http://erights.org/e-impls/e-on-smallcaps/index.html E-on-Smallcaps] ||
|-
| [http://www.squeak.org/ Squeak] || [http://erights.org/e-impls/e-on-squeak/index.html E-on-Squeak] || [http://www.squeaksource.com/SecureSqueak.html SecureSqueak] [http://wiki.squeak.org/squeak/6011 SqueakElibVM]
|-
| Common Lisp || [[E-on-CL]] || [http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html CL-E]
|-
| [http://caml.inria.fr/ocaml/index.en.html OCaml] || || [[Emily]]
|-
| [http://www.haskell.org/ Haskell] || [[E-on-Haskell]], [[eonhs]] || [http://code.google.com/p/caskell/ Caskell]
|-
| Python || || [http://twistedmatrix.com/ Twisted Python] [http://foolscap.lothar.com/trac FoolsCap] [http://www.cs.ubc.ca/~drifty/papers/python_security.pdf Secure Python] [http://plash.beasts.org/wiki/CapPython CapPython] [http://code.google.com/p/googleappengine/issues/detail?id=671 safelite] [http://www.eecs.berkeley.edu/~jsamuel/papers/cappos-dadgar-rasley-samuel-et-al-ccs2010.pdf Repy]
|-
| Perl || || [http://caperl.links.org/ CaPerl]
|-
| [http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html Pict] || || [http://www2.fiit.stuba.sk/~kosik/tamed-pict.html Tamed Pict]
|-
| E || E-on-E ||
|-
| || || [http://sebyla.sourceforge.net/ Sebyla]
|-
| Javascript || [[E-on-JS]] || [https://mail.mozilla.org/pipermail/es-discuss/2010-August/011684.html proposed Secure EcmaScript (SES)] [http://code.google.com/p/google-caja/ Caja] [http://www.adsafe.org/ ADsafe] [http://wiki.developers.facebook.com/index.php/FBJS FBJS][http://video.google.com/videoplay?docid=452089494323007214 Vats on Gears] [http://jacaranda.org/ Jacaranda] [http://websandbox.livelabs.com/ Microsoft WebSandbox] [http://research.microsoft.com/en-us/projects/gatekeeper/ Gatekeeper] [http://www.sitepen.com/blog/2008/08/01/secure-mashups-with-dojoxsecure/ Dojo Secure]
|}

Also applicable to ML and Haskell style systems: [http://okmij.org/ftp/papers/lightweight-static-capabilities.pdf Lightweight Static Capabilities]

Talk:Object-capability languages

Kosik — Fri, 15 Apr 2011 09:14:32 GMT

Kosik:

Why do you think Erlang is "almost an object-capability language"? I think, it is an example of programming languages that is "not and far from being an object-capability language". Systems written in Erlang have all or nothing security. The whole system written in Erlang is as secure as its most malicious component. It is not possible to fix this straightforwardly. The language nature would have to change. Designations of processes are not capabilities (but guessable integers). Designations of functions are not capabilities (but atoms and you can freely convert between arbitrary strings and atoms. You can freely forge any atom). The permission to call a function are set by a poor module system. Erlang supports "hot code swapping" (or some similar term) which gives attacker (from untrusted subsystem) an authority to replace any code anywhere in the system. There are many holes in Erlang. I am skeptical. [[User:Kosik|Kosik]] 03:50, 2 April 2009 (CDT)

I did not dig deeper, but Scala might be also an object-capability programming language.
[[User:Kosik|Kosik]] 11:20, 14 April 2011 (CDT)

It might be also worthwhile analyze Lua and describe why it is or it is not an object-capability programming language.
[[User:Kosik|Kosik]] 04:14, 15 April 2011 (CDT)

Talk:Object-capability languages

Kosik — Thu, 14 Apr 2011 16:20:58 GMT

Kosik:

Object-capability languages

Kosik — Thu, 14 Apr 2011 09:04:02 GMT

Kosik: The link to retrofitted Pict was updated. Now it points to its homepage with complete information.

== Independent or Prior Objcap Languages ==

Dynamic
* [http://www.erights.org/history/morris73.pdf Gedanken]
* [http://www.erights.org/history/actors.html Actors]
* [http://portal.acm.org/ft_gateway.cfm?id=323739&type=pdf Vulcan],
* [http://www.agorics.com/Library/joule.html Joule]
* [http://mumble.net/~jar/pubs/secureos/ W7]
* [http://plash.beasts.org Plash]
* [http://prog.vub.ac.be/amop/ AmbientTalk]
* [http://newspeaklanguage.org/ Newspeak]
* [http://evlan.org/ Evlan] (Possibly statically typed in future editions)

Static
* [http://portal.acm.org/citation.cfm?doid=323627.323646 Eden, Emerald]
* [http://citeseer.ist.psu.edu/279442.html J-Kernel]
* [http://www.bitc-lang.org/ BitC]
* [https://docs.google.com/document/d/1bOwopBgJWgzroObINBmopy1Gjy2OoXx_BdOSR94ydQQ/edit?hl=en# Heftza]

== Related to '''''E''''' ==
{|
|+Relationships of '''''E''''' and other languages
! Base language !! '''''E''''' Implementation !! Adapted to objcaps
|-
| [http://java.sun.com Java] || [http://erights.org/download/ E-on-Java] || [[Joe-E]] [http://waterken.sourceforge.net/ Waterken] [http://asyncobjects.sourceforge.net/ AsyncObjects]
|-
| [http://www.mozart-oz.org/ Mozart/Oz] || || [http://www.info.ucl.ac.be/people/PVR/oze.pdf Oz-E]
|-
| C/C++ || [http://erights.org/e-impls/e-on-c/index.html MC] [http://washort.twistedmatrix.com/2008/07/ecru-c-runtime-for-e.html Ecru] ||
|-
| [http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html Smallcaps] || [http://erights.org/e-impls/e-on-smallcaps/index.html E-on-Smallcaps] ||
|-
| [http://www.squeak.org/ Squeak] || [http://erights.org/e-impls/e-on-squeak/index.html E-on-Squeak] || [http://www.squeaksource.com/SecureSqueak.html SecureSqueak] [http://wiki.squeak.org/squeak/6011 SqueakElibVM]
|-
| Common Lisp || [[E-on-CL]] || [http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html CL-E]
|-
| [http://caml.inria.fr/ocaml/index.en.html OCaml] || || [[Emily]]
|-
| [http://www.haskell.org/ Haskell] || [[E-on-Haskell]], [[eonhs]] || [http://code.google.com/p/caskell/ Caskell]
|-
| Python || || [http://twistedmatrix.com/ Twisted Python] [http://foolscap.lothar.com/trac FoolsCap] [http://www.cs.ubc.ca/~drifty/papers/python_security.pdf Secure Python] [http://plash.beasts.org/wiki/CapPython CapPython] [http://code.google.com/p/googleappengine/issues/detail?id=671 safelite] [http://www.eecs.berkeley.edu/~jsamuel/papers/cappos-dadgar-rasley-samuel-et-al-ccs2010.pdf Repy]
|-
| Perl || || [http://caperl.links.org/ CaPerl]
|-
| [http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html Pict] || || [http://www2.fiit.stuba.sk/~kosik/retrofitted-pict.html retrofitted Pict]
|-
| E || E-on-E ||
|-
| || || [http://sebyla.sourceforge.net/ Sebyla]
|-
| Javascript || [[E-on-JS]] || [https://mail.mozilla.org/pipermail/es-discuss/2010-August/011684.html proposed Secure EcmaScript (SES)] [http://code.google.com/p/google-caja/ Caja] [http://www.adsafe.org/ ADsafe] [http://wiki.developers.facebook.com/index.php/FBJS FBJS][http://video.google.com/videoplay?docid=452089494323007214 Vats on Gears] [http://jacaranda.org/ Jacaranda] [http://websandbox.livelabs.com/ Microsoft WebSandbox] [http://research.microsoft.com/en-us/projects/gatekeeper/ Gatekeeper] [http://www.sitepen.com/blog/2008/08/01/secure-mashups-with-dojoxsecure/ Dojo Secure]
|}

Also applicable to ML and Haskell style systems: [http://okmij.org/ftp/papers/lightweight-static-capabilities.pdf Lightweight Static Capabilities]

Capability

Kosik — Tue, 12 Apr 2011 16:00:05 GMT

Kosik: a new example of "password" capability

Capability

Kosik — Tue, 12 Apr 2011 14:42:50 GMT

Kosik:

Capability

Kosik — Tue, 12 Apr 2011 09:11:07 GMT

Kosik: Instead of general "password capabilities" (for non-members of our community this is a void term) we now refer to some concrete kind of "password capability".

Capability

Kosik — Tue, 12 Apr 2011 08:06:06 GMT

Kosik: a direct link to page describing E programming was provided instead of linking the disambiguation page for E

Capability

Kosik — Fri, 18 Feb 2011 16:56:54 GMT

Kosik:

Protection matrix

Kosik — Tue, 08 Sep 2009 09:08:53 GMT

Kosik: missing indefinite article in the title of the section

== Definition ==

One way how to capture the [[Subject, object, operation and permission|permissions of subjects to perform various operations with objects]] is to use a large matrix where:
* rows correspond to particular subjects
* columns correspond to particular objects
and the context of each cell determines what operations on a particular object are permitted for a particular subject.

== An artificial example ==

If:
* we have only three different subjects (1, 2 and 3)
* eight different objects (six files and a printer and a mixer)
* we recognize three different operations with objects (read, write and execute)
then one possible protection matrix may be:

[[Image:Protection matrix1.png]]

The matrix determines which operations (R = read, W = write, X = execute) with particular objects are allowed for particular subjects.

It is not very usual to actually store permissions in the form of a 2-dimensional array as shown in the figure above but there are such systems which do so. Usually, the set of subjects and the set of objects are small and immutable.

== Real world examples ==

* [[Protection matrixes in Minix]]

Authentication

Kosik — Tue, 08 Sep 2009 09:02:41 GMT

Kosik: /* Examples */

== Definition ==

Given one end of a transmission channel, an authentication procedure establishes which principal is probably at the other end.

== Notes ==

"Transmission channel" means a channel over which either information or physical objects are moved from one place to another.

Often the transmission channel is implicit. For example, authenticating the originator of a document is covered by the above definition, if we view the document as representing one end of a transmission channel from its originator.

"Principal" should be interpreted broadly: a principal is any entity that holds credentials (also called authentication factors) allowing it to be distinguished from other principals that do not hold those credentials.

Authentication can be used for many purposes, including to enable accountability, or for access control. (In capability systems, authentication is typically used only indirectly for access control, to decide whether to grant a user's login shell its initial permissions.)

== Controversy over definition ==

The above definition (proposed by David-Sarah Hopwood in [http://www.eros-os.org/pipermail/cap-talk/2009-July/013050.html]) generated a long thread on the cap-talk mailing list [http://www.eros-os.org/pipermail/cap-talk/2009-September/thread.html#13237], with some participants arguing that it does not cover cases where no channel is involved, or that it is too focussed on identity (however, note that "principal" as defined above is definitely not equivalent to an identity [http://www.eros-os.org/pipermail/cap-talk/2009-September/013339.html]).

The following alternative definition was proposed by Rob Meijer:

"Authentication is the validation of a specific property of an object, where this property must either be a source of authority, a source of accountability, or both."

but some participants found this to be too vague, and the meaning of "source of authority" and "source of accountablity" to be unclear.

At the time of writing, it seems that a reasonable compromise may be to use "principal authentication" for the first definition above, "validation" for cases of validating a property that are not covered by that definition, and let "authentication" refer to either.

== Examples ==

[http://en.wikipedia.org/wiki/Banknote Banknotes], for example, can also be viewed as having been sent by a transmission channel from the central bank. A banknote states that its holder has a certain amount of money. Banknotes are valid, if that statement is claimed by the central bank. Authentication of the banknote reveals whether this is the case.

Authentication is a routine process performed everytime a Debian user installs something with the <tt>apt-get</tt> command. The ''principal'', in this case, is a group of Debian developers. Any software whose authentication fails is clearly marked and user has, for obvious reasons, has an option not to install it.

Authentication

Kosik — Tue, 08 Sep 2009 09:01:36 GMT

Kosik: /* Examples */

== Definition ==

Given one end of a transmission channel, an authentication procedure establishes which principal is probably at the other end.

== Notes ==

"Transmission channel" means a channel over which either information or physical objects are moved from one place to another.

Often the transmission channel is implicit. For example, authenticating the originator of a document is covered by the above definition, if we view the document as representing one end of a transmission channel from its originator.

"Principal" should be interpreted broadly: a principal is any entity that holds credentials (also called authentication factors) allowing it to be distinguished from other principals that do not hold those credentials.

Authentication can be used for many purposes, including to enable accountability, or for access control. (In capability systems, authentication is typically used only indirectly for access control, to decide whether to grant a user's login shell its initial permissions.)

== Controversy over definition ==

The above definition (proposed by David-Sarah Hopwood in [http://www.eros-os.org/pipermail/cap-talk/2009-July/013050.html]) generated a long thread on the cap-talk mailing list [http://www.eros-os.org/pipermail/cap-talk/2009-September/thread.html#13237], with some participants arguing that it does not cover cases where no channel is involved, or that it is too focussed on identity (however, note that "principal" as defined above is definitely not equivalent to an identity [http://www.eros-os.org/pipermail/cap-talk/2009-September/013339.html]).

The following alternative definition was proposed by Rob Meijer:

"Authentication is the validation of a specific property of an object, where this property must either be a source of authority, a source of accountability, or both."

but some participants found this to be too vague, and the meaning of "source of authority" and "source of accountablity" to be unclear.

At the time of writing, it seems that a reasonable compromise may be to use "principal authentication" for the first definition above, "validation" for cases of validating a property that are not covered by that definition, and let "authentication" refer to either.

== Examples ==

[http://en.wikipedia.org/wiki/Banknote Banknotes], for example, can also be viewed as having been sent by a transmission channel from the central bank. A banknote states that its holder has a certain amount of money. Banknotes are valid, if that statement is claimed by the central bank. Authentication of the banknote reveals whether this is the case.

Authentication is routine process performed everytime a Debian user installs something with the <tt>apt-get</tt> command. The ''principal'', in this case, is a group of Debian developers. Any software whose authentication fails is clearly marked and user has, for obvious reasons, has an option not to install it.

Talk:Authentication

Kosik — Thu, 30 Jul 2009 06:29:31 GMT

Kosik:

How can this page be improved:
* If we miss some important relationship between authentication and other concepts, notes about those relationship can be added here.
* More examples can be added. At each example we should say (if it is not clear):
** The set of possible principals at each end of the communication channel.
** What kind of information flows through the communication channel.
** Why authentication is useful in a particular case.
[[User:Kosik|Kosik]] 01:15, 30 July 2009 (CDT)

Talk:Authentication

Kosik — Thu, 30 Jul 2009 06:15:38 GMT

Kosik: How can the wiki page be further improved.

Authentication

Kosik — Thu, 30 Jul 2009 06:05:23 GMT

Kosik:

== Definition ==

Given one end of a communication channel, an authentication procedure establishes which principal is probably at the other end.

== Notes ==

Often the communication channel is implicit. For example, authenticating the originator of a document is covered by the above definition, if we view the document as representing one end of a communication channel from its originator.

The ability to perform authentication enables accountability.

== Examples ==

[http://en.wikipedia.org/wiki/Banknote Banknotes], for example, can also be viewed as "one end of a communcation channel". Banknote states that its holder has certain amount of money. Banknotes are valid, if that statement is claimed by the central bank. Authentication of the banknote reveals whether this is the case.

Authentication

Kosik — Sun, 26 Jul 2009 09:59:18 GMT

Kosik:

== Definition ==

Given one end of a communication channel, authentication procedure establishes which principal
is probably at the other end.

== Examples ==

[http://en.wikipedia.org/wiki/Banknote Banknotes], for example, can also be viewed as "one end of a communcation channel". Banknote states that its holder has certain amount of money. Banknotes are valid, if that statement is claimed by the central bank. Authentication of the banknote reveals whether this is the case.

Authentication

Kosik — Sun, 26 Jul 2009 09:54:45 GMT

Kosik:

== Definition ==

Given one end of a communication channel, authentication procedure establishes which principal
is probably at the other end.

== Examples ==

[http://en.wikipedia.org/wiki/Banknote Banknotes], for example, can also be viewed as "one end of a communcation channel". One end is in the central bank. The other one is held by some person. Through this channel, someone states that the holder of a given banknote has a certain amount of money. The authentication procedure here is important because it reveals whether this statement is claimed by the central bank.

Authentication

Kosik — Sun, 26 Jul 2009 09:30:26 GMT

Kosik:

== Definition ==

Given one end of a communication channel, authentication procedure establishes which principal
is probably at the other end.

== Examples ==

* Authentication is important in connection with [http://en.wikipedia.org/wiki/Banknote banknotes]. Paper money is useful only if it is not easily forgeable. Ideally, it should be issued by a single trusted principal. The authentication can determine that this is the case. Electronic currency has to have a similar property.
* Authentication enables us to determine that a given principal probably issued a given document.
* Authentication enables us to determine that a given principal probably published a given program.

Authentication

Kosik — Sun, 26 Jul 2009 09:19:55 GMT

Kosik:

== Definition ==

Given one end of a communication channel, authentication procedure establishes which principal
is probably at the other end.

== Examples ==

* Authentication is important in connection with [http://en.wikipedia.org/wiki/Banknote banknotes]. Paper money is useful only if it is not easily forgeable. In ideal case, it should be issued by a single trusted principal. The authentication can determine that this is the case. Electronic currency has to have a similar property.
* Authentication enables us to determine that a given principal probably issued a given document.
* Authentication enables us to determine that a given principal probably published a given program.

Authentication

Kosik — Sun, 26 Jul 2009 09:15:25 GMT

Kosik:

== Definition ==

Given one end of a communication channel, authentication procedure establishes which principal
is probably at the other end.

== Examples ==

* Authentication is important in connection with [http://en.wikipedia.org/wiki/Banknote banknotes]. Paper money is useful only if it is not easily forgeable. In ideal case, it should be issued by a single trusted principal. The authentication can determine that this is the case.
* Authentication enables us to determine that a given principal probably issued a given document.
* Authentication enables us to determine that a given principal probably published a given program.

Authentication

Kosik — Sun, 26 Jul 2009 09:14:56 GMT

Kosik:

== Definition ==

Given one end of a communication channel, authentication procedure establishes which principal
is probably at the other end.

== Examples ==

* Authentication is important in connection with [http://en.wikipedia.org/wiki/Banknote Banknotes]. Paper money is useful only if it is not easily forgeable. In ideal case, it should be issued by a single trusted principal. The authentication can determine that this is the case.
* Authentication enables us to determine that a given principal probably issued a given document.
* Authentication enables us to determine that a given principal probably published a given program.

Authentication

Kosik — Fri, 24 Jul 2009 17:53:16 GMT

Kosik: typo

== Definition ==

Authentication is a process of estabilishing which subject:
* created or is responsible for the contents of a given document;
* created or is responsible for the behavior of a given program.

== Notes ==

Authentication should not be confused with the following two other concepts:
* identity checking
* authorization

== Examples ==

* Debian packages (objects), after they are downloaded, before they are installed, are authenticated. The authentication procedure in this case establishes that given package (object) was issued by Debian community (subject). This step is useful if our trust in the Debian community is higher than to any other random subject. Genuine installation CDs contain appropriate keyring.
* Current technology well supports authentication of e-mails (via various [http://en.wikipedia.org/wiki/MUA MUA] plugins).

Authentication

Kosik — Fri, 24 Jul 2009 17:16:23 GMT

Kosik: /* Examples */

== Definition ==

Authentication is a process of estabilishing which subject:
* created or is responsible for the contents of a given document;
* created or is responsible for the behavior of a given program.

== Notes ==

Authentication should not be confused with the following two other concepts:
* identity checking
* authorization

== Examples ==

* Debian packages (objects), after they are downloaded, before they are installed, are authenticated. The authentication procedure in this case estabilishes that given package (object) was issued by Debian community (subject). This step is useful if our trust in the Debian community is higher than to any other random subject. Genuine installation CDs contain appropriate keyring.
* Current technology well supports authentication of e-mails (via various [http://en.wikipedia.org/wiki/MUA MUA] plugins).

Authentication

Kosik — Fri, 24 Jul 2009 17:14:01 GMT

Kosik: /* Examples */

== Definition ==

Authentication is a process of estabilishing which subject:
* created or is responsible for the contents of a given document;
* created or is responsible for the behavior of a given program.

== Notes ==

Authentication should not be confused with the following two other concepts:
* identity checking
* authorization

== Examples ==

* Debian packages (objects), after they are downloaded, before they are installed, are authenticated. The authentication procedure in this case estabilishes that given package (object) was issued by Debian community (subject). This step is useful if our trust in the Debian community is higher than to any other random subject. Genuine installation CDs contain appropriate keyring.
* Current technology well supports authentication of e-mails.

Authentication

Kosik — Fri, 24 Jul 2009 17:07:56 GMT

Kosik: /* Examples */

== Definition ==

Authentication is a process of estabilishing which subject:
* created or is responsible for the contents of a given document;
* created or is responsible for the behavior of a given program.

== Notes ==

Authentication should not be confused with the following two other concepts:
* identity checking
* authorization

== Examples ==

* Debian packages (objects), after they are downloaded, before they are installed, are authenticated. The authentication procedure in this case estabilishes that given package (object) was issued by Debian community (subject). This step is useful if our trust in the Debian community is higher than to any other random subject.

Authentication

Kosik — Fri, 24 Jul 2009 17:03:55 GMT

Kosik:

== Definition ==

Authentication is a process of estabilishing which subject:
* created or is responsible for the contents of a given document;
* created or is responsible for the behavior of a given program.

== Notes ==

Authentication should not be confused with the following two other concepts:
* identity checking
* authorization

== Examples ==

* Debian packages (objects), after they are downloaded, before they are installed, are authenticated. The authentication procedure in this case estabilishes that given package (object) was issued by Debian community (subject). This step is useful if our trust in Debian community is higher than to any other random subject.

Authentication

Kosik — Fri, 24 Jul 2009 16:57:52 GMT

Kosik:

== Definition ==

Authentication is a process of estabilishing which subject created of a given object (an exectuable code, a source code, a document, etc).

== Notes ==

Authentication should not be confused with the following two other concepts:
* identity checking
* authorization

== Examples ==

* Debian packages (object), after they are downloaded, before they are installed are authenticated. The authentication procedure in this case estabilishes that given package (object) was issued by Debian community (subject).

Walnut/Secure Distributed Computing/E Capabilities

Kosik — Fri, 24 Jul 2009 16:49:32 GMT

Kosik: Rephrased sentence to avoid the abuse of the word "authentication".

[[Category:Walnut|4]]

===E Capabilities===

E has no pointer arithmetic. ''E ''has no mutable statics.'' E ''has an API carefully thought out to prevent capability leaks. This would make it a capability secure language for single-processor applications. But'' E ''goes a step further. It takes the concept of a secure, unforgeable object reference and extends it to distributed objects:

* The communication links are encrypted. Third parties cannot get inside the connection.
* The objects are unfindable without a proper reference received (directly or indirectly) from the creator of the object. You must have the key to unlock the door.
* No object can pretend to be the object you are trying to contact because identity cannot be hijacked.

These aspects of'' E ''protocol can be understood better by looking at the URI that identifies an'' E ''object to other objects outside its own vat.

====A closer look at E capability URIs====

{| style="float: right; width: 2in; border-style: inset; border-width: 3;background-color: #FFFF99; font-size:80%"
|
The whole E approach to security is disorienting to anyone steeped in traditional computer security lore. On the other hand, anyone with a background in object-oriented programming will find it to be a natural extension of the OO discipline. Another entire book is needed on the philosophy of security exemplified by object capabilities and E. [http://minnow.cc.gatech.edu/squeak/3770 The closest thing to such a Philosophy of Security known to the author is a requirements document] for the shared virtual 3D world [http://croquetproject.org/ Croquet]. Croquet needs to be both very user friendly and very secure, and so requires the kind of seriousness that object-capabilities enable. A brutally abbreviated list of points from that document includes: '''No Passwords, No Certificates, No Certificate Authorities, No Firewalls, No Global Namespaces.''' POLA, pet names, and other related techniques described here supplant them all. '''Minimize Authentication. Focus on Authorization.''' Authentication-laden systems are as user friendly as post-9/11 airport security systems. And they work about that well, too. The terrorists are far more likely to have their identification in order than the rest of us. '''Do Not Prohibit What You Cannot Prevent.''' The main purpose of this advice is to prevent you from looking like a fool after you've been circumvented. '''Embrace Delegation.''' People must delegate to succeed. So they will delegate despite your most ridiculous efforts. Relax, enjoy it. Help them. And while relaxing, re-read the earlier, "do not prohibit what you cannot prevent." '''Bundle Authority with Designation.''' This makes security user-friendly by making the security invisible. Only possible after you stop wasting your effort on authentication all the time.
|}

====Security as an inexpensive lunch====

There is no such thing as a free lunch, but this does not rule out the possibility of lunches at bargain prices. When programming in'' E'', you are automatically working in a capability secure environment. All references are secure references. All powers are accessible only through capabilities. Making an'' E ''program secure is largely a matter of thinking about the architecture before you code, and doing a security audit after you code. When designing and auditing you use a small number of principles for scrutinizing the design:

====Principle of Least Authority (POLA) for Computer Programs====

The Principle of Least Authority (known henceforth as POLA), which has been used by human beings instinctively for thousands of years, translates to computer programs fairly straightforwardly: ''never give an object more authority than it needs''. In particular, if an object may be running on a remote untrusted machine, think very carefully about the minimum set of authorities it needs, and give it capabilities only on ''facets'' (described later) that ensure it gets no more. A simple word processor needs read and write access to the one file it is being used to edit, and it needs read-only access on all the system fonts. It does not need any access to anything else. Do not give it access to anything else. If it asks for something else, it is lying to you, and you should not trust it.

====Principle of Hardware Software Ownership====

When developing software, remember that the person who controls the hardware always, at the end of the day, controls the software. Hence, if you send someone a piece of a distributed program to run on their own equipment, that person totally and utterly owns everything that resides on his machine. They can modify the code you gave them, or rewrite it from scratch yet make it look from the outside like it is identical. You must therefore think carefully about what features of your system you really trust on that remote machine. A key feature of E that enhances its reliability is that objects which are manufactured in a particular vat remain resident in that vat, so that the objects remain as reliable as the objectMakers used to produce them. Only ''transparent immutables'' (immutables that don't encapsulate anything) actually move across computational boundaries.

Many people have made the error of believing this principle of hardware ownership can be circumvented. At the time of this writing, the music recording industry is throwing away truly fabulous sums of money on schemes that assume they can somehow control data after it has arrived on a user's own hardware. Microsoft is busily developing Palladium (uh, I mean, NGSCB). Intel is busily developing TCP (uh, I think they changed the name to La Grande). Their fate has already been foretold in the fate of the popular game Diablo I: authoritative representations of data were allowed to reside on user computers, assuming that the object code was too difficult to understand to be hacked and that the Diablo client code would always behave as the designers intended. They were 99% correct, which in the computer security field means they were 100% wrong. Today, 99% of the people who hack Diablo I don't understand the object code. But somewhere some single individual figured it out and posted the result on the Web. Now your grandmother can sabotage shared Diablo I games as quickly and easily as the most accomplished hacker in history. For Diablo II, the developers had learned the lesson. Authoritative information is stored only on the server, giving them the beginnings of true security.

Not only does hardware own the software, so too does the underlying operating system. As we have stated repeatedly here, ''E'' enables the construction of extremely secure computing systems. However, E systems can still be attacked from below, by viruses granted authority by the operating system underneath the ''E'' world. Such attacks can only be prevented by completing the security regime, either with capability-based operating systems, or with computers on which only capability-secure programs are allowed. There is one open-source capability-based OS under development, at [http://www.eros-os.org www.eros-os.org].

====Denial Of Service Attacks====

One form of attack that even ''E'' cannot defend against is denial of service (DOS). In a denial of service, someone simply swamps your system with requests, making your system unable to operate. Such attacks take many forms, but the key limitation in such attacks is this: such an attack can never steal your secret data or gain control of your sensitive operations. If DOS were the only kind of attack possible, the world would be a vastly better place. Indeed, if only DOS attacks were possible, even most modern DOS attacks would fail, because the serious DOS attacks require that the attacker first gain control of hundreds of computers that belong to other people, by using attacks far more invasive and damaging than DOS itself.

Talk:Object-capability languages

Kosik — Fri, 24 Jul 2009 16:05:58 GMT

Kosik:

Object-capability languages

Kosik — Fri, 24 Jul 2009 16:04:24 GMT

Kosik: Removed reference to Erlang. Reasons are in the discussion tab.

== Independent or Prior Objcap Languages ==

* [http://www.erights.org/history/morris73.pdf Gedanken]
* [http://www.erights.org/history/actors.html Actors]
* [http://portal.acm.org/ft_gateway.cfm?id=323739&type=pdf Vulcan],
* [http://www.agorics.com/Library/joule.html Joule]
* [http://mumble.net/~jar/pubs/secureos/ W7]
* [http://portal.acm.org/citation.cfm?doid=323627.323646 Eden, Emerald]
* [http://citeseer.ist.psu.edu/279442.html J-Kernel]
* [http://plash.beasts.org Plash]
* [http://prog.vub.ac.be/amop/ AmbientTalk]
* [http://newspeaklanguage.org/ Newspeak]

== Related to '''''E''''' ==
{|
|+Relationships of '''''E''''' and other languages
! Base language !! '''''E''''' Implementation !! Adapted to objcaps
|-
| [http://java.sun.com Java] || [http://erights.org/download/ E-on-Java] || [[Joe-E]] [http://waterken.sourceforge.net/ Waterken] [http://asyncobjects.sourceforge.net/ AsyncObjects]
|-
| [http://www.mozart-oz.org/ Mozart/Oz] || || [http://www.info.ucl.ac.be/people/PVR/oze.pdf Oz-E]
|-
| C/C++ || [http://erights.org/e-impls/e-on-c/index.html MC] [http://washort.twistedmatrix.com/2008/07/ecru-c-runtime-for-e.html Ecru] ||
|-
| [http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html Smallcaps] || [http://erights.org/e-impls/e-on-smallcaps/index.html E-on-Smallcaps] ||
|-
| [http://www.squeak.org/ Squeak] || [http://erights.org/e-impls/e-on-squeak/index.html E-on-Squeak] || [http://www.squeaksource.com/SecureSqueak.html SecureSqueak] [http://wiki.squeak.org/squeak/6011 SqueakElibVM]
|-
| Common Lisp || [http://erights.org/e-impls/e-on-cl/index.html E-on-CL] || [http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html CL-E]
|-
| [http://caml.inria.fr/ocaml/index.en.html OCaml] || || [[Emily]]
|-
| [http://www.haskell.org/ Haskell] || [http://homepage.mac.com/kpreid/elang/ E-on-Haskell] || [http://code.google.com/p/caskell/ Caskell]
|-
| Python || || [http://twistedmatrix.com/ Twisted Python] [http://foolscap.lothar.com/trac FoolsCap] [http://www.cs.ubc.ca/~drifty/papers/python_security.pdf Secure Python] [http://plash.beasts.org/wiki/CapPython CapPython] [http://code.google.com/p/googleappengine/issues/detail?id=671 safelite]
|-
| Perl || || [http://caperl.links.org/ CaPerl]
|-
| [http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html Pict] || || [http://altair.fiit.stuba.sk/mediawiki/index.php/Tamed_Pict Tamed Pict]
|-
| E || E-on-E ||
|-
| || || [http://sebyla.sourceforge.net/ Sebyla]
|-
| Javascript || [[E-on-JS]] || [http://code.google.com/p/google-caja/ Caja] [http://www.adsafe.org/ ADsafe] [http://wiki.developers.facebook.com/index.php/FBJS FBJS][http://video.google.com/videoplay?docid=452089494323007214 Vats on Gears] [http://www.jacaranda.org/jacaranda-spec-0.3.txt Jacaranda] [http://websandbox.livelabs.com/ Microsoft WebSandbox]
|}

Also applicable to ML and Haskell style systems: [http://okmij.org/ftp/papers/lightweight-static-capabilities.pdf Lightweight Static Capabilities]

Object-capability languages

Kosik — Fri, 24 Jul 2009 15:51:12 GMT

Kosik: Corrected link to the tamed version of the original Pict programming language.

== Independent or Prior Objcap Languages ==

* [http://www.erights.org/history/morris73.pdf Gedanken]
* [http://www.erights.org/history/actors.html Actors]
* [http://portal.acm.org/ft_gateway.cfm?id=323739&type=pdf Vulcan],
* [http://www.agorics.com/Library/joule.html Joule]
* [http://mumble.net/~jar/pubs/secureos/ W7]
* [http://portal.acm.org/citation.cfm?doid=323627.323646 Eden, Emerald]
* [http://citeseer.ist.psu.edu/279442.html J-Kernel]
* [http://plash.beasts.org Plash]
* [http://prog.vub.ac.be/amop/ AmbientTalk]
* [http://newspeaklanguage.org/ Newspeak]
* [http://www.erlang.org/ Erlang] - Erlang is almost, but not quite an object-capability language.

== Related to '''''E''''' ==
{|
|+Relationships of '''''E''''' and other languages
! Base language !! '''''E''''' Implementation !! Adapted to objcaps
|-
| [http://java.sun.com Java] || [http://erights.org/download/ E-on-Java] || [[Joe-E]] [http://waterken.sourceforge.net/ Waterken] [http://asyncobjects.sourceforge.net/ AsyncObjects]
|-
| [http://www.mozart-oz.org/ Mozart/Oz] || || [http://www.info.ucl.ac.be/people/PVR/oze.pdf Oz-E]
|-
| C/C++ || [http://erights.org/e-impls/e-on-c/index.html MC] [http://washort.twistedmatrix.com/2008/07/ecru-c-runtime-for-e.html Ecru] ||
|-
| [http://www.erights.org/javadoc/org/erights/e/elang/smallcaps/SmallcapsOps.html Smallcaps] || [http://erights.org/e-impls/e-on-smallcaps/index.html E-on-Smallcaps] ||
|-
| [http://www.squeak.org/ Squeak] || [http://erights.org/e-impls/e-on-squeak/index.html E-on-Squeak] || [http://www.squeaksource.com/SecureSqueak.html SecureSqueak] [http://wiki.squeak.org/squeak/6011 SqueakElibVM]
|-
| Common Lisp || [http://erights.org/e-impls/e-on-cl/index.html E-on-CL] || [http://www.eros-os.org/pipermail/e-lang/2005-April/010572.html CL-E]
|-
| [http://caml.inria.fr/ocaml/index.en.html OCaml] || || [[Emily]]
|-
| [http://www.haskell.org/ Haskell] || [http://homepage.mac.com/kpreid/elang/ E-on-Haskell] || [http://code.google.com/p/caskell/ Caskell]
|-
| Python || || [http://twistedmatrix.com/ Twisted Python] [http://foolscap.lothar.com/trac FoolsCap] [http://www.cs.ubc.ca/~drifty/papers/python_security.pdf Secure Python] [http://plash.beasts.org/wiki/CapPython CapPython] [http://code.google.com/p/googleappengine/issues/detail?id=671 safelite]
|-
| Perl || || [http://caperl.links.org/ CaPerl]
|-
| [http://www.cis.upenn.edu/~bcpierce/papers/pict/Html/Pict.html Pict] || || [http://altair.fiit.stuba.sk/mediawiki/index.php/Tamed_Pict Tamed Pict]
|-
| E || E-on-E ||
|-
| || || [http://sebyla.sourceforge.net/ Sebyla]
|-
| Javascript || [[E-on-JS]] || [http://code.google.com/p/google-caja/ Caja] [http://www.adsafe.org/ ADsafe] [http://wiki.developers.facebook.com/index.php/FBJS FBJS][http://video.google.com/videoplay?docid=452089494323007214 Vats on Gears] [http://www.jacaranda.org/jacaranda-spec-0.3.txt Jacaranda] [http://websandbox.livelabs.com/ Microsoft WebSandbox]
|}

Also applicable to ML and Haskell style systems: [http://okmij.org/ftp/papers/lightweight-static-capabilities.pdf Lightweight Static Capabilities]

User:Kosik

Kosik — Wed, 15 Jul 2009 14:53:03 GMT

Kosik: User:Kosik moved to User:Matej Kosik: Changed to a full name.

#REDIRECT [[User:Matej Kosik]]

User:Matej Kosik

Kosik — Wed, 15 Jul 2009 14:53:02 GMT

Kosik: User:Kosik moved to User:Matej Kosik: Changed to a full name.

[http://altair.sk/mediawiki/index.php/Matej_Kosik my web site]

Talk:Capability

Kosik — Wed, 15 Jul 2009 14:51:43 GMT

Kosik:

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? [[User:Kosik|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:
* unforgeable
* hardly unguessable
be contracted to some single adjective? Using the term "unforgeable or hardly unguessable" is awkward. [[User:Kosik|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.

[[User:Kosik|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 [http://altair.fiit.stuba.sk/mediawiki/index.php/SandboxedPing 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.

[[User:Kosik|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"?

[[User:Kosik|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.

[[User:Kosik|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.
--[[User:Toby.murray|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.

[[User:Kosik|Kosik]] 09:51, 15 July 2009 (CDT)

Talk:Ambient capability

Kosik — Mon, 13 Jul 2009 12:00:38 GMT

Kosik:

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? [[User:Kosik|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 capability|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 capability|ambient capabilities]] as being distinct from [[object capability|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 [http://altair.fiit.stuba.sk/mediawiki/index.php/Tamed_Pict 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".

[[User:Kosik|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 object|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.'' --[[User:Dmbarbour|Dmbarbour]] 15:57, 10 July 2009

----

It sounds to me like these "ambients" that you describe just above are singleton [[Unum Pattern|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? --[[User:Kevin Reid|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.'' -- [[User:198.253.49.6|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? [[User:Kosik|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 (<tt>kosik at fiit.stuba.sk</tt>)
* or, better, join [http://www.eros-os.org/mailman/listinfo/cap-talk cap-talk] mailing list.

Best regards.

[[User:Kosik|Kosik]] 07:00, 13 July 2009 (CDT)

Ambient capability

Kosik — Mon, 13 Jul 2009 12:00:03 GMT

Kosik: I am open to discussing the text (see the note in Talk:Ambient_capability page). Until then, it was deleted because it makes little or no sense.

Talk:Capability

Kosik — Sat, 11 Jul 2009 12:41:28 GMT

Kosik:

Talk:Object capability

Kosik — Sat, 11 Jul 2009 06:34:34 GMT

Kosik:

Are you sure, Dmbarbour?

May I suggest you
* first to read [http://www.erights.org/talks/thesis/ Mark Miller's thesis]
* then install E
* read E in a [[Walnut]] and experiment with E
If you like it, join e-lang or cap-talk mailing list and discuss your ideas.

[[User:Kosik|Kosik]] 15:17, 10 July 2009 (CDT)

----

I have read Mark Miller's thesis, many years ago. And I played with '''E language''' then, too. I've gained more than a few inspirations from these, but I'm not all that fond of the language (in particular, how it handles distribution, disruption, resilience, persistence, concurrency, consistency, facets, and I'm not impressed with available optimizations achievable).

Anyhow, I can only express my professional opinion on what [[object capability]] means based on the literature I have read, same as Mark Miller or anyone else, and take comfort in the fact that formal definitions are graded by '''utility in making distinctions''' rather than by their conformance with the opinions of others. You ask if I'm "sure"? I'm very certain of the utility in understanding [[object capability]] as distinct from other capabilities, and I'm very certain of the utility in understanding [[capability]] as distinct from '''secure''' capability, such that one can meaningfully discusss the security '''of''' capabilities rather than just security '''with''' capabilities. So, in that sense, I'm sure.
-- [[User:Dmbarbour|Dmbarbour]] 16:15, 10 July 2009 (CDT)

-------

Upon seeing you 'rewrite' my professional opinion on the matter with your own, it is clear to me that you would prefer to maintain and grow this wiki on your own rather than risk dissenting opinions. I'll leave you alone now. But, before I go, May I suggest that you read some capability literature that ''wasn't'' written by Mark Miller? There's a lot of it out there.
-- [[User:Dmbarbour|Dmbarbour]] 16:23, 10 July 2009 (CDT)

----

I think [http://www.eros-os.org/mailman/listinfo/cap-talk cap-talk] would be a better place for expressing your professional opinion. Join under your real name.

[[User:Kosik|Kosik]] 16:30, 10 July 2009 (CDT)

----

Kosik: I think your "complete rewrite" was unnecessarily antagonistic. Please prefer gradual improvements ''and discussion'' to discarding others' work, unless it is complete nonsense, which this wasn't. --[[User:Kevin Reid|Kevin Reid]] 19:37, 10 July 2009 (CDT)

----

I propose first discussion of the [[ambient capability]] article and if it is settled, let us discuss other things (like [[object capability]]). Sequentially. Is that fair? [[User:Kosik|Kosik]] 01:34, 11 July 2009 (CDT)

Talk:Ambient capability

Kosik — Sat, 11 Jul 2009 06:23:44 GMT

Kosik:

Talk:Object capability

Kosik — Fri, 10 Jul 2009 21:44:07 GMT

Kosik:

Talk:Object capability

Kosik — Fri, 10 Jul 2009 21:30:30 GMT

Kosik:

Are you sure, Dmbarbour?

May I suggest you
* first to read [http://www.erights.org/talks/thesis/ Mark Miller's thesis]
* then install E
* read E in a [[Walnut]] and experiment with E
If you like it, join e-lang or cap-talk mailing list and discuss your ideas.

[[User:Kosik|Kosik]] 15:17, 10 July 2009 (CDT)

I have read Mark Miller's thesis, many years ago. And I played with '''E language''' then, too. I've gained more than a few inspirations from these, but I'm not all that fond of the language (in particular, how it handles distribution, disruption, resilience, persistence, concurrency, consistency, facets, and I'm not impressed with available optimizations achievable).

Anyhow, I can only express my professional opinion on what [[object capability]] means based on the literature I have read, same as Mark Miller or anyone else, and take comfort in the fact that formal definitions are graded by '''utility in making distinctions''' rather than by their conformance with the opinions of others. You ask if I'm "sure"? I'm very certain of the utility in understanding [[object capability]] as distinct from other capabilities, and I'm very certain of the utility in understanding [[capability]] as distinct from '''secure''' capability, such that one can meaningfully discusss the security '''of''' capabilities rather than just security '''with''' capabilities. So, in that sense, I'm sure.
-- [[User:Dmbarbour|Dmbarbour]] 16:15, 10 July 2009 (CDT)

-------

Upon seeing you 'rewrite' my professional opinion on the matter with your own, it is clear to me that you would prefer to maintain and grow this wiki on your own rather than risk dissenting opinions. I'll leave you alone now. But, before I go, May I suggest that you read some capability literature that ''wasn't'' written by Mark Miller? There's a lot of it out there.
-- [[User:Dmbarbour|Dmbarbour]] 16:23, 10 July 2009 (CDT)

----

I think [http://www.eros-os.org/mailman/listinfo/cap-talk cap-talk] would be a better place for expressing your professional opinion. Join under your real name.

[[User:Kosik|Kosik]] 16:30, 10 July 2009 (CDT)

Talk:Object capability

Kosik — Fri, 10 Jul 2009 20:18:21 GMT

Kosik:

Talk:Object capability

Kosik — Fri, 10 Jul 2009 20:17:34 GMT

Kosik:

Are you sure?

May I suggest you
* first to read [[http://www.erights.org/talks/thesis/ Mark Miller's thesis]]
* then install E
* read E in a [[Walnut]] and experiment with E
If you like it, join e-lang or cap-talk mailing list and discuss your ideas.

[[User:Kosik|Kosik]] 15:17, 10 July 2009 (CDT)

Talk:Object capability

Kosik — Fri, 10 Jul 2009 20:13:27 GMT

Kosik:

Are you sure?

[[User:Kosik|Kosik]] 15:13, 10 July 2009 (CDT)

Talk:Capability

Kosik — Fri, 10 Jul 2009 19:55:03 GMT

Kosik: