It is a dubious rationalization to complain about 'lost productivity' costs after '3 of 4 tsunami warnings' (in Hawaii?) prove false. Are evacuation drills and similar preparation, or planning related to disaster response also be considered too costly, if tsunamis do not occur on some obliging schedule? (Perhaps.) At some point, technology related to detection and warning is also 'too costly'. Particular care needs to be taken to appropriately balance 'lost productivity' costs with the cost of real damage and lost lives. Obviously, while an hour's warning is inadequate in many situations, a six-hour warning could do quite a bit of good given the vast reach of a tsunami. Presumably the detectors necessary for a one hour warning would be that same ones required for the six hour warning. Harry Crowther (email@example.com) See: Sounding the Alarm on a Tsunami Is Complex and Expensive John Schwartz, *The New York Times*, 29 Dec 2004 http://www.nytimes.com/2004/12/29/international/worldspecial4/29warn.html If only people had been warned. An hour's notice for those living and vacationing along the coastlines of the Indian Ocean might have saved thousands of lives. But predictions, and acting on them, are not simple, geoscience experts say. ... According to a NASA Web site devoted to tsunamis, three of four tsunami warnings issued since 1948 have been false, and the cost of the false alarms can be high. ... An evacuation in Hawaii could cost as much as $68 million in lost productivity, according to the National Oceanic and Atmospheric Administration. Since the 1960's, there have been two warnings of tsunamis in Hawaii that ended in evacuations, and both were false alarms.
Around 1 Dec 2004, I and several people I know received this spam: > THIS IS AN OFFICIAL WARNING! > A huge 300 ft. high ocean wave is moving towards your continent. Your and > many other cities are in a real danger. Approximate wave moving speed is > 700 km/h. > Please read more about this catastrophe here: [plausible-looking URL > snipped] We are strongly urging you to evacuate yourself and your family > as soon as possible, even though you may live far away from your city. The > tsunami will reach the continent in approximately FOUR hours. I didn't check the URL then; aside from the "how would you know what city I'm in?" aspects, I'd previously received very similar messages using other shock announcements ("Terroract in Australia!") to lure people to their sites. And indeed, this one was also spam. But in the wake of this week's tragedy, it reminds me that there is no end to opportunism. I'm sure we'll see that particular message recycled; spammers aside, there are several obvious reasons why somebody might find it convenient to trigger a mass evacuation. (Looting, terrorist attack on traffic choke points, etc etc...) We know what false alarms do to the effectiveness of warning schemes. Any warning system needs to incorporate authentication - which also means limiting its distribution to people who *will* check authenticity rather than taking it on trust.
It's common for RISKS posts to point out unintended consequences of well-meaning actions, so some response to Marc's post seems called for. Having worked in the advertising and marketing industries and having run marketing campaigns I should point out some unexamined assumptions. The main one is that enhanced privacy is an unalloyed benefit. It isn't, there are costs. Advertisers use targeted advertising because they have no desire to advertise to people who are not going to buy the product. The phrase I coined while in the industry was "Every ad a wanted ad." Targeting isn't perfect but the more information an advertiser has the better their targeting and the less they have to advertise to people who aren't interested. If consumers don't provide that information, the advertisers will use less efficient, more expensive, advertising media including large blanket mailshots. Because all advertisers would be equally affected I would expect them to be free to pass on the extra costs to their customers. Privacy is a laudable aim, but not a zero cost option. I need to add that part of the warning does not apply in the UK where I am. In general if you provide personal information to a European company they are not free to sell it on. The European model assumes that you own the data and when you "give" it to a company what they receive is a limited license to use that data. Unlicensed use of the data is a criminal offence. As a database manager I, and my company directors, could do jail time for buying or selling names and addresses. Adopting a similar legislative framework in the USA would do more to protect electronic privacy than any other measure. Bernard Peek, London, UK. DBA, Manager, Trainer & Author
James Oberg wrote a great piece on the Cassini-Huygens mission that reminds us: it's the things we DON'T test that can really bite us. http://www.spectrum.ieee.org/WEBONLY/publicfeature/oct04/1004titan.html [This is a rather remarkable story of Boris Smeds, whose discovery of a flaw in Cassini's receiver and subsequent persistent apparently has saved the mission. PGN]
>From Aviation Week and Space Technology December 20/27, 2004, pp. 34-36: The trial began Dec. 15 around 00:45 EST when the target (for the interceptor) was fired from Kodiak, Alaska. However, about 16 min later, the interceptor at the Kwajalein missile range in the South Pacific shut down 23 sec. prior to launch owing to a still unspecified anomaly. It was the first test of Boeing's ground-based midcourse missile defense system using the operational Orbital Sciences Corp. interceptor. Pentagon officials are still assessing why the missile defense test failed, but are pressing ahead anyway with the next round of enhancements. Are they simply going through the motions because nobody expects this system to be used against an actual enemy? Vassilis Prevelakis, Computer Science Department Drexel University, Philadelphia, Pennsylvania
Germany introduced not one, but two big projects on 1 Jan 2005. This was not by design, but because the toll collection scheme on the autobahns was delayed by about 18 months. 1) Toll collection The government is happy to report that all is well, they collected some real money and there were no problems reported. Spiegel, however, (http://www.spiegel.de/wirtschaft/0,1518,335367,00.html) reports on its on-line edition that 10 % of all attempts to use the system ended in failure or in people just not paying the toll. The system started with just 320.000 "On-Board Units" (OBU) installed that calculate the tolls using a complicated, satellite-based scheme. If a trucker does not have an OBU they must either purchase a ticket by mobile phone (costly) or at a toll booth in a rest stop. The problems here are that many truckers do not know exactly what exit they will be getting off at. In addition, if there is a traffic jam or other problems and they have to take a detour, they must change their toll ticket. A personal observation from a rest stop visit on Sunday: there were 2 people posted at the terminal to help people use the system. The costs for this need to be factored into a success evaluation. The proof of the pudding will be when there are no helpers around anymore, just the machine with its rather intricate user interface. Other media have noted that now other EU countries are jealous and are considering their own toll systems. We will probably soon see trucks having to be completely rebuilt in order to accommodate the 25 or so different toll collection registration units..... 2) The new dole: Arbeitslosengeld II The new dole system in Germany began on Jan. 1, 2005. The government has admitted to a "computer problem" in the direct deposit scheme that left about 5 % of the recipients without money. The computer on-line news system Heise Online reports in http://www.heise.de/newsticker/meldung/54690 that the error was with account numbers that were less than the now standard 10 digits. The program was of course supposed to put in *leading* zeros, for example "0012345678". Instead, the zeros were added at the end ("1234567800") causing the payments to be unassignable to the recipient. The government had to set up an emergency payment scheme to hand out 100 Euros to people who could show that they had not received the money properly. It seems strange that there would only be 5 % of people affected, as only people with newer banking accounts actually have a 10-digit account number and many people do not put in the leading zeros when they put their account number in a form. The company that produced the software, T-Systems (a company that used to be part of the German telephone company) insists that the error is not theirs, but in the bookkeeping software of the government that sent them the account numbers already in the incorrect form. This software has been working for years, however, so the witch-hunt for the guilty continues. Since the bank workers tend to still be on Christmas holiday and the ones left at the bank are concerned with getting the year-end bookkeeping cleaned up, the money had just been transferred to temporary accounts where it awaits someone to come along and sort it out. Meanwhile, the scheme — which was supposed to save the government money so that it could use the money to find work for people - has turned out to actually *not* save money yet. The government requested many personal details from people in the hopes of denying them money. But instead of the expected 23%, only 6.5% of the 2.7 million applications for money were rejected. http://www.berlinonline.de/berliner-zeitung/tagesthema/409437.html?2005-01-04 There are very few people available for helping people find new jobs, as all of the available personnel have been concerned with getting the payment system to work. Prof. Dr. Debora Weber-Wulff FHTW Berlin, FB 4, Internationale Medieninformatik Treskowallee 8, 10313 Berlin Tel: +49-30-5019-2320 Fax: +49-30-5019-2300 firstname.lastname@example.org http://www.f4.fhtw-berlin.de/people/weberwu/ [The second system problem also noted by Jan Vorbrüggen, excerpted next. PGN Correction of 6,5 added later]
[...] Among the various media reports, see for instance (in German) http://www.spiegel.de/wirtschaft/0,1518,335141,00.html. A comment: Interbank transfers are ubiquitous in Germany - you can even use them to pay at the supermarket for your groceries. Certainly, everybody earning a salary receives it that way. It seems almost inconceivable that a programmer living here would not know that right-filling of account numbers is the wrong thing to do. Oh, and have they ever heard of testing?
Eric Bangeman, 4 Jan 2005, arstechnica An anonymous member of Ars distributed computing Team Prime Rib has found the fourth-largest prime number discovered to date as part of the Seventeen or Bust effort. The number, 28433 * 2^7830457 + 1, was found after over two days of processing by the computer that found it. ... http://arstechnica.com/news.ars/post/20050104-4497.html
Bloomberg News, 1 Jan 2005 http://www.latimes.com/business/la-fi-rup1.4jan01,1,4107985.story Walgreen Co., the largest U.S. drugstore chain, accidentally overcharged as many as 4 million customers buying gifts and decorations the two days before Christmas because its payment-processing system malfunctioned from overuse. Walgreen discovered the error on Christmas Day and electronically reimbursed customers whose credit or debit cards had been incorrectly double- and triple-charged, said company spokesman Michael Polzin. Some credits may not post on customers' accounts until early next week, he said.
Reported in several UK newspapers: Thieves steal a device which allows a woman to sleep by switching off an implant in her brain. <http://news.bbc.co.uk/go/em/fr/-/1/hi/uk/4142183.stm> "... she is hopeful, but not certain, that the hospital caring for her - the National Hospital for Neurology and Neurosurgery in central London - will be able to replace the device."
I have been saying for years that we should define a Virtual Year 0 of Length Zero, both for computer programming purposes, and to make decades and centuries come out right — i.e. the 1960s would run from 1960 to 1969, not 1961 to 1970, and the 20th Century from 1900 to 1999.
I *have* accidentally eavesdropped on a meeting using a cell phone. I used the phone to check my voicemail before going into my meeting, which uses the same phone number as my phone, turned the ringer to vibrate-only, and forgot to lock the keypad when I put it into my briefcase. At some point the send button got bumped, and since I hadn't dialed a number, it called the last number I'd called, which was my phone. It was busy, so it connected to voicemail and recorded for ~15 minutes. My briefcase wasn't designed for acoustics, so it was pretty muffled, but relatively understandable.
Ray Todd Stevens, continuing and expanding on an assumption made by Paul Wallich back in RISKS-23.62, describes possible problems with RFID tags used to lock doors in hospital neonatal units. These measures have been around for years. I recall them from when my 3 1/2 year old was born, and I'm pretty sure they were in place when my 9 1/2 year old was born - and probably even before that. RFID refers to a specific technology which didn't exist 3 years ago, much less 9 years ago. I would be surprised if they are used today. RFID tags are cheap and disposable. The tags used in neonatal units are on lock-on bracelets. As I recall, they are re-usable. They don't need to provide true identification, only proximity detection. There will certainly be pressures, once a big RFID infrastructure is in place, to use RFID chips as the "standard" alternative, but they will have to battle an incumbent "standard" that's been in place for years. Change is unlikely to be quick, because the advantages of using RFID seem minimal. As for "dumb" readers that just check if any RFID tag is present: Why would anyone even build such things? It's hard to come up with situations where they would ever be useful, and anyone who deployed such a device will quickly be swamped by random tags - and the cost advantages will be minimal, given how cheap true RFID readers will likely be in a short time. (Early targets for RFID tags are medicine bottles. A hospital is likely to have tons of the things moving around its halls pretty soon, whether or not it actually uses them for anything.) In any case, it's easy to come up with failure modes, but that doesn't make them risks. They become risks when people don't deal with them appropriately. The systems I saw in action were pretty reliable. There was a clear marking in the hallway of how far you could go before setting off an alarm. It was quite accurate - we accidentally set the alarm off by walking a couple of steps too far. (My older one was helping push the younger one's carrier.) Determining the source of the problem wasn't that big a deal. (There was more running around by the staff, checking *all* the exits, than was really called for. This undoubtedly was partially a reflection of the rarity of such events. I only saw the alarm go off that once. Once could also argue that checking all the exits is prudent in any case, since the alarm could be an attempt at a distraction.) There were two rooms adjacent to the exit door, and they were clearly used all the time without problems with the system. Radio waves may not respect room boundaries, but systems can be designed to allow for that.
BKHTCRRV.RVW 20041016 "High Tech Crimes Revealed", Steven Branigan, 2005, 0-321-21873-6, U$29.99/C$42.99 %A Steven Branigan email@example.com %C P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario M3C 2T8 %D 2005 %G 0-321-21873-6 %I Addison-Wesley Publishing Co. %O U$29.99/C$42.99 fax: 416-443-0948 800-822-6339 firstname.lastname@example.org %O http://www.amazon.com/exec/obidos/ASIN/0321218736/robsladesinterne http://www.amazon.co.uk/exec/obidos/ASIN/0321218736/robsladesinte-21 %O http://www.amazon.ca/exec/obidos/ASIN/0321218736/robsladesin03-20 %P 412 p. %T "High Tech Crimes Revealed" The title is a wee bit misleading: it is not the crimes that are revealed here as much as it is the investigations, and investigative techniques and tips. As such, the initial material in the book is more valuable than many of those that do concentrate on the crimes themselves. Chapter one deals with an insider attack at a telephone company. Branigan tells the story well (if sometimes a bit flippantly) and also provides "rules" for an inquiry as the account progresses. The narrative points out errors that were made (or fortuitously missed) and notes what might have been done better. A simple case of ISP (Internet Service Provider) banner defacement turns out to have larger ramifications in chapter two. But, the supply of rules seems to dry up, although there are notes reiterating or expanding on them. Some accidental discoveries result in the discovery of a pornographic service, in chapter three. Chapter four outlines a hacker sting operation. Identity theft is superficially reviewed in chapter five, but the "case" is minor, and only used as a lead in. There are interviews with a couple of blackhats (which, if you've read Denning's, Gordon's, or Taylor's work, don't teach very much) in chapter six. Chapter seven examines the motives of different types of blackhats. It is difficult to say that this material will help in understanding attacks or protecting systems. There is a brief history of information technology in chapter eight. The essay on high tech crime in chapter nine is a bit redundant at this point. There is also some questionable material, retailing myths such as Al-Qaida's use of steganography and the salami scam. Chapter ten describes some common mistakes in an investigation, and eleven lists an overall, if simplistic, investigative outline. Chapter twelve finishes off by recapping miscellaneous thoughts. The reports of investigations that begin the book are interesting, particularly since all too many books about computer crime concentrate on technical details, and forget the legal realities (or, like Kovacich's and Boni's "High Technology Crime Investigator's Handbook" (cf. BKHTCRIH.RVW) concentrate on the career and forget the job). It is disappointing that Branigan's work trails off into more vague generalities. copyright Robert M. Slade, 2004 BKHTCRRV.RVW 20041016 email@example.com firstname.lastname@example.org email@example.com http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
RAID 2005, CALL FOR PAPERS and PANELS Eighth International Symposium on Recent Advances in Intrusion Detection Seattle, Washington, USA, 7-9 Sep 2005 Deadlines: 31 Mar 2005: Paper & practical experience submissions 30 Apr 2005: Panel submissions 15 Aug 2005: Deadline for poster session submissions www.conjungi.com/RAID/ www.raid-symposium.org
Call For Papers and Call For Session Proposals The 2005 International Multiconference in Computer Science and Computer Engineering (composed of 16 Joint Conferences) June 27-30, 2005, Las Vegas, USA The 2005 World Congress in Applied Computing (composed of 14 Joint Conferences) June 20-23, 2005, Las Vegas, USA [Excerpted for RISKS by PGN] The 2005 International Multiconference in Computer Science and Computer Engineering is composed of the following 16 conferences (all will be held simultaneously, same location and dates: June 27-30, 2005, Las Vegas, USA): 1. The 2005 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA'05) 2. The 2005 International Conference on Artificial Intelligence (ICAI) 3. The 2005 International Conference on Software Engineering Research and Practice (SERP'05) 4. The 2005 International Conference on Internet Computing (ICOMP'05) 5. The 2005 International Conference on Computer Design (CDES'05) 6. The 2005 International Conference on Wireless Networks (ICWN'05) 7. The 2005 International Conference on Modeling, Simulation and Visualization Methods (MSV'05) 8. The 2005 International Conference on Foundations of Computer Science (FCS'05) 9. The 2005 International Conference on Imaging Science, Systems, and Technology: Computer Graphics (CISST'05) 10. The 2005 International Symposium on Web Services and Applications (ISWS'05) 11. The 2005 International Conference on Pervasive Systems and Computing (PSC'05) 12. The 2005 International Conference on Machine Learning; Models, Technologies and Applications (MLMTA'05) 13. The 2005 International Conference on Communications in Computing (CIC'05) 14. The 2005 International Conference on Engineering of Reconfigurable Systems and Algorithms (ERSA'05) 15. The 2005 International Conference on Programming Languages and Compilers (PLC'05) 16. The 2005 International Conference on Embedded Systems and Applications (ESA'05) The 2005 World Congress in Applied Computing is composed of the following 14 conferences (all will be held simultaneously, same location and dates 20-23 Jun 2005, Las Vegas, USA): 1. The 2005 International Conference on Grid Computing and Applications (GCA'05) 2. The 2005 International Conference on e-Business, Enterprise Information Systems, e-Government, and Outsourcing (EEE'05) 3. The 2005 International Conference on Biometric Authentication (BIOAU'05) 4. The 2005 International Conference on Computers for People with Special Needs (CPSN'05) 5. The 2005 International Conference on Data Mining (DMIN'05) 6. The 2005 International Conference on Human-Computer Interaction (HCI'05) 7. The 2005 International Conference on Computer Vision (VISION'05) 8. The 2005 International Conference on Scientific Computing (CSC'05) 9. The 2005 International Conference on Information and Knowledge Engineering (IKE'05) 10. The 2005 International Conference on Security and Management (SAM'05) 11. The 2005 International Conference on Mathematics and Engineering Techniques in Medicine and Biological Sciences (METMBS'05) 12. The 2005 International Conference on Algorithmic Mathematics and Computer Science (AMCS'05) 13. The 2005 International Conference on Data Fusion - From Multi-Source Data to Information (FUS'05) 14. The 2005 International Conference on Frontiers in Education: Computer Science and Computer Engineering (FECS'05) (a link to each conference's URL can be found at http://www.world-academy-of-science.org - currently under construction.) GENERAL CHAIR AND COORDINATOR: H.R. Arabnia, PhD, The University of Georgia, Department of Computer Science 415 Graduate Studies Research Center, Athens, Georgia 30602-7404, U.S.A. Tel: (706) 542-3480 Fax: (706) 542-2966 E-mail: firstname.lastname@example.org Deadline for submission of papers 16 Feb 2005:
Please report problems with the web pages to the maintainer