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…
A political scandal, known variously as ``Trentongate'' or ``Computergate'', is
brewing here in New Jersey. A staff member employed by the Republicans in the
state legislature has admitted to breaking into a computer system used by the
Democrats; reportedly, the number of documents obtained is in the thousands.
His activities were known to the staff director; he recently admitted as much
and resigned. But the Democrats aren't making too much of a fuss over this --
allegedly, they don't want the contents of the filched documents disclosed,
since they are reported to deal with improper use of state facilities for
political purposes. (Were Nixon's tapes 9-track, and was the 18 minute gap
really part of the tape drive error recovery processing...? And Haig's
``sinister force'' was just an ordinary reboot.)
--Steve Bellovin
/
[Donkey haute and pancho sans a ba(s)bar tilting at winned spills?
(Please pardon my espanofranglais, Sir Vantes!) PGN]
A 1% error in the British RPI cost the government 121M pounds in compenstation to pension and benefit losers, donations to charities, and administrative costs. The problem was discovered after a computer error caused the RPI to be understated from February 1986 to October 1987. The programs had been tested, but the tests did not reveal the error. Source: Computing (UK), 20 September 1990, submitted via airmail by Dorothy R. Graham, Grove Consultants, 40 Ryles Park Rd., Macclesfield, Cheshire SK11 8AH.
The San Francisco Chronicle had a front page article today (09/20) headlined:
High-Tech Advertising
Better Junk in New Junk Mail
A few quotes:
Junk mail is going high tech.
Across the nation, well-heeled consumers are being bombarded with
expensive computer diskettes, elaborate video-tapes of car
commercials and even catalogs that play Christmas carols. ...
+ Compaq Computers mailed 40,000 floppy disks to possible
customers last summer to introduce a new line of computers that
cost as much as $20,000. ...
Kevin Bohren, a spokesman for Compaq Computers in Houston, said
his company tripled its response rate last year when it mailed
"interactive diskettes" as a promotion for its new line of
personal computers. "People responded because we weren't just
sending out another pamphlet," he said.
If people become accustomed to inserting every floppy received in the mail into
their computers thinking that it is just another form of advertising, the risk
of viruses spreading will increase rapidly. A few thousand deviant floppies
sent to several large corporations and schools will produce marvelous results.
An AP item today was called to my attention, datelined CHICAGO (AP).
"Thank you for calling Telequiz. After the tone, please leave the
answers to your college exam."
In what is believed to be the national debut of student testing via
push-button phone, students at Governors State University telephoned in the
answers to their Psychology 519 quiz from the comfort of home.
[True-false answers are recorded with computerized voice-mail equipment. A
professor was quoted as how this saves everyone time, effort, and travel, and
provides considerable convenience because students can be tested when they wish
-- although in its present implementation only one student can call in at a
time. No reentrant exam programs (as opposed to reentrance exams) yet! RISKS
readers do not need to be reminded of the security/integrity problems. PGN]
I'm amazed by recent references to Sun's "C2" system. What system is this? There has been no Sun product evaluated by the National Computer Security Center, so there is no such thing as a "Sun C2 system". Like the Good Housekeeping Seal of Approval can be awarded by only Good Housekeeping, a rating against the Trusted Computer System Evaluation Criteria (the Orange Book, which defines C2 and the other levels of trust) can be awarded only by the National Computer Security Center, which authored the Orange Book. Each product which has been evaluated and thus earned a rating is announced in the Information Systems Security Products and Services Catalog, chapter four, the Evaluated Products List. So if you are in doubt in future, check this source. Anything not in there is, at best, DESIGNED TO MEET C2. At worst, it provides no trust at all. Don't be misled by premature or misleading claims. Relying on false security is far more dangerous than having no security - at least in the latter case you stay on guard!
Nearly twenty years ago David Wheeler of Cambridge University, lectured here on this subject in our Annual International Seminar on the Teaching of Computing Science at University Level (7-10 Sept. 1971). RISKS readers might enjoy this quote from the Seminar Report: "The Problem of Synchronisation Dr Wheeler devoted the rest of his talk to a discussion of a particular problem in logical design. He chose to do this, rather than give a more general talk, because he considers that discussion of this point should form part of every course on hardware or logical design. His reasons for emphasising this point, which he calls the problem of synchronisation, are as follows: (a) Many existing computers have faults because of neglect of this point. (Dr Wheeler found that at least 50% of the computers whose logical design he has studied in detail have faults of this kind.) (b) The point is rarely taught well and only occasionally appears in text books. (c) It is apparently difficult to to appreciate. Furthermore, people trained in switching theory or logical design find it especially difficult. (d) The problem is general. It is common to all forms of logic and may also be present in systems programs. It touches many disciplines, for example circuit theory, logical design, systems programming and information theory. (e) The occasional malfunctioning of all practical computers and peripherals is to be expected if this point is neglected." [The report then goes on to give a detailed account of David Wheeler's lecture.] (Younger RISKS readers may not be aware that David Wheeler, who I'm pleased to say is still very active, was in 1949/50 the principal source of such concepts as closed subroutines, assemblers, post mortems, and much else, in his pioneering programming work on EDSAC, and went on to do much hardware design, for example of EDSAC2 and of the Cambridge Ring.) Brian Randell, Computing Laboratory, University of Newcastle upon Tyne, UK PHONE = +44 91 222 7923 FAX = +44 91 222 8232 Brian.Randell@newcastle.ac.uk
[Quoted from the referenced article by jaffe@safety.ICS.UCI.EDU] >The point is that the issue of designing Aegis to handle commercial flight data >was addressed and rejected as not cost-effective. Whether one agrees with this >specific decision or not, the general point is that no military system (or any >system) can be designed to deal with all contigencies that someone thinks of as >appropriate. The point is, I don't think Aegis had to be designed to keep track of all aerial traffic in the area; I'm pretty sure that *Air Force* systems in the area did have a positive ID on everything that was flying at the time. The trouble is, I also suspect that there was no way the captain could just call somebody and ask "Hey, what's that on my screen?" Amos Shapir, National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522255 TWX: 33691, fax: +972-52-558322 amos@nsc.nsc.com
The renewed discussion of the Vincennes incident brought back some 25-year-
old memories about displaying aircraft tracking data. I don't think this
problem has been discussed in RISKS (at least not recently):
The risk of displaying data that was computed for a different purpose.
*I have no reason to believe that there's any direct connection between
the following story and the Aegis system--I'm only saying that the Aegis
developers must have faced the same kind of problems.*
At that time, I was supporting myself in graduate school by programming
for a major aerospace manufacturer. I worked on a weapons guidance system
that I've heard is still used in top-of-the-line US combat aircraft.
I was responsible for displaying the tracking data. Newsweek published
a picture of an Aegis display that included the same track symbols as we
were using, but that probably just means they are some kind of a military
standard.
Before testing our software with real sensor data, we ran numerous tests
with simulated data. It quickly became apparent that the velocity displays
were unacceptably erratic, and didn't have much connection to the velocities
of the simulated targets. So we simplified the data to a single target
moving in a straight line with no acceleration. Still looked awful.
So we reduced the simulated sensor noise, and finally eliminated it.
The velocity display was a lot smoother, but it showed target velocities
and maneuvers that just weren't in the input.
Finally I decided to do a little mathematical analysis. I was able to
identify two sources of error in the second-order difference equations used
to smooth and extrapolate track data:
- Sensor data was supplied in polar coordinates, and all calculations
were done in polar coordinates. In general, unaccelerated straight-line
motion produces non-zero derivatives of all orders in polar coordinates.
At the ranges and velocities for which the system was designed, these
virtual velocities and accelerations were not negligible.
- The smoothing algorithm initialized the first and second difference
estimates on all coordinates of a track to 0. At the ranges and
velocities for which the system was designed, the differences could
start from zero, overshoot, overshoot in the other direction, ... and
not stabilize within the time a straight-line target remained in range.
I was able to show that a straight-line target 60 miles away that was moving
perpendicular to the tracking plane could have an indicated velocity 90
degrees off its true velocity, i.e., the display would show its velocity
as being straight towards the tracking plane. I didn't think that such
a velocity display was likely to help the Missile Control Officer make
good decisions.
Our department was only responsible for the software. I wrote up my
analysis, including a demonstration of the improvements that would result
from smoothing and extrapolating in a cartesian coordinate system and from
initializing the differences more reasonably. I sent my analysis off to
the department that had supplied the smoothing algorithm, feeling very
proud of my young self for having caught the problem and figured out the
solution before it caused any real trouble. But the answer from that
department was: "We don't understand your mathematics. We optimized the
algorithm using Z-transforms, and it's not your job to second-guess us."
(This was one of several reasons why my career in aerospace was brief.)
Later, I learned that the algorithm was not as unreasonable as it had seemed
to me. The primary purpose for maintaining the track files was to lock
a missile's sensors onto a particular target before launch, and the sensors
had to be aimed in polar coordinates.
The real problem was that someone designing the man-machine interface had
seen that the track file format contained fields R, RDOT, RDDOT, etc.,
and decided that, since the velocity information was available, it would
be a good idea to display it for the MCO. But it wasn't a good estimator
of velocity, and was never designed to be.
To me it is entirely plausible that the junior officer on the Vincennes who
made errors in reading the altitude and speed of the approaching aircraft was
in fact being misled by the displayed velocity, and not just by stress. I
doubt that the logging data for the Aegis records enough of what is displayed
at each instant to settle this. Doubtless some readers of RISKS know enough
about the Aegis software to know whether this is possible, but they may not be
free to comment on the subject.
Jim H.
Various people have commented on Vincennes incident without noting the applicable international law. This law, which has counterparts running back over a century, places the responsibility for identification upon the *CIVILIAN*. The military is permitted to presume hostile intent from all unidentified people or things in a combat area. The civilians must demonstrate by words and actions that they are non-combatant. Transponder codes are explicitly listed as not sufficient. In the particular case of the Vincennes, the military did comply with the law by issuing a challenge and demand for course change. Unfortunately the aircraft ignored this challenge (probably because it was to ``unidentified aircraft'' and in nautical phraseology). And for these reasons there has been no real effort to condemn the action in any court of international law. This is not to say that problems and errors did not occur. One problem that an expert system might have resolved would be a more universal and internationally understandable challenge terminology. It took the shooting down of two airliners by the Soviets to force general installation of mutually usable radios in both military and civilian aircraft. This accident reveals that despite mutually usable radios, there remain significant communications difficulties. (Not the original mentioned use for expert systems, but much easier and well within the present state of the art.) The other risk that this shows is the danger of fundamental ignorance of overall environment. International law and treaties do exist, and do matter, but both within this group and within the developers of the expert systems there is profound ignorance of these rules. When the rules are in software or hardware what do you do when treaties change? R Horn horn%hydra@polaroid.com
Not attempting to address other issues involved in the article by Perry Morrison in comp.risks 10.40, I would like to simply point out that the space shuttle has had many more successful launches than any other launch system employed to date. The shuttle, as a whole, is extremely reliable... it can only be considered a failure in comparison with the outrageous levels of reliability *claimed* for it by NASA prior to the Challenger accident.
> The bill from Illinois Bell should have read $87.98, not $8,709,800.33.
Hmph. That's only 5 orders of magnitude.
Mark Brader, Toronto utzoo!sq!msb, msb@sq.com
[So what's an order of magnitude here or there?
Thank goodness it wasn't an earthquate. PGN]
Please report problems with the web pages to the maintainer