The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 8 Issue 15

Wednesday 25 January 1989

Contents

o More video piracy
Dave Curry
o Computerized records of employee informers
Mike Trout
o Censorship and computers
Anthony Finkelstein
o Re: Object Oriented Programming
Benjamin Ellsworth
o Structuring large systems
John Spragge
o About non-redundant redudant systems
Elizabeth D. Zwicky
o Engine-count and the Spirit of St. Louis
Michael McClary
o Counting engines
Jordan Brown
o Re: Space shuttle computer problems, 1981--1985
Henry Spencer
o Revised Computer Ethics Course Proposal
Bob Barger
o Info on RISKS (comp.risks)

More video piracy

davy@riacs.edu <Dave Curry>
Wed, 25 Jan 89 08:29:47 -0800
Taken from the San Jose Mercury News, Jan. 23, 1989.

Video pirates disrupt Super Bowl broadcast on L.A. cable system

  LOS ANGELES(AP) - Cable television viewers of the Super Bowl said video
pirates disrupted the audio portion of the play-by-play Sunday with music
from "The Jetsons" cartoon show and an anti-Semitic slur.
  "First there was music from 'The Jetsons' cartoon show.  Then someone said
something about Century Cable and 'There's too many (expletive deleted) Jews
in this industry,'" said Doug Debber, a viewer in Santa Monica.    [.....]
  The interruption occurred about 3:15 p.m., when an audio signal invaded
Century's cable system, he [Bill Rosendahl, a company spokesman] said.
Viewers in West Los Angeles, Santa Monica and Beverly Hills reported the
intrusion, Rosendahl said.   [.....]
  Company officials have contacted the FBI and Santa Monica police and were
planning to contact the Federal Communications Commission Monday morning, he
said.


Computerized records of employee informers

Mike Trout <miket@brspyr1.brs.com>
25 Jan 89 16:15:59 GMT
The 16 May 1988 issue of _Flagship_News_ (employee publication of American
Airlines) includes a small article on a spiffy way for employees to rat on
their fellow workers.  It's part of a nationwide computerized database on
"business abuse," which is apparently a euphemism for workers who don't measure
up to management's standards.  Listed examples of business abuse include 
theft, drug and alcohol abuse, unsafe work habits, and "any act not in the best
interest" of the employer.  All you have to do to destroy your fellow workers
is call the National Business Crime Information Network Inc. (known as "The
Network"), at 1-800-241-5689.  You may do this anonymously, as each caller is
simply assigned a code number.  This also allows you to call back later and
check to see what action has been taken against that guy in the next cubicle
who took a pencil home.  The Network says that your information is relayed to
top management, who it is claimed will not take any disciplinary action on the
basis of the phone call alone.

Right.                                         Michael Trout 
BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110  (518) 783-1161

  [If you make your ratfink call from a phone with automatic calling
  identification, do they store YOUR phone number as well?  PGN]


Censorship and computers

<acwf@doc.imperial.ac.uk>
Wed, 25 Jan 89 12:02:54 GMT
The following is taken from an advertisement which appeared in The Spectator (a
conservative review and comment journal of high repute) 14 Jan 1989.  The
advertisement was placed by INDEX ON CENSORSHIP a magazine which publishes
banned literature from all over the world, factual reports on writers and
journalists who have been silenced, as well as comment, interviews and a
country-by-country chronicle of censorship.

  "Dear Spectator Reader,

  Vaclav Havel, the well known Czechoslovak playwright, had his personal
  computer/word processor confiscated by police on 27 October 1988. I wonder
  if you would like to join with others in providing him with a replacement?

  Havel had the computer for just over a year and had been using it - for
  work and correspondence for only a month or two. It was obtained
  perfectly legally. He has written to the authorities to ask for his
  property back, but it has not yet been returned, nor is there any sign
  that it will be.

The letter continues by requesting contributions for a replacement. This is of
interest reflecting the risk that computers pose to oppressive states, the risk
of confiscation by the police of a vital tool of modern work and communication.

Anthony Finkelstein, Imperial College of Science, Technoloy & Medicine
(University of London). UK.

   [I imagine replacements would be confiscated even more quickly, especially
   if more continue to arrive.  The police may be developing a taste for
   computers.  Besides, they may have discovered that the storage provides a
   convenient record of what he has written.  I wonder whether Glasnostradamus
   predicted things like this.  PGN]


Re: Object Oriented Programming (Risks-8.14)

Benjamin Ellsworth <ben%hpcvxben@hp-sde.sde.hp.com>
Wed, 25 Jan 89 9:23:17 PST
[Regarding adding functionality without changing the code:]
> I should hope the risks are obvious. [Ellsworth, RISKS-8.14]
 <>MBR@PELICAN-SPIT.ACA.MCC.COM        [Message to Ellsworth and RISKS]
 <>from "Mark Rosenstein" at Jan 25, 89 6:07 am
 <> ...Oh dear. They're not obvious to me. If change means modify existing
 <> code, then I can't quite see the problem, if change means add code, 
 <> yep you'll have to add code to get more functionality.          Mark.

To detail the exchange seems to me to be a bit maudlin, so let me just say that
we were talking about adding/changing functionality to an object.  The
professor's statements were cleary pointed toward no change neccessary to the
code comprising the object.

The risks are:

    - Merely parroting the party line (OOP eliminates changes to
      operational code), and not thinking carefully about the question.
      This seems especially dangerous when instructing the empowered
      naive.  There were managers and engineers who were receiving
      their first exposure to OOP in that class.  They were going to
      try to use the information from that class in real products.
      Their (the empowered naive) perceptions and beliefs are soon
      going to effect other people's lives.

    - Management hearing the party line and accepting a "panacea" type
      solution.  This is an "oldie-but-goodie" (maybe even in the
      all-time top ten) in the category of "Engineer's Gripes," and
      it's currently getting a thorough flogging in RISKS.

The above in no way reflects the views of Hewlett-Packard Company.

Benjamin Ellsworth    ben%hp-pcd@hp-sde.sde.hp.com

   [There are indeed lots of ways to get a program to do something else
   without modifying the code.  Moving it from one directory to another
   can have all sorts of side-effects, especially in a system with search
   strategies.  Not moving it but altering the search strategy for subtended
   programs is another way.  Redefining parameters, abbreviations, user
   profiles, etc., is another.  How about inadvertent effects resulting from
   someone else innocently introducing an operating system change?  All of this
   relates to the old saw about hardware degrades but software does not.  Not
   true.  PGN]


Structuring large systems

<John.Spragge@QueensU.CA>
Wed, 25 Jan 89 17:08-0500
By all means, we need new structures. There's no question about that.
The only question is, what should we build those new structures on?

I believe that the problem of relating the behaviour of a program to
it's (human-readable) static representation has been solved at a
"micro" level. And, pace the disbelievers in structured programming,
I believe that structured techniques represent the best solution at
the procedure level. The question is the a matter of tying a large
number of procedures into a workable, consistent, large system.

The answer to that, it seems to me, is to envisage the system as a machine
(needless to say, programs are, in the strict sense, machines in the same way
computers are). The starting point for fulfilling the requirements of an
end-user who wants a particular software product is to ask what sort of
"special purpose" computer would be best at solving that problem. The program
can then be structured as an attempt to simulate that system on a
general-purpose computer.

For example, a good analogy for writing a spreadsheet would probably be a large
array (or "matrix") processor, in which every cell could simulate a "processor"
having access to a central series of processing functions. A windowing system
can be written as an "ideal" terminal device.

This approach has the advantage of encouraging the same sort of "generality" in
design that computer hardware benefits from; the adders on a system generally
work because the system has just one general purpose adder, not a vast series
of different adders.  In the same way, a wide variety of the functions in a
system which appear to be very different share many (if not most) critical
attributes, and sufficiently flexible routines can be devised, in many cases,
to apply to all the disparate functions required.

This is only one approach to the "larger" structure of systems design. But when
building a large building, it does no good at all to discard the girders.
Orthodox "structured" programming techniques are, I am convinced, at the heart
of building reliable procedures, without which no large system can be built. It
isn't possible to build a giant program on nothing but the knowledge of Ifs,
Whiles, and Cases; but they are essential components of good programming.

John G. Spragge, Computing Consultant, Box 2042, Kingston Ont. (SPRAGGEJ@QUCDN)


About non-redundant redudant systems (Re: RISKS-8.14)

Elizabeth D. Zwicky <zwicky@cis.ohio-state.edu>
Wed, 25 Jan 89 11:14:04 EST
Of our many computer rooms and labs, 2 have redundant air-conditioning systems.
One of them has two separate systems installed at two completely different
times by two different companies; it gained redundancy out of necessity because
the first air conditioner barely had the capacity.  The second one started out
with two air conditioners, because it seemed like a good idea. They were
installed at the same time, by the same company.  Less than a month later, that
room started getting hotter and hotter and hotter.  We called A/C repair. They
said they would log it as non-emergency, due to the second A/C in the room. We
pointed out that the second A/C was not air conditioning any more than the
first was. They grudgingly updated it to an emergency call, and in short order
one of Ohio State's people arrived. 5 minutes later he developed an amazed/
appalled look, and began to curse.  "What the hell sort of a redundant system
is this?  What do those jerks think they are playing at?" It seems that our two
A/Cs had but one thermostat, which had duly failed. Needless to say, Ohio State
made all sorts of grief for the vendor, who eventually managed to make the
systems more redundant. Nevertheless, reliability is *still* higher in the
cobbled-together, afterthought-redundant system, than in the "properly"
designed one.

Elizabeth D. Zwicky, Ohio State University Computer and Information Science


Engine-count and the Spirit of St. Louis

Michael McClary <xanadu!michael@uunet.UU.NET>
Sat, 21 Jan 89 01:29:46 PST
The more-is-less phenomenon of aircraft engine reliability has been noted
previously.

During the push to extend aircraft technology to non-stop trans-Atlantic
flight, most of the designs were multi-engined.  The designers of the
Spirit of St. Louis recognized:

 - they were on the edge of the technology, therefore
 - there was insufficient spare capacity to carry a dead engine, and
 - there was nowhere to land for repairs, therefore
 - all the engines would have to run for essentially the whole flight, so
 - assuming roughly equal engine mean-time-to-failure, the more engines,
   the greater the risk of failure (with loss of craft and pilot).

Thus the Spirit of St. Louis was designed with a single engine.

It's a classic examples of the counter-intuitive nature of probability
theory and risk assessment.

(Of course, practical service had to wait a bit, until aircraft capacity
and airport availability improvements made single-engine-failure survivable.)


Counting engines

Jordan Brown <jbrown@herron.UUCP> <jbrown@jato.Jpl.Nasa.Gov>
Sun, 22 Jan 89 19:55:01 PDT
Don Alvarez <boomer@space.mit.edu> writes:
> Imagine two planes which are identical except that one plane has 2
> Bratt&Zittley Foobar-900 engines, and the other has 3 B&Z F-900 engines.
> Well, clearly the second will fly better on n-1 engines, ...

This is the misconception that I'm trying to point out.  If you have an
airplane which flies fine on two B&Z F-900s (meets single-engine performance
requirements, etc) then no manufacturer would ever put another engine on that
airplane.  It just wouldn't make sense.  (This is for civilian applications;
military apps have other issues.)  The three-engine airplane discussed will
either be bigger or have wimpier engines.  The controlling factor is engine-out
performance.  The two-engine airplane with one out will have performance
comparable to the three-engine airplane with one out.

727 engines (3/airplane) are wimpy compared to DC-9 engines (2/airplane).
BAe-146 engines (4/airplane) are *really* wimpy.  (This assumes that
727s are approximately the same size as DC-9s.  Bae-146's are smaller.)

Jordan Brown 


Re: Space shuttle computer problems, 1981--1985

<attcan!utzoo!henry@uunet.UU.NET>
Tue, 24 Jan 89 00:25:52 -0500
>STS-6, April 4, 1983: ... Landing gear must be manually deployed after computer
>fails to trigger its descent.

I wonder if this is not mistaken reporting at some level.  My recollection,
possibly incorrect, is that lowering of landing gear is specifically not
under computer control in the space shuttle -- it *has* to be done manually.
The reason is that once lowered, the shuttle's landing gear is *down* --
it can't be raised again in flight.

Possibly the problem was that the computer did not say "time to lower the gear"?
                                     Henry Spencer at U of Toronto Zoology
                                 uunet!attcan!utzoo!henry henry@zoo.toronto.edu


Revised Computer Ethics Course Proposal

Bob Barger <CFRNB@ECNCDC.BITNET>
Wed 25 Jan 1989 09:34 CDT
The following revision is based on critiques received on a proposal published
in RISKS digest 7.75. Comments are still welcome (send to CFRNB@ECNCDC.BITNET).
Course Description: The course will investigate current ethical issues
involving computers.  While it is not a "computer course," students will make
frequent use of postings on the electronic bulletin board of the ECN mainframe
computer to research and discuss ethical issues. Prerequisites: 75 Semester
Hours and previous experience with computers. [Class size limit = 15 students
for Fall, 1989, semester]. Outline of topics: Week 1: Orientation to the course
(introduction, explanation of course content, class procedures, and evaluation
methodology). Consideration of ethical theory. Week 2: Consideration of ethical
theory (continued). Week 3:  On-line reading of the "Discussion of Ethics in
Computing" list, the "Forum on Risks to the Public in Computers and Related
Systems" digest, and the "Computers and Society" list (all are available on the
ECN bulletin board); written reactions to these readings, and written
commentary on other students' reactions. [The instructor will insure that these
activities equate to the activities of a traditional two hour class meeting].
Week 4: Consideration of professional ethics. Week 5: Same activities as for
Week 3. Week 6:  Consideration of liability for software design, manufacture,
and use.  Week 7: Same activities as for Week 3. Week 8: Consideration of
privacy issues. Week 9: Same activities as for Week 3. Week 10:  Consideration
of power/control issues. Week 11: Same activities as for Week 3. Week 12:
Consideration of ownership and theft issues.  Weeks 13 & 14: Same activities as
for Week 3. Week 15: Seminar members will reconvene as a group for the last
meeting to allow for group reflection on the seminar experience and course
evaluation.  Semester Exam week: Final Examination. Writing component: Students
will type thirteen 30-to-50 line (i.e., one-to-two page) reactions to the
on-line electronic bulletin board readings. Students will "post" these
reactions (i.e., electronically send them to the mainframe computer bulletin
board set aside for members of this seminar). In their reactions, students
will: 1) identify the particular publication or publications to which they are
reacting, 2) identify the particular issue or issues raised in the
publication(s), 3) identify the ethical implications of the issue or issues, 4)
identify the ethical paradigm used by the author, 5) add their own reasons for
agreement or disagreement with the viewpoint of the publication's author, 6)
and, finally, offer an alternative solution or viewpoint to that presented by
the author, or present other appropriate considerations not raised by the
author or covered in their own (i.e., the student's own) previous comments. The
instructor will send weekly, by confidential electronic mail, a grade on the
student's posted reaction, together with whatever comments the instructor
thinks helpful. The student's original posted reaction will also be open to
public comment by the other students in the seminar [this is accomplished by
posting notes to the bulletin board, referencing the original posted reaction].
These latter comments by the other students in the seminar will be considered
along with classroom discussion in computing the "participation" factor of the
student's semester grade. Evaluation: Each student's semester grade for the
seminar will be calculated according to the following weighted formula: 13
posted reactions (at 5% each) = 65% ; Participation (based on class discussion
and posted comments on other students' reactions) = 20%; Final Exam = 15%.
Materials in the course will include: 1) Texts: Deborah Johnson, Computer
Ethics (Englewood Cliffs, NJ: Prentice Hall, 1985); privately published notes
on systematic ethics from Dr. Barger's Philosophy 1800 class (furnished free to
seminar members); postings on the above-mentioned ECN electronic bulletin board
lists. 2) Resource people: Computer professionals (e.g., administrators,
systems analysts, programmers, etc.) will be utilized as guest contributors to
the class. This will be accomplished by personal appearances, as well as by
electronically mediated conferencing (e.g., postings, e-mail, relay
round-tables, etc.).

Please report problems with the web pages to the maintainer

Top