[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A (Low-Level) Opaque Object Proposal for R5RS
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
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.