Raffaello Giulietti | 19 Apr 2012 15:05
Picon

immutable objects

In section 9.1 of his unusual Ph.D. thesis, Mark S. Miller defines the
object-capability model.

Data is defined to be immutable information.

An instance, on the contrary, combines code and state. The latter is a
mutable map from indices to references.

A capability is defined as a reference to non-data, i.e., to an
instance, a device or a loader.

What about deeply immutable instances, like an immutable Point or an
immutable Date or even more complex immutable instances like an
immutable Person that maintains references to an immutable Address in
addition to Strings for names and a birth Date?

Are they only information? Is a reference to such an instance a capability?

On the other hand, is an instance to an immutable object (e.g.,
java.math.BigInteger) simply data or is a reference to it a full
capability, even if it points to immutable information?

In other words, where is the boundary between data and immutable instances?
Mark Miller | 19 Apr 2012 19:38
Picon
Gravatar

Re: immutable objects

On Thu, Apr 19, 2012 at 6:05 AM, Raffaello Giulietti <raffaello.giulietti-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

In section 9.1 of his unusual Ph.D. thesis, Mark S. Miller defines the
object-capability model.

Unusual? Thanks I think ;).
 

Data is defined to be immutable information.

An instance, on the contrary, combines code and state. The latter is a
mutable map from indices to references.

A capability is defined as a reference to non-data, i.e., to an
instance, a device or a loader.



What about deeply immutable instances, like an immutable Point or an
immutable Date or even more complex immutable instances like an
immutable Person that maintains references to an immutable Address in
addition to Strings for names and a birth Date?

Are they only information? Is a reference to such an instance a capability?

On the other hand, is an instance to an immutable object (e.g.,
java.math.BigInteger) simply data or is a reference to it a full
capability, even if it points to immutable information?

In other words, where is the boundary between data and immutable instances?

The main purpose of this taxonomy is the following text from that same section:

Access to these are knowledge limited rather than permission limited. If Alice can figure out which integer she wants, whether 7 or your private key, she can have it. Data provides only information, not access. 
 
So the key issue is that capabilities are unforgeable whereas data can be resynthesized given only adequate information. The ocap model is purposely neutral on whether objects have identity. In an object system without identity, transitive immutability should be adequate. E objects in general have identity, so we define Data as <http://wiki.erights.org/wiki/Data>. The crucial bit of this regarding the present discussion is that Data is both transitively immutable and transitively identity-free.

Joe-E, because of the constraints that it be a no-rewrite subset of Java, can't avoid pervasive identity, even on individual BigIntegers. So we make a distinction via the marker interface Token as to whether the unforgeability of the identity of an object is supposed to be used for security purposes. The Joe-E "Powerless" type implies the object is transitively immutable and transitively purposeful-identity-free. If these "extra" unmarked identities are in fact not used, then Joe-E Powerless is effectively Data.

But strictly speaking, because of this unavoidable pervasive unforgeability of object identities, in Joe-E only scalars are Data.

--
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
_______________________________________________
cap-talk mailing list
cap-talk@...
http://www.eros-os.org/mailman/listinfo/cap-talk

Gmane