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…
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: zielke@physics.rice.edu
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@128.42.9.23
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