RISKS-LIST: RISKS-FORUM Digest Wednesday 20 April 1988 Volume 6 : Issue 65
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Creating Alternatives to Whistleblowing (Vin McLellan)
Safety nets under falling bridges (Rob Horn)
Datamation, 15 April 1988, on "Risk" (Martin Minow)
Poorly designed error messages (Bob Larson)
RISKy Airline Meals (Mark Jackson)
Response-time variability -- prior art (Martin Minow)
Re: Security of OS: who is responsible? Klaus Brunnstein
Israeli Viruses (Fred Cohen)
Time-zone problem (Peter Webb)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, nonrepetitious. Diversity is welcome.
Contributions to
[email protected], Requests to
[email protected].
For Vol i issue j, ftp kl.sri.com, get stripe:<risks>risks-i.j ... .
Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85).
----------------------------------------------------------------------
Date: Tue 19 Apr 88 05:56:14-EDT
From: "Vin McLellan" <SIDNEY.G.VIN%
[email protected]>
Subject: Creating Alternatives to Whistleblowing
On April 14, an MIT graduate student organization sponsored a
forum on Ethics in Engineering and Science which turned into
a discussion of whistle-blowing: what can lead an engineer to
consider it, how it can be done, and how badly one can expect
to be punished for being the messenger bearing troublesome news.
Sylvia Robins, the Rockwell software engineer from the space
vehicle program who protested fraudulent and fudged testing,
lack of required security, and contract featherbedding up the
line within her company, Unysis, and then jumped into the
hierarchy of the prime contractor, Rockwell, was a brisk,
impressive, and inspiring example of the breed as she spelled
out the difference between a salary hack and a self-respecting
professional.
With lives and important missions at stake, she said,
she couldn't and wouldn't participate in massive and normative
fraud. As a result, Robins said, she has been bugged, tapped,
followed, slandered, had her property vandalized, and was subjected
to repeated threats, even assaults. Robins' story has been reported
in detail elsewhere (and recent federal charges seem to substantiate
many of her specific complaints) but she gave the MIT kids
a few thought-provoking bulletins from the real world.
According to Robins, at Rockwell the Corporate Ombudsman and
the Corporate Ethics Office are both managed by the corporate
security staff -- the very thugs who apparently saw their duty
in orchestrating the campaign against her within and around the
company. (When she returned to her office after she finally went
public with her charges at a press conference, the walls at
Rockwell closed in around her -- literally. The partitions that
shaped her workspace had been moved to crowd her desk: she
could reach out, seated at her desk, and touch both sides of the
room.)
Lone messengers really do get the shaft, she said, no
matter how real or accurate their complaints -- although sometimes,
even so, a woman has to do what is right. Robins said she now
realizes that many engineers unexpectedly find themselves confronted
with major ethical issues on the job; in the past six months, she
said, some 160 engineers have contacted her for advice in how to deal
with such situations in their work. Among her bitter lessons,
she said, was that anyone caught in her position should try to
build a consensus among peer engineers and, if at all possible,
to present major complaints in a group petition. A whole department
is harder to ignore, slander, or ostracize. For a lady with a rep
for a carbon steel spine, her suggestions and attitudes were
politically savvy and not confrontational.
Beside the pert matronly Robins, a slouched yet looming
presence on the MIT stage was fellow panelist Ralph Nader.
(Astonishingly, this was only the third time in 15 years that
Nader -- still probably the leading critic of poor and unsafe
engineering knowingly foisted upon the public -- had been
invited to speak at MIT.) While the planning of the forum left
much to be desired, in that Nader was given only 20 minutes to
address a crowd largely drawn by his name, his sardonic and
bitter humor brought an edge to what had been a sometimes
blithering panel. After paying warm homage to the courage and
honor of Ms. Robins -- and worrying aloud how many of the students
before him could have survived the brutish campaign Robins
endured -- Nader left the podum with an interesting observation,
almost a challenge, to both the students and career engineers.
In the mid-1970s, he noted, rising concern over social issues
among law students was directly reflected in the sort of questions
the students asked of the corporations which sought to recruit them
from the campuses. And those questions, he said, quickly and quite
directly shaped the image of themselves the major law firms
learned to project -- and were soon reflected in the work practice
of the best law firms themselves, those most successful in recruiting
top students. Specific questions about the amount of time a law
firm committed to pro bono legal work, for example, *introduced*
the practice of pro bono work in many large law firms.
If engineering is truly a profession, with minimal standards
of technical prowess and personal integrity to be upheld, said Nader,
engineering students could similarly have a major impact on
corporate behavior by asking about specific policies and practices
which could protect a dissident or worried professional within a
corporate setting, perhaps guarrantee him or her a hearing (before
engineering peers, in matters of technical or professional integrity)
when immediate corporate superiors were hostile or unsympathetic.
A lawyer, albiet one skilled in corporate infighting, Nader
couldn't go into details for his suggestion. RISKS, however, is
an unusual forum that reaches deeply into academic, corporate,
and government engineering. Could we hear some suggestions for those
students? What questions could be asked? What corporate structures
and/or procedures could guarrantee an honorable engineer who confronts
an issue of ethics on the job a viable alternative to the
self-sacrifice of public whistle-blowing?
Vin McLellan
The Privacy Guild (617) 426 2487
Boston, Ma.
------------------------------
Date: Mon, 18 Apr 88 21:30:21 est
From: Rob Horn <
[email protected]>
Subject: Safety nets under falling bridges
Brian Urquhart wrote
``I believed then, as most conceited young people do, that a strong
rational argument will carry the day if sufficiently well supported by
substantiated facts. This, of course, is nonsense. Once a group of
people have made up their minds on something, it develops a life and
momentum of its own which is almost impervious to reason or argument.''
This belief was based on his experience as intelligence officer prior to the
Arnhem attack and in the UN where he reached Under-Secretary General. It is
relevant to risks because engineers seem to fall into the perenially young
category in their faith that evidence can change decisions.
Most of the discussion of whistle-blower protection etc. make as much sense
as putting a safety net under a poorly engineered bridge. It may help
reduce injuries but it ignores the more fundamental problem. The problem is
that momentum is built up in the system beyond the point where a decision
can be reversed. This is inherent in Feynman's and others' complaints about
the Challenger disaster. The problem is not the O-rings, it was that the
momentum to launch was allowed to get so strong. This was clear for months
prior to launch. Aviation Week was full of stories about rushed schedules,
botched work, confusion, fatal and near fatal accidents. Yet no one could
stop the launch.
When a system has reached this point disaster is inevitable. All you can do
is try to soften the blow. Yet the focus of debate here and elsewhere is on
issues that arise too late. When the system has reached the point that a
whistle-blower needs protection you are already past the point of no return.
Much more important, but much harder, is understanding the human decision
and organizational structures that lead to this momentum. How do you
destroy this overwhelming force to completion without destroying the will to
succeed?
Rob Horn, Infinet, 40 High St., North Andover, MA
..harvard!adelie!infinet!rhorn ...ulowell!infinet!rhorn ..decvax!infinet!rhorn
------------------------------
Date: 19 Apr 88 16:00
From: minow%
[email protected]
(Martin Minow THUNDR::MINOW ML3-5/U26 223-9922)
Subject: Datamation, 15 April 1988
The cover article is on "Risk." "When you become dependent on any resource,
you become more vulnerable." Martin.
------------------------------
Date: Tue, 19 Apr 88 00:33:02 PDT
From: blarson%
[email protected] (Bob Larson)
Subject: Poorly designed error messages
Organization: USC AIS, Los Angeles
The message in a recent RISKS about starting from false assumptions when
someone gives you their conclusions rather than the symptoms (which I
assume many of us have discovered the hard way) got me thinking about
how the bad conclusions are reached.
Primos has a "standard" error message "Access Violation". On a number of
occasions, people come to me (as the local primos "guru") asking me to help
me find the file they can't access when they get this message. The error
message is used exclusivly for MEMORY access violations. (This is one of
several messages that usually indicate a bad pointer.) File messages
include "insufficent access rights" and "not found" to cover files that
can't be opened due to insufficent access rights.
While not a huge error, this poorly designed error message has probably
caused many man-months of time wasted looking for the wrong problem.
Bob Larson
[email protected] {sdcrdcf,cit-vax}!oberon!skat!blarson
------------------------------
Date: 19 Apr 88 07:50:52 EDT (Tuesday)
From:
[email protected]
Subject: RISKy Airline Meals
The following is from the letters column of the "Travel" section of the
April 17 /New York Times/. Mark
To the editor:
The perils of ordering special meals on airline flights cannot be
overlooked. A while back we traveled from Fort Lauderdale to Detroit with
Delta Airlines and ordered a cold seafood plate instead of the regular meal.
Delta responded with a hot seafood plate. We wrote them a letter to
complain and they apologized.
However, since then we have been on three morning Delta flights where
breakfast was served. Each time we were brought a cold seafood plate. We
did not want it. We did not order it. Somehow, our name has gotten into
the computer, and every time we fly we get the cold seafood plate.
The last time it happened, the flight attendant referred to us as "Mr. and
Mrs. Seafood" instead of Mr. and Mrs. Stanton.
Roger Stanton, Grosse Pointe, Mich.
/A spokeswoman for Delta Airlines replies:/
There are two codes that can be used to tell the computer that a request for
a special meal has been made, one for a specific flight, the other for all
flights a passenger might take. In Mr. Stanton's case, the agent apparently
used the wrong code. That has now been corrected. We encourage passengers
to request special meals at the time the flight reservation is made, but it
can be done up to three hours before flight time for most meals, eight hours
for kosher meals. Passengers should specify whether they want a standing
order or a one-time-only order.
[At 35,000 feet, on a clear day you can seafood forever,
especially if you are standing -- or Stanton. PGN]
------------------------------
Date: 19 Apr 88 09:55
From: minow%
[email protected]
(Martin Minow THUNDR::MINOW ML3-5/U26 223-9922)
Subject: Response-time variability -- prior art
The recent re-invention of response-time variability reduction techniques
forced me to dig out an article I published in an obscure journal in 1977.
In the Decus Proceedings vol. 4, no. 2, I wrote a long article on system
performance and usability. To quote:
One example of a simple method to improve the way a system seems
to perform is illustrated by the program segment [as follows]:
100 PRINT "Prompt";
200 INPUT request
300 start = [get time of day]
400 ... Calculate result ...
500 elapsed = [time of day] - start
600 IF (elapsed < 5) THEN sleep(5 - elapsed)
700 PRINT result
... This has several implications:
-- Response times are less dependent on system load.
-- The operator learns when to expect a response from the system
and thus is able to build a rhythm by knowing when to look
back at the terminal.
-- The system response degrades more slowly. If the actual response
time varies from one second to six seconds, the operator will
see only a one-second variation, instead of an almost five-
second variation.
...
In general, your programs should be written so that the operator
feels that "they're always there;" that they will always do something
reasonable in a resonable time. Early computers often had loudspeakers
attached to some part of the CPU. The operator heard what was happening:
how far the production run ahd progressed, when it was about time to
change tape reels. ...
In all cases, try to keep the feeling that the system "listens" to
the operator at all times, and -- especially -- "tells" the operator
what is happening.
I don't claim originality for these ideas: I was taught them by the
customers I supported in Sweden in the early 1970's. I guess my mistake was
not wrapping them inside some theoretical framwork ("System usability and
implications for the eight queens problem") and publishing them in CACM. Of
course, if I did so, the people who needed the information might not have
seen it.
Martin.
------------------------------
Date: 19-Apr-88 07:45:48-PDT
From: Klaus Brunnstein
<brunnstein%
[email protected]>
Subject: Re: Security of OS: who is responsible? (RISKS-6.64)
In his information how to cope with an error in DEC's Kid Install software
for its recent security update for Vax Workstation Software, Darren compares
the security of an operating system to a house. Inhabitants are, according
to his example, themselves responsible to prohibit thieves from easy access
by just using their keys and locks.
Unfortunately, the example is misleading: while every `user' of a house
knows about access and how to control it, complex operating systems have so
many doors that nobody can understand the diverse control techniques. While
house are designed, as socio-technical systems, according to a
user-understandable model, an operating system is designed as a technical
system without virtually any reference to users concepts.
In this situation, the designers responsibility to guarantee a `safely
usable operation system' (especially when a design or programming error is
probable) cannot so simply be transferred to the users (also in the case of
non-benevolent users). I therefore greet DEC's activities to provide better
professional standards in dealing with security updates.
Klaus Brunnstein, University of Hamburg, Fed.Rep.Germany
------------------------------
Date: 19 Apr 88 02:18:53 EDT (Tue)
From:
[email protected] (Fred Cohen)
Subject: Israeli Viruses
I should point out that I wrote the research papers that detailed the class
of methods proposed for detecting viruses by the Isreali team - they were
published in Computers and Security in 1987 - the checksums I have seen are
fairly easy to forge, but even the very strong ones like the one I published
can be broken given enough time. They are a "Complexity Based Integrity
Maintenance Mechanism" (the name of one of those papers). Indeed, I suspect
that I could still write a virus that they could not detect, as I have done
considerable research into the topic and understand the underlying
mechanisms. I should note that the source code for such a high quality
checksum is to be published in the April issue of C+S, so you'd better take
all the cash you can get right away, before the public finds out they can
get the same or better protection for free. - FC
------------------------------
Date: Fri, 15 Apr 88 10:30:17 EDT
From:
[email protected] (Peter Webb)
Subject: time-zone problem
I have learned that Telnet announced, on April 7, that everyone who
uses its Electronic Bulletin Board service should ignore any and all bills
for daytime usage, from Sept 1987 to Feb 1988. Apparently, calls to Telnet are
often automatically re-routed by the local phone company. In some cases the
calls are forwarded to an exchange in a different time zone than that of the
originating user. Under the correct circumstances, ie a user dialing in less
than an hour after night/evening rates go into effect and having his or her
call forwarded to a node in a time zone at least one hour earlier, this can
lead the Telnet system to believe the call was placed during daytime
hours, and to consequently bill the user at daytime rates. The problem is
excaberated by Telnet's policy of billing an entire session at daytime rate
if any part of it occurs during daytime hours
Peter Webb.
{allegra|decvax|harvard|yale|mirror}!ima!applicon!webb,
{mit-eddie|raybed2|spar|ulowell|sun}!applicon!webb,
[email protected]
[Again! This has happened to the competition as well. If it wasn't so
late and I wasn't commuting to the Security and Privacy meeting, I'd
dig up three or four previous cases in RISKS. PGN]
------------------------------
End of RISKS-FORUM Digest
************************
