RISKS-LIST: Risks-Forum Digest Friday 17 October 2008 Volume 25 : Issue 39 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.39.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: NSA posts secrets to writing secure code (Joab Jackson via Jim Innes) Excel error leaves Barclays with extra Lehman assets (Gabe Goldberg) LAPD blames fingerprint errors for false arrests (PGN) Maryland Police Put Activists' Names On Terror Lists (David Hollman) Airport baggage screener charged with stealing passengers' stuff (Peter Houppermans) Credit card readers compromised (Peter Houppermans) More Smart Card Cracking (Gene Wirchenko) Stolen Votes and Stolen Elections (Mark E. Smith, PGN) Online health records (David Magda) New Data Privacy Laws Set For Firms (Ben Worthen via Monty Solomon) New Massachusetts Regulation Requires Encryption of Portable Devices ... (Monty Solomon) Amazon e-mail accounts (Steve Loughran) Security questions with unacceptable answers (Earl Truss) Worrisome money transfer (Martin Cohen) Stallman vs. Cloud Computing (jidanni) A comment on "outliers" (Ken Knowlton) The Risks of "Something you know" (Steve Taylor) Re: D10T: National Debt Clock is out of digits (Andrew Raybould) "Sydney NS vs. Sydney NSW" and popup adds! (Paul D.Smith) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: October 14, 2008 11:58:28 AM EDT From: "Jim Innes" <james.innes_at_private> Subject: NSA posts secrets to writing secure code [Recall that RISKS has always sought to include success stories on approaches that can avoid the types of risks that continually reappear here. Here is one example of something that might be educationally worth considering. PGN] [From Dave Farber's IP group. PGN] Archives: https://www.listbox.com/member/archive/247/=now Joab Jackson, Tokeneer case study serves as an example of writing low-defect, highly-reliable code, researchers claim, *Government Computer News* weekly newsletter. The National Security Agency has released a case study showing how to cost-effectively develop code with zero defects. If adopted widely, the practices advocated in the case study could help make commercial software programs more reliable and less vulnerable to attack, the researchers of the project conclude. The case study is the write-up of an NSA-funded project carried out by the U.K.-based Praxis High Integrity Systems and Spre Inc. NSA commissioned the project, which involved writing code for an access control system, to demonstrate high-assurance software engineering. With NSA's approval, Praxis has posted the project materials, such as requirements, security target, specifications, designs and proofs. The code itself, called Tokeneer, has also been made freely available. ``The Tokeneer project is a milestone in the transfer of program verification technology into industrial application," said Sir Tony Hoare, noted Microsoft Research computer scientist, in a statement. "Publication of the full documents for the project has provided unprecedented experimental material for yet further development of the technology by pure academic research.'' Developing code with very few defects has long been viewed as a difficult and expensive task, according to a 2006 paper by Praxis engineers describing the work that was published in the International Symposium on Signals, Systems and Electronics. For this project, three Praxis engineers wrote 10,000 lines of code in 260 person-days, or about 38 lines of code per day. After the project was finished, a subsequent survey of the code found zero defects. Moreover, Tokeneer meets or exceeds the Common Criteria Evaluation Assurance Level (EAL) 5, researchers said. Common Criteria is an ISO-recognized set of software security requirements established by government agencies and private companies. Industry observers have long concluded that it would be too expensive for commercial software companies to write software programs that would meet EAL 5 standards. According to the 2006 paper, the engineering team used a number of different techniques for writing the code, all bundled into a methodology they call Correctness by Construction, which emphasizes precise documentation, incremental developmental phases, frequent verification and use of a semantically unambiguous language. The developers wrote the code in a subset of the Ada programming language called SPARK, which allows for annotations that permit static analysis of the program. They used the GNAT Pro integrated developer environment software from AdaCore. "This case study has shown that software-based security products can be built that are reliable, verifiable and cost effective against Common Criteria guidelines," the paper concluded. "The bar has been raised for both procurers and suppliers." ------------------------------ Date: Tue, 14 Oct 2008 19:35:22 -0400 From: Gabe Goldberg <gabe_at_private> Subject: Excel error leaves Barclays with extra Lehman assets A reformatting error in an Excel spreadsheet has cropped up in the largest bankruptcy case in U.S. history, prompting a legal motion by Barclays Capital Inc. to amend its deal to buy some of the assets of Lehman Brothers Holdings Inc. The law firm representing Barclays filed the motion (download PDF) on Friday in U.S. Bankruptcy Court for the Southern District of New York, seeking to exclude 179 Lehman contracts that it said were mistakenly included in the asset purchase agreement. The firm -- Cleary Gottlieb Steen & Hamilton LLP -- said in the motion that one of its first-year law associates had unknowingly added the contracts when reformatting a spreadsheet in Excel. [Source: Excel error leaves Barclays with more Lehman assets than it bargained for, *Computerworld*, Oct 14 2008] http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9117143 [Another Excel-lent risk report, also noted by Chris Leeson, who observed that there should be fireworks at the hearing scheduled for 5 Nov, which will be just in time for Guy Fawkes Night! PGN] ------------------------------ Date: Fri, 17 Oct 2008 10:40:13 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: LAPD blames fingerprint errors for false arrests Police have arrested innocent people due to faulty fingerprint analysis but have not determined how many cases were affected by such errors. The *Los Angeles Times* has obtained an internal police report that notes two cases in which charges were dropped after problems with the fingerprint analysis were discovered, blamed on "shoddy work and poor oversight". One fingerprint analyst, who was involved in both the mishandled cases, was fired and three others were suspended and two supervisors replaced. "This is something of extraordinary concern," said Michael Judge, public defender for Los Angeles County. "Juries tend to afford the highest level of confidence to fingerprint evidence. This is the type of thing that easily could lead to innocent people being convicted." [Source: AP item, 17 Oct 2008; PGN-ed, thanks to Lauren Weinstein] http://www.dailynews.com/breakingnews/ci_10743941 ------------------------------ Date: Wed, 15 Oct 2008 20:25:05 +0100 From: "David Hollman" <david.hollman_at_private> Subject: Maryland Police Put Activists' Names On Terror Lists *The Washington Post*, 7 Oct 2008 http://www.washingtonpost.com/wp-dyn/content/article/2008/10/07/AR2008100703245.html "[Some of the involved officials] said the activists' names were entered into the state police database as terrorists partly because the software offered limited options for classifying entries." (from the second page). The gist of it is that the MD police added names of people who were nonviolent protesters to a terrorist watch list/database; their names were also included on a federal database as well. While there may be software design and use issues involved (such as: did the database admins have an incomplete grasp of all the "use cases" to be tracked? Were the choices deliberately limited for some political or statistical purpose?) the most potent risk may be that "computer problems" can be used as an excuse for a much more serious human error. ------------------------------ Date: Wed, 15 Oct 2008 13:01:27 +0200 From: Peter Houppermans <peter_at_private> Subject: Airport baggage screener charged with stealing passengers' stuff From http://www.theregister.co.uk/2008/10/14/tsa_screener_theft/: A baggage screener for the US Transportation Security Administration has confessed to brazenly stealing a trove of electronics gear from the luggage of passengers he was sworn to protect, federal prosecutors said. Pythias Brown, 48, of Maplewood, New Jersey, regularly sold the high-priced video cameras, laptop computers, and global positioning systems on eBay using the handle "alirla," according to a criminal complaint filed in federal court in Newark. Brown told investigators he began stealing the items in September 2007 while screening luggage at Newark Liberty International Airport. ------------------------------ Date: Wed, 15 Oct 2008 13:07:49 +0200 From: Peter Houppermans <peter_at_private> Subject: Credit card readers compromised This is a biggie: http://www.theregister.co.uk/2008/10/10/organized_crime_doctors_chip_and_pin_machines/ In a nutshell, criminals installed mobile phone kit INSIDE credit card readers before they arrived at merchants and shops, thus sending details of every card used on those terminals to criminals in Pakistan. Not sure how this was discovered, but the scale is breathtaking. [Followup: I requested more details, and Peter replied. PGN] You should watch a BBC program, available on YouTube. In part 2, my favourite news reported, Jeremy Paxman, goes into grilling mode, and he tears strips off the credit card suppliers who are trying to pretend it's not a big deal. Well, it is. See http://www.youtube.com/watch?v=L7QzOcZAwbg, part 2 is http://youtube.com/watch?v=pHdX3ZYEvXw. It's quality TV. (Paxman can be incredibly obnoxious if he doesn't get a straight answer, enjoy.) Also features Ross Anderson from Cambridge, oh, and they managed to get a terrorist angle on it (grin). OK, below an elaboration. I have omitted by part 2 that I'm one of the two principal authors of an algorithm that addresses that mutual authentication problem in full (which will become part of our token firmware Q1 2009 or maybe earlier), I didn't really want to blow my own horn (or be seen to), nor do i want to play the marketing buffoon. I solve problems, not flog gadgets - and I will get back to you with something new there too. FYI, www.axsionics.ch, happy to send you docs. Interesting challenge to discover.. 1 - it's an add-on, so the electronics won't detect changes as inputs are tapped before they get to the tamperproofing. 2 - if you block mobile comms there will be another way. You're fixing the wrong problem (more on that later). The good news is that the method they used caused interference, eventually leading to discovery. It sort of radiated trouble.. A disclosure before I start: I actually work for the company that solved this whole problem about a year ago (well, actually several years ago, but the startup has grown into a "real" company :-). Who wants to know will find out easily enough, but my reply is not for marketing. Transaction challenges (also by banks): 1 - ensure that, as a payment provider, you're talking to the actual account holder 2 - assure to the account holder that you are, indeed, the payment handler 3 - secure this whole process to ensure authentication, authorisation, confidentiality and integrity of the process (bonus challenge: 4 - ensure that a transaction is actually as expected by the client and get an approval that supports non-repudiation) Point 1 is done by PIN. The above hack destroys that assurance, but it was IMHO weak to start with, even though most of my cards have 6 digits. The ones with signatures have my face next to the signature (given the quality of the picture mainly to frighten people). How do I know as provider that "owner" and card are together when this happens? I don't - at a point of sale Chip & PIN has driven the assumption that "it must be so", and merchants no longer have any means to check other than picture cards which nobody examines other than with a signature. Point 2 is where both ATMs and credit card terminals fall down, as well as banks that call their customers - how do you know it's really the bank? How do I know I'm entering my PIN safely? Nothing assures the user of the rightful recipient of their always-the-same PIN.. Point 3 is inadequately dealt with by the "secure shell" approach a("secure" network and "secure" terminal, which means a rogue insider -network or hardware- nulls your whole approach). It is moderately OK from a risk management point of view as you contain the fraud ability to a limited audience, but as soon as someone gets *really* creative many will follow the new path - QED above. With Internet banking there is a dependency on the user terminal being moderately safe, something you can never ensure as a bank. In addition, OTP lacks feedback, challenge - response devices work with cleartext so a Man In The Middle or Man In The Browser remains possible. Note that we started this discussion with a credit card which has NOTHING apart from a secure terminal - if it isn't you thus have a major problem. Point 4 is now dealt with with out-of-band methods - get a display and confirmation via another route, typically mTAN. But do you really want transaction details travel via an insecure network which principally has no SLA for SMS? SMS traffic is the first that gets dropped if the cell gets busy.. In credit cards PIN entry is assumed to function both as authentication and authorisation, but the above hack would have worked even if those steps were with different PINs. There are a few solutions to the whole picture, but keep in mind that the base assumption should always be that the system the card is used on is infected/hacked/tampered with, which rather reduces the number of options. In addition, improving security has normally a tendency to make life harder for the poor end user who has to go through more ritual, incantations and incense burning on behalf of the relevant issuer to keep things safe. ------------------------------ Date: Tue, 14 Oct 2008 18:54:58 -0700 From: Gene Wirchenko <genew_at_private> Subject: More Smart Card Cracking http://www.infoworld.com/article/08/10/07/Researchers_show_how_to_crack_popular_smart_cards_1.html?source=NLC-SEC&cgd=2008-10-13 ------------------------------ Date: Tue, 14 Oct 2008 22:46:47 -0700 From: "Mark E. Smith" <mymark_at_private> Subject: Stolen Votes and Stolen Elections http://globalpundit.org/2008/10/13/oped-stolen-votes-and-stolen-elections/ http://www.opednews.com/articles/OpEd-Stolen-Votes-and-Sto-by-Mark-E-Smith-081014-17.html ------------------------------ Date: Fri, 17 Oct 2008 10:40:13 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Stolen Votes and Stolen Elections Mark Smith's message reminds me of a book I just received: Richard Hayes Phillips Witness to a Crime: A Citizen's Audit of an American Election Canterbury Press, Rome NY, March 2008 ISBN 978-0-9798722-3-5 This is an extraordinarily detailed analysis of the 2004 presidential election in Ohio, and perhaps a harbinger of things to come. PGN] ------------------------------ Date: Fri, 17 Oct 2008 10:02:46 -0400 (EDT) From: David Magda <dmagda_at_private> Subject: Online health records This needs to proceed very, very carefully: > The Progressive Conservative government plans to start slowly, at first > offering only a bit of information such as vaccination records. However, > the end goal is to post everything, including prescriptions, X-rays and > laboratory test results. [...] > > Mr. Brisson said addressing security and privacy concerns will be > paramount as the province builds the new e-health service. He's hopeful > that 'an incremental approach' will not only build up confidence but also > usage. > > He said Alberta is in a position to take this step because it's already > developed an electronic medical record system accessible exclusively to > health-care providers. Every other province and territory is now setting > up similar paperless systems. http://tinyurl.com/6755ak http://www.theglobeandmail.com/servlet/story/RTGAM.20081017.health17/BNStory/National/home The whole "exclusively to health-care providers" bit sounds a bit naive, given the reports out of the US of hospital and IRS employees accessing records of celebrities. Maher Arar is probably glad that the Syrians couldn't get his medical records: http://en.wikipedia.org/wiki/Maher_Arar Can government agencies request (warrant or not) a copy of your medical records if it's in a central database? We generally know how to secure paper records, I don't think we've quite figured out how to do the same with electronic records. ------------------------------ Date: Fri, 17 Oct 2008 00:06:43 -0400 From: Monty Solomon <monty_at_private> Subject: New Data Privacy Laws Set For Firms (Ben Worthen) Ben Worthen, New Data Privacy Laws Set For Firms, *The Wall Street Journal*, 16 Oct 2008 Alicia Granstedt, a Las Vegas-based hair stylist who works for private clients and on movie sets, never worried about conducting most of her business through e-mail. Ms. Granstedt regularly receives e-mails from customers containing payment details, such as credit-card numbers and bank-account transfers. Since she travels frequently, she often stores the e-mails on her iPhone. But a Nevada law that took effect this month requires all businesses there to encrypt personally-identifiable customer data, including names and credit-card numbers, that are transmitted electronically. After hearing about the new law, Ms. Granstedt started using e-mail encryption software, which requires her clients to enter a password to read her messages and send responses. It is a hassle, "but I can't afford to be responsible for someone having their identity stolen," she said. Nevada is the first of several states adopting new laws that will force businesses -- from hair stylists to hospitals -- to revamp the way they protect customer data. Starting in January, Massachusetts will require businesses that collect information about that state's residents to encrypt sensitive data stored on laptop computers and other portable devices. Michigan and Washington state are considering similar regulations. ... http://online.wsj.com/article/SB122411532152538495.html ------------------------------ Date: Fri, 17 Oct 2008 09:13:37 -0400 From: Monty Solomon <monty_at_private> Subject: New Massachusetts Regulation Requires Encryption of Portable Devices and Comprehensive Data Security Programs Miriam Wugmeister and Charles H. Kennedy, Morrison & Foerster, Sep 2008 http://www.mofo.com/news/updates/bulletins/14495.html Randy Gainer, New State Laws Require Extensive Data Security Plans and Encryption, Davis Wright Tremaine LLP, Sep 2008 http://www.dwt.com/practc/privacy/bulletins/09-08_DataSecurityPlans.htm 201 CMR 17.00: Standards for The Protection of Personal Information of Residents of the Commonwealth http://www.mass.gov/?pageID=ocaterminal&L=4&L0=Home&L1=Consumer&L2=Privacy&L3=Identity+Theft&sid=Eoca&b=terminalcontent&f=reg201cmr17&csid=Eoca Ben Worthen, New Data Privacy Laws Set For Firms, *The Wall Street Journal*, 16 Oct 2008 http://online.wsj.com/article/SB122411532152538495.html ------------------------------ Date: Thu, 2 Oct 2008 19:56:00 +0100 From: "Steve Loughran" <steve.loughran_at_private> Subject: Amazon e-mail accounts Regarding the issue about Amazon allowing >1 login per e-mail address, its a historical legacy that they probably hate. Remember back in 1995 when the whole family had one compuserve or AOL e-mail address? That's when Amazon was created, and that is where they came up with the fact that an Amazon user does not have a 1:1 mapping of e-mail->userID. What they do have is a mapping of (e-mail,password)->userID; you can create two accounts with the same e-mail address, but you will get into trouble if you try and give them the same password. I'm not sure what happens, so try it and see. The newer Amazon services, such as the Amazon Web Services, have a stricter "one e-mail address" per account rule. Clearly their support organisation has learned the error of the original design decision. ------------------------------ Date: Fri, 3 Oct 2008 10:05:05 -0500 From: "Earl Truss" <etruss_at_private> Subject: Security questions with unacceptable answers My wife recently bought a new car and the dealer arranged financing through a local credit union. This credit union has a web site that allows one to check on their accounts and do transfers between accounts and such. I wanted to use the site to make sure the first payment was credited correctly so I attempted to log in. First off, the owner of the account has to call them so they can send out a password to be used for the initial log in so we did that. When I received the password, I again went to the web site and it required me to change the default password. So far, so good. It then required me to set up some security questions by choosing from a fixed list of perhaps ten questions. One of the first was "What was the color of your first car?" I picked that one since I thought that was easy for me to remember but difficult for anyone else to know or find out so I typed in the answer - "red". I was told that I had to enter at least four characters for the answer to the question. I really had no idea what to do except laugh at the programmer who came up with this one. Figuring that this was the case for all of them, I tried again ... "What is your father's middle name?" "Bud" "You must enter at least four characters for the answer to this question." Obviously we must distort reality to pass this test. ------------------------------ Date: Thu, 2 Oct 2008 13:16:09 -0700 (PDT) From: martin cohen <mjc_q_at_private> Subject: Worrisome money transfer I wanted to transfer some money between two of my IRAs (banks unnamed). I logged into the one where the money was to go (I prefer pull to push). I anticipated having to go to the source, print out a form, signing it, and mailing it in. Instead, all I had to do was, at the receiving site, enter the source account number, and request a transfer. No authentication of any type was asked for. Less than a week later, the money was transferred. I don't know if this is common, but this worries me. Can anyone withdraw money from my account just by knowing the account number? I did not see any matching of names between the accounts. ------------------------------ Date: Wed, 15 Oct 2008 05:52:31 +0800 From: jidanni_at_private Subject: Stallman vs. Cloud Computing Stallman cautions against the "cloud computing" myth: http://lists.gnu.org/archive/html/bug-findutils/2008-10/threads.html http://techblog.dallasnews.com/archives/2008/10/cloud-computing-is-stupidity-s.html http://blogs.zdnet.com/carroll/?p=1880 http://www.guardian.co.uk/technology/2008/sep/29/cloud.computing.richard.stallman http://blogs.computerworld.com/rms_hates_cloud_computing_says_you_should_too and also http://www.osnews.com/thread?332053 if you have the right browser. I just want to add a warning that one day when one's Gmail breaks, one will attempt for the first time in one's life to contact the massive Google Corporation. Whereupon one will discover that despite their best intentions, due to their massive scale, there is little chance one will get a personal reply. "No problem" you might say, "there will certainly be many others in the same boat, so it will get fixed". Well, yes that's usually how it works with power outages and the electric company, if not at least you can still always just call their local service center. [When Gmail breaks? What about the complaints that repeated failed login attempts (a simple type of denial-of-service attack) results in YOUR Gmail account being disabled, with no easy way to get it reactivated? PGN] ------------------------------ Date: Fri, 3 Oct 2008 16:54:04 EDT From: Ken Knowlton <KCKnowlton_at_private> Subject: A comment on "outliers" (RISKS-25.37) PGN mentions "outliers" (RISKS-25.37) -- leading me to muse on the automatic elimination of aberrant points. In some sporting events, a common practice is to eliminate the highest and lowest judges' scores, and to average the rest. But now consider generalizing on the idea: It may not be generally known, for example, that there are configurations of equally-weighted points in 3-D space for which the pair of points that are farthest apart from each other are the two points that are closest to the center of gravity of the lot! [I guess that very few RISKS readers will identify Ken with one of his most delicious innovations (if I remember correctly from our Bell Labs days in the 1960s): the 17-sided unistable uniform solid that will always roll over onto the same side: the ultimately loaded-but-unloaded die. Very dicey matter. PGN] ------------------------------ Date: Fri, 3 Oct 2008 12:15:00 +1000 From: "Steve Taylor" <staylor_at_private> Subject: The Risks of "Something you know" (Re: Miller RISKS-25.37) A recent article (RISKS-25.37) mentioned the danger that the "something you know" used to authenticate an account may sometimes be "something everybody knows". This brings to mind a newspaper article I once read on computer security. While for the most part it was a pretty decent article, I winced when the reporter mentioned that his own e-mail account had once been broken into, even though he'd carefully chosen the extremely obscure password "THX1138". While that looks pretty much like a random string of letters, it is in fact the name of George Lucas's first film, from his student days. I don't know what the overlap is between hackers and science fiction fans, but I'm sure it's substantial. "THX1138" is probably more secure than "Gandalf", but it's still nothing to feel safe with. The moral: choose a *really* secure password. I suggest "Picard" or "Skywalker". ------------------------------ Date: Thu, 16 Oct 2008 22:56:48 -0400 From: "andrew raybould" <stop.posting.addresses_at_private> Subject: Re: D10T: National Debt Clock is out of digits This is one integer-overflow problem where it seems an opportunity was lost by not using a signed integer... Oh, well, the timing is fortuitous: just when this counter needs another digit, one has become available from the Dow Jones Industrial Average. ------------------------------ Date: Wed, 15 Oct 2008 09:17:21 +0100 From: "Paul D.Smith" <paul_d_smith_at_private> Subject: "Sydney NS vs. Sydney NSW" and popup adds! (Re: RISKS-25.36-38) I tried to read the story from the "Athens News" but every single link takes me into a popup add zone for domains. I presume the "Athens News" website has something hacked into it because I see the story briefly but then I'm thrown elsewhere. ------------------------------ 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.39 ************************Received on Fri Oct 17 2008 - 14:04:53 PDT
This archive was generated by hypermail 2.2.0 : Fri Oct 17 2008 - 14:25:11 PDT