The RISKS Digest
Volume 2 Issue 51

Sunday, 11th May 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…

Contents

Reliability limits
Brian Randell
NSA assigning encryption keys
Jay Elinsky
HBO pirate
Lauren Weinstein
Failure to Backup Data, by James H. Coombs
Roy Smith
Admissibility of legal evidence from computers
Mike McLaughlin
Electronic document media
Mike McLaughlin
Word processing and bad writing
many messages received
none included
Info on RISKS (comp.risks)

Reliability limits

Brian Randell <brian%cheviot.newcastle.ac.uk@Cs.Ucl.AC.UK>
Fri, 9 May 86 10:28:52 gmt
    I have for a number of years held, and expounded, the opinion that:
"If one automates a complex manual system, which is being carried out
reasonably competently, then the very best that one can hope to achieve
is fewer but BIGGER errors".

    To give a couple of low-key illustrations: an automated payroll system can
normally be expected to get virtually all of its calculations exactly correct -
but have you ever heard of a manual payroll system producing a paycheck
for $999,999.99 or for $0.00? When a newspaper goes over to computerized
type-setting one normally sees a considerable drop in the number of typos, but
the sudden appearance of occasional major errors - e.g. instructions to the
formatter in capitals in the middle of a paragraph, whole sections in
completely the wrong font, etc.

    The thinking behind my statement is that, compared to computer-based
systems, humans usually have a great ability to recognise an unusual
situation, and to use their general knowledge of the world in assessing its
correctness, and its possible consequences.

    I now no longer have any idea whether the statement is one that I have
plagiarized from someone else, and often find that people find it illuminating
as well as believable, and that it is a good way of injecting a note of caution
into the more naive and over-optimistic discussions that often take place
concerning possible new computer-based systems.

    I would be most interested to see how the RISKS forum reacts to it -
always assuming that something along this lines has not already been the
subject of a debate which took place before I became a subscriber.

Brian Randell - Computing Laboratory, University of Newcastle upon Tyne

  ARPA  : brian%cheviot.newcastle@ucl-cs.arpa
  UUCP  : <UK>!ukc!cheviot!brian


NSA assigning encryption keys

<ELINSKY@IBM.COM>
9 May 86 10:55:02 EDT
In light of all the recent spy cases, if the NSA keeps records of the keys
it has assigned to users, there's the risk that someone with access to them
might sell them "for the right price".  The keys would be worth so much that
a would-be intruder could offer an irresistibly high price to the right
individual, and still come out ahead.
                                       Jay Elinsky, IBM T.J. Watson Research


HBO pirate

Lauren Weinstein <vortex!lauren@rand-unix.ARPA>
Thu, 8-May-86 11:00:05 PDT
Let me preface this by mentioning that my consulting includes work with
the company that uplinks WTBS to the bird, and that I have some
experience in the details of satellite uplink technology.

Just briefly:

The odds are very high that the HBO pirate was at a commercial uplink
facility.  A variety of technical considerations (which I won't go into
here) make it very unlikely that a terrestrial microwave path was involved.
The signal quality put out by the pirate was actually quite good.  He had to
run 10db more power than the HBO uplink to capture, which is a fair amount
of juice.  This was probably made possible by the fact that most uplink
operators have tended to run much less power than they have at hand on site
since new transponders are very sensitive.  I think you can bet HBO is
running full power on their uplinks now! The character gen used by the
pirate was clearly of a standard commercial type that would be located at
virtually any site with uplink facilities.  Also, it should be noted that
when the pirate's "in the clear" signal captured the scrambled HBO uplink
signal, the far-end decoders noted the loss of scrambling and switched back
into "normal" video passthru mode with scrambling off.  It would be trivial
for the pirate to disable any ID on the colorbars by throwing one switch.
In fact, many uplinks never use such IDs at all.

Actions being taken to catch the pirate have supposedly included checking
the logs of many licensed uplink facilities to find out who was on duty at
the suspect time.  In fact, there are already rumors that the pirate has
been caught and fired by his company, but this has not been confirmed.  If
he (or she) is still unknown, however, the most likely way they'll be caught
is if someone starts bragging.

--Lauren--


Re: Failure to Backup Data, by James H. Coombs

Roy Smith <allegra!phri!roy@seismo.CSS.GOV>
Thu, 8 May 86 17:26:01 edt
    One thing not mentioned in James's article is what happens when you
get a new system which has different backup media than the last one?  In
our case, that meant switching from 800 to 1600 bpi tape a couple of years
ago.  We no longer have a drive that can read our old 800 bpi tapes, so
we've got all these wonderful archive tapes that we can't do much with.

    Of course, there are media-copy services.  They may not be cheap,
but for the occasional needed file from antiquity, just about anybody can
do a raw tape to tape copy for you.  But what do you do when your backup
media is a 5-1/4" floppy in wombat-DOS verson 6.4 format?  Where are you
going to get that transfered onto something you can read?


Admissibility of legal evidence from computers

Mike McLaughlin <mikemcl@nrl-csr>
Sat, 10 May 86 13:24:17 edt
In one of my previous incarnations the taxpayers paid me to think small.
Specifically, to implement microform (microfilm, microfiche, COM) where-
ever it was cost effective.  Among other things, we converted about two
million personnel records from paper to microfiche.  Did lots of good things
besides saving money.  But, there were certain practical problems...

Personnel records are frequently placed into evidence at court proceedings.
With 2,000,000 or so records, each representing a real live (or formerly
live) person, several dozen records were in court at any given time.  Not
to speak of class action suits.

We had researched laws, federal regs, etc.; gotten legal opinions, whatever.
There was no question in *anyone's* mind that the records were legal, that
the microfiche WAS the record, and that it WAS admissable in any federal
court, and in most other courts.

Trouble was, it wasn't readable.  Plaintiffs and lawyers do not come equipped
with 24X eyesight.  Judges and jurors don't either.  Ever try to annotate a
microfiche?  Underline a telling phrase - highlight a key date?

We had to set up a fairly expensive system JUST TO HANDLE COURT CASES.  We
had to go back to paper (copies for all concerned) in every court case.
Worse yet, we had to prove the heredity, ancestry, and legitimacy of the
paper copies.

Now, a word to those keeping records on magnetic media, or optical disk, or
holographic crystals... Better have a printer handy!



Electronic document media

Mike McLaughlin <mikemcl@nrl-csr>
Sat, 10 May 86 14:09:56 edt
Risks 2.48 contains several items related to electronic document creation and
transmission.  James Coombs worries about loss of data and loss of tenure due
to authors being unaware of some of the discipline necessary for preserving
electronic drafts.  Bruce Sesnovich and "PGN" are concerned with the poor
quality of submissions to Risks, while I mutter about distinctions between
mistakes and lies.

I agree entirely with Coombs, but take some exception to Sesnovich and PGN.

1.  Editors and proofreaders are not the same - or should not be.  The
editor reads an author's draft, and assists the author to clarify it, or to
achieve some desired end (i.e., making it fit the available space).  The
proofreader checks the edited draft, ensures that it matches some
appropriate style guide, and ensures that the "galley" faithfully reflects
whatever the author and the editor have agreed upon.  Actually, the old
cycle used to be Author -> Editor -> Printer/Typist -> Proofreader ->
Pressman/Copier.  There were a lot of checks, and a lot of delays.  The end
product was quality work... as long as timeliness did not matter.

2.  Micros, word-processors, e-mail, bulletin boards and electronic forums
have abridged the process.  Unless PGN or Captain Midnight interpose themselves
in the process, the readers of Risks will see exactly what I say, regardless
of what I mean.  Right out of my head and into the keyboard.  The reader gets
my half of an extemporaneous conversation.  That is both the charm and the
risk of e-mail and e-forums.

3.  I still have the choice of composing off-line, getting peer review, cor-
recting my work, up-loading it, then proofing the up-load (best done by some-
one else), and finally transmitting it to PGN.  I choose not to do so (but
might choose _to_ do so on some other topic or some other day).

In short, I assess the competing demands of spontaneity and perfection, and
then act accordingly.  My desktop micro, e-mail, and PGN have given me that
option.  When I started writing, there was no choice.

Bruce, if the computer has done anything harmful to communication, that harm
lies in the penchant for excessive iteration of repetitious revisions that
squeeze all the juice out of some *person's* thought or opinion until it has
no more intellectual appeal than a spare-parts listing.
    - Mike McLaughlin <mikemcl@nrl-csr>

Please report problems with the web pages to the maintainer

x
Top