[e-lang] What's a SturdyRef (or TraversalKey, String, ...), anyway?

[David Hopwood]

Kevin Reid wrote:
> On Aug 7, 2007, at 12:02, David Hopwood wrote:
>> I thought that such objects should be considered Selfless but not
>> Transparent?
>>
>> (see Figure 3 of <http://www.erights.org/elang/kernel/auditors/>)
>> ...
>> "Do not reveal [all of] their components" is absence of an  
>> auditable property. So I am not sure that this category needs a  
>> specific name. Why is "Selfless && !Transparent" not sufficient?
> 
> I'm starting to think that this may be the right answer; especially  
> as I've thought of two categories of S&!T objects:
> 
>    - those compared in some primitive way (e.g. integers).

These should be considered Transparent. Otherwise, objects with
primitive fields cannot be DeepTransparent (if DeepTransparent just
means 'transitively Transparent').

>    - those compared, like S&T, by an uncall (portrayal), but not one  
> revealed to all clients.

These are called "selectively transparent" in
<http://www.erights.org/javadoc/org/erights/e/elib/prim/MirandaMethods.html#__optUncall(java.lang.Object)>.

> I accept that we shouldn't have a specific name for S&!T, and that  
> the objects I was asking about are S&!T.
> 
> Given this, the stamp (not yet true auditor) I'm calling  
> SelflessStamp in E-on-CL must be renamed, as it really means  
> SelflessTransparentStamp.
> 
> I imagine splitting it into TransparentStamp and Selfless. Selfless  
> auditing would consist of verifying that the object provides some  
> reliable comparison; TransparentStamp being one of them.
> 
> (Auditing for transparency is nontrivial, as it not only involves the  
> object's definition, but also its maker, which must be shown to  
> produce a similar object when given the object's uncall message.)

<http://www.erights.org/elang/kernel/auditors/>:

# OpenSource: Ensure the existence of a standard method whose implementation
# invokes a special language keyword for returning the abstract syntax tree
# of the object expression.
# OpenState: Ensure the existence of a standard method that generates and
# returns a mapping containing the names and values of all the variables
# accessed in the object expression.
# Transparent: Check that the object passes both the OpenSource auditor and
# the OpenState auditor.

But this appears to be out of date (as is
<http://www.erights.org/elang/same-ref.html>).
Is the following documentation what I should be looking at instead?

<http://www.erights.org/javadoc/org/erights/e/elib/prim/MirandaMethods.html#__optUncall(java.lang.Object)>

# Scalars (ints, float64s, chars, boolean, null) and bare Strings are
# atomic. __optUncall on an atomic object[] return[s] null, but atomic
# objects are still considered transparent. Objects which return non-null
# are non-atomic and transparent.

So according to this, any object that (always?) returns non-null from
__optUncall is transparent, whether or not the returned portrayal is
accurate.

I am a little confused: whether __optUncall always returns non-null is
undecidable in general. Auditable properties should be stable (i.e. if
an object ever has a property, it should always have it), so it is not
sufficient to just call __optUncall once and test whether the result is
non-null, since the object may not be deterministic.

It would make more sense to test whether the __optUncall method has been
overridden (or remove it from the Miranda methods, and test whether the
method exists). Alternatively it would be possible to test whether it
exists and has an appropriate return guard that excludes null.

[This has a consequence for implementing forwarders: different forwarder
definitions would be needed for transparent and non-transparent objects.
I don't think that is a problem.]

I am assuming that there is no intended distinction between "transparent"
and "passes the Transparent auditor".

Continuing the quote from the Miranda methods page:

# Non-atomic objects that return null are opaque. Opaque objects may be
# selectively transparent to certain clients by using
# __optSealedDispatch(java.lang.Object, org.erights.e.elib.sealing.Brand)
# as described there.
#
# When a transpa[r]ent non-atomic object is Selfless, then the result of
# __optUncall is guaranteed to be accurate: It describes a call that, when
# performed, must result in this very same object, according to E's "=="
# operation. The Selfless auditor ensures that all Selfless objects are
# accurately self-describing in this way.

Hmm. This is self-consistent, but:

 - the terminology does not convey the right intutitions, I think -- it is
   not obvious that the portrayal of a Transparent object is guaranteed to
   be accurate only if it is also Selfless.

 - why is it the Selfless auditor that is responsible for enforcing
   accurate portrayal? Logically, "accurately portrayed" is a subtype
   of "portrayed", independent of Selfless (and independently useful).

   (It could be argued that "accurately portrayed" is not an enforceable
   security property, because the same effect as an inaccurate portrayal
   could be achieved by a flag that causes the object to suddenly behave
   differently. However, that argument only holds if we consider objects
   to be black boxes; when doing a security review of the source, it is
   still useful to be able to check just the 'implements' clause to see
   whether the portrayal must be accurate.)


>> Note that !Transparent does not imply "always keeps all of its  
>> components secret".
> 
> Is a FlexList Transparent?

According to the above definitions, yes, since it overrides __optUncall
to return non-null.

> It reveals all of its components, though  
> it is Selfish, and can be accurately copied by its uncall (if and  
> only if its element guard is idempotent).

Transparency as defined above does not require accurate portrayal/copying.

>>>    * Should it be considered a subcategory of Selfless, and if so,  
>>> what are Selfless but not Atomic objects called?

[To avoid potential confusion, "Atomic" here refers to the generalization
proposed in your original post, not the definition from the __optUncall
documentation above ("scalars and bare Strings").]

>> PassByCopy (again, see Figure 3).
> 
> No, this is necessary but not sufficient: A Selfless and Transparent  
> object whose maker is not PassByConstruction is not PassByCopy,
> because it would necessarily fail to unserialize.

Ah. Good point.

Arguably "Transparent" is misnamed, since:

 - a non-Selfless object has an opaque identity, and in that sense it
   is not transparent.
 - "returns non-null from __optUncall" does not guarantee transparency
   in any intuitive sense: an object with an inaccurate portrayal is
   not intuitively transparent.

Note that not-provably-accurate portrayals can potentially be useful.
For example, state that is only used as a cache, and does not affect
an object's observable behaviour, can safely be omitted from a portrayal.
This is what transient fields are for in Java's serialization mechanism.
It is not provable that the resulting object has the same observable
behaviour as the original; we have to take the original object's word
for it.

It might be useful to be able to perform cacheing or memoization in
a way that can be recognized by the auditing mechanism. (This would also
have the advantage of not preventing an object from being DeepFrozen or
Functional.) However, that's something that can be discussed separately.


====
Here is a suggested clean-up, illustrated in the attached diagram:

 - remove __optUncall from the Miranda methods (consider also renaming
   it to __optPortray);
 - call any object that is either primitive or has an
   __optUncall method "Portrayed";
 - call a Portrayed object that is guaranteed to have an accurate
   portrayal (because its __optUncall method has a standard form?)
   "WellPortrayed";
 - call any WellPortrayed and Selfless object "Transparent" (this is
   an incompatible change to the meaning of "Transparent", but I think
   it fits the name better).
 - objects with an __optSealedDispatch(brand) method that can return a
   sealed portrayal would be called "selectively portrayed".

For example:

 - FlexList would be WellPortrayed but not Selfless
 - SturdyRef would be DeepSelfless but not Portrayed
 - scalars and bare Strings would be DeepPassByCopy

and your question about what to call Selfless but not Atomic objects
is answered as "Transparent".


Going back to something in your original post:
> [...] our discussion last Wednesday assumed (!) that any Selfish object
> has the property that once finalizers are invoked on it, that identity
> cannot reoccur.

This property would be true, if objects such as SturdyRef, TraversalKey
etc. are Selfless.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: prop-tree2.png
Type: image/png
Size: 9855 bytes
Desc: not available
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20070808/61482a09/attachment-0001.png