Somehow it escaped my attention when I put out RISKS-23.95 a few minutes ago, that it was exactly the 20th anniversary of the day on which I had put out RISKS-1.01, on 1 Aug 1985 -- using a primitive line-by-line editor on a huge (not-so-)Silent 700 with an acoustic coupler over a very slow cross-country phone line. Since then, the various technologies have of course increased dramatically. Unfortunately, the risks have also -- in that the same kinds of problems still recur with respect to safety, reliability, security, survivability, interoperability, human culpability, and so on, seemingly ad infinitum, combined with the reality that so many more people are now dependent upon computers and their interconnectivity. I imagine that I won't keep it up for *another* 20 years (for example, I observe that my ratio of puns seems to have declined), but hopefully one (or some) of you will want to continue the tradition when the time comes. It would be a real shame to let the Risks Forum disappear. Even though the same or similar problems keep recurring, there is an important message herein -- and just another reminder of the needs for constant vigilance, increased awareness, better education, and -- above all -- BETTER SYSTEMS. Cheers to all! PGN
Two regional false alarms over the Emergency Alert System last week: one apparently a hardware glitch, another a user error that resulted in the National Weather Service rethinking the interface to their alert-issuing software. [EASy does it? PGN] http://www.wired.com/news/technology/0,1282,68363,00.html Bogus Homeland Alerts Hit the Air, Wired.com, 1 Aug 2005 By Kevin Poulsen </news/feedback/mail/1,2330,0-1323-68363,00.html> As if Florida didn't have enough to worry about this hurricane season, some residents of the Sunshine State were alerted to a nonexistent radiological emergency last Wednesday after a National Weather Service operator fat-fingered a routine test of the Emergency Alert System. The EAS, a 1997 replacement for the Cold War-era Emergency Broadcast System, transmits emergency audio and text information to the public over weather-alert radios and by interrupting commercial television and radio broadcasts. A digital header at the top of every EAS alert dictates how long it's in effect and how far the message should be propagated. It also identifies the type of event by a three-letter code. The Florida gaffe occurred when an operator at the National Weather Service's Tallahassee forecast office inadvertently entered the code "RHW" instead of "RWT," keying a radiological hazard warning instead of a required weekly test. The warning was broadcast to the Florida panhandle and parts of southern Georgia, said National Weather Service warning-coordination meteorologist Walt Zaleski. Fortunately, it failed to cause panic, in part because the audio accompanying the message still identified it as "only a test," and the office moved rapidly to quash the false alarm. "They quickly alerted every radio and television station within their viewing and listening area that the ID had gone out incorrectly and there was no emergency to speak of," said Zaleski. A similar glitch at a Las Vegas radio station a day earlier falsely alerted cable companies, radio and TV stations in five counties to a national crisis that didn't exist. That error occurred Tuesday afternoon when KXTE-FM tried to send out a message canceling an earlier Amber Alert, and instead transmitted an EAN, or emergency action notification -- a special code reserved for the president of the United States to use in the event of a nuclear war or similar extreme national emergency. KXTE ("X-treme Radio"), which didn't return phone calls about the incident, serves as the local primary feed for southern Nevada and parts of California, which means broadcasters in that region are tuned to the station 24 hours a day to pick up and propagate EAS messages. Under FCC regulations, those broadcasters must interrupt their regular programming when they receive an EAN code. But anomalies in the header, the absence of accompanying audio and the fact that there has never been a genuine national activation caused stations to question Tuesday's message, said Nevada EAS chair Adrienne Abbott. "A lot of stations caught it and did not forward it out," Abbott said. The error apparently resulted from a hardware problem in the station's EAS encoder-decoder. "We think that the internal battery had failed, the programming had scrambled itself," said Abbott. The FCC is in the midst of a comprehensive review of the EAS network, with an eye to updating the system for the internet age. But experts say the public has already developed some immunity to bogus warnings. "Research into the behavior of warning recipients suggests that a single false alarm, without corroboration from other credible sources, generally elicits only limited reaction from the public," a report from the nonprofit Partnership for Public Warning noted last year. Carolyn Levering, plans and operations coordinator for the Office of Emergency Management in Clark County, Nevada, says equipment failure is a fact of life in a system as complex as the EAS. "There wasn't a lot that could have been done to avoid it," Levering said. But the human error behind Florida's false alarm is more easily dealt with. The National Weather Service said last week that as a result of the Tallahassee incident, it's adding a confirmation process to its alerting software nationwide that should make issuing a serious alert at least as difficult as deleting a folder from a Windows desktop. "Now when the operator calls up on their computer screen what particular three-letter ID they'd like to send, another window will pop up and say, 'Do you really want to issue this radiological hazard warning?'" said Zaleski. More stories </news/storylist/0,2339,1323,00.html> written by Kevin Poulsen
Car industry officials and analysts say hackers' growing interest in writing viruses for wireless devices puts auto computer systems at risk of infection. As carmakers adjust on-board computers to allow consumers to transfer information with MP3 players and mobile phones, they also make their vehicles vulnerable to mobile viruses that jump between devices via the Bluetooth technology that connects them. [Source: Reuters, 1 Aug 2005, thanks to Lauren Weinstein; PGN-ed] http://www.cnn.com/2005/TECH/08/01/viruses.cars.reut/index.html
I just received an e-mail from my Congressman, David Dreier, touting his efforts to put RFID chips in Social Security cards. Dreier, never noted for clear thinking, writes: There is a common sense solution to thwarting identity theft and the fraudulent use of Social Security cards: the cards must be made counterfeit-proof... H.R. 98...improves the integrity of the Social Security card by adding a digitized photo of the cardholder. These Smart Cards will also contain a unique electronic encryption code that will allow employers to verify each applicant's work eligibility prior to hiring. Smart Cards will decrease Social Security information theft and prevent illegal immigrants from using fake or stolen Social Security information to get a job. Note that HR 98 doesn't do anything to actually address identity theft, which isn't performed using Social Security cards in the first place. Sensible measures, like making the Social Security Number self-checking, decoupling it from identification, and penalizing corporations who fail to protect SSNs or who misuse them, are notably absent. Instead we have yet another case of technology as a panacea. But in the current hysterical climate, and with the popular fascination with overhyped technology, I have no doubt that the bill will pass. I also have no doubt that it will have no effect on its true target, illegal immigration, since it will be easy to find low-paid insiders to help forge the "impossible to forge" cards. Geoff Kuenning firstname.lastname@example.org http://www.cs.hmc.edu/~geoff/
Excerpting an article about the recent US House of Representatives vote on CAFTA, which was preceded by some pretty intense politicking: Hayes switched his vote, and the agreement passed 217-215. Hayes wasn't the only North Carolina Republican voting for CAFTA. Sixth-term Rep. Sue Myrick, who represents a safe Republican district in Charlotte, announced her support for the treaty several weeks ago. Rep. Charles Taylor, who represents western North Carolina, also had pledged a no vote but missed the roll call. Taylor said he voted no but that it wasn't recorded because HIS ELECTRONIC VOTING CARD FAILED. [my emphasis -- rcs]
As something of an aside: some years ago I had a PDA which did the same thing. I populated its diary program with appointments prior to a trip to the US (I live in the UK), and when I arrived and set the device's local time all the appointments jumped forward several hours (throwing some of them into the next day). I can see some limited use for UTC-based appointments - times for phoning home from abroad, maybe? - but by and large diary entries really do mean "in local time". The vendor of the diary program refused to acknowledge this behaviour as a bug. nick rothwell -- composition, systems, performance -- http://www.cassiel.com
> In the run-up to the 2004 election, I found activist messages about > (against) Arnold Schwarzenegger were being screened by ACM's e-mail > screening service controlled by Postini. I was only able to verify this, > and retrieve my messages, because I had chosen the "quarantine" option,... Probably because you asked them to: Postini is an anti-spam service which provides mechanisms for you to control what is filtered (as well as a heck of a lot of stuff that they do for you). My ISP uses it and offers me full control over the amount of filtering done, including complete disabling. So, I have no problem with them doing exactly what I asked them to. The issue that you bring up has nothing to do with Postini or any other optional service.
>The dealer said that a tachometer feedback sensor had gone bad "and the van >didn't know what speed it was going so it shut down to be safe". I propose a slightly different interpretation of the facts: The dealer doesn't know what he's talking about beyond the sensor being bad. He has absolutely no idea why that made the van shut down, and he makes something up. Another alternative is that he doesn't mean 'safe' the way you mean safe. He means 'it shut the engine down as an alternative to revving up until it explodes'. Because I guarantee that if the van's CPU let a bad sensor destroy the engine you'd be plenty po'd, and you'd probably be screaming even louder. Frankly, there are lots of risks involved in designing a car, and the engineering team may well not have balanced them correctly. On the other hand, you've got only the words of a dealer for what the engineering team was trying to accomplish, and no knowledge of what they were REALLY doing. They may well have had some perfectly valid reason for designing the system the way they did. Any complex system has many failure modes and many risks. Very seldom are all of them evident to the casual observer.
The problem may not be solely the sensor. The A604 automatic is apparently *critically* sensitive to the ATF you use, since it *assumes* the viscosity and pressure characteristics of the fluid, rather than *responding* to them as hydraulically controlled automatics do. You *must* use Chrysler ATF-3 or ATF-4, in order for that transmission to function properly and last it's full life, or so I was told. (I'm now driving an '87 BMW 635 with a stick, which has it's own problems. Paid for it with the total check from the Voyager. :-) Jay R. Ashworth <email@example.com>, Ashworth & Associates, St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274
Colin Percival may not have understood the notice he received and wrote about in his posting (RISK-23.95), or else there's been a rash of similar problems with multiple brands of blood glucose meters. Like Colin, I received in July a notice recently about my Lifescan One Touch Ultra blood glucose meter, noting that if the meter momentarily loses power such as when it gets dropped, that it may change the units (mg/dL versus mmol/L) and/or the code number used to correct for a particular batch of test strips, and that users should be sure to check which units are being displayed, and the code number before taking a reading. The Lifescan press release noting the problem is here: http://lifescan.com/company/about/press/pruom/ Lifescan notes it will modify future models of the same glucometers to eliminate this problem, but isn't recalling the existing 4.7 million glucometers with this "feature". Rather they are advising people to verify the units displayed are correct, and that the correct code number is displayed each time they take a reading. Both are a good practice even if the "feature" wasn't an issue. I suppose that its possible that Colin's medical provider is voluntarily recalling and replacing these meters, but Lifescan is not. I find it somewhat alarming that the press release was issued in mid-April, but my health-care provider took until July to notify me! Misreading and misunderstanding one's blood glucose reading can be life-threatening over time if undetected. Rus Sheptak <firstname.lastname@example.org> Research Associate Archaeological Research Facility, University of California, Berkeley
Please report problems with the web pages to the maintainer