[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A (Low-Level) Opaque Object Proposal for R5RS

   Date: Fri, 26 Apr 96 12:29:53 -0400
   From: Michael R. Blair <ziggy@martigny.ai.mit.edu>

		      A (Low-Level) Opaque Object Proposal

Date's "Attributes of Relational Databases" number five specifies that
a Comprehensive Language (encodable as character strings) be available
which supports authorization privileges.  In writing SLIB's relational
database module, I did not include support for authorization
privileges.  Even beyond the desire to simplify my initial task, my
lack of experience with authorization constructs in the Lisp family of
languages would have hampered efforts to support it.  I am glad to see
this issue addressed in Scheme.

   ...  Its _sole_ purpose is to provide an opaque type/object
   facility completely orthogonal from any other language mechanism.

This is an excellent reduction.  I think you have reached the heart of
the matter.

   I proposal the following four procedures be standardized for Scheme and
   their names be added to the list of reserved identifiers:
   [1].     (MAKE-OPAQUE-TYPE                              . <passkey>)
   [2].     (     OPAQUE-UP   <opaque-type>       <object> . <passkey>)
   [3].     (     OPAQUE-DOWN              <opaque-object> . <passkey>)
   [4].     (     OPAQUE-TYPE                     <object>            )

A few minutes with a Thesaurus finds some descriptive transitive verbs
which might better serve users' memories than OPAQUE-UP and

 OPAQUE-UP: obscure hide darken obfuscate perplex cloud baffle perplex
 scramble jumble

 OPAQUE-DOWN: illumine clarify realize fathom illuminate elucidate

I find particularly appealing that a computer language might have the

   Both MAKE-OPAQUE-TYPE and OPAQUE-UP must be reserved identifiers so that
   users cannot re-define them to subvert the abstraction barriers they are
   designed to enforce.

I agree.  The macro appendix of R4RS (which will presumably be
incorporated into R5RS) states:

  With this extension, there are no reserved identifiers.

To reconcile no-reserved-identifiers with any sort of security
mechanism, either no-reserved-identifiers must be removed from R5RS or
a new syntax (not incorporating a special identifier) must be
specified for OPAQUE-* procedures.  I hope this detail does not
scuttle your OPAQUE types proposal.

   I. Opaque Object Creation

   [1]. (MAKE-OPAQUE-TYPE . <passkey>)

      Returns a predicate (a procedure of one or more arguments) that returns
      #T only on objects coerced to this opaque type by a call to OPAQUE-UP
      with this predicate as the <opaque-type> argument and with matching
      <passkey>, if any was supplied in the call to MAKE-OPAQUE-TYPE.

      The resulting ``opaque type'' predicate is not EQ? to any datum except
      itself (i.e., it is a ``unique'' object).

At first I was leery of the uniqueness requirement because I thought
it would require an implementation to make procedures non-EQV? which
were allowed to be EQV? by R4RS:

 The `eqv?' procedure returns `#f' if:


    * OBJ1 and OBJ2 are procedures that would behave differently
      (return a different value or have different side effects) for
      some arguments.

But on further thought, it is correct as it is -- by using the OPAQUE
constructs, a user is explicitly asking for an abstraction barrier.
An implementation should not be considered conforming which does not
provide that barrier (by refusing to distinguish between


   Under such a diversity, sharing source code would still be possible.
   Sharing executables and/or marshalling opaque data and exchanging it
   between incompatible systems is already quite _im_possible,

Databases are routinely used to exchange data, parts of which have
access restricted to certain authorizations.

   so nothing is
   lost by giving implementors this latitude.  And people worried about
   shipping proprietary code to binary compatible sites with unknown opaque
   type enforcement could either encrypt the passkeys embedded in their code
   on a per-site basis (requiring site registration) or they could adopt some
   site certification protocol, or they could require a legally binding
   contract to be signed.  Whatever.

In your Matthias example, I am not certain at what level(s) you have a
security guarantee.  Is it that once the system is debugged Matthias
will know that if his encryption (OPAQUE-UP) and decryption
(OPAQUE-DOWN) are secure, then his whole (compiled) program is?

Or is it that, even when interpreted, his program is secure from
attack in Scheme (but not necessarily from core dumps).


    Question  (MAKE-OPAQUE-TYPE . <passkey>)  ==>  ``opaque type'' predicate
	    Should an ``opaque type'' predicate be EQ? to other opaque type
	    predicates created from an EQ? <passkey>?  That is, should opaque
	    types be hashed on the <passkey> argument(s) when supplied?  The
	    dotted argument for the (optional) <passkey> CONSes a fresh list
	    with each invocation, but one could hash on the list components
	    rather than on the list as a whole. Or we could restrict this to a
	    single optional argument rather than accept numerous optionals as
	    an aggregate <passkey>.  The reason I raise this question is to
	    address whether reloading a file of MAKE-OPAQUE-TYPE defines
	    should result in new opaque types being created or not.

I am interested in storing and retrieving opaque data in files in such
a way as to preserve its opacity or at least its key associations.
This would seem to require that keys be externally representable and
that distinct keys be non-equal?.  With those conditions, should it


OPAQUE data seems to be related to weak pointers.  If the key for some
OPAQUE data has been lost, then, subject to the reconstructability of
keys, all OPAQUE data with that key can be collected, because it
cannot be ELUCIDATEd again.  If it were collected, then EQ?-ness
(different data being not EQ?) of OPAQUE data would then not be
guaranteed.  That is not necessarily bad -- it might make OPAQUE data
more secure if unauthorized pointers to it were subject to change.