RISKS-LIST: Risks-Forum Digest Sunday 14 February 2010 Volume 25 : Issue 94 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/25.94.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Happy Valentine's Day! (My heart is still in RISKS.) Electronic Systems That Make Modern Cars Go (Jim Motavalli) Toyota Braking Problem Link (Gene Wirchenko) How computers took over our cars (Amos Shapir) Ex-Toyota lawyer points to electronic throttle control (PGN) Motor racing solution to Toyota runaway (Dave Crooke) Mercedes Benz E Class Commercial (Richard S. Russell) Medical privacy: They never, ever learn (Geoff Kuenning) Who Owns Your PC? (Lauren Weinstein) EMV busted (David Magda) Website glitch drives up parking penalty (Nick Rothwell) The Century Bug will repeat ... (Jonathan de Boyne Pollard) Making the grade or changing the grade? (Jeremy Epstein) Phishing Scam Cripples European Emissions Trading (Danny Burstein) Meta-spearphishing (Jeremy Epstein) CAPTCHA with the answer in the ALT text (jidanni) Re: GPS Control Software Glitch: NANU Issued (Andy Piper) Re: Unsearchable Stores (Bob Bramwell) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Sat, 6 Feb 2010 14:41:34 PST From: "Peter G. Neumann" <neumann_at_private> Subject: Electronic Systems That Make Modern Cars Go (Jim Motavalli) Source: Jim Motavalli, *The New York Times*, 4 Feb 2010 http://nytimes.com/2010/02/05/technology/05electronics.html The electronic systems in modern cars and trucks -- under new scrutiny as regulators continue to raise concerns about Toyota vehicles -- are packed with up to 100 million lines of computer code, more than in some jet fighters. ``It would be easy to say the modern car is a computer on wheels, but it's more like 30 or more computers on wheels,'' said Bruce Emaus, the chairman of SAE International's embedded software standards committee. Even basic vehicles have at least 30 of these microprocessor-controlled devices, known as electronic control units, and some luxury cars have as many as 100. [Nice article on "throttle-by-wire" cars, eschewing physical linkages. PGN] ------------------------------ Date: Thu, 11 Feb 2010 12:09:57 -0800 From: Gene Wirchenko <genew_at_private> Subject: Toyota Braking Problem Link It appears that the problem was software: Toyota to recall 400,000 Prius cars over software glitch. Following driver complaints about poor braking performance, Toyota plans to recall around 400,000 Prius hybrid cars to replace software controlling the antilock braking system. http://www.itbusiness.ca/it/client/en/home/news.asp?id=56365 ------------------------------ Date: Thu, 11 Feb 2010 17:56:55 +0200 From: Amos Shapir <amos083_at_private> Subject: How computers took over our cars Increasingly, computers are in control of our cars, says Paul Horrell, and that is changing our relationship with the open road http://news.bbc.co.uk/1/hi/magazine/8510228.stm ------------------------------ Date: Thu, 11 Feb 2010 7:33:14 PST From: "Peter G. Neumann" <neumann_at_private> Subject: Ex-Toyota lawyer points to electronic throttle control (USATODAY.com) Nancy Leveson commented to me, ``When is the auto industry (and everyone else) going to learn that you cannot `exhaustively test' software and introduce modern safety engineering techniques that are appropriate for digital systems and not just use those developed for the electro-mechanical systems of the past?'' ------------------------------ Date: Sun, 31 Jan 2010 13:38:00 -0600 From: Dave Crooke <dcrooke_at_private> Subject: Motor racing solution to Toyota runaway It occurred to me that I've had a throttle stuck wide open twice in the past[*], and neither incident was at all dramatic; the recent Toyota problem is only deadly due to the misapplication of the PC-style "soft power button" concept to a safety critical system. This is compounded by the use of a non-standard control interface in an environment that is otherwise highly standardized - that very standardization is a "key" safety feature. Home-made dashboards with non-standard layouts and pushbutton ignition switches are common in motor racing, and a simple, robust solution was implemented decades ago - all race cars are required to have a *mechanical* switch which cuts power to all drive-train systems, with standard color, labeling and placement. Perhaps in future cars with ignition buttons like this Toyota, or software controlled drive-trains like in a hybrid, there could be a mandatory standard requiring a hard-wired engine cutoff knob on the right hand side of the steering column, thus implementing the UI everyone (who doesn't drive a Saab) is familiar with? Also ... I would have expected that the US federal "PRND21" standard for automatic transmission controls would require that a car could always be freely shifted from D or R to N to guard against just this circumstance ... any US auto engineers available to comment? * For Lindsay Marshall's amusement: one in Tyne Tunnel at rush hour, when it was used by the A1. ------------------------------ Date: Thu, 4 Feb 2010 23:27:06 -0600 From: "Richard S. Russell" <richardsrussell_at_private> Subject: Mercedes Benz E Class Commercial An ad for the Mercedes Benz E Class touts its "safety" features, among which is that it can "even stop itself if [the driver] becomes distracted". http://www.youtube.com/watch?v=3DgjfzHY5-2sM Right. Because nothing could EVER go wrong with THAT. Richard S. Russell, 2642 Kendall Av. #2, Madison WI 53705-3736 608+233-5640 RichardSRussell@private http://richardsrussell.livejournal.com/ Any idiot, upon seeing the first automobile, could easily predict that it would revolutionize transportation. Only someone with exceptionally keen insight could have foreseen that it would also revolutionize the sex lives of teenagers. Isaac Asimov ------------------------------ Date: Mon, 08 Feb 2010 10:55:58 -0800 From: Geoff Kuenning <geoff_at_private> Subject: Medical privacy: They never, ever learn I've been buying some medications through an online pharmacy run by my health plan. They seem to have added a new feature: when it's refill time, an automated system calls you and walks you through reordering. All in all, I found it to be a pretty convenient system. Of course, Federal law requires them to protect my privacy; as I understand it, they can't legally reveal my prescriptions even to a family member. So when they got to the point of telling me what was available for refill, the automated voice kindly told me that they needed to verify my identity, then asked me to enter my birthdate and one other super-secret piece of information... my ZIP code. Um, yeah. My wife *definitely* isn't going to know that one. Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/ Keep trying, and keep the best. ------------------------------ Date: Thu, 11 Feb 2010 17:21:19 -0800 From: Lauren Weinstein <lauren_at_private> Subject: Who Owns Your PC? Who Owns Your PC? New Anti-Piracy Windows 7 Update "Phones Home" to Microsoft Every 90 Days ( http://lauren.vortex.com/archive/000681.html ) ( http://lauren.vortex.com/WAT-KB971033.jpg ) Greetings. Sometimes a seemingly small software update can usher in a whole new world. When Microsoft shortly pushes out a Windows 7 update with the reportedly innocuous title "Update for Microsoft Windows (KB971033)" -- it will be taking your Windows 7 system where it has never been before. And it may not be a place where you want to go. [Very long but worthy item TRUNCATED for RISKS. Check out the original. PGN] ------------------------------ Date: Thu, 11 Feb 2010 18:29:12 -0500 From: David Magda <dmagda_at_private> Subject: EMV busted Seems that the EMV standard has been compromised: > "Chip and PIN is fundamentally broken," Professor Ross Anderson of > Cambridge University told ZDNet UK. "Banks and merchants rely on the words > 'Verified by PIN' on receipts, but they don't mean anything." http://news.zdnet.co.uk/security/0,1000000189,40022674,00.htm More reports: http://resources.zdnet.co.uk/articles/0,1000001991,40022669,00.htm http://www.telegraph.co.uk/science/science-news/7215920/ http://www.physorg.com/news185118205.html Anderson's paper is available: http://www.lightbluetouchpaper.org/2010/02/11/chip-and-pin-is-broken/ EMV is called often called "Chip and PIN", as well as "Chip Card" in Canada. Some financial institutions put a lot of stock in the security of this: > You are responsible for the full amount of all authorized activity or > other Transactions resulting from use of the Card or Connect ID and PIN or > Password by any person, including any entry error or fraudulent or > worthless deposit at an ABM or other machine. You are responsible for the > full amount of all unauthorized activity or other Transactions which occur > before we receive notification that your PIN, Password or Card was lost or > stolen or that your Connect ID, PIN or Password may have become known to > an unauthorized person. On receiving such notice from you we will block > the Card's, PIN's or Connect ID's ability to access our services and/or > the use of a Card or the Account. https://www.tdcanadatrust.com/tdvisa/pdf/select.pdf (column 9) In many cases, the banks' (now no longer trust-worthy) logs are the definitive record: > Our records will be conclusive proof of use of a Card or the Account or > electronic services and will be considered your written request to perform > the Transaction. Even though you may be provided with a Transaction > receipt, verification or confirmation number, or interim statement by or > through an ABM or other machine, the following applies to all Transactions > or other activity on the Account: > * our acceptance, count and verification of Transactions or deposits > will be considered correct and binding unless there is an obvious error > [...] (Ibid.) Some are a bit more reasonable, but if your card has been cloned (and put back in your wallet/purse), you may not notice the problem until too late: > If someone uses your Visa Card and your PIN or your Visa Account number > with any other security code to make unauthorized purchases or otherwise > obtain the benefits of your Visa Card, you will not be responsible for > those charges provided that you (i) are able to establish to our > reasonable satisfaction that you have taken reasonable steps to protect > your Visa Card [...] and (ii) cooperate fully with our > investigation. [...] > You are not responsible for unauthorized use of your Visa Card or your > Visa Account number in transactions in which neither a PIN nor a security > code is used as the cardholder verification method. http://www.rbcroyalbank.com/cards/documentation/pdf/ch-agreement.pdf ------------------------------ Date: Fri, 12 Feb 2010 12:49:30 +0000 From: Nick Rothwell <nick_at_private> Subject: Website glitch drives up parking penalty A driver's parking penalty fee escalates after the council payment web site repeatedly reports that she has nothing to pay - because she entered her car registration number in lower case. http://www.guardian.co.uk/money/2010/feb/12/southwark-council-car-registration ------------------------------ Date: Sun, 24 Jan 2010 19:00:03 +0000 From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups_at_private> Subject: The Century Bug will repeat every hundred years, sometimes every ten years, because we forget or ignore what we should have learned. In RISKS-25.89 ("Y2K+10 problem 4: SpamAssassin tags '2010' e-mail as spammish") M. Burstein wrote that the problem was that "It seems the 'year date' was hard/hand coded, as opposed to making a comparison to 'today's' date." and observed that "The SpamAssassin folk have a new version which corrects this problem." In fact, they do not. The replacement rule incorporates the same problem as before, scheduled to occur simply ten years further into the future, in January 2020. This mistake has not been learned from, let alone corrected. This is a core problem. The human race forgets or ignores problems that it has already solved. Back in the 1990s I was quietly predicting that by the year 2010 people would have forgotten all of the issues that had to be dealt with for the 1999-to-2000 transition, and would have gone back to (say) using two-digit year numbers. In part this would have been because people were erroneously calling it a "Millennium Bug", causing the erroneous inference that it was something that only ever arose every thousand years and could be forgotten once the year 2000 was past. Michael C. Battilana (www.cloanto.com/usrs/mcb), D. R. Ladd (writing in the letters page of New Scientist on 1998-03-14), J. R. Stockton, and others besides, all more loudly than I pointed out that the bug was due every century, and that the foolish name "Millennium Bug" tended to disguise that. But in part it would also have been because we won't have turned to people making the same mistakes all over again, saying "What you are doing is a bad idea, that cost the world a lot of time, effort, and money the last time we had to clean up the mess made. Don't repeat it.". And here we are, in 2010, showing that the world has not only not learned from the mistakes of 10 (and more) years ago, but is even making mistakes of the same type but with shorter periods than a century. The developers of SpamAssassin hit a problem caused by, in effect, ONE-digit year numbers (with regular expressions that fix the first three digits of the year at "200"), and rather than learn from the world's experience with the problems of two-digit year numbers of a mere ten years ago, they simply put the bug off for another ten years. It's "Rollover Year" every ten years with SpamAssassin. And it's "Rollover Year" every century with others. It's sad to note that not only have some parts of the world forgotten the lessons of two-digit year rollover of a mere ten years ago, and gone back to using two-digit years, but other parts of the world never really even fixed the problem in the first place. Here's one example from personal experience. Recently, I wrote an NNTP server and updated an NNTP client. Following RFC 3977, section 7.3.2, I made the client use 4-digit years in all "NEWNEWS" commands that it sends. I also made the server outright reject "NEWNEWS" commands that used 2-digit years, on the grounds that the RFC 3977 semantics for 2-digit years differed from the RFC 977 semantics, differed from the Single Unix Specification semantics, and were quite silly (requiring, as they did, the inference of year numbers that pre-date by several decades the very existence of NetNews); and that surely everyone had long since switched to 4-digit years, it being more than a decade since the specification for 4-digit years in NNTP (which has been around since IETF draft specifications of the 1990s) was invented and (supposedly, given that IETF standardization is supposed to follow practice) put into practice. I was quite saddened to discover in testing that the world of NNTP simply ignored the Century Bug completely, and largely ignores RFC 3977 too. I have yet to find in production use (albeit that I've not finished testing) an NNTP client that sends anything other than 2-digit years with the "NEWNEWS" (and "NEWGROUPS") command, despite the strong recommendation in RFC 3977 to the contrary, and I have yet to find an NNTP server (other than my own) that actually recognizes 4-digit year numbers when sent, despite the outright requirement in RFC 3977 for supporting this. I haven't tested, but I strongly suspect that no-one even implements the RFC 3977 semantics for inferring four-digit years from two-digit ones, and the world still implements the RFC 977 semantics, which date from 1986 and mandate (for example) protocol commands as daft as asking for the NetNews articles from the year 1961. (The RFC 3977 changes to those semantics make things yet dafter, mandating protocol commands as daft as asking for the NetNews articles from the year 1912, and which introduce a new problem of jitter resulting from poor implementations on the 31st of December and the 1st of January every year.) I'm sure that RISKS readers can produce similar experiences in other fields. So WHY haven't we learned the lessons here? Why are people, only a mere ten years on, forgetting the problem entirely and going back to employing two-digit years? Why are people even creating and perpetuating new ONE-digit year rollover problems, that they then had to deal with this year, and will even have to deal with again a few years from now? JosephKK, in RISKS 25.85, on a different subject, touched upon one of what is almost certainly many reasons. Xe is right. Current computer programming courses are inadequate in several areas which are perennial RISKS staple topics: bad handling of personal names; bad handling of dates, times, and timezones; and bad handling of geographic locations. I did a quick review of a couple of IT textbooks at the time of RISKS 25.85 but didn't turn up anything that explained the common IT errors to avoid with personal names. It would be interesting to hear from RISKS' resident book reviewer, M. Slade, or anyone else, how many IT textbooks he has encountered that explain, for example, how it doesn't match reality to design database schemata (or laws!) specifying "Christian name" and "Surname" fields that hold one, capitalized, word each; how many books explain that there is an inherent ambiguity in a timestamp that doesn't include, or have implicit in its specification, a timezone; and how many books explain that there are practices that the world discovered, from the 1999-to-2000 transition, to be bad, and that it is simple foolishness to repeat them. How much of the experience that we've gained with doing simple, everyday, things with computers in the wrong ways, over and over again (as past issues of RISKS will attest), have we written down, published, and taught, for the benefits of those who will come after us? On the subject of not learning lessons from situations that we've already experienced years before, here's a final something to think about in relation to the recent RISKS discussion of synthetic engine noise for otherwise nearly-silent cars (Gezelter, RISKS 25.88; Strickler, RISKS 25.90; and others): Look up and consider the decades-long legal battle in the U.K. (and elsewhere) over the requirement for and use of the humble bicycle bell. ------------------------------ Date: Thu, 4 Feb 2010 14:43:08 -0500 From: Jeremy Epstein <jeremy.j.epstein_at_private> Subject: Making the grade or changing the grade? Montgomery County Maryland public schools have learned that students apparently installed keyloggers on teachers' computers, then used the passwords they captured to log in and change their grades. Besides disciplining the students, they've given teachers two (ineffective) instructions: to check grades, and to change their passwords. The first is ineffective because most teachers enter grades directly into the system, and don't have hardcopies of the assigned grades to compare against. (According to the reports, there's an audit log, but no indication whether teachers are being sent copies of their portions of the log to examine for anomalies.) Changing the passwords is ineffective, of course, unless they're confidence the keyloggers are cleaned up.... Source: http://www.washingtonpost.com/wp-dyn/content/article/2010/01/28/AR2010012803494.html http://www.washingtonpost.com/wp-dyn/content/article/2010/01/29/AR2010012902352.html http://voices.washingtonpost.com/answer-sheet/montgomery-county-public-schoo/mcps-orders-password-changes-a.html?hpid=newswell The RISK is quite similar to many other types of systems -- if there's no way to cross-check data, then data attacks are much harder or even impossible to detect. That's true if you have a bank account and don't balance your checkbook, a grading system if the teacher believes everything on the screen, or an electronically cast vote. ------------------------------ Date: Thu, 4 Feb 2010 23:36:24 -0500 (EST) From: danny burstein <dannyb_at_private> Subject: Phishing Scam Cripples European Emissions Trading (putting aside the whole issue of whether "cap and trade" and AGW is good, bad, or indifferent...) [Speigel Online] Phishing Scam Cripples European Emissions Trading Sneaky cyber-thieves have made millions by fraudulently obtaining European greenhouse gas emissions allowances and reselling them. The scam has hampered trading of the credits, which are seen as an important tool in curbing climate change, in several European countries. .... According to a report in the Wednesday edition of the Financial Times Deutschland, hackers sent e-mails last Thursday to several companies in Europe, Japan and New Zealand which appeared to originate from the Potsdam-based German Emissions Trading Authority (DEHSt), part of the EU's Emission Trading System (EU ETS). Ironically, the e-mail said that the recipient needed to re-register on the agency's Web site to counter the threat of hacker attacks. The cyber-thieves then exploited the user data that was entered into their spoof Web site to transfer emissions allowances to other accounts, mainly in Denmark and Britain, from which they were quickly resold. The new owners of the allowances would have assumed that they had acquired them legally. ... The crime has hampered the registering of trades in allowances across a wide swath of the European Union. -------------- rest: http://www.spiegel.de/international/europe/0,1518,675725,00.html ------------------------------ Date: Wed, 10 Feb 2010 12:33:22 -0500 From: Jeremy Epstein <jeremy.j.epstein_at_private> Subject: Meta-spearphishing I received the following message today (links removed for obvious reasons) with a subject line "Russian spear phishing attack against .mil and .gov employees". What's interesting is that it's carefully written (good grammar), explains the real issue with Zeus, references a real project ("2020 project" which is at DNI) and then provides links to innocent (but presumably compromised) sites to download a "fix". In fact, the first paragraph is taken from a legitimate site: http://intelfusion.net/wordpress/2010/02/08/russian-spear-phishing-attack-against-mil-and-gov-employees/ and the signature at the bottom is a legitimate researcher/company - but of course the email didn't come from him, as shown by the email headers. This is definitely the best example I've seen of a phish.... >Russian spear phishing attack against .mil and .gov employees > >A `relatively large' number of U.S. government and military employees >are being taken in by a spear phishing attack which delivers a variant >of the Zeus trojan. The email address is spoofed to appear to be from >the NSA or InteLink concerning a report by the National Intelligence >Council named the `2020 Project'. It's purpose is to collect passwords >and obtain remote access to the infected hosts. > >Security Update for Windows 2000/XP/Vista/7 (KB823988) > >About this download: A security issue has been identified that could >allow an attacker to remotely compromise a computer running Microsoft® >Windows® and gain complete control over it. You can help protect your >computer by installing this update from Microsoft. After you install this >item, you may have to restart your computer. > >Download: >http://REMOVEDTHEDOMAIN.org/downloads/winupdate.zip >or >http://www.REMOVEDTHEDOMAIN.com/file/tj373l > >___________ >Jeffrey Carr is the CEO of GreyLogic, the Founder and Principal Investigator >of Project Grey Goose, and the author of “Inside Cyber Warfare”. >EMAILREMOVED_at_private ------------------------------ Date: Wed, 03 Feb 2010 08:01:13 +0800 From: jidanni_at_private Subject: CAPTCHA with the answer in the ALT text Hmmm, a accessible CAPTCHA http://en.wikipedia.org/wiki/CAPTCHA#Accessibility with ALT text for each letter, <img alt='0' src="0.gif"><img alt='9' src="9.gif">... (Seen on http://www.mofnpb.gov.tw/PubOpinionMail.php?cat_id=99) Well I suppose they aren't giving away the store by putting them all in one string, but it is still nice for we text browser users. ------------------------------ Date: Mon, 01 Feb 2010 10:53:57 +0000 From: Andy Piper <andy_at_private> Subject: Re: GPS Control Software Glitch: NANU Issued (PGN, RISKS-25.93) > Mostly affects military users, but also implications for some civilians. Good old RISKS! My old TomTom Go 300 has been having trouble telling which road I am on for the last couple of weeks. Usually it's out by about 20 yards - enough that sometimes it gets the road right and sometimes wrong. I thought maybe it was a hardware fault, but now I am not so sure. How long until we have a flurry of new SatNav-got-it-wrong related posts? ------------------------------ Date: Sat, 13 Feb 2010 16:57:07 -0400 From: Bob Bramwell <bob_at_private> Subject: Re: Unsearchable Stores (Brader, RISKS-25.92) There's no way to enter an apostrophe on the GPS. (quoting John Varela) Equally irritating is the inability to search for names which contain digits on my iPod Classic. Since I have a large number of classical music tracks with titles along the lines of: BWV 198: Lass Fürstin, Lass Noch Einen Strahl this makes life unnecessary awkward. The risk, I suppose, is that next time I'll look for a product that provides a better user interface - assuming such a thing exists. Bob Bramwell +1 902 531 2289 ------------------------------ Date: Thu, 29 May 2008 07:53:46 -0900 From: RISKS-request_at_private Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest, with Usenet equivalent comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request_at_private containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe_at_private or risks-unsubscribe_at_private depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> The full info file may appear now and then in RISKS issues. *** Contributors are assumed to have read the full info file for guidelines. => .UK users should contact <Lindsay.Marshall_at_private>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks_at_private with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume <http://www.risks.org> redirects you to Lindsay Marshall's Newcastle archive http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 25.94 ************************Received on Sun Feb 14 2010 - 14:40:15 PST
This archive was generated by hypermail 2.2.0 : Sun Feb 14 2010 - 15:36:42 PST
