RISKS-LIST: Risks-Forum Digest Friday 18 July 2008 Volume 25 : Issue 23 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.23.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: E-mail response to wrong address, intended recipient arrested (Danny Burstein) San Francisco admin hijacks city net (David Lesher) Risks of wrong preprogrammed emergency message system being sent (C.Y./J.E. Cripps) P2P Data Breach affects SCOTUS (Jay R. Ashworth) "Plug and Play" Hospitals (Terrence Enger) Gmail Reveals the Names of All Users (Gene Wirchenko) Google Desktop, Word may expose encrypted data (Gene Wirchenko) UPS "Virus Warning" virtually indistinguishable from phishing attack (Jonathan Kamens) DR/BCM lessons from the Vancouver fire (Daniel Wesemann in SANS via Brent J. Nordquist) Re: Map coordinate errors for California fire (Henry Baker, Al Stangenberger) California's Super-Stupid Anti-Science Cell Phone Law Takes Effect (Kurt Thams) Handheld mobile safety (Paul D.Smith) The toll for terrorism is too high (David Lesher) Firefox 3's Step Backwards For Self-Signed Certificates (Lauren Weinstein) A not-so-obvious hyperinflation risk (B. Elijah Griffin) Re: Approval voting and sincerity (Anthony W. Youngman) Re: ComCast in Concrete? ((Greg Fife, Paul Wallich) US FTC seeks comments on privacy in contactless payments (Kevin Fu) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Thu, 10 Jul 2008 09:04:04 -0400 (EDT) From: danny burstein <dannyb_at_private> Subject: E-mail response to wrong address, intended recipient arrested (slightly edited/reformatted for clarity) http://www.law.com/jsp/nylj/PubArticleNY.jsp?hubtype=TopStories&id=1202422872356 Mark Hamblett, Mistaken Identity in Civil Rights Lawsuit Bronx [NYC] resident William Hallowell filed suit in the Southern District yesterday claiming police and prosecutors blundered by wrongfully arresting him for an e-mail he never sent. Mr. Hallowell was working part time at the Riverdale Country School Library in April 2007, and exchanging e-mails about the return of a library key with his supervisor, Robin Berson, when Ms. Berson inadvertently typed the wrong e-mail address - to a Ben Hallowell. She received in return an unsigned e-mail saying the recipient had sold the key for "hookers," a "handful" of drugs and a gun. The writer also professed his desire for Ms. Berson and proposed a sexual liaison in the library. The lawsuit alleges that, on a complaint from Ms. Berson, New York City police, "Despite the obvious lack of evidence against him," arrested William Hallowell and held him for more than 30 hours. The complaint, charging false arrest and malicious prosecution, states, "Determined to make an arrest, any arrest, defendants bluntly violated Mr. Hallowell's rights by turning a blind eye to the overwhelming evidence of his innocence," and blames prosecutors for waiting for four months to dismiss the case. The Bronx County District Attorney's Office declined comment. ------------------------------ Date: Tue, 15 Jul 2008 23:39:00 -0400 (EDT) From: "David Lesher" <wb8foz_at_private> Subject: San Francisco admin hijacks city net San Francisco IT worker arrested in hijacking of city network, CNET <http://news.cnet.com/8301-1009_3-9991769-83.html?part=rss&subj=news&tag=2547-1_3-0-20> A disgruntled city worker is in jail on $5 million bail after allegedly locking other administrators out of the city's wireless network. The Risk? The same one the Intelligence Community faces daily: the people often are the problem... [Jim Horning noted "S.F. officials locked out of computer network" in the *San Francisco Chronicle*. PGN] <http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/07/14/BAOS11P1M5.DTL> ------------------------------ Date: Thu, 10 Jul 2008 23:45:59 -0400 (EDT) From: "C.Y./J.E. Cripps" <cycmn_at_private> Subject: Risks of wrong preprogrammed emergency message system being sent Potential risks in preprogrammed emergency message systems: About 2,000 State Farm employees spent almost two hours Thursday afternoon in the lower level of the company's corporate headquarters [in Bloomington, Illinois] after a passer-by reported seeing a man with a "long gun" outside the building. A preprogrammed tornado announcement sent people to the lower level when the company had intended to send out an emergency warning. Police eventually determined the person actually saw a custodian holding what probably was a pipe. [Source: Pantagraph.com State Farm, police pleased with response to security threat; see link for full article and some further risks. PGN] http://www.pantagraph.com/articles/2008/07/08/news/doc487256756564f585165529.txt ------------------------------ Date: Wed, 9 Jul 2008 09:57:30 -0400 From: "Jay R. Ashworth" <jra_at_private> Subject: P2P Data Breach affects SCOTUS Mr Justice Stephen Breyer was apparently among the over 2000 people affected by a personal data breach caused when an employee of a financial services firm installed Limewire on a computer he used for work, was careless about how he configured it, and shared some directories containing the data in question. Brian Krebs' piece in *The Washington Post* [1] missed both of the important points; the one I made above in how I (correctly) characterized what (probably) actually happened -- not glossing over the fact that p2p servent software is not inherently black-hat, as the piece encourages the reader to assume -- and the other one, covered by the comment I posted, which I reproduce here: I'm more than a little bit disappointed that this piece fails to mention the root cause of *why* this breach bothers so many people -- because the last clear chance to avoid it did not happen when the file sharing program was installed. It happened when AT&T, and the credit card companies, and whosoever, saw fit to treat as *authenticators* the mere knowledge of birthdates and SSNs. That someone knows my bday, or SSN, *does not prove they're me*, and this problem will not go away until large corporations cease acting as if it does... which is a point privacy activists have been making loudly in public places since at least 1992 that I know of, and likely longer. If you want to authenticate me, do a better job. And don't make *me* responsible for paying to deal with the consequences of you not being smart enough to do so. That's my manifesto. Maybe if enough other people say it too, loudly, it will stop. This is why I customarily refuse to give out my SSN. This is not an idea original to me, of course, and I originally stole it either from RISKS or from Lauren Weinstein's Privacy Forum, to which I've CC:ed this message. But the risks here are multiple, and subtle (at least to some :-), so I'll enumerate them: 1) Thinking that p2p software is all inherently bad because a) a p2p servent producer picked a bad default and a non-savvy user accepted it. 2) Blaming the subsequent breach on p2p software inherently, and painting it as a bad thing -- when indeed several major companies are developing legit p2p distribution networks for various things. 2a) The fact that so many supposedly technology-centric reporters miss the most important points on stories where technology intersects with society and the law -- which is most of them these days, right? 3) Blaming the breach on even the bad guys, when the root cause is an excrescently poor process design decision on the part of the good guys, to wit: choosing to use, as absolute proof that an applicant is who they claim to be, the fact that they know a birthdate, SSN, mother's maiden name, or city of birth. Just as with reusable password security: one of the reasons you use different passwords for different services (or at least, different security classes of service) *is because you can't trust the operator of the service not to leak them*. Well, this is worse: just like with biometrics, *you can't change the things these companies are asking for*. And nowadays, you can't even lie about them, since apparently, violating the terms of service of a *free* website is a felony[2]. Does anyone see any reasonable way out of this conundrum? 'Cause I don't. [1] http://www.washingtonpost.com/wp-dyn/content/article/2008/07/08/AR2008070802997.html [2] http://www.secureworks.com/research/falsepositive.php Jay R. Ashworth, Ashworth & Associates, St Petersburg FL USA +1 727 647 1274 http://baylink.pitas.com ------------------------------ Date: Thu, 10 Jul 2008 11:20:55 -0400 From: Terrence Enger <tenger_at_iseries-guru.com> Subject: "Plug and Play" Hospitals MIT's *Technology Review* has an article "Plug and Play" Hospitals: Medical devices that exchange data could make hospitals safer. Just the title is enough to excite my "oh yeah?" reflex. <http://www.technologyreview.com/Biotech/21052/?a=f>. The body of the article focuses entirely on the benefits of the new technology. Speaking of the ventilators, which are potentially life-preserving, it says the following without even a hint that there may be a risk: Goldman says that as a result of his demonstration, standards for ventilators are in the process of being revised so that future versions of the devices will include a pause function and will be subject to network control, moving toward interoperability. Don't hold your breath. [What about the nurse who takes a nap on the remote controller? And of course the veterinarian in the missing L-wing is "Pug and Pay". PGN] ------------------------------ Date: Thu, 17 Jul 2008 08:16:27 -0700 From: Gene Wirchenko <genew_at_private> Subject: Gmail Reveals the Names of All Users http://tech.slashdot.org/article.pl?sid=08/07/16/2220232&from=rss "Have you ever wanted to know the name of admin_at_private? Now you can. Through a bug in Google calendars the names of all registered Gmail accounts are now readily available. All you need to find out the names of any gmail address is a Google calendar account yourself. Depending on your view this ranges from a harmless "feature" to a rather serious privacy violation. According to some reports, spammers are already exploiting this "feature"/bug to send personalized spam messages." ------------------------------ Date: Thu, 17 Jul 2008 08:33:28 -0700 From: Gene Wirchenko <genew_at_private> Subject: Google Desktop, Word may expose encrypted data Opening paragraphs: "If you're using encryption software to keep part of your computer's hard drive private, you may have a problem, according to researchers at the University of Washington and British Telecommunications. They've discovered that popular programs like Word and Google Desktop store data on unencrypted sections of a computer's hard drive -- even when the programs are working with encrypted files." http://www.itbusiness.ca/it/client/en/home/News.asp?id=49190 ------------------------------ Date: Tue, 15 Jul 2008 09:33:26 -0400 From: <jik_at_private> Subject: UPS "Virus Warning" virtually indistinguishable from phishing attack This morning, I received an e-mail message purporting to be from UPS (I have an account at ups.com) and reading in part as follows: *Attention Virus Warning* We have become aware there is a fraudulent e-mail being sent that says it is coming from UPS and leads the reader to believe that a UPS shipment could not be delivered. The reader is advised to open an attachment reportedly containing a waybill for the shipment to be picked up. (I'm sure we've all seen the spam to which the warning is referring.) My full name is not mentioned anywhere in the message. The numerous links in the message are all encrypted query strings and point at rm04.net rather than ups.com. The e-mail header contains a bunch of randomized garbage (for example, the envelope address looks like this: v-dj_dklajdn_ndk_jccfkkddpdkkkkhkbk__at_private), and ups.com doesn't appear anywhere in it. I'm savvy enough to know that this is /probably/ a legitimate e-mail message from UPS, but a savvy attacker could craft a message that looks exactly like this one, so I'm also savvy enough to know not to be foolish enough to click on any of the links. On the other hand, checking out the links with lwp-request (a Perl command-line HTTP client) is safe enough. I checked the "Privacy Policy" link, and it redirects to http://www.ups.com/content/us/en/privacy.html, so at least one of the encrypted links in the message is legitimate. In this day and age, it is amazing to see a corporation as large as UPS failing to use the two easiest and most well-known methods of differentiating legitimate e-mail from scams -- put the customer's name in the e-mail, and make sure that all the links point directly at your site. Are there any RISKS readers with connections inside UPS to whose attention they might bring this matter? ------------------------------ Date: Tue, 15 Jul 2008 08:13:44 -0500 From: "Brent J. Nordquist" <brent_at_private> Subject: DR/BCM lessons from the Vancouver fire (Daniel Wesemann in SANS) [quoting from <http://isc.sans.org/diary.html?storyid=4729>:] DR/BCM lessons from the Vancouver fire Published: 2008-07-14 by Daniel Wesemann (Version: 1) An fire in an underground power distribution room today knocked a good portion of Vancouver's inner city power grid offline. Several news media like the Vancouver Sun are carrying the story by now. As bad as this event is on its own, the e-mail provider Hushmail reports on its web page some additional interesting details. What happened, apparently, was that Vancouver's "Harbour Centre" web hosting location brought their emergency generator successfully online when the power dropped. But as soon as the fire department started drawing massive amounts of water in their attempt to contain the fire, the water pressure in the mains was reduced to a level where the (water cooled) emergency generator couldn't operate any more. Poof. Darkness. Now, let me guess how many BCM/DR plans out there didn't think of that one... Time to update! ------------------------------ Date: Wed, 09 Jul 2008 00:33:24 -0700 From: Henry Baker <hbaker1_at_private> Subject: Re: Map coordinate errors for California fire (Baker, RISKS-25.21) After additional research, this particular error may not be a conversion error at all, but a more classical error. Apparently, the "Gap" fire was originally reported to have started at the "Gap", which does indeed reside at the original coordinates close to Highway 154. However, this original report was in error, so the naming of the "Gap Fire" after the "Gap" was actually a misnomer. Unfortunately, once the fire had been named the "Gap Fire", it would have been even more confusing to change its name, so the name has stuck, even though (so far) the fire hasn't come near the actual "Gap". This naming error is entirely analogous to the naming of mathematical theorems, very few of which are named after their actual/original discoverors. ------------------------------ Date: Mon, 14 Jul 2008 17:45:24 -0700 From: Al Stangenberger <forags_at_private> Subject: Re: Map coordinate errors for California fire (Baker, RISKS-25.21) Fortunately, InciWeb is not part of the command and control system for fighting fires, but is an informational database which attempts to supply information on incidents nationwide. Hence the consequences of an error in location of a fire are not catastrophic. However, InciWeb has been plagued by instability (possibly server overload) during the California fire emergency of the past couple of weeks. As I write this, the Plumas National Forest has set up a Google group to release information on the Canyon Complex of fires in a timely fashion. >From the PNF homepage: "Due to the unstable nature of InciWeb, updated information about the Canyon Complex can temporarily be found here [URL for the Google group]". Al Stangenberger, Univ. of California at Berkeley, Center for Forestry 145 Mulford Hall # 3114 1-510-642-4424 Berkeley, CA 94720-3114 ------------------------------ Date: Tue, 08 Jul 2008 12:08:27 -0700 From: Kurt Thams <thams_at_private> Subject: California's Super-Stupid Anti-Science Cell Phone Law Takes Effect On day 3 of the new law, we were speculating whether forcing people to use headsets would have the effect of encouraging people to talk longer, increasing overall risk. During our discussion, a friend called to say she'd be late. While fumbling for her headset she had hit a curb and blown a tire. ------------------------------ Date: Thu, 17 Jul 2008 11:07:11 -0400 (EDT) From: "David Lesher" <wb8foz_at_private> Subject: The toll for terrorism is too high The *Los Angeles Times* is reporting that the city is using $16,000,000 of "anti-terrorism" money to install faregates on their rail lines. Both Los Angeles Mayor Antonio Villaraigosa and state Homeland Security Advisor Matthew Bettenhausen said the turnstiles will enhance security at the rail lines, as well as stop fare jumpers, although a transportation security expert said the gates by themselves will have only a nominal effect on stopping potential terrorist attacks. Of course, someone, in this case Don Surber of the Charlston Daily Mail, HAD to mention the "Gov. William J. Le Petomane Thruway" <http://blogs.dailymail.com/donsurber/2008/07/16/turnstiles/> approach. Why am I reminded of "Terrorists Can't Type" yet again? RISK 1: Throw enough money into the air, and it's amazing how many problems shall appear that need it... for some value of "need"... RISK 2: With enough RISK 1's, and the fighting over the spoils that results; real honest-to-gosh threats can be, well, lost in the dust. ------------------------------ Date: Tue, 8 Jul 2008 12:25:28 PDT From: Lauren Weinstein <lauren_at_private> Subject: Firefox 3's Step Backwards For Self-Signed Certificates Firefox 3's Step Backwards For Self-Signed Certificates http://lauren.vortex.com/archive/000402.html Greetings. If you've switched over to Firefox 3 as your Web browser already -- and in general it's a fine upgrade -- you may at some point discover that rather than encourage (or at least not overly discourage) the use of self-signed security certificates, Firefox 3 makes it *less* likely that anyone other than an expert user will ever accept a self-signed certificate. This is particularly of concern to me since I've urged an expansion of self-signed certs deployment as a stopgap measure toward pervasive encryption ( http://lauren.vortex.com/archive/000339.html ). Compared with Firefox 2, version 3 throws up so many barriers and scary-sounding warnings to click through to accept such certs, that it would be completely understandable if most persons immediately aborted. What's going on is that Firefox is now putting so much emphasis on identity confirmation that it's making it even harder for people to use the basic encryption functionality of the browser, which works just fine with self-signed certificates (which admittedly are not good carriers for identity credentials). But in many situations, we're not concerned about identity in particular, we just want to get the basic https: crypto stream up and running. I am fully aware of the associated identity considerations, and I know that basic signed certificates that will work in Firefox and some other browsers (but last I heard not in Internet Explorer at this time) can be obtained for free. If browser acceptance of free signed certs broadens out (and especially if wildcard certificates also become freely available) the need for self-signed certificates could significantly diminish. But for now, Firefox 3 is going overboard with its complicated and alarming warnings, which if nothing else could include improved explanatory text, so that users would be able to better judge whether or not they should accept any particular self-signed certificate. The current wording is unreasonably judgmental given the range of perfectly legitimate situations where self-signed certificates might be used. I'm not saying to give self-signed certs the same invisible, automatic acceptance as signed certificates, but Firefox 3 has simply gone too far toward making self-signed certs unusable -- from a practical standpoint -- in many situations where they otherwise would be completely adequate and suitable. Lauren Weinstein +1(818)225-2800 http://www.pfir.org/lauren Co-Founder, PFIR and NNSquad (Network Neutrality Squad, http://www.nnsquad.org) PRIVACY Forum - http://www.vortex.com Lauren's Blog: http://lauren.vortex.com ------------------------------ Date: Wed, 16 Jul 2008 17:49:57 -0400 (EDT) From: eli_at_private (B. Elijah Griffin) Subject: A not-so-obvious hyperinflation risk The Zimbabwe government is facing a money printing crisis: the government has been able to maintain power by printing more and more money to pay the security forces. Now there is a threat to the paper supply needed to print more and more money. No computer risk there, but the last paragraph has a kicker. Besides needing paper to print more money, they use computer software to design the ever larger denominations required to keep pace with the hyperinflation, and there is a risk: "that its software license for the European banknote design technology that it uses could be withdrawn because of new sanctions threatened against the Mugabe government." http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2008/07/15/MNR011OT0Q.DTL ------------------------------ Date: Tue, 8 Jul 2008 20:19:51 +0100 From: "Anthony W. Youngman" <wol_at_private> Subject: Re: Approval voting and sincerity (Drysdale, RISKS-25.21) The best proportional system I've come across requires ranking but doesn't seem to have been covered here so far. The voter lists all the candidates they wish to in order of preference. If you don't list the candidate, they don't count as far as your vote goes. When counting the votes, it's treated as a series of two-horse races - for each pair of candidates you count how many people list A above B, and B above A. Unless you get a very weird result (i.e., it's statistically very unlikely), one candidate will win all his individual contests. That person should be elected. Failing that, someone will almost certainly lose all his contests and should be eliminated. When they're removed from consideration the win-lose cycle can be repeated until you're left with a winner. (Effectively, you're voting FOR the people you DO want, AGAINST the people you DON'T want, and ABSTAINING for people you DON'T CARE about.) ------------------------------ Date: Wed, 09 Jul 2008 07:15:01 -0400 From: Greg Fife <greg_at_private> Subject: Re: ComCast in Concrete? (Schaefer, RISKS-25.22) I ran across this problem with ComCast in Harrisonburg, VA about a year ago. The Linksys router's "MAC Address Clone" feature was sufficient to fix the problem. The ethernet adapter in a PC and the ethernet "WAN Port" on a router both have a unique six byte identification known as a MAC (Medium Access Control) address. The first three bytes identify the manufacturer (i.e. Linksys), and the other three bytes identify the specific device. Default values are assigned by the manufacturer and programmed into the hardware. A "MAC Address Clone" merely allows you to change the factory assigned external MAC address on a router. Basically, ComCast's DHCP server just takes each distinct MAC address and assigns an Internet Protocol (IP address). From the pathological behavior that we've seen, I assume that ComCast programs their DHCP server to reject equipment made by Linksys, Belkin, DLink, and so on. In most consumer routers that I've worked with, the MAC Address Clone is somewhere in the advanced configuration pages of the web configuration system. It will probably default to clone the MAC address of your PC's ethernet adapter, but if not, you can get your PC's mac address from "IPCONFIG /ALL" in a Windows XP command window or the WINIPCFG program in Windows 98. If this doesn't work, I would turn off remote management, "Universal Plug and Play," and anything else that might allow the cable company to interact with your router over the network and recognize its specific behavior. Greg Fife <greg_at_private> 1-540-447-4038 ------------------------------ Date: Tue, 08 Jul 2008 16:47:49 -0400 From: Paul Wallich <pw_at_private> Subject: Re: ComCast in Concrete? (Schaefer, RISKS-25.22) > To sum up, the implication is that at the same instant that ComCast chose to > refuse to work with Firefox browsers on Win98 machines they also were > (allegedly) in collusion with Lynksys to obsolete a model of wireless > router, all scheduled to occur just in time for the July 4th holiday. ... This sounds fishy at best (albeit it's unclear where the fishiness is). At the point where you're doing DHCP negotiation, it's impossible for the ISP to know what browser you're using. It may be a little easier to know which router or other machine is attached to the cable modem, but the motivation for keeping a list of allowed and disallowed routers (especially given the possibilities for spoofing) seems unclear to me. What I do know is that customer service representatives are typically graded on their ability to get a customer off the line quickly, and if telling them "We don't support X" will do it faster than "One of our internal routers just went belly-up" then that's likely what they'll do. On the other side of the argument, ComCast is pretty much known for doing thorough inspection, aka wiretapping, of the packets its customers send out, and for sending packets that misrepresent the state of machines with which their customer is communicating. So it seems they would be perfectly capable of bollixing someone's connection in this way, with the only question being where the profit is. ------------------------------ Date: Wed, 9 Jul 2008 18:46:30 -0400 From: Kevin Fu <kevinfu_at_private> Subject: US FTC seeks comments on privacy in contactless payments The US Federal Trade Commission issued a request for comments on issues such as security and privacy of contactless payments last month, but the FTC has extended the deadline to submit comments. If you have any comments for the FTC on privacy for contactless payments, do submit ASAP. Here are the comments received thus far. http://www.ftc.gov/bcp/workshops/payonthego/index.shtml#comments http://www.ftc.gov/os/comments/payonthego/index.shtm You may submit either by e-mail or the Web form. Kevin Fu, Assistant Professor, Computer Science Department, Univ. of Massachusetts Amherst 413-545-4006 http://www.cs.umass.edu/~kevinfu/ ------------------------------ 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.23 ************************Received on Fri Jul 18 2008 - 15:51:47 PDT
This archive was generated by hypermail 2.2.0 : Fri Jul 18 2008 - 16:15:32 PDT