[An earlier message asked, "Why did the Northeast corridor disappear from the Arpanet last weekend? The Network Operations Center said one trunk had been broken, and they were cut off from most everyone, too. I thought there was enough redundancy in the Arpanet to prevent a single trunk from causing such extensive outage...":] At 1:11 AM EST on Friday, AT&T suffered a fiber optics cable break between Newark NJ and White Plains NY. They happen to have routed seven [different] ARPANET trunks [all] through that one fiber optics cable. When the cable was cut, all seven trunks were lost, and the PSNs in the northeast were cut off from the rest of the network. Service was restored by AT&T at 12:12. The MILNET also suffered some trunk outages, but has more redundancy, so it was not partitioned. Andy Malis [Robert W. Baldwin <BALDWIN@XX.LCS.MIT.EDU> noted: This is a classic example of redundancy at one level of abstraction that turns out to be non-redundant at a lower level of abstraction.] [Redundancy works sometimes: I received several copies of Andy's note. Yes, this is a lovely example. By the way, AT&T is laying a fiber-optic cable under the Atlantic. That will provide LOTS of opportunities for virtually distinct paths to co-occupy the same physical channels. PGN]
There was an article in The Independent recently (2nd Dec 1986) about dynamic signature verification and "the arrival of biometrics as a practical security technology". A company called AI Transaction Security from Cambridge have produced a gadget called Securisign, two of which are being used to control access to "a very secure area" at the EEC's headquarters. [EEC is European parliament] The article concluded as follows: "Dynamic signature verification has turned up one disappointment. Researchers originally hoped that signature pads could test the sobriety of people such as nuclear plant operators when they signed on for a shift. However, research shows that most people can sign their names convincingly even when hopelessly drunk". [Copyright (c) 1986 Newspaper Publishing PLC] I found this last comment interesting because the last time this topic came up on RISKS, I recall that the consensus was that the technology did not work because you had to sign your name very carefully, i.e. not when you were "tired and emotional". However, when I showed the article to Brian Randell, he told me the following anecdote: Some years ago, I was involved (in an official capacity) in reviewing a research project, at a Laboratory which I would prefer not to identify, on dynamic signature verification. I was given a demonstration of the system, which involved my being asked to sign my name five times, and then being asked to sign again to confirm that the system had now "learnt" and could recognise my signature. Much to the consternation of the demonstrator, my entirely unpremeditated reaction was to turn to a colleague, and ask him to sign my name. Without any prior warning or practice, he roughly imitated what he could recall of my hand movements, without attempting to reproduce the written appearance of my signature. The machine accepted his efforts as my signature. I was then informed, in tones of considerable embarassment, that in an effort to speed up the demonstration, the thresholds had been set low, and that all would be well if they were reset and I gave an adequate number of signatures. So, they were reset, and I gave (more than) the requested numbers of signatures. To my surprise, the demonstrator expressed surprise when I indicated that I felt it appropriate to repeat my experiment, and again challenged my colleague to repeat his "feat" - something he did immediately and effortlessly! The point of this story is that this struck me as an elementary check to make on dynamic signature verification systems - yet I do not recall ever seeing claims, in any of the (admittedly popular) articles I have read on the topic, regarding the ability of the system to defeat attacks based on seeing how a person signed his/her name. [End of Brian's story]
PGN in RISKS-4.26 > This raises interesting questions about the relative precision, accuracy, > and soundness of "metal algorithms" and comparable analog devices in general. If you change the scene a bit and take a mildly absurd example, you could have the same sort of considerations in a desk lamp - either use a normal passive Anglepoise type, or a hi-tech computer-controlled active servo-postioned type lamp. I'd reckon that the old fashioned lamp would behave itself it power cuts (although not very brightly), electrical storms, glitchy mains periods, the last day of february of the year 2000, etc., whereas I wouldn't be at all surprised if the robot lamp went berserk sometime and brained me or smashed my teeth in because the chap next door started radio broadcasting. For whatever reason - perhaps that we have had such or similar artifacts for centuries - we are confident and "know" that passive devices made of metal tubes and weights and springs are not sensitive to various outside effects which DO affect computers and consequently computer controlled devices, and if only because they behave resonably, (i.e. as we expect them to) such passive devices have a great safety advantage.
Audi did more damage with the '...there isn't anything wrong.' statement than could be done by simply saying they don't know what it is. Statistically, the rate of such accidents with the Audi should be proportional to the rate of such accidents with other vehicles. It obviously is not, leading me to think there's some defect in the engineering of the vehicle. I had a similar problem with an old Ford truck of mine, and it took months for me to figure out that it was due to a defective motor mount. The torque of the engine would lift it off the mount and subsequently pull the accelerator linkage to the floor. A similar oddity could be plaguing the Audis. ...nosc!crash!pnet01!msmiley@NOSC <Matt Smiley> [The summary list of RISKS-4.1 notes that an Audi investigation was reported earlier in Software Engineering Notes, but I just noticed that the reference was wrong: it should have been SEN 11 2 (April 1986). PGN]
From the Los Angeles Times, Dec. 15, 1986 (Reuters): COMPUTER 'HACKERS' HELD IN W. GERMANY WIESBADEN, West Germany -- Police have arrested four computer "hackers" said to have robbed banks in the Frankfurt area of more than $50,000 by manipulating cash dispenser cards with a home computer. Hesse State police said the four, one woman and three men, had been roaming Frankfurt and surrounding towns since May with a computer plugged into the battery of their Mercedes limousine. They were arrested at the end of November. The four hackers bought bank cash cards for $1,500 apiece from their family and friends, who then notified their bank that the cards had been stolen. The four then used their computer to change the codes on the cards' magnetic strip so that they could withdraw more money than the limit set by the cards from automatic tellers, or to tap other accounts. Under a law on computer crime passed last August, the four face jail terms of up to five years if charged and found guilty.
I have noticed a new trend in the way stores imprint credit card slips. In the olden days, the embossed numbers and letters on the card were mechanically transfered to the slip. The only use of the magnetic strip on the back was for verification of the credit limit. I have now seen two stores (including the local Radio Shack) where the mag strip reader feeds data to an electronic cash register which not only dials-up the bank to verify credit but also prints out the slip for the customer to sign. Unless the clerk checks the printed information on the slip against the embossed card, there is no verification of the information. Credit card companies are making it harder to counterfit the embossed information on the cards. But a hardware hack can still build a gizmo for $20 that will copy the magnetic information from a "borrowed" card to his. He then makes sure the other card gets returned so that the bank isn't notified. The hack walks into the Radio Shack, buys $1000 worth of stuff with "his" card, and it gets charged to his friend's account. The only thing to trace him with is the signature on the slip, and it's easy to sign your name so that it's close enough for the clerk but no one will ever trace it to you.
I must have been in the cycle early for McDonald's fast-food intelligent man-machine systems, according to Guthery's law: > In an evolving man-machine system, the man will get > dumber faster than the machine gets smarter. McDonald's fast food computers (i.e., cash registers) collect all sorts of data on the individual employee at the counter and on all counter sales as a whole. They also do not have a <no sale> key that opens up the cash register, probably to prevent theft. That made it real hard to fix a mistake without calling a manager to get a key to open the drawer. Solution? Well, the people I worked with at McD's had been around the system long enough to figure out how to get around it. Without getting into too many details of why things were as they were, the easiest way to open the drawer without a manager was to ring up a sale that gave away a tub of barbecue sauce for McNuggets and nothing else. (Hit <promo> <barbecue> <promo> <total> .) Of course, that messed up the daily statistics some. Edward Vielmetti, Ex-McDonalds employee, Computing Center Microgroup, U. Mich.
plugs Unwanted trash that contaminates output. The classic example is a cheery advertising blurb like "Welcome to MUCUP Version 2.7," which cripples the next program down the pipe. drugs Unwanted features that contaminate specs; something the cat drug in.
At a recent course I heard Jim Gray of Tandem (seriously) describe two more bug types: Heisenbugs: generally transient failure conditions that exist inside systems. ('I can't let you have this resource now because it has been locked'.) Typically, when the operation is retried on another processor, it succeeds because the backup processor is in a different internal state. Bohrbugs: repeatable failures even when retried on another processor. Typically these are 'hard errors'.
"augs" - induced while augmenting a system. "dugs" - added while fixing other bugs, digging the hole deeper. "jugs" - portable bugs, bottled and bonded. "lugs" - which slow down the system [e.g., security features]. "nugs" - little "nuggets" of gold, which didn't pan out. "qugs" - errors in queues that make batch jobs miss deadlines, and print files twice, or not at all. "rugs" - evenly distributed throughout the code, and pervasive. "tugs" - little interfaces which keep big systems in tow. "xugs" - alien bugs [like E-Mail penetrations of UNIX systems]
Please report problems with the web pages to the maintainer