RISKS-LIST: Risks-Forum Digest Friday 25 September 2009 Volume 25 : Issue 79 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.79.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Complex Machinery: a parody (Ken Knowlton) Los Angeles Drought Restrictions: Unintended Consequences? (Thomas Russ) More on the DC Metro collision 22 June 2009 (David Lesher) New York Nuclear Plant Mistakenly Blares Emergency Alarm (PGN) Air Force loses control of autonomous aircraft, shoots it down (Rob McCool) Policemen's sanitary habits result in high breathalyzer reading (Matt Fichtenbaum) Children's hospital in Ohio infected with spyware (Rob McCool) 'Robot' computer to mark English essays (Polly Curtis via Tom Heathcote) Swiss watchdog sets court ultimatum for Google Street View (Peter Houppermans) *NYTimes* Web Ads Show Security Breach (Matthew Kruk) Google Buys reCAPTCHA, Creating a Potential Privacy Issue (Lauren Weinstein) DMAchoice.org - a case study in how to run an insecure website (Jonathan Kamens) Retailer Must Compensate Sony Anti-Piracy Rootkit Victim (jidanni) Re: Quantum chip helps crack code (Steve Wildstrom) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 22 Sep 2009 12:12:43 EDT From: KCKnowlton_at_private Subject: Complex Machinery: a parody An advertisement for a high-class car [Lexus] in an equally classy magazine [9/21/09 New Yorker] begins with a satirical quote by the president [John Maeda] of a respected School [RISD], the punch line of which, I fear, may float well above the grasp of many grade C students of the modern world: "Digital technology will enable the creation of ultra-complex machines, processes, and imagery. But that amazing technology will be framed in an elegant and simple form that makes it user-friendly. The more complex the machinery, the simpler the interface will be." [High school dropouts, I think, might thus hope for jobs as pilots of thousand passenger airplanes, or controllers of nuclear power plants - punching and twiddling a few intuitively understood buttons and knobs. KCK] [Rhode Island is a small but nevertheless complex state. But perhaps the upshot of the supposed satire is that School of Design students are actually learning that "Everything should be made as simple as possible, and then massively oversimplified." (It won't work even in the architecture of buildings, let alone computer architectures. But the secret of success is giving the appearance of simplicity that implicitly masks the inherent complexity.) PGN] ------------------------------ Date: Tue, 22 Sep 2009 13:17:27 -0700 From: Thomas Russ <tar_at_private> Subject: Los Angeles Drought Restrictions: Unintended Consequences? The city of Los Angeles, California has run into a rather curious set of unintended consequence of lawn watering restrictions imposed as a conservation measure. A couple years of drought has strained the water resources of the city. So, to reduce water consumption, the city restricted lawn watering to just two days per week: Mondays and Thursdays. Unexpectedly, this may have led to a dramatic increase in the number of water main breaks, 34 since September 1st. For comparison, the numbers for September 2008, 2007 and 2006 were 21, 17 and 13. There is some suspicion that pressure shocks from the much larger swings in usage and pressure overtax the aging infrastructure. I suppose the law of unintended consequences is always operating, and this one seems to have caught everyone by surprise: "The rationing began in June, shortly before they noticed an uptick in major blowouts. There were 24 blowouts in July and 31 in August, increases from the same months last year." More details from the Los Angeles Times: http://www.latimes.com/news/local/la-me-water-main19-2009sep19,0,88564.story http://www.latimes.com/news/la-me-water-burst17-2009sep17,0,4531113.story [Nice lesson there. Put all your watery eggs in one leaky basket.] ------------------------------ Date: Tue, 22 Sep 2009 23:36:06 -0400 (EDT) From: "David Lesher" <wb8foz_at_private> Subject: More on the DC Metro collision 22 June 2009 (RISKS-25.73) The NTSB has issued an urgent interim recommendation re: the fatal Metro collision in June. <http://www.ntsb.gov/recs/letters/2009/R09_15_16.pdf> The letter discusses the failure they found: "Testing found that a spurious high-frequency modulated signal was being created by parasitic oscillation from the power output transistors in the track circuit module transmitter. This spurious signal propagated through the power transistor heat sink, through the metal rack structure, and through a shared power source into the associated module receiver, thus establishing an unintended signal path. The spurious signal mimicked a valid track circuit signal. The peak amplitude of the spurious signal appeared at the correct time interval and was large enough to be sensed by the module receiver as a valid track circuit signal, which energized the track relay. This combination -- of an alternate signal path between track circuit modules and a spurious signal capable of exploiting that path -- bypassed the rails, and the ability of the track circuit to detect the train was lost." and makes recommendations for WMATA, and other involved parties. Comment: Attention has long focused on the track signaling circuit that inexplicably failed to detect the stopped train. What was not know was why it failed; when AC track signals have been in use for a century. After a great deal of work on the scene and off, NTSB has part of the answer. The RISK here is this was and is the classic "all the eggs in one basket" protection scheme. It was a very sturdy basket, but... Now the issue is how to retrofit real redundancy into this system...and how to pay for it. [Doug Hosking noted a CNN item. PGN] http://www.cnn.com/2009/US/09/22/transit.rail.alert/index.html?iref=mpstoryview ------------------------------ Date: Sun, 20 Sep 2009 9:18:14 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: New York Nuclear Plant Mistakenly Blares Emergency Alarm Fox News, 19 Sep 2009 A suburban New York City nuclear power plant's siren system has mistakenly blared out the warning, "Emergency! Emergency! Emergency!" The ominous message rattled some of the residents of New City, about 30 miles north of midtown Manhattan. Auto shop worker Rudy Gaspari says the mechanical voice had an unsettling, post-apocalyptic overtone to it. The voice came from an Indian Point plant siren located downtown during a test Friday, The Journal News reported. Indian Point spokesman Jerry Nappi says the voice message "shouldn't have happened." He says plant officials have disabled the voice mechanism in the siren. Four other sirens with faulty connections also have been fixed. A new $15 million system is undergoing tests. It's supposed to give voice directions in park areas only. [Doug Hosking remarked, "disabled the voice mechanism"? What could possibly go wrong there? PGN] http://www.foxnews.com/story/0,2933,552603,00.html?test=latestnews ------------------------------ Date: Fri, 18 Sep 2009 21:43:09 -0700 (PDT) From: Rob McCool <robm_at_private> Subject: Air Force loses control of autonomous aircraft, shoots it down The US Air Force in Afghanistan "lost positive control" of an autonomous MQ-9 aircraft in Afghanistan, and decided to destroy it before it crossed Afghanistan's border. A piloted plane was sent and presumably shot down the errant aircraft. http://io9.com/5362338/robot-fighter-jet-killed-before-it-could-go-awol ------------------------------ Date: Mon, 21 Sep 2009 21:41:45 -0400 From: Matt Fichtenbaum <mattfic_at_private> Subject: Policemen's sanitary habits result in high breathalyzer reading [Online Swedish press, probably Svenska Dagbladet, a week or so ago.] A motorist in Piteċ in the north of Sweden crashed his car, injuring himself. Before sending him off to the hospital the police gave him a breathalyzer test, which resulted in a very high reading of 0.45 percent. The hospital folks ran their own test on a sample of his blood, with a result of 0.12 percent. Still over the "drunk" threshold, but not so badly so. It turns out that the police had a bottle of alcohol-based hand sanitizer in their car, and evidently used it. And some of it must have found its way onto the breathalyzer. "Officer? Do you have a standard reference sober person to check the calibration?" ------------------------------ Date: Fri, 18 Sep 2009 21:49:28 -0700 (PDT) From: Rob McCool <robm_at_private> Subject: Children's hospital in Ohio infected with spyware An Ohio man who had a relationship of some sort with a woman who works at Akron Children's Hospital decided to monitor her activities. He sent spyware to her Yahoo account, and instead of reading his e-mail at home (and unfortunately placing trust in him that it seems he didn't deserve), she read it at work, infecting several systems in the cardiac surgery department. Work she performed during the time her computer was infected, including patient details and some medical records, were sent to the man's computer. http://www.cio.com.au/article/319073/misdirected_spyware_infects_ohio_hospital This illustrates an increasing risk I think, that more and more employees are taking casual network access for granted on their work computers. Similar to cellular phones and USB sticks in the workplace, it's becoming difficult to isolate sensitive data from multitasking workers who mix personal with professional computing activity. Maintaining the kind of separation of duties that would be required to prevent this sort of incident seems to be either expensive or inconvenient, or maybe just not imagined beforehand by IT departments. ------------------------------ Date: Fri, 25 Sep 2009 18:23:18 +0100 From: Tom Heathcote <TomHeathcote_at_private> Subject: 'Robot' computer to mark English essays (Polly Curtis) Polly Curtis, *The Guardian*, 25 September 2009 The owner of one of England's three major exam boards is to introduce artificial intelligence-based automated marking of English exam essays in the UK from next month. Pearson, the American-based parent company of Edexcel, is to use computers to "read" and assess essays for international English tests in a move that has fueled speculation that GCSEs and A-levels will be next. http://www.guardian.co.uk/education/2009/sep/25/robots-to-mark-english-essays ------------------------------ Date: Tue, 15 Sep 2009 00:31:19 +0200 From: Peter Houppermans <peter_at_private> Subject: Swiss watchdog sets court ultimatum for Google Street View Classic example of ignoring a smoldering until it turns into a raging fire. The Swiss data protection commissioner has made fresh proposals to Google Switzerland to improve privacy of its online Street View. The office of Hanspeter Thür said on Monday that there were many problem pictures that did not respect anonymity, particularly in private roads and gardens. Google Switzerland has said it is "very disappointed" at Thür's position because it had supplied much information and had received the go-ahead to go online, only for Thür to change his position a few days later. The office of the Federal Data Protection and Information Commissioner says Google has to improve its system of blurring faces and car registration plates. It also has to pay particular attention to blurring such places as hospitals, schools and prisons. Google has 30 days to accept the proposals; if they are rejected, Thür may go to the Swiss Federal Administrative Court. The organisation says Street View has been very popular in Switzerland and people should continue to enjoy it. Wonderful ignoring of the real issues. Another publication in the NZZ illustrates what Google has been asked to do, over and above ensuring that their masking software actually works. They have been asked to remove small private streets from their database, and -- as in Japan -- they have been told to take pictures at eye height so fences can do what they were originally placed for. http://www.swissinfo.ch/eng/news_digest/Watchdog_barks_again_at_Google_Street_View.html?siteSect=104&sid=11215004&cKey=1252954358000&ty=nd ------------------------------ Date: Tue, 15 Sep 2009 07:20:01 -0600 From: "Matthew Kruk" <mkrukg_at_private> Subject: *NYTimes* Web Ads Show Security Breach "OVER the weekend, some visitors to the Web site of *The New York Times* received a nasty surprise. An unknown person or group sneaked a rogue advertisement onto the site's pages. The malicious ad took over the browsers of many people visiting the site, as their screens filled with an image that seemed to show a scan for computer viruses. The visitors were then told that they needed to buy antivirus software to fix a problem, but the software was more snake oil than a useful program." http://www.nytimes.com/2009/09/15/technology/internet/15adco.html?_r=1&th&emc=th ------------------------------ Date: Wed, 16 Sep 2009 14:01:48 -0700 From: Lauren Weinstein <pfir_at_private> Subject: Google Buys reCAPTCHA, Creating a Potential Privacy Issue Google Buys reCAPTCHA, Creating a Potential Privacy Issue http://lauren.vortex.com/archive/000612.html Greetings. Google has announced ( http://bit.ly/2r4BOL )_their acquiring of Carnegie Mellon University's "reCAPTCHA" system. You've no doubt seen reCAPTCHA in action -- it is very widely used by a vast array of sites. CMU's reCAPTCHA is a specific implementation of the more generalized CAPTCHA concept, which attempts to validate user input as coming from a human, not a (typically spam-related) robot. The reCAPTCHA system presents pairs of words optically scanned from books, and asks the user to identify them. In the process, it also uses the resulting data to help "decode" those scanned words into their correct machine-readable textual representations as part of larger book scanning efforts. This obviously makes reCAPTCHA a perfect match for Google, who is faced with the challenge of processing vast numbers of books in their Google Books project, some of which have fairly high OCR (Optical Character Recognition) error rates due to the difficulty of machine recognition of odd fonts, faded printing, and so on. However, there is a potential privacy problem with reCAPTCHA (or any centralized CAPTCHA system, for that matter), that Google will need to face. Early this year, while in the process of setting up an Internet-based forum, I considered using reCAPTCHA as part of the validation procedures. Since centralized CAPTCHA servers will typically collect IP address and potentially other data from users at the time of page display, and again when users interact with the CAPTCHA systems (for registration, message sending, etc.), these servers receive a running log of information regarding the users of the sites who are incorporating those CAPTCHAs into their pages. So I was very surprised to discover that I could not find any reCAPTCHA privacy policy explaining to ordinary Web users displaying those pages, or interacting with the reCAPTCHA system, how that collected data would be handled from a privacy and data protection standpoint. I queried CMU about this, and the reCAPTCHA support team replied that they did have an extensive privacy policy, but that it only appeared when reCAPTCHA API keys were created -- that is, when a Web site administrator wanting to incorporate reCAPTCHA into a site applied for reCAPTCHA access. There was nothing to tell conventional users how their IP address or other data would be handled by reCAPTCHA as a result of their viewing or interacting with a Web site page incorporating reCAPTCHA functionalities -- that is, no privacy policy to be found at all for those users at that time. Partly for this reason, I chose not to use reCAPTCHA for my forum. With reCAPTCHA moving under the Google umbrella, it will be crucial that Google clearly explain, in a visible and specific privacy policy, how they will collect, correlate, and otherwise use IP address and other data associated with reCAPTCHA display and use. Fundamentally, this situation is similar to that with ad display systems, where the very act of viewing a page that includes external ads may pass IP address info (and sometimes other data) to third parties. However, while Web users can usually choose to block external ads in various ways if they wish (something I do not recommend or promote -- see "Blocking Web Ads -- And Paying the Piper" - http://lauren.vortex.com/archive/000281.html ), blocking CAPTCHAs would usually mean losing access to the associated sites in significant ways. As an enthusiastic supporter of Google Books ("The Joy of Libraries, a Fireman's Flame, and the Google Books Settlement" - http://lauren.vortex.com/archive/000611.html ), I fully appreciate the value that reCAPTCHA will bring to Google, and ultimately to all users of Google Books. But I also believe that it's very important for the privacy issues associated with reCAPTCHA to be properly handled by Google, hopefully in a manner significantly better than Carnegie Mellon's own approach earlier this year. Lauren Weinstein, lauren@private +1 818-225-2800 http://www.pfir.org/lauren Network Neutrality Squad http://www.nnsquad.org Blog: http://lauren.vortex.com Global Coalition for Transparent Internet Performance - http://www.gctip.org pfir mailing list: http://lists.pfir.org/mailman/listinfo/pfir ------------------------------ Date: Wed, 23 Sep 2009 23:06:34 -0400 From: Jonathan Kamens <jik_at_private> Subject: DMAchoice.org - a case study in how to run an insecure website The Direct Marketing Association runs a Web site, http://dmachoice.org/, that people are supposed to be able to use to enroll in the DMA's "Mail Preference Service" (MPS) to opt out of bulk mailings (paper junk mail, not spam), or to opt into bulk mailings from specific companies. I registered at the site about a year ago. I had to create two different accounts because they only allow up to five addressees to be specified on a single account. At that time, I was asked to provide a username distinct from my e-mail address, which is good idea security-wise. Recently, I returned to the site to confirm that I was still opted out of bulk mailings. Lo and behold, the login page had changed, and where before it had said "Username", it now said "E-Mail". It appeared that they had decided to no longer differentiate usernames from e-mail addresses and I would have to register again using my e-mail address as my username. In fact, I learned later that I could have logged in with my old username, at which point it would have prompted me to enter my e-mail address and changed my username to it. Problem #1:* *Forcing users to use e-mail addresses as usernames is bad security. Problem #2: Switching your username format without bothering to tell existing users that they can still log in with their old usernames is stupid for all sorts of reasons, albeit perhaps not a security issue per se. Thinking that my old accounts were no longer valid (having been given no reason to believe otherwise), I set out to register again. Note that they still only allow up to five recipient names to be specified on a single account, which leads us to... Problem #3: If the site requires you to use your e-mail address as your username, how are you supposed to register more than one account on the site if you need to enroll more than five addressees in the MPS? Fortunately, my mail server supports extended addresses with the semi-standard syntax of using "+" as the separator between the mailbox name and extension to the left of the "@" sign (i.e., "jik+foo@...", "jik+bar@...", etc. all end up in my inbox), so I figured that I would simply register two accounts with the e-mail addresses "jik+dma@..." and "jik+dma2@...". Alas... Problem #4: The DMA Web site does not accept "+" as a valid character to the left of the "@" in an e-mail address, even though in fact it's perfectly valid according to all relevant e-mail standards. (I wish I could say that this problem is unique to the DMA site, but alas it's one I've encountered many times before.) However, all was not lost. Since I maintain my own mail server, I was able to create two new aliases for myself without "+" signs in them, which I did. I then proceeded to successfully register using the first alias. I ran into a bit of difficulty along the way, because... Problem #5: The site uses CAPTCHAs to prevent automated registrations. The CAPTCHAs are case-sensitive, but the letters in the CAPTCHA are of varying sizes and for many of them it's impossible to tell whether they're in lower or upper case. (I don't know whether this is because the DMA implemented a stupid home-grown CAPTCHA generator or there's actually a third-party generator out there which is this stupid, but I don't think I've ever encountered another Web site with CAPTCHAs with the same problem.) When I registered the first account, a confirmation screen was displayed after I clicked the "Submit" button on the registration screen, and I was sent an e-mail message with a link I had to click on to confirm my e-mail address and activate my account. Unfortunately, when I tried to register a second time with the other e-mail alias so that I could enroll the rest of my family in the MPS... Problem #6: I got a blank confirmation screen after clicking the "Submit" button, and no activation e-mail was sent. Thinking that perhaps my cookies and/or browser cache were confusing the site, I cleared them both. It didn't make any difference. Thinking that perhaps they were throttling the number of registrations from a single IP address, I tried from two other IP addresses on completely different networks; that didn't make any difference either. Thinking that perhaps Firefox might be a problem, I tried with both IE7 and IE8; no luck. In short, for some inexplicable reason, although I was able to register just fine once, I was unable to repeat the feat a second time. Only just now, as I'm writing this, have I realized that the first e-mail address I used was 30 characters long, while the second was 31. Therefore, I have realized that... Problem #7: The reason I was unable to register the second account is almost certainly because there's a hard-coded, bogus 30-character limit on e-mail addresses somewhere in the DMA's application or database schema, along with a bug which prevents the application from notifying the user of the problem when the limit is exceeded. I used the "Contact Us" link on the Web site to let them know the address I was trying to register and the behavior I was seeing. A day later, I received a response. Paraphrasing: "Sometimes the Web site doesn't work. Try again after about an hour. If it still doesn't work, you'll have to print out the form and register by mail." Problem #8: If I'm right about the 30-character limit on e-mail addresses, and I'm fairly certain that I am, and I told their customer service people the e-mail address I was trying to register, then surely the "Supervisor" who responded to my e-mail should know about this problem and should have been able to tell me what was wrong and how to work around it (use a shorter e-mail address). In response, I asked to speak with someone who could actually debug the issue and figure out why it wasn't working so that I could register through the Web site. My correspondent said that would not be possible. Problem #9: Web site problems which make the site completely useless for some users are dismissed with "Oh, well, sometimes the site doesn't work," and, "It's just too bad for you if it doesn't." The people running the site simply don't care about getting to the bottom of these issues. I sent back a more strongly worded complaint to this effect. Several hours later, I received a response from someone different at the DMA. Excerpting from her response: I did a little research on your behalf and found that you had already created two accounts last year for the same seven family members back on 08/14/2008; for [names elided] the old username for the 2008 account is: [elided] and the old password is: [elided]. The second account for the other two names [elided] was created on 08/14/2009. The old username name was: [elided] and password [elided]. What I did on the existing second account was to change the username into the other e-mail address that you were trying to use. So now the second account is username: [elided] and the password is the same. I'm sure I don't have to tell people what's wrong here, but just to be pedantic... Problem #10: Passwords are stored in plain-text and accessible to DMA employees rather than stored as the result of a one-way hash. Problem #11: The DMA employee provided me with usernames that I had never provided to her. Problem #12: The DMA employee sent my passwords through e-mail. (The last three problems are, of course, by far the worst of the ones listed in this message.) Problem #13: This second DMA employee made no more effort than the first one to acknowledge the root cause of my problem, i.e., that I should have been able to register the second account myself and that the DMA should actually make some effort to figure out why I couldn't and fix it. Problem #14: This second DMA employee also didn't say anything about e-mail addresses more than 30 characters long not working. (On the other hand, if you combine the "Never attribute to malice..." rule with the fact that neither employee I dealt with showed any inclination to try to identify the root cause of the issue, perhaps it's reasonable to conclude that they really don't know this is the problem.) I'm so flabbergasted that I have to go back a bit and repeat myself in capital letters here: PASSWORDS ARE STORED IN PLAIN-TEXT AND ACCESSIBLE TO DMA EMPLOYEES, WHO HAVE NO COMPUNCTIONS ABOUT LOOKING THEM UP AND SENDING THEM TO PEOPLE IN E-MAIL. ARGH! Thanks, I feel much better now. When there are Web sites like this on the Internet and people like this maintaining them, is it any wonder that there are new revelations about serious data breaches several times every week? ------------------------------ Date: Wed, 16 Sep 2009 05:46:29 +0800 From: jidanni_at_private Subject: Retailer Must Compensate Sony Anti-Piracy Rootkit Victim [[From the boy who cried RISK]] ...Claiming for his losses, the plaintiff demanded 200 euros for 20 hours wasted dealing with the virus alerts and another 100 euros for 10 hours spent restoring lost data. Since the plaintiff was self-employed, he also claimed for loss of profits and in addition claimed 800 euros which he paid to a computer expert to repair his network after the infection. Added to this was 185 euros in legal costs making a total claim of around 1,500 euros. The judge's assessment was that the CD sold to the plaintiff was faulty, since he should be able to expect that the CD could play on his system without interfering with it. The court ordered the retailer of the CD to pay damages of 1,200 euros. http://torrentfreak.com/retailer-must-compensate-sony-anti-piracy-rootkit-victim-090914/ ------------------------------ Date: Tue, 15 Sep 2009 12:40:54 -0700 (PDT) From: Steve Wildstrom <steve.wildstrom_at_private> Subject: Re: Quantum chip helps crack code (RISKS-25.78) I'm sure it can also factor 4, 6, 8, 9, 12,and 14. But if you only have four qubits, you can only count to 15, assuming unsigned integers. The real hard problem is scaling a quantum computer into something useful. It seems that no matter which technology we use, we have been stuck at 4 to 8 qubits for many years. Wake me when a quantum computer can factor RSA151. ------------------------------ 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.79 ************************Received on Fri Sep 25 2009 - 15:33:59 PDT
This archive was generated by hypermail 2.2.0 : Fri Sep 25 2009 - 16:31:10 PDT