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…
My sincere regrets for the annoyance to you (and to me receiving triple the BARFMAIL) for the multiple mailing of RISKS-9.23 — especially when that issue contained an explanation for the fact that readers received from ZERO to as many as (at least) 12 copies of RISKS-9.22. The problem this time was NOT the long-list time-out problem, but rather the crash-in-the-middle problem with TWO server crashes, resulting in many of you getting THREE copies. (Strangely, a few of you apparently got MORE!) Although the first of yesterday's two crashes was accidentally human induced, the second was intentional, necessary for our wizard to unwedge a serious catastrophe that had downed an entire subnet of machines for most of the day. But these were circumstances vastly beyond my control — which is very annoying for someone who really tries to do things carefully. There are some strong lessons for RISKS readers. Distributed systems are full of tricky problems (synchronization, timing, distributed atomicity, recovery, fault tolerance, security, etc.) that are very demanding. Furthermore, even if everything were done right in the first place (which is most unlikely), there would still be extreme difficulties in ensuring that such systems would continue to work dependably in the presence of on-line evolutionary development. It is important that computer researchers and developers be subjected to the use of the systems and networks that they develop, under really stressed conditions. Even then there will be lurking problems that are not triggered. So, it is time for some widely used really rugged, secure network software that is hardware-fault tolerant and system-crash-tolerant. For example, SENDMAIL should be resistant to time-outs, system crashes, certain human screwups, debug option attacks, etc. (Maybe such a version already exists?) Overall, you RISKS folks, whose awareness is already heightened, need to play a stronger role in ensuring that R&D is really concerned about stringent requirements. [End of SoapBox] Peter P.S. In case you were wondering, I have no intention of making a career of writing notes to RISKS explaining new ways for you to get multiple copies. But I certainly hope this does not recur. [ReCur ==> doggedly persistent ? No, I do not want to be a REcur of havoc. And NO, I am not trying to overflow the mailboxes of private subscribers so that they will cancel their subscriptions.]
Your story of the sendmail bug reminded me of a somewhat similar bug in the UUCP network smart mailer program SMAIL. As nearly as I can tell, if there is an address that needs automatic resolution near the end of an alias file with many (~100) addresses, *that* recipient receives one copy of the mailing, but a few of the other recipients in that part of the file get an extra copy. Not nearly as extreme as the sendmail problem, but an irritant nonetheless. Had you split the RISKS list BEFORE sending out the previous digest, would it have been a 22 twain? Scott Hazen Mueller, Ardent Customer Support (408) 732-0400 x336 uunet!ardent!scott
>From SCIENCE Vol 245, 8 September 1989 p1045 On 27 March ... the spacecraft was passing near Phobos for what was, by then a routine session of imaging. "It was on automatic operation" he [Kremnev, director of the soviet spacecraft manufacturing plant] said. "To conserve energy, the transmitter was off during imaging. But at the time it was due to restart, no signal was heard on Earth." the control group hurriedly sent up emergency commands," Kremnev said, and they indeed were able to reestablish contact. "They got 17 minutes of telemetry data. But the spacecraft was tumbling so that the only communication was through the spacecraft's small antenna.. Therefore they couldn't decipher the telemetry. Then they lost the telemetry". Phobos 2 was never heard from again. But since then, said Kremnev, "Considerable time has been taken, and we have been successful in deciphering the telemetry." There is now no doubt that the failure lay in the spacecraft's on board computer, he said, and was not due to, say, a meteoroid collision. "after the failure of Phobos," he said, "People at Babakan said 'We have luck only with women - not spacecraft!'" Kremnev also offered new details as to how the Phobos 1 spacecraft was lost last year on the way to Mars. As part of the ground checkout prior to launch, he said, the spacecraft computer had been loaded with a program for testing its steering. Once the test was completed, of course, the program was no long[er] needed. However it was in "firmware" - read-only memory - which could only be cleared with special electronics equipment. "We would have had to remove the computer from the spacecraft and take it to the people who could do it," said Kremnev. "[But] we had VERY little time before the voyage. So the program was 'locked in a safe.'" That is, it was sealed off and rendered harmless by other software in the spacecraft computer. Unfortunately, said Kremnev, "the key was found to unlock the safe." On 29 August 1988, not long after launch, a ground controller omitted a single letter in a series of digital commands sent to the spacecraft. And by malignant bad luck, that omission caused the code to be mistranslated in just such a way as to trigger the test sequence. Phobos 1 went into a tumble that was not noticed until the next attempt at contact, 2 days later. It was never recovered. Kremnev said that future versions will have more on-board safeguards. And what happened to the controller who made the error? Well Kremnev told SCIENCE with a dour expression, he did not go to jail or to Siberia. In fact, it was he who eventually tracked down the error in the code. Nontheless, said Kremnev, "he was not able to participate in the later operation of Phobos" Ralph Hartley
A previous RISKS posting suggested that aircraft be programmed to simulate various flight conditions for "practice" while in "routine flight", but stressed the importance of not confusing reality and simulation. How about deliberately confusing the two - a pilot in an emergency situation would not know if it was real or simulation, and could therefore be expected to behave in a calm, professional manner without panic. (Sort of like not telling school children if the fire bell is a true alarm or a drill). The computer would record response to simulated emergencies for review and evaluations by the rear echelon boys. There is also a vast untapped market for an "aircraft passenger simulator". (get come cramped seats, small rest rooms, hard to view movies and poor food for a few hours). The market would be large, and there are many more aircraft passengers than there are pilots. Rob Boudrie
Digital Speed Limit Signs Malfunction, Set 75 mph Pace on New Jersey Turnpike NEWARK, N.J. (AP) - New Jersey native Bruce Springsteen's fabled muscle cars might have a field day on the state's turnpike these days, where digital speed limit signs are mistakenly sanctioning speeds of 75 mph. State police and turnpike authority officials said the erroneous speed limit has been showing up on about half a dozen of the signs in northern New Jersey because of a computer programming error. The legal limit is 55 mph. Gordon Hector, a spokesman for the authority, says technicians were trying to correct the problem. He said workers have also been correcting the signs manually while technicians ponder the trouble. Meanwhile, some motorists found the problem amusing. "It was kind of strange to see everybody below the speed limit for a change," joked Casey Raskob, a Springfield, N.J. attorney. A state police spokesman, who asked not to be identified, said no traffic problems were reported as result. "But I don't think any judge is gonna buy that excuse," he said.
In RISKS 9.23, Frank Houston, discussing the accreditation of professionals, writes: The ultimate lever for accreditation [in the medical domain] is the willingness of paying customers, Medicare, to accept accreditation as a sufficient guarantee of quality service. I suggest that this is an understatement. A stronger phrasing would be The ultimate lever for accreditation is the action of government in defining non-accreditation as proof of the absence of quality, and, ultimately, banning non-accredited service on that basis. That's the way it works in U.S. medicine. First, it's not that Medicare accepts accreditation as quality-proof, but will accept real proof too — rather they accept (as I understand it) _only_ accreditation. Second, there's the crime of "practicing medicine without a license."
I was kind of watching Mission Impossible the other night (the episode had something to do with a "man of 1000" disguises trying to frame the gray haired guy). For some reason the MI team wanted to access to the personnel records of a facility (a prison?). The electronic/computer penetration whiz (the black fellow) says "Unfortunately, they're not on a computer system so I can't break into the records [or words to that effect]." The MI team go on to get the records in a more mundane way (impersonation, breaking and entering, etc). I was pleased to note the general effect of stating that computerized record keeping was a security risk especially with regards to penetration from outside the physical facility. This mention of "computer fallibility" is a positive change in the entertainment industry. This message will self-destruct in five minutes.... ;-) Benjamin Ellsworth, Hewlett-Packard Company All relevant disclaimers apply.
Working Group for IEEE Software Safety Standard Organizational Meeting October 2 & 3, 1989; McLean, Virginia (703) 883 5631 or (703) 883 6086 ++++++++++++++++++ This is the first meeting of the working group. We will form working committees and identify major subareas for an IEEE draft standard on software safety. Dr. Nancy Levenson will present a background briefing. You are encouraged to attend if you want to be a working member of the standards drafting group. Please post this message and forward as appropriate. * * Details as to times, locations, local hotel arrangements, and a written agenda may be obtained from: Cynthia Wright, SSWG Chair at (703) 883 5631 CWRIGHT@MDF.MITRE.ORG or Tony Zawilski, SSWG Vice Chair at (703) 883 6086 M16143@MWVM.MITRE.ORG
Dates: October 10-13, 1989 Place: Baltimore Convention Center Registration: 12th National Computer Security Conference c/o Office of the Comptroller National Institute of Standards and Technology A807, Administration Building Gaithersburg, MD 20899 Payment: $150.00 before September 25, 1989, $175.00 after September 25, 1989 Conference hotels in area, single cost, and local phone numbers: Hyatt Regency $99.00 (301) 528-1234 Days Inn Inner Harbor $59.00 (301) 576-1000 Holiday Inn $69.00 (301) 685-3500 Baltimore Marriott $79.00 (301) 962-0202 Radisson Plaza $80.00 (301) 539-8400 Best Western Hallmark $52.00 (301) 539-1188 Additional information: Tammie Grice (301) 975-2775 Payment: Mastercard, VISA, checks, money orders, training or purchase requests. (payment to "National Institute of Standards and Technology/Computer Security Conference")
Please report problems with the web pages to the maintainer