In response to Chris Craddock's stricture about the disclosure of the
contents of fetch-protected storage Peter Relson wrote

<begin extract>
This is not necessarily a violation of the IBM statement of integrity.
 It depends on whose data is being copied. I am allowed to put my own
non-sensitive data into fetch-protected storage and copy it to
non-fetch protected storage if I so choose. The requirement is that I
not allow the unauthorized user to access something he should not be
given access to. Fetch protection is just one tool in the bag of
tricks.  The owner of the data is typically the one that decides what
the access limitations are to be.
<end extract/>

To borrow one of Chomsky's distinctions, this is true, but it is not
interesting.
I may of course do anything I like with something I myself put into
fetch-protected storage.  Moreover, I can know, locally and
procedurally, when I can do so; but most of the time I am dealing with
someone else's fetch-protected storage; and for it the only proper
rule is non-disclosure to the unauthorized.

An exact, entirely correct description of every action that
constitutes a breach of integrity at some time T may just be
achievable; but if it is achieved it will be obsolescent when it is
achieved; and it will resemble a contract drawn up by an attorney not
to inform but to protect a client from hostile litigation.  It will
not, that is, be at all helpful or even intelligible to any but the
already well-informed.

Integrity remains a crucial goal.  Practices that clearly put it at
risk must be avoided, and breaches must be closed as they are
detected.  (Disagreeable as this sounds, 1) we now learn chiefly from
these breaches; and 2) there will be more of them.)

ROTs simplify reality, and they thus always entail overkill, but they
are useful to people who lack the experience to make subtle
distinctions.

John Gilmore, Ashland, MA 01721 - USA

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Reply via email to