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…
There is also the reverse of the Titanic problem. Sometimes trying to protect against a particular mode of failure that you are very worried about actually makes the overall reliability worse. I'm thinking of the cases where the whole system gets so much more complicated because "fixing" something pushes it over the edge of well understood technology. The aspect of calculating failure probabilities that has always bothered me is that I can't see any way to take into account the things I have totally overlooked, the areas that I haven't even dreamed about. You know, the sort of problem where, after you hear the story, you sigh, and feel sorry of the people involved rather than thinking that they would have noticed the problem if they had been a bit more diligent when testing. Is there any theory in this area? I've helped track down several very obscure bugs in hardware and/or microcode. Each time we finally located a problem, I've been amazed at how easy it was to make it happen. That is after we knew where to poke and had set up the right test programs. Two examples come to mind. Ten years ago, I worked on a PDP-10. At one point, the machine was acting a bit funny. It would run Tenex for days. However, our only big hairy LISP program sometimes got the wrong answer and the bootstrap loader sometimes zeroed itself while it cleared memory. One day, the boot loader trouble got reasonably solid. We wrote a small program to mimic what the it was doing, catch the trap, reconstruct the test sequence, and try again. It didn't fail. We included the previous 6 instructions from the loader into our test sequence. They were doing something totally uninteresting. It failed solidly - every few milliseconds for an hour while we poked around with a scope. We finally found a textbook example of a runt pulse. It was happening just when the end test should decide to stop. (The real problem was a sick power supply.) Several years ago, I was doing a lot of Ethernet tire-kicking. The early Dandelions were coming out of the factory. Everybody was looking for trouble rather then introducing new problems into their code. Things felt pretty solid. One evening, I was testing some transceivers. Nothing interesting was happening, so I connected in another spool of coax. Poof. Lots of packets started falling through the cracks. Simple tests worked 100%, but more complicated tests would miss 50% of the packets. It was a simple timing problem. If a packet started arriving while the microcode was preloading the transmit FIFO, the microcode/hardware discarded the input packet as it disabled the transmitter while switching modes to go inspect the input packet. By inserting the extra coax, I had increased the delays enough to drop a packet right into the window. PS: I second Earl Boebert's recommendation for John Gall's Systemantics. If only I could remember all his lessons that seem so simple and obvious while reading about them.... [Maybe you could be COAXed. PGN]
I suppose if I had said to the designer of the Titanic: "Yes, the worse maritime accident on record involved the breaching of four watertight compartments, SO LET'S PLAN ON SURVIVING FIVE," the designer would have specified smaller compartments, so that the Titanic would have had eighteen, not sixteen, compartments. And the iceberg would have ruptured six compartments...
Some years ago the ARPANet Network Control Center (NCC) at BBN was tasked to check periodically that each dialup line to each TIPs was in fact functional. Absent such a check, a TIP port could be non-operational for a long time before anyone would notice. To make the check, a computer at NCC was connected to an outward WATS line and programmed to call every TIP line around the country periodically, every week or so, to be sure it could properly connect to a modem. For a busy signal or other failure to handshake with a modem, the program would retry a few times and then alert a human being about a possible problem. Then a person at the TIP site would be asked to check the line there. All this was OK, and it worked just fine. Once, however, by some accident, the computer was connected to an ordinary phone line rather than to the outward WATS line. The first indication BBN had about this disaster occured when the phone bill came, in a cardboard box, with some three inches thickness of call itemization slips for all those calls. I don't remember the total, but I do remember that it attracted a *lot* of attention at very high management levels. There was much discussion about whether the improper phone connection was BBN's error or the phone company's; I think a compromise was eventually worked out. A nice check was immediately added to the whole system. The outward WATS line had the property that it could be used to call anywhere in the 48 contiguous states except Massachusetts (which is where BBN is). Thereafter, each night the program placed the first call to a Massachusetts modem. If that call worked, the run immediately aborted and a human was notified that some line other than the proper WATS line was in use. A lot of problems are easy to solve, once you know what the problem is. Art Evans
Modems and calling software should treat as special the case that the phone on the receiving end goes off hook, but no carrier is detected. This means either that (1) a person has picked up the phone, or (2) there is some incompatibility between the calling and answering modems, or (3) there is a bad connection. (3) should also be detectable to a modem (is this true?), so we eliminate it from the special case. In the special case the calling software should retry the number a very few times, then call for human intervention. Unfortunately, the ultra-standard Hayes Smartmodem 1200 cannot distinguish between various NO CARRIER conditions at all, much less distinguish (3) from (1) and (2). Better (smarter) modems are needed before the calling software can deal with this special case, and stop its modems from accidentally torturing people. ---- Sam Kendall allegra \ Delft Consulting Corp. seismo!cmcl2 ! delftcc!sam +1 212 243-8700 ihnp4 / ARPA: delftcc!sam@nyu.ARPA
While setting up a link to a new system, I entered the phone number incorrectly. I failed to connect when the machine attempted to do the call. Being very suspect of myself (on the first call), I dialed the number the machine was attempting to call. A person answered, and I attempted to determine the phone number she was at. This number was not the same number I was dialing. I then called the operator (good old AT&T), and asked what was going on. The operator dialed the same number, got the same person on the line, and verified the number was different. We worked on the crossed lines problem for 2 days. The final solution was not crossed lines, but the fact that multiple numbers connected to ONE phone. Sadly, neither the operator, nor the person answering the phone, had any idea that multiple phone numbers went to the same physical unit. How many phones sit on your desk. How many phone numbers will it ring to. Are you really sure? -- David Barto, Celerity Computing, San Diego Ca, (619) 271-9940 decvax-\ bang-\ ARPA: celerity!barto@sdcsvax.ARPA ucbvax-->-sdcsvax->!celerity!barto ihnp4--/ akgua-/ "Moderation in all things, including moderation" [Including net addresses? PGN]
Once upon a time, early in the days of my computer-life, I worked late. I told my Z-120 to tell my Hayes to call a number. It did, and I heard the ring, and then the answer. No whistle-hiss-CONNECT, but a quavery young female voice saying, "Hello?... " I sent three pluses and an ATH to the Hayes, read the (wrong) number off the screen, and dialed it on my voice phone. I wanted to render immediate and abject apologies. The phone rang and rang. I redialed, in case I had incorrectly dialed the wrong wrong number. It rang and rang. I quit. There was no way to un-scare that young woman. I have been much more careful since then - but still ring a wrong number now and then. If it is during the day I voice-phone to apologize. If it is in the wee hours, I just say a prayer for that person's serenity, and mine, and go on. It seems common courtesy to check all supposed "computer phones" by voice, by day, prior to using them in an auto-dial mode. The computer doesn't lie awake at night wondering what wierdo is ringing the phone and hanging up. - Mike McLaughlin
In my experience, battery backup for computer systems is usually of extremely limited capacity (an hour or two) when you're talking about a large computer center with lots of power-hungry disks and so forth. Frequently, the amount of battery storage capacity is enough to permit the system operators to shut down their machines in a graceful fashion, and requeue any work-in-progress for processing when the AC mains come back up. Sites that absolutely require uninterruptable power generally have backup diesel generators... they're much smaller per kilowatt than batteries would be, and can run for days at a time as long as you keep feeding them fuel. I'm not sure what would happen to the NYSE if there were a two-day blackout in New York. There was an extensive blackout (six hours or so???) back in the 60's, I seem to recall... but it was shorter than the one that you're speaking of, and the NYSE is probably much more dependent on computers than it was twenty years ago. I imagine that they'd probably have to shut down. I read a book recently that might be of some interest to Risks readers, as it addresses the problems of centralized data transmission and storage to some extent. The book is "Night of Power", by Spider Robinson; it's fictional, borderline SF [by my standards... open to dissent], and revolves around the seizure of Manhattan Island (and the East Coast's major satellite uplink) during a social revolution in the 1990's. The point was made that the seizure of the uplink could easily have resulted in a major collapse of the world's interlinked financial systems, if the data flowing through the link were to be cut off or corrupted.
GAAK! Maybe I'm misunderstanding [Larry Polnicky], or the systems actually used in the computerized voting booths... but I had always believed that the voting systems in this country [paper, computer-based, or whatever] were designed to GUARANTEE A SECRET BALLOT! I've NEVER heard of a public-voting system that was designed to permit anyone to identify a particular vote, or set of votes, with a particular voter. There is a longstanding tradition in this country of guaranteeing that an individual can vote his or her conscience, without being identified afterwards as "the person who voted for Smidget for Congress". There have been plenty of examples in the past of the problems that can occur when a person's votes are not kept secret. Both in this country, and in numerous countries overseas, people who have voted the "wrong way" (usually against a clique in power) have been pressured, fired from their jobs, beaten, tortured, or killed. I would strongly resist any computerized (or paper) voting system that would make any votor's voting record identifiable to *anyone* without that votor's explicit approval. Note here that I'm not talking about voting systems such as Congress uses, in which the public has an explicit right to know who voted for & against what. In systems such as this, it's fine to have records kept, and some sort of accuracy/accountability audit... but by their very nature, these systems are generally much smaller than state-wide or national voting systems, and are thus less likely to be subject to large-scale fraud. [Even in paper ballot systems, there is usually a serial number which provides a back-link from the voter to the ballot. Otherwise fraud is far too easy, with mystery ballots appearing out of nowhere. But recall the earlier Phillipine election in which a local power failure downed the central ballot-counting computer, which upon reboot immediately finished the ballot counting. Somebody has to be trusted somewhere. There is a choice as to whom the trust must be given. PGN]
In response to the DES item, the National Security Agency and other US intelligence services have conducted numerous signal intercept exercises throughout the US. The results of such exercises are for good reasons classified under national security directives. Readers Digest, however, which obviously has good connections, has published several articles during the last 5 years describing the threat from foreign intelligence services as well as from industrial espionage. IEEE Spectrum publication had an excellent article, "Thwarting the Information Thieves," in its Jul 85 edition. Presently under Fed Standard 1027 DES devices are export controlled items. This would means that US firms who build such encryption hardware must obtain an export license before any foreign sale. Since NSA is the author of the Standard, their position would seem to be consistent. IBM of course does sell and build DES devices, and its personnel developed the algorithm upon which DES is based. Therefore, their position would seem to be consistent. Chris McDonald White Sands Missile Range
Please report problems with the web pages to the maintainer