Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 7: Issue 28
Tuesday 26 July 1988
Contents
Pentagon testing- Mike Trout
- Re: "Man in the Loop"
- Rodney Hoffman
- NOVA on risks of fighter technology
- Dave Curry
- Re: Hacking central office switches
- Laura Halliday
- Law student sues micro sysop under ECPA
- John Gilmore
- Scanning instant-win lottery cards
- Rich Kulawiec
- Wanted: Info on Ergonometrics
- Emily S. Bryant for Michael Whitman
- Info on RISKS (comp.risks)
Pentagon testing (an oxymoron) (Re: RISKS-7.24)
Mike Trout <miket@brspyr1.brs.com>
25 Jul 88 21:21:13 GMT
In article <12415398632.18.NEUMANN@KL.SRI.COM>, Gary Chapman writes: > Subject: Aegis testing data withheld from Congress > Defense Week reports that an unclassified report of the General Accounting > Office (GAO) reveals that the Navy withheld testing problems of the Aegis > air defense system from the Congress. "Personnel and Aegis equipment were > not subjected to targets or tactics that would be found in combat," ... This is typical of Pentagon testing, and seems to be particularly prevalent in the Aegis system. An interesting parallel concerns the testing for the Phalanx close-in shipboard missile defense system, which of course is included as part of the Aegis umbrella. The Navy's final results of the testing conducted for Phalanx reported that the system had achieved greater than 80% "success." But what was the definition of "success?" Pentagon watchdog groups did a little digging with the Freedom of Information Act, and determined that "success" had been interpreted as "destruction of the incoming missile." Well, that seemed okay, so most investigations were dropped. But some whistle-blowers in the Pentagon produced some disconcerting information. While it was true that simulated incoming missiles had indeed been "hit" and "destroyed," it had been determined that the debris and rocket fuel of the destroyed missile would continue onward and hit the ship, causing tremendous impact and an inevitable fire. It was estimated that this would be enough to destroy or knock out nearly any vessel. But since the simulated missiles had been "destroyed," the Navy proudly announced that Phalanx had passed the test. Empirical evidence from the Falklands war makes the Phalanx testing look even less realistic. Only one of the Exocets hitting Royal Navy ships exploded, yet the dud Exocets still did hellish damage, including sinking two ships. It also appears that the missile that hit the USS _Stark_ did not go off. Another example uncovered by the Dina Rasor group: A mobility/breakdown test was conducted for the new M-1 Abrams tank. The tank failed the test. The test was run again, with identical results. The Aberdeen Proving Grounds was instructed to just keep running the test until the tank passed. On the 161st try, the tank passed the test. The testing information provided to Congress included only that which pertained to the 161st test; the previous 160 tests were not even mentioned. Rasor has also uncovered suspicious changes in the testing for both ALCM and GLCM (Air- and Ground- Launched Cruise Missiles). Recent stories of doctored test results for the Rockwell B-1B are similar. In any system in which hardware or software is to undergo a realistic test, it is critical that ALL test results be released, unaltered. Any other course of action changes the test from a realistic simulation to a public relations gimmick. In the case of software written for a computer game, the results of doctored testing may be comical. In the case of a military weapon, the results may be disastrous. Michael Trout (miket@brspyr1) =-=-=-=-=-=-= UUCP:brspyr1!miket BRS Information Technologies, 1200 Rt. 7, Latham, N.Y. 12110 (518) 783-1161
Re: "Man in the Loop"
Rodney Hoffman <Hoffman.es@Xerox.COM>
26 Jul 88 07:38:52 PDT (Tuesday)
I recently posted excerpts from Peter Zimmerman's article about AEGIS and Star
Wars and the "man in the loop". Just in case it wasn't clear, all but the lead
introductory sentence of that was from Peter Zimmerman, not directly from me.
Anyone wishing a copy of his complete article may contact me.
I completely agree with Will Martin and Bill Murray when they each insisted on
adding to Zimmerman's piece a stronger statement about HUMAN fallibility.
In my initial posting, I thought I would let Zimmerman speak for himself. In
light of the responses, I probably should have appended my own reactions. In
particular, I believe many lessons implicit in Zimmerman's piece (and familiar
to all RISKS readers) are well-taken. Among them:
* The blind faith many people place in computer analysis is rarely
justified. (This of course includes the hype the promoters use to
sell systems to military buyers, to politicians, and to voters.)
* Congress's "man in the loop" mandate is an unthinking palliative,
not worth much, and it shouldn't lull people into thinking the problem
is fixed.
* To have a hope of being effective, "people in the loop" need additional
information and training and options.
* Life-critical computer systems need stringent testing by disinterested
parties (including operational testing whenever feasible).
* Many, perhaps most, real combat situations cannot be anticipated.
* The hazards at risk in Star Wars should rule out its development.
Rodney Hoffman
NOVA on risks of fighter technology
Dave Curry <davy@intrepid.ecn.purdue.edu>
Mon, 25 Jul 88 16:59:49 EST
WTTW (Channel 11), the Chicago PBS station, showed a commercial last night for a NOVA episode on the risks of fighter plane technology. The preview blurb mentioned questions like is there too much data for the pilot to keep track of, are G's too great, etc. I would assume other PBS stations will have this episode at some point also (I'm not a regular watcher of PBS or NOVA, so I don't know how they work). WTTW is showing it on Tuesday 7/26/88 at (I believe) 9pm EDT. --Dave Curry, Purdue University
re: Hacking central office switches
<Laura_Halliday@mtsg.ubc.ca>
Mon, 25 Jul 88 14:30:38 PDT
John T. Powers Jr. writes (Risks 7.27): > It would have been easy for them to make this kind of activity much harder > than it evidently was. ... When I worked for BCTel, we had an even simpler solution: remote access to the console was over dedicated lines. Grossly unsophisticated, but effective. laura halliday laura_halliday%mtsg.ubc.ca@um.cc.umich.edu
Law student sues micro sysop under ECPA
John Gilmore <hoptoad.UUCP!gnu@cgl.ucsf.EDU>
Mon, 25 Jul 88 22:09:35 PDT
This appeared in a recent FidoNews (comp.org.fidonet on Usenet).
The FidoNet is a few thousand IBM PC's all calling each other over
dialup lines; similar to Usenet; less flexible; evolving faster.
Copyright 1988 by the International FidoNet Association. All
rights reserved. Duplication and/or distribution permitted for
noncommercial purposes only. For use in other circumstances,
please contact IFNA at (314) 576-4067. IFNA may also be contacted
at PO Box 41143, St. Louis, MO 63141.
FidoNews 5-30 Page 3 25 Jul 1988
Jonathan D. Wallace, Esq.
1:107/801
SYSOP LIABILITY FOR DISCLOSING PRIVATE MESSAGES
In what appears to be the first case of its kind, an Indiana law
student and BBS user has sued a local sysop, Bob Predaina, in
federal court, claiming that he intentionally disclosed her
private electronic mail to others without her permission.
The lawsuit, which is in the early stages and has not reached
trial, relies upon the Electronic Communications Privacy Act of
1986 (the "ECPA"), which makes disclosure of private electronic
mail without consent either of the sender or the recipient a
federal crime.
The ECPA does not obligate sysops to offer private mail on their
systems. However, if a sysop promises private mail, that promise
must be kept and the contents of private messages may not be
disclosed without consent.
The ECPA provides limited exceptions to the general rule of no
disclosure. A sysop may voluntarily disclose to law enforcement
authorities the contents of a message pertaining to the
commission of a crime, if read inadvertently by him or if it is
read pursuant to the exercise of his duties as a sysop.
Until the courts clarify these rules, sysops who read private
mail on their systems and disclose it may be playing with fire.
Prior court cases involving telephone operators have established
some useful guidelines: an operator may disclose information she
overheard while checking the line at the user's request, but may
not disclose information overheard while eavesdropping out of
curiosity. Sysops, like phone operators, will not be considered
to have a blanket authorization to intercept and disclose private
messages.
Systems such as Fido 11w which routinely make all
private mail visible to the sysop are therefore problematic. BBS
programmers should consider making private mail truly private--
while allowing sysops to turn the private mail option off if they
do not want it.
In the meantime, sysops should reconsider whether it is
worth having private mail on their systems and should make clear
to users in no uncertain terms, through bulletins and messages,
the degree of privacy which can be expected, if any.
Note: a copy of the complaint filed in the Thompson v.
Predaina case is available on the LLM BBS, Fido 107/801
(212)766-3788) in file area 5 under the name "Indiana".
* * *
JONATHAN D. WALLACE, ESQ. is an attorney in New York
City specializing in computer law. With Rees Morrison, he is the
author of the Sysop's Legal Manual, published this year by LLM Press.
He can be reached at (212) 766-3785 (voice) or at the LLM BBS,
given above.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The same issue of FidoNews also contains a relevant ad:
SYSOP LEGAL MANUAL FOR SALE
SYSLAW, the Sysop's Legal Manual,
by Jonathan D. Wallace Esq. and Rees Morrison Esq.
This 130 page book, newly published by LLM Press, includes
chapters on the Electronic Communication Privacy Act, sysop
liability for illegal uploads such as pirated software and stolen
credit card codes, libel and state computer crime laws. The book
is $21.00 (includes postage and handling) from LLM Press, 150
Broadway Suite 610, New York, New York 10038. New York residents
include 8.25 percent sales tax.
[This item is included in RISKS because the book might just answer
questions that have been raised here repeatedly. This notice
represents no endorsement of the book, and is for your information
only. On one hand, much of the cited information is publically
available. On the other hand, its compilation and interpretation in
one place might be useful -- assuming the book is accurate. If this
redistribution in RISKS can in any way be deemed in violation of the
FidoNet banner above, then perhaps FidoNet itself was in violation of
its own noncommercial dictum. By the way, RISKS is unquestionably a
noncommercial effort, in case you hadn't noticed. PGN]
Scanning instant-win lottery cards (Re: RISKS-7.27)
Rich Kulawiec <rsk@payton.cc.purdue.edu>
Tue, 26 Jul 88 01:43:27 EST
Fred Baube <fbaube@note.nsf.gov> writes:
"Even if they make instant-win lottery cards immune to non-
destructive testing by X-ray, aren't there small CAT scanners
or NMR imagers out there that can determine the location of ink
molecules, providing the same winner/no-winner information ?"
CAT scanners also use X-rays to produce an image, so a card immune
to "peeping" by a conventional X-ray machine is very likely to be immune
to a CAT scanner as well. (All that is necessary for this is that the
inked area have the same absorption cross-section as the non-inked area.)
A similar comment applies to ultrasonic imaging techniques. NMR imaging
might reveal the hidden print, if the ink molecules are distinguishable
from those non-ink molecules around them. My (very casual) guess is
that using an area that's written in two shades of ink with slightly
differing formulations might defeat this approach; i.e. if both areas
consist of a substance with nearly the same chemical composition and
structure, they may be indistinguishable via NMR.
Rich Kulawiec
Wanted: Info on Ergonometrics
Emily S. Bryant <dartvax!eleazar!emilyb.UUCP@seismo.css.gov>
25 Jul 88 18:42:52 GMT
I am posting the following for a colleague; please send responses by mail to:
michael.whitman@dartmouth.edu or ...{decvax, ihnp4}!dartvax!michael.whitman
and NOT to me! Thanks. Emily Bryant.
WANTED: Information on how to set up a computer workstation's screen,
keyboard, and seating to minimize eyestrain and physical fatigue.
I am interested in any research results which pertain primarily to
eye- and backstrain, but am not looking for information on possible
effects of video display terminals on pregnant operators.
I am looking for recommendations on
1) Worker's height : chair in inches;
2) Distance from eyes to computer screen;
3) Angle from eye level to center of screen;
4) Height of keyboard above lap level;
Also,
5) Do higher screen resolution and refresh-rate reduce eyestrain?
6) Is it personal preference or documentable fact that black letters
on "white" background (Macintosh), green on black, amber on black, or
some other combination, are easier on daylong viewers' eyes?
8) What kind of ceiling fluorescent bulbs help reduce eyestrain?
9) What kind of chairs help minimize backstrain?
Finally, how about common sense suggestions in addition to these:
10) Workers should look away periodically from their screens and
focus on objects in the distance;
11) Use a screen font which is large enough to be read easily;
12) Use eyeglasses when computing for long hours, with a
prescription specifically for one's actual eye-to-screen distance.
I am researching a feature article for a publication at Dartmouth
College. Since I have been able to find no recent articles on this
except a NY Times 6/23/88 article, I hope suggestions for
information sources will be sent.
Michael Whitman
Dartmouth College
Report problems with the web pages to the maintainer