RISKS-LIST: Risks-Forum Digest Tuesday 19 August 2008 Volume 25 : Issue 29 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.29.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Olympics Windows crash (PGN) Translate of device mech auto-reproduce (Rob Slade) Electronic voting and antivirus software (jared) Officials Say Flaws at Polls Will Remain in November (Ian Urbina via PGN) Glitch let hundreds get free transit rail tickets (William Neuman via PGN) Big trouble with Germany's New Unified Tax Identification Codes (Ralf Fritzsch) Online Consumers at Risk and the Role of State Attorneys General (CAP/CDT item via Monty Solomon) 11 charged with massive ID theft (Monty Solomon) Re: Firefox 3's Step Backwards For Self-Signed Certificates (Michael Barrett) Re: 'Fakeproof' microchipped British e-passport (Hamish Marson) Billion dollar IT failure at Census Bureau (Michael Lewchuk) Attempt to muzzle MIT subway research backfires (B.K. DeLong) My date and place of birth are public (jidanni) Re: How reliable is DNA ...? (Geoff Kuenning, Rob Searle, Brian Hayes, Bob Buxton) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Tue, 12 Aug 2008 16:26:50 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Olympics Windows crash This is rather amusing, but not particularly surprising: A Windows XP/Vista-style Blue Screen of Death projected onto an overhead display at the opening ceremonies to the 2008 Olympics in Beijing, courtesy of River Cool Forums. http://macenstein.com/default/archives/1562 ------------------------------ Date: Sun, 17 Aug 2008 14:35:23 -0800 From: Rob Slade <rMslade_at_private> Subject: Translate of device mech auto-reproduce Given the number of times RISKS has noted problems with automatic correction and translation systems, I thought you'd find this cute: http://adweek.blogs.com/adfreak/2008/07/then-well-grab.html [The sign says something in Chinese that would correctly translate to "... Restaurant". The supposed translation that appears on the sign says "Translate server error." The humorous caption on the photo is "Then we'll grab a bite at 404 Not Found." PGN-ed] rslade_at_private slade_at_private victoria.tc.ca/techrev/rms.htm rslade_at_private blogs.securiteam.com/index.php/archives/author/p1/ ------------------------------ Date: Sat, 16 Aug 2008 14:21:25 -0600 From: jared <jared_at_private> Subject: Electronic voting and antivirus software >From an Ohio (USA) Secretary of State press release http:// www.sos.state.oh.us/PressReleases/2008%20Press%20Releases/2008-0806.aspx "These malfunctions resulted in dropped votes when memory cards were uploaded to the server. " "The office is also continuing to test Premier's undocumented contention that the sharing violation is because of virus protection software that had been certified by the Board of Voting Machine Examiners as part of the Premier system at the time it was introduced in Ohio." The xkcd web comic has a summary: http://xkcd.com/463/ [I find the contention that failures of a voting machine could be attributed to interactions with anti-virus software to be really outrageous. Premier (formerly Diebold) has developed an inherently untrustworthy application on top of an inadequately trustworthy and relatively huge operating system that anyone with access could compromise the application software or merely accidentally disrupt elections. Blaming the anti-virus software (which exists primarily because of the weaknesses of the operating system) seems totally fatuous. There should be no need for anti-virus software in a well-designed voting system. PGN] ------------------------------ Date: Mon, 18 Aug 2008 17:30:42 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Officials Say Flaws at Polls Will Remain in November Election Assistance Commission officials say they will not be able to certify that flawed machines are actually repaired in time for the November election -- because of the backlog at testing labs. [Source: Ian Urbina, *The New York Times*, 16 Aug 2008; PGNed] ------------------------------ Date: Mon, 18 Aug 2008 17:27:51 PDT From: "Peter G. Neumann" <neumann_at_private> Subject: Glitch let hundreds get free transit rail tickets Apparently due to a programming error, ticket vending machines on the Long Island Railroad and Metro-North Railroad have been giving out free tickets whenever debit cards with inadequate balances were used, since 2001. The problem was discovered only recently, when an audit by the LIRR showed 990 such transactions. Although many people have gotten free travel without even realizing it, three people have been charged with acquiring about $800,000 worth of tickets -- which they then sold. [Source: William Neuman, *The New York Times* 13 Aug 2008; PGN-ed] [I read the article over breakfast. George Mannes noted it online. http://www.nytimes.com/2008/08/13/nyregion/13scam.html?ref=nyregion PGN] ------------------------------ Date: Thu, 14 Aug 2008 11:28:41 +0200 From: "Fritzsch, Ralf" <Ralf.Fritzsch_at_private> Subject: Big trouble with Germany's New Unified Tax Identification Codes As a reader of comp.risks digest for at least 13 years I could now for the first time contribute a nice story, happened in my home town Stade, Lower Saxony, 35 miles west from Hamburg. Since the beginning of August 2008, the "Bundeszentralamt für Steuern" (Federal Central Tax Office) sends out letters to all 82 millions inhabitants of Germany, from newborns to old men, with information regarding their new Tax Identification Code, a mathematically spoken, eleven-digit hash value dereferencing information like title, surname, given names, birth name, sex, address, birthday, place of bird, country of birth. Whereas in other places there were no or only minor problems, in Stade near 100% of the information for the roundabout 46000 inhabitants contained errors with birth name, and country of birth. E.g. in my own family (14 year old boy, 11 year old girl, my wife, and me, all native german-born Germans) three of us have as country of birth "Kazakhstan", my daughter has "Italy", and all but my wife have false, entirely fictitious birth names. The registration office of Stade is overwhelmed with complaints, and no one has until now found out, where the errors do come from. As a Stade official said, the raw data of the registration office are correct, and the transport of the data to the Federal Central Tax Office was not done via Internet, but there was sent a CD containing the data (See (1)). Until now, nobody from the Federal Central Tax Office phoned back to enlighten the situation. They said, that a 1000 of errors in 80 Millions of data is not bad, either, and blamed Stade for the error. Against this speaks the fact, that Bremerhaven, and two other towns in Lower Saxony, suffered from the same problem. And furthermore, a quick consistency check of the New Tax ID numbers with tax consultant standard transmission protocol software showed, that 70% of the IDs failed the consistency check (see also (1)). Until now it is unknown, who or what was responsible for the mess-up. The story made up to the tabloids (see (2)). The town of Stade recommends the inhabitants to do nothing and wait until the situation has cleared up. (see (3)). Appendix: Cited website information, unfortunately in German :-( (1) http://www.heise.de/newsticker/Kommunen-melden-grobe-Fehler-bei-Ausgabe-der-neuen-Steuernummer--/meldung/114161 (2) http://www.bild.de/BILD/hamburg/aktuell/2008/08/12/steuerdaten-chaos/behoerde-verschickt-bescheide-mit-falschen-namen.html (3) http://www.kreis-stade.de/default.cfm?DID=1207942 Dr. Ralf Fritzsch, Bundesanstalt fuer Wasserbau Federal Waterways Engineering and Research Dienststelle Kueste Tel. +49-40-81908-324 [Added by RF 19 Aug 2008:] The latest news, to be found (auf deutsch) under http://www.stadt-stade.info/default.cfm?did=1207884 "... Fest steht bisher nur, dass offenbar bei der Datenübermittlung vorhandene Leerfelder im Datensatz durch die EDV falsch interpretiert worden sind. Die technischen Gründe hierfür sind derzeit noch nicht geklärt." That is, "It seems definite, that obviously white spaces in the original data were misinterpreted during data transfer. Technical reasons remain until now unknown." ------------------------------ Date: Thu, 14 Aug 2008 23:03:10 -0400 From: Monty Solomon <monty_at_private> Subject: Online Consumers at Risk and the Role of State Attorneys General Study: State AGs Fail to Adequately Protect Online Consumers State attorneys general received thousands of complaints about online fraud and abuse in 2006 and 2007. Yet, with the exception of several notable standouts, few states brought significant cases in response to those complaints, according to a report released today from the Center for American Progress and the Center for Democracy and Technology. The study finds online fraud and abuse aren't given a high priority by most attorneys general. The report recommends several steps state attorneys general can take to protect online consumers, such as: assess the applicability and adequacy of state laws; develop computer forensic capabilities; train investigators and prosecutors to identify Internet fraud; and devote greater resources to enforcement efforts. Online Consumers at Risk and the Role of State Attorneys General By Reece Rushing, Ari Schwartz, Alissa Cooper | August 12, 2008 Center for American Progress, Center for Democracy and Technology http://www.americanprogress.org/issues/2008/08/online_consumers_report.html http://www.americanprogress.org/issues/2008/07/pdf/consumer_protection.pdf http://cdt.org/press/20080812press.php http://www.cdt.org/privacy/20080812_ag_consumer_risk.pdf ------------------------------ Date: Thu, 14 Aug 2008 20:27:27 -0400 From: Monty Solomon <monty_at_private> Subject: 11 charged with massive ID theft (Re: RISKS-25.26) A ring of people spread across the globe hacked into nine major US companies and stole and sold more than 41 million credit and debit card numbers from 2003 to 2008, costing the companies and individuals hundreds of millions of dollars, federal law enforcement officials said yesterday. "So far as we know, this is the single largest and most complex identity theft case ever charged in this country," US Attorney General Michael Mukasey said at a news conference at the John Joseph Moakley US Courthouse in Boston. A grand jury indictment released yesterday charged that Albert "Segvec" Gonzalez of Miami and his 10 conspirators (one from Estonia, three from Ukraine, two from China, one from Belarus, and one of unknown origin) cruised around with a laptop computer and tapped into accessible wireless networks, allegedly concealed the data in encrypted computer servers they controlled. They then hacked into the networks of TJX, BJ's Wholesale Club, OfficeMax, Boston Market, Barnes & Noble, Dave & Buster's, Sports Authority, Forever 21, and DSW. After gaining access to the systems, they installed programs that captured card numbers, passwords, and account information, officials said. [Source: David Abel and Jenn Abelson, *The Boston Globe*, 6 Aug 2008; PGN-ed] http://www.boston.com/business/articles/2008/08/06/11_charged_with_massive_id_theft/ ------------------------------ Date: Wed, 13 Aug 2008 06:14:44 -0700 From: "Barrett, Michael" <mbarrett_at_private> Subject: Re: Firefox 3's Step Backwards For Self-Signed Certificates (R 25 23) I read a rather worrying criticism of Firefox 3.0 on RISKS the other day, which made me realize that perhaps there isn't a common agreement amongst the infosec industry about the threatscape and how we should prioritize our response to them. Specifically, the complaint against Firefox 3.0 is that the user experience has been deliberately crafted to make it hard to accept self-signed certificates. The argument is that there are times when simply establishing an encrypted tunnel (i.e. an SSL session) is all that's needed. I certainly wouldn't argue that encryption is unnecessary, just that the threat has changed. While our old "friend" Mallory isn't particularly busy these days, it's pretty clear that he'd be having a field day if he could easily penetrate communications across the Internet. The attacker however is no longer limited to passive eavesdropping. Modern attacks use active DNS spoofing, active MITM attacks and the like, on public networks. The main threats these days are against the weakest link in the chain - the end user. That's why phishing is such a popular method of e-crime - it's simple and it works. It relies completely on the gullibility of users in clicking on links in e-mails apparently from organizations with whom they have a relationship. However, it's equally clear that almost everyone who wants to communicate securely using a browser can afford an SSL certificate from CAs such as GoDaddy, Thawte, etc. The cost of single certificates from these sources can only be described as nominal. My company is a major target of phishing, and as such we've spent quite a bit of time researching what anti-phishing approaches work We published a whitepaper on this topic (which can be found on the company blog at www.thepaypalblog.com), which explains this in detail. However, a couple of relevant conclusions are that: 1) the vast majority of users simply want to be protected, 2) there's no single "silver bullet", and 3) that what we describe as "safer browsers" such as IE 7, and Firefox 3.0 are a significant part of the solution based on their improvements in user visible security indicators and secure-by-default behaviors. I conflated two or three separate ideas in that last sentence, and I should explain them. The general logic is that most users should never be presented with a security dialog that gives them a choice - if they are, there's typically at least a 50:50 chance that the wrong decision will be made. Instead, the browser should make the decision for them. However, in the case of self-signed certificates it's almost impossible to see how any technology can disambiguate between legitimate uses and criminal ones. When viewed through this lens, the changes to the Firefox user experience for self-signed certificates makes perfect sense. It's not that self-signed certificates are impossible to use - but for most users, the experience will be such that they won't accept them. In the unsafe world in which we live, that will be the right choice. For organizations which wish to use self-signed certs internally, it is still technically possible - but it will require either explicit user training, or deployment of pre-installed certificates on PCs. I should also add that the major security features which have been added into the most recent browser versions (and which we believe are necessary in order to be considered 'safer') are exactly those which impact this area. That is: support for Extended Validation certificates, which make it clear to end users whose web site they're on; and support for spoof-site black lists, so that users can't easily reach spoof-sites. While I'm personally a great supporter of RISKS, I think it's important that the Infosec industry speaks with good consensus about risks. In this case, I believe that the criticism of Firefox 3.0 was simply misguided and ill-informed. This is not helpful. This post is also at: http://www.thesecuritypractice.com/ ------------------------------ Date: Wed, 13 Aug 2008 12:07:10 +0100 From: Hamish Marson <hamish_at_private> Subject: Re: 'Fakeproof' microchipped British e-passport (Poulsen, R-25.28) > I know that I am not so smart that I have figured out something that all the > experts have overlooked, so I must be missing something critical. What have > I overlooked? Lets see... After a quick think you've missed... 1. Authentication... How does the issuing agency authenticate the border agent requesting the information? Passwords? Secure Certs? One time tokens? Each have their own down sides... 2. Assuming someone solves the problem of how to get all the border agencies to agree on a method of authentication, how do you keep it secure? Passwords get written down... The issuing agency has no control over the remote access devices so can't guarantee the security of any client certs... 3. Comms... Long time readers will be well aware of the risks of depending on long comms links to be up at inopportune times. 4. How much info would be required? I think this would bring in various privacy laws... Witness the debacle between the EU and the U.S. over passenger data... 5. What's to stop a border agency from just browsing someone else's database by just brute forcing all those passport ID's? Again, what faith can we have that the ID's used won't be easily guessable... And a myriad of others... Basically they boil down to Connectivity, Authentication of border agents and privacy... Count me out. ------------------------------ Date: Wed, 13 Aug 2008 10:03:50 -0600 From: "Michael Lewchuk" <michael.lewchuk_at_private> Subject: Billion dollar IT failure at Census Bureau (Re: RISKS-25.12,13) I do have a few comments about this one: * The handhelds should be simple and cheap. They should be able to download their information to a computer via a common interface (e.g. wireless). How long they survive is dependent upon use and care. If using 10 year old computers seems strange to you, I know of many production plants that are still using 30 year old hardware. The key factor is whether it does what needs doing. If a device is damaged, it may be replaced with a new device (that is, in 12 years the Census Bureau may have another one designed, presumably for a lot less, and enough replacements built to last another 3 censuses). * I fail to see how anyone could spend $11B on such things. I mean, that's, what, $300 per capita? Engineering a small device should be in the single digit millions of dollars, shouldn't it (anyone know how much the Blackberry cost to design)? The device should use standard tech and interface easily with PCs. It should be cheap. Let's say $100 each for 1 million census workers =3D $100M. Where do they get $11B from?! * If there is significant waste and mismanagement, perhaps someone should consider decapitating the Census Bureau: a simple revocation of all posts pending review. * One thing I would note is that there should be a law requiring executives of public companies and their subsidiaries to be bondable. That is, in order to work as an executive for a company that is publicly held, or one in which the majority of the ownership is public, you must be trustable. * Ever notice how managers spend so much time trying to find ways to measure and improve output while there really is no solid criteria by which management itself can be measured? That is, why is executive X paid $8M/yr rather than $5M/yr or $2M/yr? Is said executive really more effective than having the business managed by a potted plant? If so, by how much? Note: end profit and/or share price, by which a lot of managers are measured, is too dependent upon market fluctuations and simple year-to-year sales. I'm sure that if we replaced the executive of any conglomerate by potted plants that the company would still continue to run for decades due to sheer inertia. Michael J. Lewchuk, Software Engineer (M.Sc., M.Eng. P.Eng.(Alberta Canada)) MatrikonOPC Technical Lead, Software Development 1-780-448-1010 x.4512 ------------------------------ Date: August 12, 2008 5:41:50 PM EDT From: "B.K. DeLong" <bkdelong_at_private> Subject: Attempt to muzzle MIT subway research backfires (Re: RISKS-25.28) [From Dave Farber's IP distribution.] Year after year, I am incredibly surprised at the amount and types of companies and organizations that have a knee-jerk reaction to a vulnerability or security hole being presented at either the Black Hat or DEFCON security events. Do PR professionals, crisis response managers, or corporate image specialists do their homework? Why isn't there an industry case study that says the fastest way to HELP a vulnerability in your software or product get absolute full and fast disclosure before you have time to fix it, is to try and stop it being discussed at one of these two events? In the MBTA's case, they hit the absolute pinnacle by filing a lawsuit in Federal court setting off a trigger to both the cadre of journalists, security researchers, civil libertarian activists, and hackers to begin doing everything in their power to make sure the story gets heard and (in some of their minds), the vulnerability gets exposed. The Public Relations Society of America should send out a brief every year in mid-July to remind them of the forthcoming security conferences and how extremely public attempts to quash research that may appear to be harmful to an organization's image will backfire horribly. In some cases, even quiet attempts to stop it could be detrimental as well. It should serve to all companies and organizations across the country (and world) that maybe in the long run cooperation with these researchers very early on (or at least as soon as the talks are announced every year) is the best way to ensure proper lead time to put together patches while allowing for full disclosure of the vulnerabilities that may effect a product's userbase. Why does no one seem to be getting the hint until after it happens to them? ------------------------------ Date: Thu, 14 Aug 2008 04:01:44 +0800 From: jidanni_at_private Subject: My date and place of birth are public Like everybody else, I was determined to keep my date and place of birth a secret to prevent identity theft -- until one day I discovered someone had written a Wikipedia entry on me, http://zh.wikipedia.org/wiki/%E7%A9%8D%E4%B8%B9%E5%B0%BC Mom will be proud! -- but only if I untwisted one fact first. Everything on Wikipedia is a battle, for me at least. To establish that I was BORN in Philadelphia, but GREW UP in Chicago, just saying "I was there, I ought to know", is not enough. They need reliable references. Something they can quote. I.e., it all spelled out on my personal website, which I then did. And of course all proper famous people have a date of birth listed (which I dare not cheat on as you never know what database they'll be using at Heaven's Gate on Judgment Day :-) By the way, one's Taiwan temporary Tax ID is date of birth + first two letters of surname: 19601216JA. Good thing I don't have a twin. So I'm now "living in a glass house". Well, plastic: http://jidanni.org/me/home/images/ ------------------------------ Date: Wed, 13 Aug 2008 01:50:09 -0700 From: Geoff Kuenning <geoff_at_private> Subject: Re: How reliable is DNA ...? (Schaefer, RISKS-25.27) Actually, there's a third question that can be asked: if you randomly choose a particular person at your party, what is the probability that that person shares your birthday? Obviously, it's one in 365.25, or about 0.3%, and the probability is independent of the number of people at the party. The problem is that during criminal investigations, investigators can ask either question 2 or question 3, but evidence presented to the jury quite consistently gives the probabilities from question 3, and in a number of cases judges have prevented defense attorneys from pointing out that the wrong calculation has been used. (Question 3 gets asked when the police have identified a suspect through other means, and the DNA match is used to confirm or reject the hypothesis. Question 2 gets asked when there is no suspect, and a statewide DNA database is searched. If you have a big enough database--and some states do--you're almost guaranteed to get a hit.) Geoff Kuenning geoff@private http://www.cs.hmc.edu/~geoff/ ------------------------------ Date: Thu, 14 Aug 2008 11:09:31 +1200 From: rob searle <robert.searle_at_private> Subject: Re: How reliable is DNA ...? Schafer RISKS 25.28 I mostly agree with this interpretation but the asterisk note at the end is more a hope a truth. In a number of investigations an entire community is asked to provide DNA "to exclude them" and there is also a lot of "nothing to hide, nothing to fear" innuendo. The DNA evidence in such cases is tainted with the birthday paradox, family relationships (and in many communities secret relationships). An alternative view, from Medical research, is that a multi-variate study needs to adjust its correlation significance threshold downward to take account of the number of variables. For example, the significance of finding a correlation between behaviour A and disease D in a study of the available evidence is much stronger than that of finding a correlation between one of A, B, C, and one of the diseases D, E, F. ------------------------------ Date: Wed, 13 Aug 2008 23:20:28 -0400 From: Brian Hayes <brian_at_bit-player.org> Subject: Re: How reliable is DNA ...? (Michael Black, Steve Schafer) Michael Black's analysis of DNA forensics likens a genetic fingerprint to a binary numeral of nine to thirteen digits. In effect, Black assumes that each genetic locus has just two possible forms, or alleles, which occur with equal probability. In fact, the markers commonly used in DNA forensics have dozens of alleles. Thus the number of possible 13-locus matches is not 2^13 but N^13 where N has a value somewhere in the neighborhood of 10 or 15 or even 25. The number is reduced somewhat (and the calculation is made more complicated) by the fact that not all the alleles are equally likely, but the number of variants is well above 8,192. There's a good explanation of all this in a 1992 report from the National Research Council, The Evaluation of Forensic DNA Evidence (see especially pp. 14-15). The report is available on Google Books at http://books.google.com/books?id=SnHYMZXAkQEC There's plenty of reason to be skeptical of overwrought claims that DNA never lies, but the numerical counter-evidence isn't quite as stark as Black suggests. ------------------------------ Date: Thu, 14 Aug 2008 12:19:41 +0100 From: Bob Buxton <bob_buxton_at_private> Subject: Re: How reliable is DNA ...? (Schaefer, RISKS-25.28) Steve's analogy to the Birthday Problem/Paradox can be extended further in considering the DNA question. The birthday problem probabilities contain a number of assumptions: - We know the number of days in the year - Births are evenly distributed across the year - Party invites are random If we find at my party there are lots of people with a common birthday or more than two with my birthday we have to ask whether: - This is perfectly normal and likely event based on the probabilities - It is a rare, but still normal 'fluke' - The interpretation of the probabilities was incorrect. - The calculation of the probabilities was incorrect - There is a flaw in the underlying assumptions. I am neither a genetics or statistical expert but it seems that Troyer found a result that didn't match the expected results for the first part of the birthday problem. You can't tell much from a single sample but if you get similar results from multiple samples you have a better basis for questioning the underlying assumptions and by modifying them provide a far better estimate of the true probability of an actual genetic match from a profile. With DNA I am not even sure we are confident with knowing the number of day in a year It seems to me that the FBI in their attempts to prevent lawyers using/misusing statistical data to induce confusion in mathematically naive juries by casting doubt on Troyer's work and blocking attempts to conduct further analysis are actually preventing legitimate research which could ultimately provide a proper basis for the uniqueness statistics. ------------------------------ 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.29 ************************Received on Tue Aug 19 2008 - 10:58:29 PDT
This archive was generated by hypermail 2.2.0 : Tue Aug 19 2008 - 11:21:48 PDT