The RISKS Digest
Volume 2 Issue 41

Sunday, 13th April 1986

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


o Computer Naivete
Lindsay F. Marshall
o Admissability of computer files as evidence
Scott E. Preece
o Programming productivity
Henry Spencer
o The San Jose Public Library [and responsibilities]
Sriram Vajapeyam
o Info on RISKS (comp.risks)

Computer Naivete

"Lindsay F. Marshall" <>
Fri, 11 Apr 86 11:32:53 gmt
  A LITTLE OFF KEY          [from the Guardian Computer Page April 10]

    A member of our Moles in Schools project reports that an
  adviser was called to a school where they were having trouble with
  their new disc drive.  He arrived to find a C15 cassette tape wedged
  firmly in the slot.
    Then a headmaster reported that his school had "broken their
  BASIC".  They had got a syntax error message.
    Best of all was the school where staff took exception to the
  QWERTY arrangement and rearranged the keys to read ABCD etc.  To their
  consternation the character on the key which had been hit did not then
  correspond to what appeared on the screen.  The adviser was greeted,
  on arrival, by an eight-year- old boy saying: "Thank goodness you've
  come.  They don't know what they are doing.  I told them they had to
  change the switches underneath as well but they wouldn't take any
  notice of me."

Re: Admissability of computer files as evidence?

Scott E. Preece <preece%ccvaxa@gswd-vms>
Fri, 11 Apr 86 09:56:01 cst
> From: kathy%gsg.UUCP@harvard.HARVARD.EDU (Kathryn Smith)
> I, for one, find the thought that some court of law might, in
> ignorance, accept computer files as evidence frightening...

I would think that a computer file would be acceptable evidence under the
same conditions that a paper document would be acceptable evidence — when
there was a believable evidentiary chain establishing its provenance.  Thus
a computer file bearing a particular date would mean just as little as a
piece of paper with the same date, unless it could be established that that
particular piece of paper was in a known place, under neutral or believable
control, since that date.  If I take my dump tape from this afternoon to a
neutral agent and leave it there, I would expect a court at some time in the
future to accept that everything on it at that future time was on it today.
I would not expect the court to believe an arbitrary date BEFORE today on
the tape any more than I would expect the court to believe the date on a
paper letter from my files.

scott preece [gould/csd - urbana]

         [Lay people — and even some of our colleagues — tend to TRUST
          computers and ignore the people risks involved!  But a tape can
          easily be forged — unless some nontrivial authenticator (crypto
          seal?) is used.  And even that can be forged with a little effort.
          Similarly, on-line files can often be changed without leaving any
          audit trail record of the change.  Furthermore, detecting Trojan
          horses and viruses in the computer world is generally nontrivial.
          On the other hand, in the paper world the piece of paper without
          provenance is more likely to be suspect.  Occasionally there may
          even be some evidence of tampering.  The burden comes down to good
          audit trails and protocols for handling both computer data and
          paper, as well as anticipation of what might someday be subject to
          tampering — possibly everything — and treatment accordingly.
          But once again, there are no guarantees and many pitfalls.  PGN]

Programming productivity

Fri, 11 Apr 86 10:38:46 EST
Herb Lin writes:

>                 ... But why do you think that large amounts of effort
> invested would necessarily improve productivity? ...

Remember "chunking".  Cognitive limitations can often be bypassed by
moving things to a higher level.  Few people would ever write (say) C code
if doing so required understanding the details of the compiler.  One major
thrust of the sort of support systems, both human and automated, that I
was alluding to, is removing the need to attend to unnecessary detail.

We have already come a long way in this direction:  much of the fundamental
knowledge base of a programmer of thirty years ago is obsolete.  Not just
because the machines have changed, but because modern programming is done
at a much higher level, where the low-level details are no longer visible.

Of course, the low-level details have not vanished; they have merely been
taken over by the support systems.  Which means that one must worry about
whether the support systems understand the details properly.  Although
programmer productivity is much increased if one can work entirely in
a high-level language and not have to care about the details of the
underlying machine, one's compiler had better be fairly well debugged or
this strategy will not work.

Even if one stipulates that ultimate limitations exist, it seems to me
that there remains good reason for believing that we are nowhere near
them yet, and that investments in better support systems are worthwhile
now and will remain worthwhile for the foreseeable future.

                Henry Spencer @ U of Toronto Zoology

The San Jose Public Library

Sriram Vajapeyam <>
Fri, 11 Apr 86 22:27:49 cst
<>From an article in the 27 March 1986 San Francisco Chronicle:
>                    ------------------------------
>  An employee of the San Jose public library "destroyed 16 days of records
>  and garbled two weeks of circulation files."  A supervisor had "neglected
>  to create a backup file".  [...]
>  Training was still incomplete.  Several employees will be disciplined.
   ^^^^^^^^ ^^^ ^^^^^ ^^^^^^^^^^           ^^^^^^^^^ ^^^^ ^^ ^^^^^^^^^^^
>                    ------------------------------
>Not only does poor computer usage cause risks to everybody else, I think we
>should be concerned about workers who are forced to use unfamiliar systems
>and then are held responsible for the damage they did.  Somehow it does not
                             ^^^^^^^ ^^ ^^^^ ^^^
>seem fair, but I believe this is becoming far too common.
 ^^^^ ^^^^

    Penalising the employees DOES seem unfair in the above case, and I
feel they are sure to win if they go to a court of law seeking remedy. (They
didn't have enough training; the system was very young; we don't know if the
system was fully reliable; etc etc.)  I have a few points about which others
might want to express their opinions :

    * Mistakes made while using computers result in much more loss than
those made, say, when working with official documents on paper.

             [This is influenced by the shorter time scale, the (misplaced)
              willingness to trust computers, and by the laziness/complacency
              of computer users in not spotting mistakes.  But I'm not sure
              that your point is generally true.  PGN]

    * It seems easy for a person not very comfortable with computers to
make mistakes that can't be corrected. (It doesn't seem fair to expect
*everyone* to be comfortable with computers.)

    * How reliable is it to use computers in cases such as above (e.g.,
banks, libraries, etc), when they will be handled by people who might be
more prone to making mistakes?  SDI, even though having been brought into
existence and being maintained and used by professionals, is not supposed to
be reliable. Human error is always a frightening possibility even there!

    ...Sriram V.  

Please report problems with the web pages to the maintainer