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…
An AT&T crew removing an old cable in Newark NJ accidentally severed a fiber-optic cable carrying more than 100,000 calls. Starting at 9:30am on 4 Jan 91, effects included shutdown of the New York Mercantile Exchange, several commodities exchanges, disruption of FAA air-traffic control communication in NY, Washington and Boston, causing lengthy flight delays at those and impinging airports, and blockage of 60% of long-distance telephone calls into and out of NY, for much of the day. (AP, 5 Jan 91). This came as we approach the anniversary of the 15 Jan 90 nine-hour outage due to a self-propagating bug in the recovery software.
An article in `The Irish Times' Jan 3 states that extremely sensitive information relating to British military operations in the Gulf may still be on a computer which was stolen from a staff car beloning to Wing Commander David Farquhar on December 17th. The laptop was stolen along with some documents. The documents were later found in a skip, but the computer is still missing. Presumably the inherent value of the computer made the thief keep it. Charles Bryant (ch@dce.ie) [A skip is an open-top container for rubbish (garbage) which is about the size of a small car and is delivered and collected by a special type of vehicle. It must be called something different in the US.] [Dumpster]
I too am concerned at the seemingly naive acceptance by the Department of Defense of the trustworthiness of simulated combat. Others have pointed out that the military cheat at war games, citing especially the Battle of Midway. That is a clear risk. As another example, the German General Staff often gamed the Schlieffen Plan, and also often cheated. However, there is in my opinion a further, and equally significant risk, even in an honestly conducted simulation, and that is the risk that the simulation incorporate some fallacy critical to the simulated outcome. As an example, consider how, in the 1930s, a possible German invasion of France would be gamed. On the map, the Ardennes would be clearly labelled 'heavily wooded: impassable to tanks', as was the general opinion of the time. A German player who attempted an armoured breakthrough at that point would be immediately stopped by the referee, and informed of his rule violation. But we all know what happenned in 1940. To relate this to today: the performance figures for military tanks, helicopters, aeroplanes &c are usually taken either from nominal specifications or from the results of field exercises in temperate terrain. However, for the present terrain and climate, values for speed, range, manoeuverability and endurance should be adjusted downwards, by some unknown but probably drastic amount. Has this been done? If so, where did the numbers come from? Robert Firth
Actually, I believe that elevators with mechanical door sensors (strips)
are also programmed to override the sensors and close anyway after a
certain number of tries. (I know for sure that the ones in Wean Hall at
CMU do this; they are of '60s vintage. They even have the warning buzz
you describe.) The reasoning, presumably, is the same as you gave: to
defend against sensor failures and denial-of-service attacks.
However, the door closing mechanisms (at least at Wean Hall) are not
strong enough to actually hurt a person; in fact they can be forced back
by a reasonably determined push. This strikes me as a far better failsafe
design than relying on a backup sensor, which is what I think you are
advocating. (Think about common-mode failures...) The doors *are* strong
enough to be uncomfortable, which I'm sure is deliberate.
Of course, that's not to say that the elevator you encountered is actually
designed properly; but the mere use of electrical rather than mechanical
sensors does not seem to me to increase the risk in a properly designed
system. Mechanical sensors fail, too.
tom lane
...!cs.cmu.edu!tgl tgl%cs.cmu.edu@cmuccvma >internet:tgl@cs.cmu.edu
On some elevators this sensor is not a discrete strip, but is built into the seemingly rigid edge of one of the two layers of door. Either it senses flexing of the edge, or it senses resistance to the door being closed; I can't tell which. It does require more force to operate than the traditional rubber strip, but not so much as to make a "meaningful attempt to crush" the user. Perhaps the elevator in question actually had this type of sensor, but it was not working. Mark Brader, SoftQuad Inc., Toronto, utzoo!sq!msb, msb@sq.com
The University of Illinois is suing Otis Elevator because of a pair of these hungry elevators. They've bitten a few people, most notably people pushing computers and/or huge boxes onto and off of the elevator.
Curtis Jackson writes about elevator doors that close, regardless of who's in
the way. I know of such elevators, too. (Incidentally, they may use some
other sensing mechanism like micro-switches rather than mechanical panels or
light beams; an elevator engineer once told me that some elevators use
micro-switches in the floor to estimate load and then adjust motor settings
accordingly.)
The elevator doors I have seen withdraw several times before becoming
insistent, then slowly beep their way closed. This, however, is always
followed a few seconds later by a voice on the intercom from a guard downstairs
asking if anything is wrong. A human gets into the loop. Guards are always on
duty, though I don't know what controls over the elevator they might have from
their station.
Jake <AKE@DBCLUA>
Darrell D. E. Long writes of thoughtlessly-designed billing software that assumes that all people have only one middle initial. This is not, as he implies, only a risk of old COBOL programs. Instead, he has identified one aspect of a larger ongoing problem: balancing the desire to edit to ensure data validity against the need for sufficient flexibility to accomodate unusual cases. Within the past year alone I have had to argue against system designs that would assume that: - All names look like "Given I. Family" (I have no middle initial, and my SE has only one name. Many of our customers prefer their family name printed first) - All children share their parents' family name - Leading zeros should never print (There are both post-office boxes and street addresses in Portland, Oregon that have significant leading zeros, that is, the same number without the leading zero represents a different address) - Zipcodes are always 5 (or 9) digits (non-USA zipcodes?) - Names never contain special characters (Hyphens? Also, some businesses have exclamation points and numbers in their names) - All names start with a capital letter followed by lower case (I know of at least one person whose name starts with a lower case and contains an embedded upper case. I know of another whose full name is III, pronounced "three") For the applications I most frequently work with - business systems for a public utility - I try to keep limiting assumptions about personal information (names, addresses) to a minimum, and to edit with warnings that can be overridden. Our customers will forgive a one-time error far more quickly than they will forgive our inability to correct that error. Karen Ward (wardk@cse.ogi.edu)
> ...Red Force electronic warfare is reduced or eliminated because its > success causes a complete breakdown in exercise force command and > control... After a discussion several years ago on a vaguely similar theme, I had a bit of correspondence with a fellow who'd spent some time in electronic warfare in the Army. (I suspect I should not identify him.) He said that they were normally under severe restrictions in what they could do as part of field exercises, and as a result the folks who were supposed to benefit from said exercises had gotten very blase' about communications practices and the like. Then the EW people, after a lot of begging and pleading, got permission to take the gloves off just once and show the commanders what serious EW could do. His summary of the results: "we paralyzed them". Henry Spencer at U of Toronto Zoology henry@zoo.toronto.edu utzoo!henry
I've been a packrat for most of my life and I've done historical research and I've worked with databases. But I'm finding it very hard to mourn the *general problem* of fading and decomposing magnetic media. For one thing, the data is meaningless if you don't know how it was collected. NASA has zillions of tapes, but do we really know how all of that data was collected? Which sensor? What setting? Once this information is lost, the data itself is just a tombstone. For another thing, data has no value for its own sake. If there's a researcher that can use some of the computer readable data out there, then that's great. But I don't think we should save every last byte "just in case" someone wants to use it in their dissertation on rat populations in rural Podunk. The pot only holds so much. What do we discard instead? Sure, we should save what is "reasonable." For lack of a better measure, let's save what people will use. For example, we might want to establish a "computer research data recovery fund" which paid the costs for grad students to recover "threatened" digital data and use it in their research. The costs would pay for converting the data to work on the researcher's PC or whatever and for a copy of the data in an archival format. This is somewhat similar to the way that various (usually state) historical societies are making microfilm collections of community newspapers. I don't know what a good "archival format" would be, however. I read recent descriptions of de-lamination problems with CDs, and I have personal experience with the unreliability of paper tape ... Rick Arden Hills, Secure Computing Technology Corporation, Minnesota
I am currently the sustaining software engineer for the product mentioned by zowie in his posting (11-25-90), and I wanted to clarify some things. He was disturbed by hearing modem tones during an ATM card activation at a Wells Fargo Bank branch. In fact, recording the 300 BAUD transaction (or tapping the phone line) would not reveal his friend's PIN. The PIN is encrypted by the terminal, using DES and a "Unique Key Per Transaction (UKPT)" algorithm (our newer terminals conform to ANSI 9-24, Wells Fargo still uses some older terminals that predate 9-24 with a psuedo UKPT). Once the transaction is reported to the host, a hardware security box translates the PIN from the terminal's key to some irrreversible internal format. Once the PIN is entered into the terminal, it never appears in the clear (that is to say unencrypted) in any computer. This is much better than the usual situation, where you would either be assigned a PIN, or have to write down your PIN and have somebody enter it for you. If anybody would like more details on the process, feel free to contact me. Michael McKay (MCKAY_MICHAEL @ tandem.com) (408) 435-8850 US MAIL: Atalla, A Tandem Company, 2304 Zanker Road, San Jose, CA 95131
We were driving at 70 mph [automatic transmission, new car < 1 K
miles]. All of a sudden the speedometer cable got cut [I believe] and
the needle fell back to 0 mph. In addition there was a heavy noise and
could feel the drag on the engine. I pulled out, put it in neutral and
raised the engine hood. Nothing wrong with the engine. All other things were
OK. Car moved without much problem up to 15 mph. Beyond that it felt
like driving at Ist gear. Auto mechanic checked it too. Conclusion:
"Either auto transmission or fuel injection system is taking the input/cue from
the speedometer. They think the car is at a lower speed and act accordingly"
Could someone explain the situation?
We could have got into a major accident. Sure, the cause of the accident would
have been careless driver.... When I called the rental company for
replacement, they could not locate my file on the computer [god knows why] and
it took three hours ........
-balakumar pbk@cs.cmu.edu
[Please respond directly to balakumar, unless this really is a
computer-related problem. Otherwise, try the two brothers in Boston
on NPR. PGN]
Please report problems with the web pages to the maintainer