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

[Aubrey Jaffer <jaffer@martigny.ai.mit.edu>]

   Date: Mon, 29 Apr 1996 02:45:14 -0400
   From: Alan Bawden <Alan@lcs.mit.edu>

   Exactly what is it that you are trying to defend against?  What is
   programmer A trying to hide from programmer B?  Is this intended to be a
   method that can be used to protect trade secrets embodied in Scheme
   programs that you ship to customers?  Or to protect programmers working on
   the same project from each other somehow?  (In that case, does the security
   of the rest of the programming environment they share matter?  Does it
   matter if they have access to each other's source code?)  Or is this just
   to protect a single programmer from himself somehow?  Can you give me a
   realistic scenario in which this passkey stuff protects some realistic
   thing from some realistic threat?

In all this discussion, I don't remember seeing many real-world
examples to answer the question "what sort of data protections are
useful?"  Here is one:

 Your employer maintains a database about employees.  Each record in
 this database relates an employee's name, office telphone extension,
 home address, home telephone number, social security number, direct
 deposit bank ID, salary, etc..  This database is kept up-to-date by
 someone in the accounting department.

 It is useful to query this database in order to find a peer's
 extension.  However, employees don't want information such as salary
 and social security numbers released to just anyone in the company.

 But this isn't the only restriction desired.  Managers want to be
 able to query the database for home telephone numbers (during weekend
 emergencies); But employees don't want unsolicited calls from people
 who aren't their managers.

Desired in this example are at least two levels of access restriction
on retrieving information from database records.  Of course there must
also be restrictions on modifying information in these database
records.

In SLIB, I use Scheme to implement a relational system from more
primitive table operations.  Scheme seems well suited to this task,
especially from its ability to create unnamed procedures.  Currently,
my system does not support access restrictions; Ziggy's Opacity
proposal looks promising for this sort of capability.