Summarized from a story by Gregory Crouch in the `Los Angeles Times', 18-April-89: A whistle-blower alleges that Litton Systems designed a company software system to under-record the computer usage of Litton's commercial clients, causing the federal government to be over-charged. Former Litton employee James Carton has filed suit after concluding that Litton rigged its computer billing service to over-charge the government more than $25 million between 1983 and 1988 for computer work on hundreds of defense contracts. Late last month, the U.S. Justice Dept. announced that it has taken over Carton's suit. With fines for every instance of over-charging and treble damages, the total could reach $175 million. Under the False Claims Act, Carton stands to receive 15% to 30% of any damages awarded to the government. Litton denies the charges, claiming it saved the government money by letting commercial customers use the same computers. While writing an assigned report on the profitability of Litton's computer services, Carton noticed that most of the commercial customers, accounting for more than half of the data center's revenue, were actually costing the company money. One company was charged for using two disk drives when it actually was using three. At the same time, the government was being overcharged. He discovered and reported more discrepancies, but, more than a year later, nothing had changed. He finally decided to file suit.
>From "World Press Review," May 1989, quoting "Wirtschaftswoche," Duesseldorf: A "black box," or data recorder, for cars is being developed by a consortium in West Germany. The size of two cigarette packs, it will cost $215 and record changes of direction, the status of lights and turn signals, steering-wheel and pedal positions, and even whether the radio is on. Every 30 seconds new data will be stored on a microchip; in an accident, this data will freeze, and later information will continue to be recorded... [Once again, there is a serious question as to the integrity of the data in the recorder. In a court of law, we have the problem that the data may not be what was recorded in real-time... PGN]
A colleague of mine in county planning is having trouble convincing people not to smoke next to computer systems containing supposedly irreplacable info, and is worried about tar and nicotine buildup on disk drives. Any suggestions? [Use digital filters? Responses to David, please. PGN]
[The foregoing discussion] raises a computer version of a well-known risk: that of testing for errors. (Not to mention the risk of finding and/or reporting them!) Almost any test of any piece of equipment is definable as trying to make the equipment fail. If it does fail, the person doing the testing is liable to civil or criminal penalties. If it does not, she risks being subject to lesser penalties for trying to make the equipment fail. This is an interesting double-bind (well, 1.5-bind actually) that can be used to discourage testing of potentially dangerous things. Because it typically requires some kind of legal protection for the tester, it is often held to be something only a government should do. Yet if it is, then we are faced with finding out how to test the testers who are acting as our agents... It can also make ordinary people reluctant to run **necessary** tests. Well before the Internet Worm of yore, I executed a uucp-test program named "virus" that informed system managers if their security was unnaturally low. As you might guess, some were concerned. Regrettably, some took exception to the fact that the test was done **at all**, and called upon my management to ensure that their opinions would be made known to me. (In my Honeywell days this sort of thing was known as a "career killer"). In fairness I should point out that some people knew a test program on sight and publicly defended the test, the program and myself. (Thanks, Dave and Erich!) Nevertheless, the chilling effects were real. And the problem of protecting the testers is still outstanding. --dave (I survived, obviously) c-b David Collier-Brown, 72 Abitibi Ave., Willowdale, Ontario, CANADA. 223-8968
John Luce's comments on the design goals of electronic elevators certainly raised the level of my knowledge about them. I would like to offer some comments: 1) Automatic systems should not outguess the user and do unexpected things without an explanation at the time of occurrence. I am referring to the fact that, after the doors are held open for a length of time, a car sometimes has to go to a specific place to initialise itself. This behaviour is disconcerting, and can be frightening to a person who is afraid of elevators. The recorded announcement could be used to tell the user what is happening and thus reassure him. Arbitrarily cancelling the buttons inside the car is not foolproof. What about a group of small children, each going to a different floor? How would a blind user know about the cancellation? A better solution would be a specially-shaped button inside the car (maybe you'd pull instead of push) that would allow someone getting in an car with no-one inside to to cancel the uselessly selected floors. Sometimes it's desirable to be able to select a floor that's in the wrong direction. For example, in many buildings, especially apartments, the call buttons outside only go one way (down). For a trip upward, you have no choice but to select the wrong way. Also, if a large number of people (several cars full) want to make the same trip, it is useful for people in the first cars to send them back for more. 2) The elevator manufacturer was wrongly blamed for features that were the building owner's responsibility. I have yet to see an elevator where the division of responsibility is spelled out for the user (e.g. a sign saying "If you have any comments or complaints about the audio announcements, please contact _______, and not Otis." Peter Jones MAINT@UQAM (514)-282-3542
An article by Jim Schachter in the 'Los Angeles Times' 19-April-89 is headlined U.S. INDUSTRY DOES A POOR JOB OF PROTECTING PRIVACY, STUDY SHOWS. Univ. of Ill. Prof. David Linowes chaired the U.S. Privacy Protection Commission more than a decade ago. He has now released a new study showing just how little attention has been paid to the commission's conclusions and just how much ground has been lost. He urges Congress to act. Prof. Harley Shaiken of UC San Diego calls for "applying the standards of the Bill of Rights to the workplace." Linowes says outdated, inaccurate records are being used to make critical decisions about hiring and promotions. "This information is never destroyed, and it's obtainable instantaneously." State and federal privacy laws remain a patch-quilt, and advances in computer and telecommunications technology have increased data collection and analysis. According to the new survey of major corporations, 38% still have no policy on releasing employee records to government agencies, and 57% do not tell employees what records about them are maintained. 42% gather data about workers without telling them, and 57% hire private investigators to probe employees' or job applicants' backgrounds. A sidebar lists PRINCIPLES OF A 'FAIR INFORMATION' POLICY: 1. Minimize intrusiveness. Don't collect more data than is necessary. 2. Maximize fairness. Let the subject know what information is being collected and why. 3. Establish an enforceable expectation of privacy. Provide recourse if privacy is violated.
The serious security problem that was reported in Risks Volume 8, Issue 15 has been corrected by Sun. Sun support and Sun's field offices are now able to supply a new set of programs that will solve the problem. We strongly recommend contacting Sun A.S.A.P. Until you receive the new programs from Sun, we suggest that you change the protection of the login program. chmod 2750 login This will allow login to continue to work but removes users access to it. Since we do not have a Sun 386i system at CERT, we were unable to test the new programs being supplied by Sun. Field reports indicate that the new programs do solve the problem. Thanks, Ed DeHart, Software Engineering Institute / Computer Emergency Response Team, 412-268-7090 [Sun fix also noted by gww@Sun.COM (Gary Winiger). PGN]
When using floppies, the user is generally led to beleive that nothing can happen to alter a floppy that lacks the notch giving permission to write. In actual fact, this is not the case. For example, the APPLE II inplemented the protection of diskettes in software. Worse still, in the case of the APPLE, was a failure (observed by the author on at least two systems) of the drive electronics whereby the heads would be "on' continually, and thus degauss random spots on the floppy (while the head was moving) and all of one track (when the head stopped moving, generally on the boot track!) on any disk inserted! At an Apple club here in Montreal, members were warned to try their Apple with a working diskette with no critical files, then a backup copy of that if the first failed, then to DO NOTHING ELSE if neither worked. That way, at worst you would only risk degaussing two virgin copies of a working disk, and not, say, a $300 copy-protected software package or irreplacable data. I had always thought the problem was unique to the Apple. However, the following item, from Info-IBMPC Digest, shows that this is not the case. Do RISKS readers know of other systems that are not protected at the hardware level? What about 3 1/2 "rigid floppies"? What about magnetic tapes? Cassettes? Peter Jones MAINT@UQAM (514)-282-3542 ----------------------------Original article follows: ------------------ Info-IBMPC Digest Wed, 19 Apr 89 Volume 89 : Issue 41 Today's Editor: Gregory Hicks - Chinhae Korea <COMFLEACT@Taegu-EMH1.army.mil> Today's Topics: ... Possible to write to a "Write Protected" Disk ... ------------------------------ Date: 10 Apr 89 17:44:00 CST From: firstname.lastname@example.org Subject: Possible to write to a "Write Protected" Disk In reference to the sure fire cure for viris problems using a bootable disk in drive A which is "write protected". This write protection is performed in software at some level. It is possible "At least on a Real IBM-AT 6mhz, first rom revision" to write directly to the disk and bypass the write protect mechanism. I do not know how it was done but I know that it can be done, I ran across someone who had written this code so as to be able to write on disks with no notch cut in them... David M. Zielke ARPA==> Zielke@Physics.Rice.Edu Zielke@220.127.116.11 MaBell==> 713-527-8101 ext. 4018 work 713-666-2982 home US Snail==> David M. Zielke, 7490 Brompton #110, Houston, Tx 77025
Please report problems with the web pages to the maintainer