29-Mar-94 4:23:45-GMT,28693;000000000001 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21379; Mon, 28 Mar 94 23:23:44 EST Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA01128; Mon, 28 Mar 94 23:22:32 EST Received: by chiron.csl.sri.com id AA17067 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Mon, 28 Mar 94 20:14:39 -0800 From: RISKS Forum Sender: RISKS Forum Date: Mon, 28 Mar 94 20:14:37 PST Subject: RISKS DIGEST 15.70 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 28 March 1994 Volume 15 : Issue 70 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: April Fools on the Senate (John Dvorak and Chris Casey via Arthur R. McGee) Risks to government (Robert Davis) IRS persistence (Dave Methvin) BT Billing computers innocent (Marcus Marr) Insurance claims ignore patients name (David Bazell) The RISKs of Canadian Poodles using 911 (John Oram) Ottawa, Canada, Radio contest overloads phone system (Henry Troup) 911 as wrong number - they don't seem to care anymore (Jeff Hibbard) Re: Denver Baggage Handling (Jan Vorbrueggen) Re: The RISKS of whale removal (David G. Novick) Re: Banknotes and photocopiers (Tom Standage, Padgett Peterson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Fri, 25 Mar 1994 19:50:47 -0800 (PST) From: "Arthur R. McGee" Subject: April Fools on the Senate (fwd) [PLEASE SEE MODERATOR'S NOTE BEFORE THE INCLUDED MESSAGE BELOW. THIS EXPLICITLY MARKED APRIL FOOL'S PIECE IS INCLUDED NOT FOR ITS SURPRISE VALUE, BUT IN THE PUBLIC INTEREST. PGN] ---------- Forwarded message ---------- Date: Fri, 25 Mar 94 12:16:58 EST From: Chris_Casey@kennedy.senate.gov To: ace-mg@esusda.gov Subject: April Fools on the Senate Hello ACE, In the April issue of PC Computing, John Dvorak's column describes a Senate Bill, supposedly introduced by Senator Leahy and co-sponsored by Sen. Kennedy, to keep people from being intoxicated on the information highway. The column is an April Fools hoax and I'm sure plenty of people will find it amusing (see below). Unfortunately there are also people that are actually believing it to be true. Our office has received several calls from outraged constituents and I understand Leahy's staff has as well. I originally received the article via e-mail, and I understand that the on-line rumors are flying leading some people to learn about it without the benefit of the actual article (which when read closely, reveals the hoax). Congress has taken some great forwards steps recently, particularly through the availability of the Senate and House gophers (gopher.senate.gov, gopher.house.gov) and it would be unfortunate if people weren't aware of them. I share this with ACE in hopes that you can help quash any of these on-line rumors if you see them. Feel free to put people in touch with me if they'd like to hear more about what's happening in the cyber-Capitol :-) Thanks for any help. I enjoy April Fools gags, but a lot of folks just aren't getting this one! Regards, Chris ############################################################################ Chris Casey chris_casey@kennedy.senate.gov Office of Senator Kennedy 202/224-3570 Washington, DC 20510 ############################################################################ [RISKS MODERATOR'S NOTE: THE FOLLOWING ITEM IS REPRODUCED IN THE RISKS FORUM WITH THE KIND PERMISSION OF THE AUTHOR, WHO HAS HIMSELF RECEIVED SEVERAL CALLS FROM PEOPLE WHO MISSED THE SPOOFINESS. John is quite well known for his annual spoofs. He noted to me that there are (at least) four clues herein. (See if you can find them, but don't bother informing RISKS.) As we approach the big day, I note that this piece is akin to the 1984 Chernenko spoof (due to Piet Beertema) and the "Spafford" spoof (due to Chuck von Rospach), the latter (see RISKS-6.52, 1 April 1988) fully laden with self-referential clues. PGN] >Trust Congress? Not With This Unbelievable Lair of Slop >PC Computing, April 1994, page 88. >By John C. Dvorak > > When Vice President Gore began talking about the Information Highway, > we all knew the bureaucrats would get involved more than we might > like. In fact, it may already be too late to stop a horrible Senate > bill from becoming law. > > The moniker -- Information Highway -- itself seems to be responsible > for SB #040194. Introduced by Senator Patrick Leahy, it's designed to > prohibit anyone from using a public computer network (Information > Highway) while the computer user is intoxicated. I know how silly this > sounds, but Congress apparently thinks that being drunk on a highway > is bad no matter what kind of highway it is. The bill is expected to > pass this month. > > There already are rampant arguments as to how this proposed law can > possibly be enforced. The FBI hopes to use it as an excuse to do > routing wiretaps on any computer if there is any evidence that the > owner "uses or abuses alcohol and has access to a modem." Note how it > slips in the word 'uses'. This means if you've been seen drinking one > lone beer, you can have your line tapped. > > Because this law would be so difficult to enforce, police officials > are drooling over the prospect of easily obtaining permits to do > wiretaps. Ask enforcement officials in Washington and they'll tell you > the proposed law is idiotic, but none will oppose it. Check the > classified ads in the "Washington Post" and you'll find the FBI, > National Security Agency, and something called the Online Enforcement > Agency (when did they set that up?) all soliciting experts in phone > technology, specifically wiretapping. > > It gets worse. The Congressional Record of February 19, 1994, has a > report that outlines the use of computerized BBSes, Internet, > Inter-Relay Chat, and CompuServe CB as "propagating illicit sexual > encounters and meetings between couples -- any of whom are > underage...Even people purporting to routinely have sex with animals > are present on these systems to foster their odd beliefs on the > public-at-large." A rider on SB #040194 makes it a felony to discuss > sexual matters on any public-access network, including the Internet, > America Online, and CompuServe. > > I wondered how private companies such as America Online can be > considered public-access networks, so I called Senator Barbara > Boxer's office and talked to an aide, a woman named Felicia. She said > the use of promotional cards that give away a free hour or two of > service constitutes public access. You know, like the ones found in the > back of books or in modem boxes. She also told me most BBS systems > fall under this proposed statute. When asked how they propose to > enforce this law, she said it's not Congress's problem. "Enforcement > works itself out over time," she said. > > The group fighting this moronic law is led by Jerome Bernstein of the > Washington law firm of Bernstein, Bernstein and Knowles (the firm that first > took Ollie North as a client). I couldn't get in touch with any of the > co-sponsors of the bill (including Senator Ted Kennedy, if you can believe > it!), but Bernstein was glad to talk. "These people have no clue about the > Information Highway or what it does. The whole thing got started last > Christmas during an antidrinking campaign in the Washington D.C., metro > area," Bernstein said, "I'm convinced someone jokingly told Leahy's office > about drunk driving on the Information High and the idea snowballed. These > senators actually think there is a physical highway. Seriously, Senator Pat > Moynihan asked me if you needed a driving permit to 'drive' a modem on the > Information Highway! He has no clue what a modem is, and neither does the > rest of Congress." > > According to Bernstein, the antisexual wording in the bill was > attributed to Kennedy's office. "Kennedy thought that technology was > leaving him behind, and he wanted to be perceived as more up-to-date > technologically. He also though this would make amends for his alleged > philandering." > > Unfortunately, the public is not much better informed than the > Senate. The Gallup Organization, at the behest of Congress, is > polling the public regarding intoxication while using a computer and > online "hot chatting." The results are chilling. More than half of the > public thinks that using a computer while intoxicated should be > illegal! The results of the sexuality poll are not available. But one > question, "Should a teenage boy be encouraged to pretend he is a girl > while chatting with another person online?" has civil rights activists > alarmed. According to Kevin Avril of the ACLU, "This activity doesn't > even qualify as virtual cross-dressing. Who cares about this stuff? > What are we going to do? Legislate an anti-boys-will-be-boys law? It > sets a bad precedent." > > I could go on and on with quotes and complaints from people regarding > this bill. But most of the complaints are getting nowhere. Pressure > groups, such as one led by Baptist ministers from De Kalb County, > Georgia, are supporting the law with such vehemence that they've > managed to derail an effort by modem manufacturers (the biggest being > Georgia-based Hayes) to lobby against the law. "Who wants to come out > and support drunkenness and computer sex?" asked a congressman who > requested anonymity. > > So, except for Bernstein, Bernstein, and Knowles, and a few members of > the ACLU, there is nothing to stop this bill from becoming law. You > can register your protests with your congressperson or Ms. Lirpa Sloof > in the Senate Legislative Analysts Office. Her name spelled backward > says it all. ------------------------------ Date: Mon, 28 Mar 94 16:20:48 GMT From: rdavis@nyx10.cs.du.edu (Robert Davis) Subject: Risks to government My records show this happened on 22 February 1994. The risks we take using computers are one thing, but the risks government officials take when talking about computers are extreme. Here I am, at home watching CSPAN. The entire morning is devoted to the new regulations from the Federal Communications Commission concerning cable television. I find it quite interesting. Then the chairman of the FCC shows up in a news conference. He answers questions about the new rules and regulations. The chairman of the FCC then opines that information about and from the FCC will appear on the "Information Superhighway". He says to connect to ftp.fcc.gov What follows is a near a quote as I remember his words: "G O V stands for government. F C C stands for [long pause] F C C. I don't know what F T P stands for." Remember, this is the chairman of the Federal Communications Commission speaking live on CSPAN. === Being a curious person, I made the connection to ftp.fcc.gov and as of that morning, no FCC files were available for FTP. However, one directory, bearing a name which may have been the initials of a system operator at the FTP site had something in it. One file, a GIF picture of actress Erika Eleniak, wearing most of her clothing, was available for FTP. So I grabbed it. As of today (28 March) that directory does not appear on the system, but there are directories containing FCC stuff. rdavis@nyx.cs.du.edu Robert Davis Salina, KS ------------------------------ Date: Sun, 27 Mar 94 22:47 EST From: Dave Methvin <0003122224@mcimail.com> Subject: IRS persistence Unlike [many others], I dutifully filed an IRS Form 942 for a nanny we employed in the first quarter of 1992. Unfortunately, my calculations were too high by a dollar; I suspect human error. The ever-vigilant IRS computer found my mistake and issued a $1.01 refund check within a month, even adding that penny for interest. Something about having a $1.01 government check really tickled me, so I decided to just keep it instead of cashing it. Since the check expires after a year, I figured I was doing my part to reduce the deficit. This week, two years later, I get _another_ check for $1.01, with the same notation ("F-942 REF 03/92") as the previous check. I'm not cashing this one either; now I want to find out how badly they want to give me this money. dwm ------------------------------ Date: Mon, 28 Mar 94 13:50:39 BST From: Marcus Marr Subject: BT Billing computers innocent The current issue of New Scientist (26 March 1994, p. 19) includes an article following up from the one I quoted (RISKS-15.56, 17 February 1994: Telephone charges fail to fit the bill) regarding the overcharging on some telephone bills in multiples of \pounds 420. ``Human error, not computer failure, was to blame for British Telecom's recent overcharging of some subscribers. BT says that each case of incorrect billing was caused by ``an extremely unlikely combination of two human errors''. The findings exonerate the computers, but indicate that BT staff sometimes ignore odd discrepancies in bills. The first error arose when an engineer working on a new digital exchange broke house rules and used a procedure borrowed from old analogue exchanges. He sent a handwritten note to BT's billing department, asking it to log the meter reading as zero on its computer. The computer's software registers the last four digits of the meter reading, and on being given a reading ending in a string of zeros it deduced that the meter reading must have risen past 9,999 to 10,000. When the time came to prepare the bill, the computer then took the same logic a stage further and added together two spurious quantities: one from the last real reading up to 10,000, and one from zero to the new reading. Each unit costs 4.2p, leading to an overcharge of \pounds 420. The second error came when BT's automatic verification system correctly highlighted these figures as inordinately high compared with past readings on the same line. But BT's staff ignored the warning and dispatched the bill, complete with errors.'' New Scientist made no reference to their last sentence of the original article: ``[Insiders] believe that BT has a bug in its accounting software and that the problem is thus much more widespread than has so far been recognised.'' >From the article as I understand it, it seems that the computer software has difficulty in making the distinction between freshly reset meter readings, and normal `clocked' meter readings. This could be explained cleanly if it was not possible (or unnecessary or difficult) to reset the meters of old analogue exchanges. The move to digital exchanges would therefore either need a change in the software or a change in the procedures. Ignoring my suppositions, though, the system (including personnel and computers) is designed correctly to cope with both analogue and digital exchanges. ------------------------------ Date: Mon, 28 Mar 1994 09:58:33 -0500 From: bazell@cuba.gsfc.nasa.gov (David Bazell) Subject: Insurance claims ignore patients name I just got off the phone with my prescription plan holder, trying to find out why my son Jason's deductible had not been fulfilled. I picked up a prescription for him last week and had to pay the full $43.95 cost of the medicine. My plan has a $50 deductible per family member but I was sure that he had had several other prescriptions since the beginning of the plan year. I check my records and, sure enough, the prescriptions totaled more than $50. After checking back with the pharmacy, it was determined that although the Jason's name was on the prescription, the prescription had gone toward fulfilling my other son Graham's deductible. The pharmacist had entered the wrong code (02 rather than 03). However, I was also sure that Graham had had several prescriptions filled, so his deductible should already have been fulfilled. Further checking showed that Graham's prescriptions had been charged toward my deductible (my code is 00). Talking to the prescription plan representative on the phone, I declared that this was a stupid way to do things. The system ignored the name that was entered and keyed only on the family member's number. I was assured that this was the best way to reduce the RISK of a mistake (he used that word). I guess the person who set up the system must have had several siblings with the same name. Fortunately, my wife keeps all our medical records in good order so we were able to find documentation and figure out what had happened. The monitary cost to us would have been small if we had not sorted it out, but I can easily see this happening where the costs could be much higher. Dave Bazell, General Sciences Corporation. ------------------------------ Date: Thu, 24 Mar 1994 22:44:12 -0800 From: oramy92@halcyon.com (John Oram) Subject: The RISKs of Canadian Poodles using 911 VANCOUVER (Reuter) - A pesky pet played havoc with Canadian police who responded to an emergency call only to find they were barking up the wrong tree. A team of officers burst into a Vancouver home after receiving a 911 emergency phone call but found nothing more threatening than a poodle inside, police said Wednesday. The dog had knocked the phone off the hook and hit an automatic dial button that called police. Police feared the worst when all they heard on the line was the dog barking. ``We came screeching over. It was a bit silly,'' confessed police spokesman Joe Arduini. They had 911 on speed dial? Come on - that's inexcusable, given how easy it is to accidentally hit the wrong button on a phone. Do that many people die because they never finish dialing all three numbers? "Poor guy. Would have made it, but he was only able to hit 9-1." I suppose the moral of this story is that the RISK isn't necessarily in the technology but rather in the people (mis)using it. John Oram oramy92@halcyon.com ------------------------------ Date: Mon, 28 Mar 1994 11:11:00 -0500 From: "henry (h.w.) troup" Subject: Ottawa, Canada, Radio contest overloads phone system Friday, March 25th, the Ottawa radio station CHEZ-FM offered 53 pairs of Pink Floyd concert tickets free to callers. The offer was open from 6 pm. The station is on a specially equipped exchange, but an estimated 300,000+ call attempts in an hour caused delayed dial tone and other problems from Cornwall, Ontario to Pembroke, Ontario (about 100+ miles). Ottawa is Canada's capital. One story noted that some people (100 or so) called 911 to report telephone trouble, instead of 611. There were reports of actual outages, but it is not clear that people were waiting for dial tone and not hanging up and trying again. Personal observation - I certainly had delayed dial tone, but only delayed 10 seconds or so. One person I spoke to said that he had had seven phone lines active trying to get the free tickets. Very little is new here. I leave the obvious pun for the moderator. ------------------------------ Date: Mon, 28 Mar 1994 12:27:33 -0600 From: Jeff Hibbard Subject: 911 as wrong number - they don't seem to care anymore When 911 was first implemented (many years ago) here in Peoria IL, everyone with a phone number of the form x91-1xxx was forced to change their numbers. After a few years, though, the phone company started reassigning numbers of this form. Jeff Hibbard jeff@bradley.bradley.edu [In various old small-town switching centers, one could dial just the last four digits, or in some cases five digits, for local calls. That led to similar problems when 911 was introduced, and has now disappeared almost everywhere in the U.S.A. (although for other reasons as well.) PGN] ------------------------------ Date: 25 Mar 94 12:41:34 GMT From: jan@neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen) Subject: Re: Denver Baggage Handling (Wexelblat, RISKS-15.68) 1. I would think Frankfurt/Main airport (FRA) was the first to have an integrated, computer-controlled baggage distribution system. For years I heard they were the only international airport able to guarantee 45 minute connections because of it. 2. When the system was installed (ca. '72), the contractor, AEG, required something like six months past the deadline to get it running. In that time, they reputably paid a penalty (or whatever you call "Konventionalstrafe" in English) of DM 200K _per_day_. I don't think they made much profit on the contract... Jan ------------------------------ Date: Mon, 28 Mar 94 10:02 PST From: novick@cse.ogi.edu (David G. Novick) Subject: Re: The RISKS of whale removal (Stalzer, RISKS-15.67) I cannot explain why the Highway Dept. chose to blow up the deceased whale. I can, however, explain why this problem fell to the Highway Dept. Unlike most states, which allow private ownership of beaches, Oregon has kept all its beaches owned by the state. The mechanism for this, curiously, is that the beach is technically part of the of state highway system--although you generally aren't allowed to drive on it. So the whale shows up on a state highway, and it's the Highway Dept.'s problem David G. Novick | Department of Computer Science and Engineering | Oregon Graduate Institute of Science & Technology novick@cse.ogi.edu | 20000 N.W. Walker Road tel (503) 690-1156 | P.O. Box 91000 fax (503) 690-1548 | Portland, OR 97291-1000 ------------------------------ Date: Mon, 28 Mar 94 13:49:47 -0800 From: Tom Standage Subject: Are there really pictures of banknotes inside photocopiers? Following the resent posting about how photocopiers prevent banknote forgery, I wonder how many other readers' jaws dropped open at the suggestion that there is a ROM inside a colour photocopier (such as the Canon CLC350/550) with images of common banknotes in it. This just wouldn't make sense, aside from the fact that it would rapidly go out of date - it would simply be too computationally expensive to compare every image placed on the copier with the images in ROM. The Canon machines in question can also be used as colour laser printers in conjunction with special interfaces, so presumably any anti-forgery computer inside the copier would also have to check that banknotes weren't being scanned into a personal computer and then printed out via the colour copier. This is absurd. We have a CLC300 at work, and when an engineer came to fix it one day, he said that the problems we were having (with jammed paper) were a design fault that had been fixed on the CLC350. I asked what other features the 350 had, and he said it had anti-forgery features - and proceeded to tell me the same story about a chip with pictures of banknotes in it. I found this so hard to believe that I asked around, and eventually someone gave me a more believable explanation. Apparently the security measures depend on special inks used when the banknotes are printed. These inks change colour when illuminated by the scanner in the copier, and produce copies of the banknote with an obvious colour shift. I don't know whether the 350 and 550 have a different kind of bulb in the scanner or are able detect the special inks, but I have also heard of other documents that won't copy properly because the copier thinks they're banknotes. Rumour has it you can get round this by photocopying through very thin tracing paper - which presumably works with banknotes as well. Anyhow, perhaps someone at Canon can give us a definitive answer. On the other hand, I wouldn't be surprised if they wished the status quo to continue, where we all believe that copiers have chips with pictures of banknotes in them. What makes me laugh is the message on the front panel of the CLC300, which warns you not to copy money or certain other documents: "you *may* be committing a criminal offense for which you *may* be prosecuted." Pretty strong language, huh? ------------------------------ Date: Fri, 25 Mar 94 19:58:12 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: "Funny Money" and Smart Copiers Once upon a time, long long ago in a galaxy far far away, an automobile manufacturer known to all of its employees as "Generous Mother" began using computers to control such things as mixture and spark advance and a host of other variables. The maps for these variables were carried in 1k x 8 PROMS. Certain individuals who shall remain nameless acquired the maps of these programs for certain "performance" cars and designed their own maps. Unfortunately, these new maps, though amazing in improving performance and efficiency were not what the manufacturer had certified. So the aspiring young engineers replaced the 1k x 8 PROM with a 2k x 8 EEPROM and a switch concealed under the dashboard. The lower 1k contained the stock settings and the upper 1k, settings of a more "interesting" variety. For roadside tests the switch was turned "off" and for normal driving "on". I suspect that copiers that rely on "firmware" to block copying of bills might soon acquire such switches. Padgett [RISKS received lots of mail on this topic, most of which is NOT included, including bob@demosthenes.ilt.tc.columbia.edu (Bob Matsuoka), dgursky@nextsrv1.andi.org (David Gursky), jml4@cus.cam.ac.uk (John Line), hoover@cs.ualberta.ca (Jim Hoover). dylan@mundil.cs.mu.OZ.AU (Dylan John SHUTTLEWORTH) noted that Australian $5 and $10 notes are plastic with a transparent "hole" around a hologram. PGN] ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.70 ************************ 30-Mar-94 1:44:58-GMT,30187;000000000001 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11986; Tue, 29 Mar 94 20:44:57 EST Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA13780; Tue, 29 Mar 94 20:34:32 EST Received: by chiron.csl.sri.com id AA03745 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 29 Mar 94 17:29:40 -0800 From: RISKS Forum Sender: RISKS Forum Date: Tue, 29 Mar 94 17:29:37 PST Subject: RISKS DIGEST 15.71 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 29 March 1994 Volume 15 : Issue 71 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Risks of washroom automation (Paul Colley) Pay-per-View failure lets adult station go unscrambled (Mike Carleton) Role-playing Addiction (Mich Kabay) Software theft statistics (Mich Kabay) Risks of spelling checkers (John Girard, PGN) Busy-waiting woes (Darren Senn) Recent useful newspaper pieces on crypto policy (Lance J. Hoffman) Re: L.A. Phone Fire (Nevin Liber) Re: Canadian Poodles using 911 (Shawn Mamros) Re: Banknotes and photocopiers (Mike Sullivan) Re: IRS persistence (Robin Kenny) Preliminary Program: 7th IEEE Computer Security Foundations Workshop (Li Gong) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon Mar 28 14:22:02 1994 From: ember!pacolley@qucis.queensu.ca Subject: Risks of washroom automation (Erma Bombeck) Here's one paragraph of Erma Bombeck's humour column, The Kingston Whig-Standard, 28 March 1994. "I dropped by an airport washroom. In my stall, I wrestled with my jumpsuit, and in doing so the belt fell into the commode. Before I could retrieve it, the automatic flusher sucked it away and into the sewers of San Jose. I held my hands under the automatic water tap and went for a paper towel. I turned in time to see my handbag fall into the sink and activate the water. It proceeded to drown." The column also enumerates many other more familiar problems with automation. - Paul Colley colley@qucis.queensu.ca +1 613 545 3807 [Beware of the automatic handwringer. PGN] ------------------------------ Date: Tue, 29 Mar 94 13:37:20 EST From: mcarleton@zendia.enet.dec.com Subject: Pay-per-View failure lets adult station go unscrambled Cable company adds unexpected Spice to subscriber's dinner hour. A problem with a pay-per-view system caused all customers of the Greater Media Cable TV service in Worcester Massachusetts to receive the unscrambled broadcast of an Adult cable cannel offered by the system. The Spice cable channel was unscrambled for 90 minutes between 6:00pm and 7:30pm on Monday March 28th. According to a representative of the cable company, Ed Goldstien, the cause of the glitch was not known and an investigation was in progress. Goldstien presented the cable company's apology and promise that it would not happen again to subscribers over the local radio station WXLO. The Greater Media Cable system uses a call in voice response system to allow customers to activate the pay-per-view stations offered by the system. The activation code for the customer's cable box is broadcast over the cable system to unscramble the selected pay-per-view offering. RISKS readers could speculate that this incident is an indication that a universal activation code must exist for all cable decoders in the system. We could further speculate that the voice response system could have broadcast this code in response to a pay-per-view request of a single subscriber if internal tables were faulty. The RISK here is dependence on an automatic system to save cost when the cost of its failure is not taken into account. Mike Carleton mcarleton@zendia.enet.dec.com ------------------------------ Date: 29 Mar 94 12:59:07 EST From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Role-playing Addiction Washington Post Staff Writer John Schwartz has published a moving and insightful article entitled, "Game Boy." It explores the life and death of an eighteen year old man addicted to cyberspace role-playing. I have asked Mr Schwartz for permission to post the original article in its entirety. For the time being, here's a brief summary. <> Nathaniel Davenport was an unassertive, socially-isolated teenager who did poorly in high school but had excellent S.A.T. scores. He entered the University of California at Santa Cruz autumn 92 and quickly became active in AmberMUSH, a M.U.D. (multi-user dimension) loosely based on the _Amber_ stories of Roger Zelazny. AmberMUSH "features a series of mirrors that you walk through into different elaborate fictional situations: One is the ruins of a city; another a rowdy Western town; a third, the smoky darkness of the "World's End Bar," a cross-dimensional speakeasy. Wherever you go, other players are there, gathered from around the world to engage in a collective fantasy; you converse with whoever is in the `room' you are in at the time, something like a pickup game in basketball." Nathaniel became a M.U.D. addict. He was asked to leave his university because he had missed all of his classes while living in AmberMUSH. Back in Virginia, he continued his addiction through student terminals at George Mason University, where he would spend entire days interacting with other role players from around the world. Nathaniel's persona in AmberMUSH was Sabbath, a beautiful seductress devoid of empathy for the characters she manipulated. For example, she spent months seducing another character, only to goad him to his death in a battle with a more powerful character. After bitter arguments with his family, Nathaniel agreed to get a job. He began working at a computer company from 5 a.m. to 1:30 p.m. He incorporated his new job into his frenetic role-playing life by skimping on sleep. A week after starting work, he apparently fell asleep at the wheel of his mother's car and smashed head-on into a truck. He died instantly. When Nathaniel's father sent out requests for correspondence on the Internet, addressing the AmberMUSH users his son had spent so much of his life with, he was astonished at the volume and quality of the responses. Over time, Tom Davenport came to believe that Nathaniel's interactions were not futile game-playing or pornographic flirting. "[I]n his quest to better himself, Nathaniel had also turned to the tool he was most comfortable with: He was using his character to explore social interactions, to learn to be funny, charming, direct. `He was using the net,' says Davenport, `to work out his life.'" "Contacted via e-mail, AmberMUSH administrator Mark Grundy said the death of Nathaniel Davenport has made him think hard about players' responsibility to one another in the on-line society. `The future for human relationships in the Communication Age seems particularly uncertain,' Grundy wrote. `For me, the lesson that Tom has taught is that the answers can come, if you look for them with the right heart.'" <> This young man, isolated from a local community, unhappy in his own skin, found happiness as a different person in a different world. The pity is that he lost touch with his own body's needs. Like a rat on an endorphin high, poor Nathaniel died from addiction to his own form of satisfaction. Should we shrug and dismiss his death? "It's his problem--he was free to act as he chose." Surely, but could anyone in his cyberspace community have helped avoid this sad end, crushed uselessly at the age of 18? I wonder if cyberspace role-players will reach out to accept and support the tangible person behind the electronic persona? Would it have helped if someone had asked how Nathaniel was doing instead of focusing only on Sabbath? As human beings interact electronically, we will be forced to integrate morality and reason into cyberspace. Cyberspace must not remain a moral vacuum; common sense must grow to encompass all the ways we now have to touch other people's lives and alter our own. Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn ------------------------------ Date: 29 Mar 94 12:59:16 EST From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Software theft statistics >From the Associated Press newswire via Executive News Service on CompuServe (GO ENS): JEANNINE AVERSA, Associated Press Writer, reports on the Software Publishers Association's statistics concerning software theft. Key findings: o Worldwide losses of $7.4 billion for business software in 1993. o Rate is down 25% from $9.7 billion in 1992. o Business software (spreadsheets, electronic mail, accounting and data base programs) sales revenues in 1993 were $6.8 billion. o Companies whose employees make unauthorized copies or put single-copy programs on network servers account for the most frequent violations of software copyright. o The SPA audited or initiated lawsuits against 245 companies, all of which were resolved out of court. o Settlements totalled $3 million. o Manufacturers in the U.S. lost $1.57 billion; Japan lost $650 million; France lost $435 million. o Software theft grew fastest in India and Pakistan (up 95%); Korea and Brazil showed 89%, and Malaysia's theft grew 88%. Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn ------------------------------ Date: Tue, 29 Mar 94 23:32 BST-1 From: John Girard Subject: Risks of spelling checkers I was recently quite shocked (UK: gob-smacked) to find that an event connected with my spell checker could have put me at risk of losing my job. I was editing a publication to be sent to several hundred of my client contacts, and had made a series of trivial spelling corrections, the last being a "replace". Sitting poised over the replace button, I was presented with the suggestion that the word "Goldman" (as in a large company we all know) should be replaced with "goddamn". The word processor involved was MS Word for the Macintosh. I then tested this on Word for Windows, and got the same result. (I have the `always suggest' option selected) This event scared me greatly, because it is easy to go unconscious in front of the mouse and press "replace" one too many times without realizing the result. I contacted my support agency and was told that "goddamn" is in the main dictionary, and that I could not delete it from the main dictionary. It was suggested that I program Goldman as a replacement to goddamn. Of course, defining a replacement in this one case does not assure me that the "bad" word will not be suggested in the future for other replacements. And, I have not yet encountered other unprofessional and undesirable word replacements which I would grudgingly agree that, in an academic sense, belong in the dictionary, but are a risk to my job. Yet, I wait in fear of these discoveries. My concern here is that products such as word processors that are sold for use in "business" applications should either not freely suggest profane words in the main dictionary, or should have an option to leave them out or supply an extra warning. Obviously, the problem is further complicated by words or phrases that have different meanings in different countries even when the language seems otherwise equivalent. Has anyone else had problems similar to this? Are there any alternative "business-oriented" main dictionaries which can be purchased to eliminate the risk? And, should I be obligated to live-with/fix this problem when purchasing a "business" product? John Girard New Science Associates, Ltd./ UK ------------------------------ Date: Tue, 28 Mar 94 16:21:07 PST From: "Peter G. Neumann" Subject: Re: Risks of spelling checkers (Girard, RISKS-15.71) The RISKS archives are full of cases such as transforming a Mafia "enforcer" into an "informer", "payout" into "peyote", "back in the black" to "back in the AfroAmerican", and many other garbles. And I just happen to notice a note from Abhijit Chaudhari in the YUCKS digest (from spaf@cs.purdue.edu) noting that NeXTSTEP 3.0 Webster's barfs on "UNIX", and offers "unfix" instead. That is not Unix-friendly, although I distinctly recall Steve Jobs suggesting at the San Francisco birth announcement for NeXT that NeXT was UNIX-emulatable and UNIX-friendly (but that nobody would care once they had seen NeXT!). I wonder what that spelling corrector does to NeXT? Maybe it gets turned into a NeWT. ------------------------------ Date: Tue, 29 Mar 1994 00:19:48 -0800 (PST) From: sinster@scintilla.santa-clara.ca.us (Darren Senn) Subject: Busy-waiting woes A few years back, I was working as a student computer consultant at UC Santa Cruz. The San Diego Supercomputer Center was pulling itself up by its bootstraps, and a few of the researchers at UCSC had won grants of CPU time on SDSC's CRAY Y/MP. SDSC sent some of their tech. support staff up to Santa Cruz to give our researchers a quick introduction to UNICOS (CRAY's flavor of SYSV UNIX) and SDSC's special features. Needless to say, they didn't want to leave their tech support people in Santa Cruz, so they gave us a small grant for our consultants to use while learning their system. I was one of the lucky consultants who got to participate. So far so good. At the same time, one of my friends was finishing up his physics thesis (a weird little study of aerodynamic surfaces), and had written a small flight simulator to do some of his calculations. This study was weird enough that my friend was calling his programs 'funny', 'goofy', 'damgoofy', etc. It was a simple program which simulated the flight of a plane for a short duration, and the user couldn't adjust any control surfaces after the program started. As a favor to him and as a convenient way to learn more about the Y/MP, I ported his program over to UNICOS. The program normally asked the user for its parameters when it started up, printed the results to the terminal, and waited for the user to hit return before quitting. The program was almost entirely math, so all I had to do was convert it to batch processing. Simple: just change a few scanf()'s to fscanf()'s, tweak a few paths, and we're all set.... Or so I thought. (ominous background music, please). I ftp'd the files over to the cray, compiled them, and made a few short test runs. No problems. So I set it up to calculate 30 seconds of flight at 1ms intervals, and to print out the time when it started and stopped. Then I set it loose. It was truly impressive watching those columns of numbers scrolling by. But alas, my next class was starting, so I couldn't wait for it to finish. I was capturing the output to a file anyway, so I just disconnected and went to my class. That was Friday evening. Sunday morning rolls around, and I get rudely shaken from bed by a phone call at 7am! Imagine the nerve! hmph. It was SDSC's support staff calling. It seems that a renegade program had eaten up all the consultant's time grant by running continuously (100% CPU usage) for 35 hours in the interactive `batch` queue! Clearly this program was intended as some warped prank, considering it was called 'damgoofy'! Uh-oh. I was sure there was some kind of mistake, so I rushed up to campus to see what had happened. It turns out that I had forgotten to remove the program's last gets(): that's the line which made the simulator wait for the user to hit return before quitting. That shouldn't have been a problem in itself, since the function should've immediately returned with an error after it discovered it had lost it's terminal (when I logged out). It didn't. No problem, right? The program should've just stopped waiting for input, consuming no CPU resources. Nope. Under that version of UNICOS, the program was waiting in a busy-loop, uselessly using the CPU while it waited for input. :( Ooooops! Luckily SDSC was nice to us, and the Y/MP was underutilized back then anyway, so they just refunded the money, my friend got an impressive simulation, and I got an anecdote. :) Darren Senn Phone: (408) 988-2640 Snail: 620 Park View Drive #206 sinster@scintilla.santa-clara.ca.us Santa Clara, CA 95054 ------------------------------ Date: Tue, 29 Mar 1994 14:01:51 -0500 (EST) From: "Lance J. Hoffman" Subject: Recent useful newspaper pieces on crypto policy Two interesting newspaper articles on encryption policy recently appeared: In The Australian, an influential national newspaper similar to The Guardian in the U. K. or The New York Times in the U. S., a large article describes the Clipper chip controversy including a bit more technical detail than is common for U. S. newspapers. Professor Bill Caelli of Queensland University of Technology's School of Data Communications is quoted as saying "Is Clipper the start of a more onerous agenda? Does Clipper represent attempts to outlaw the use of encryption in any form by the public unless he or she uses an 'approved' (and breakable) cipher system such as Clipper? This last question is a far darker scenario and goes to the very heart of freedom and privacy in a democratic society." -- All this in The Australian of 29 March 1994. In the New York Times of 26 March 1994, on the first page of the second section and wrapping around to page 26, there is an article "Collisions in Cyberspace on Data Encryption Plan" which starts "To paraphrase Oscar Wilde, the Clinton Administration threw a couple of its lions into a den of savage Daniels here this week" (now last week). That refers to the Fourth Conference on Computers, Freedom, and Privacy in Chicago, and the article appears under a wonderful photo of Emmanuel Goldstein, editor of 2600, clad in T-shirt, etc., taling with Frank Carey of Bell Labs, replete in coat and tie, but holding beer bottle. The article goes on to describe an arrest of a man in the conference hotel (actually a conference attendee) who fit the description of fugitive hacker Kevin Mitnick and the rough go Dave Lytel of the President's Office of Science and Technology Policy had as the keynote speaker trying to defend Clipper. Professor Lance J. Hoffman, Department of Electrical Eng. and Computer Science The George Washington University, Washington, D. C. 20052 (202) 994-4955 ------------------------------ Date: Tue, 29 Mar 1994 02:32:49 -0700 (MST) From: Nevin Liber Subject: Re: L.A. Phone Fire (Weinstein, RISKS-15.67) We felt the effects here in Tuscon, Arizona, 500 miles and another state away from Los Angeles. I went to the local grocery store to do some shopping and, you guessed it, they couldn't take my charge card because of that fire (they had notices posted throughout the store). I guess it's not just earthquakes anymore that have a rippling effect all the way to Arizona... ------------------------------ Date: Tue, 29 Mar 94 10:55:27 EST From: mamros@ftp.com (Shawn Mamros) Subject: Re: The RISKs of Canadian Poodles using 911 (RISKS 15.70) John Oram , in RISKS 15.70: >They had 911 on speed dial? Come on - that's inexcusable, given how easy it >is to accidentally hit the wrong button on a phone. Not when the phone manufacturer provides speed dial buttons explicitly labelled for that purpose. I own a General Electric phone (purchased about five years ago) that has three buttons on it labelled "Fire", "Police", and "Ambulance". There are other risks associated with such a phone, in addition to that of pets (or small children) accidentally hitting one of those buttons. The buttons need to be programmed with the correct number, since 911 is not (yet) universal in the US. If the owner of a phone does not set the numbers for those buttons - or worse, moves without changing the numbers (where one of the old or new locations does not have 911) - one could picture a scenario where a guest is present, the phone's owner is incapacitated, and the guest tries to use the "Ambulance" button to contact same... -Shawn Mamros mamros@ftp.com [RISKS received a large number of messages on this topic, including those Jay Schmidgall , Jeff Nelson , Nevin Liber , Tom Russ ) Andrew Duane who noted built-in emergency features. The risks therein seem quite widespread. Also, Bob Peterson noted the risks of defaults returning when batteries are replaced. PGN] ------------------------------ Date: 29 Mar 94 00:12:24 EST From: Mike Sullivan <74160.1134@CompuServe.COM> Subject: Banknotes and photocopiers In RISKS-15.70, Tom Standage noted that some color photocopiers prevent forgery by reacting to the color shift in the ink. This seems similar to how our Xerox black-and-white copiers react to an American Express card. The cards apparently use two different inks for the pattern filling the face of the card, one of which is invisible to the copier, although both inks look identical to the eye. When photocopied, the card image bears the word VOID all over its face (this is the green card; haven't tried it with a gold or platinum one). Perhaps a similar technology is involved in preventing copying of currency. ------------------------------ Date: Wed, 30 Mar 94 10:16:25 +1000 From: Robin Kenny Subject: Re: IRS persistence (Methvin, RISKS-15.70) This is not a good idea. What happened to me, basically, was that I closed my old VISA account with the State Bank Victoria (Australia) with 4 cents credit, , believing I was a good guy for not trying to get the money out - after all, it probably costs VISA $x per transaction. Some years later I had occasion to apply for another VISA card... When trying to use my bank DEBIT card to pay for petrol a security alert was flashed to the operator and my card was seized. Using my ATM card showed no funds and my ATM card was seized. My PASSBOOK account had a security trigger fire when I presented it at the local branch... It was all caused by the previous VISA account; the four cents was never allowed to be reabsorbed by the bank and my application for a new card found a bug in the validation software that said "there is a problem with this applicant". This automatically put a hold on all my finances! Even the home loan joint account was frozen. It took TEN WORKING DAYS for a human to finally backtrack to the root cause (the security re-asserted itself each night) I did get an official letter of explanation (I was beyond accepting apologies) on letter-head so future repercussions could be minimised. What may happen to "dwm" could be something bizarre like being arrested by the IRS for undisclosed income, not so improbable as a friend had his 1987 tax refund assessed as income for 1988! (Did I read in RISKS about a person having $1M accidentally transferred into their savings account, now fighting it out with the bank over the $50,000 funds-transfer tax?) [The original item was in RISKS-15.60. I don't recall seeing the transfer-tax item before. PGN] Robin Kenny (robink@hparc0.aus.hp.com) ------------------------------ Date: Tue, 29 Mar 94 10:33:56 -0800 From: Li Gong Subject: Preliminary Program: 7th IEEE Computer Security Foundations Workshop [This workshop is by invitation of the General Chair only. To participate, please contact Professor Ravi Sandhu at sandhu@isse.gmu.edu as early as possible since the number of spaces is very limited.] 7th IEEE Computer Security Foundations Workshop (CSFW-7) (Preliminary Program) Franconia, New Hampshire, June 14-16, 1994 Tuesday, June 14 8:50-9:00am -- Welcoming Remarks Ravi Sandhu (George Mason University, General Chair) Li Gong (SRI, Program Chair) 9:00-10:30am -- Non-Interference and Composability Session chair: Jose Meseguer (SRI) * Unwinding Forward Correctability Jonathan Millen (MITRE) * A State-Based Approach to Non-Interference William Young and William Bevier (Computational Logic, Inc.) * Combining Components and Policies George Dinolt, Lee Benzinger and Mark Yatabe (Loral) 11:00-12:00pm -- Formal Methods and Semantics Session chair: Simon Foley (University College Cork) * Formal Methods for the Informal World Carol Muehrcke (Secure Computing Corporation) * Formal Semantics of Rights and Confidentiality in Deductive Databases with General Integrity Constraints Adrian Spalka (University of Bonn) 12:00-2:00pm -- Lunch Break and Croquet Tournament 2:00-3:00pm -- Modeling Session chair: Stewart Lee (University of Toronto) * Confidentiality in a Replicated Architecture Trusted Database System: A Formal Model Oliver Costich, John McLean and John McDermott (Naval Research Lab) * Conceptual Foundations for a Model of Task-based Authorizations Ravi Sandhu and Roshan Thomas (George Mason University) 3:30-5:00pm -- Panel on "The General Write-Up Problem" Panel moderator: John McDermott (Naval Research Lab) Panelists: to be confirmed Wensdesday, June 15 9:00-10:30am -- Cryptographic Protocol Analysis Session chair: Virgil Gligor (University of Maryland) * A Model of Computation for the NRL Protocol Analyzer Catherine Meadows (Naval Research Lab) * AUTLOG -- An Advanced Logic of Authentication Volker Kessler and Gabriele Riemer (Siemens, AG) * Nonmonotonic Cryptographic Protocols Aviel Rubin and Peter Honeyman (University of Michigan) 11:00-12:00pm -- Security Policies Session chair: John McLean (Naval Research Lab) * Formal Specification of Information Flow Security Policies and Their Enforcement in Security Critical Systems Ramesh Peri and William Wulf (University of Virginia) * A Taxonomy of Security Properties for CCS Roberto Gorrieri and Riccardo Focardi (Universita di Bologna) 12:00-2:00pm -- Lunch Break and Croquet Tournament 2:00-3:00pm -- Access Control Session chair: Joshua Guttman (MITRE) * One-Representative Safety Analysis in the Non-Monotonic Transform Model Ravi Sandhu and Paul Ammann (George Mason University) * Reasoning about Confidentiality Requirements Simon Foley (University College Cork, Ireland) 3:30-5:00pm -- Panel on "Reconsidering the Role of the Reference Monitor" * Redrawing the Security Perimeter of a Trusted System Dan Sterne and Glen Benson (Trusted Information Systems) Panel moderator: Dan Sterne Panelists: Len LaPadula (MITRE), Ravi Sandhu (GMU), Carl Landwehr (NRL), and Glenn Benson (TIS) Thursday, June 16 9:00-10:30am -- Protocol Security Session chair: Michael Merritt (AT&T Bell Labs) * Development of Authentication Protocols: Some Misconceptions and a New Approach Wenbo Mao and Colin Boyd (University of Manchester) * A Taxonomy of Replay Attacks Paul Syverson (Naval Research Lab) * Cryptographic Protocols Flaws Ulf Carlsen (Telecom Bretagne, France) 11:00-12:00pm -- Workshop Business Meeting 12:00pm -- Workshop Adjourns ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.71 ************************ 1-Apr-94 0:11:39-GMT,31514;000000000001 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27452; Thu, 31 Mar 94 19:11:37 EST Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11625; Thu, 31 Mar 94 19:04:47 EST Received: by chiron.csl.sri.com id AA08883 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Thu, 31 Mar 94 15:55:59 -0800 From: RISKS Forum Sender: RISKS Forum Date: Thu, 31 Mar 94 15:55:57 PST Subject: RISKS DIGEST 15.72 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Thursday 31 March 1994 Volume 15 : Issue 72 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Mud Slide Cuts East Coast Phones (PGN) Briton Survives "Monster" Attack due to computer glitch (Will Deatrick) Risk Evasion Measures Create New Risks (Stephen A. Stough) Rental cars and financial derivatives (Phil Agre) White collar crime in Australia (Mich Kabay) Hotline reassignment (Mich Kabay) Electronic purse (Mich Kabay) Dials! (Bob Frankston) Re: Spelling Checkers (Geoff Cole, Mary Shafer, Scott A. Siege, Simson L. Garfinkel) Disclaimers in software (PGN) Junior Exec's Reverse Alchemy (Martin Howard) Yet another SSN misuse (Brian Clapper) EFF Summary of Public Interest NII Summit 29 Mar 1994 (Stanton McCandlish) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Thu, 31 Mar 94 15:05:32 PST From: "Peter G. Neumann" Subject: Mud Slide Cuts East Coast Phones Telephone service to thousands of MCI Communications Corp. East-Coast customers was disrupted early in the morning of 30 Mar 1994 when a mud slide severed a fiber-optic cable. Calls into and out of the Washington D.C., Maryland, and Richmond VA areas were affected. Custromers in Miami, Atlanta, and St. Petersburg also reported disruptions. [Source: San Francisco Chronicle, 31 Mar 1994] ------------------------------ Date: 31 Mar 1994 12:20:48 -0800 From: "Will Deatrick" Subject: Briton Survives "Monster" Attack due to computer glitch The 30 March 1994 issue of the San Diego Union contained a Reuters story from Land's End, England. It reads in part: A mechanical sea monster designed to terrify tourists attacked and injured a set designer working on it ... the hydraulic tentacled beast went out of control because of a temporary fault in its computer program and held designer George Thain in its 3-foot toothed jaws for nearly a minute." The man was badly bruised, but otherwise unharmed. The story does not state what corrective action is planned, but the town chairman ``assured visitors they would have nothing to fear from the monster, which will be kept 3 feet away from spectators.'' Will will_deatrick@smtp.esl.com [Also heard on NPR by gat@aig.jpl.nasa.gov (Erann Gat). PGN] ------------------------------ Date: Wed, 30 Mar 1994 18:25:42 -0800 (PST) From: "Stephen A. Stough" Subject: Risk Evasion Measures Create New Risks Final report blames Lucas design, Lockheed's procedures for HTTB crash Federal safety officials yesterday blamed an inadequate actuator design by Lucas Aerospace and Lockheed's failure to take account of its shortcomings for the crash last year of Lockheed's one-of-a-kind High Technology Test Bed plane. In its final report on the Feb. 3, 1993, crash at Dobbins AFB, Ga., the National Transportation Safety Board said the plane lost all rudder control during a high-speed taxi test with a simulated No. 1 engine failure when an experimental fly-by-wire control system for the rudder disengaged. "The disengagement was a result of the inadequate design of the rudder's integrated actuator package by its manufacturer," NTSB said. A design feature in the actuator removes hydraulic pressure if the rudder position commanded by the pilot exceeds the actual rudder actuator position for a specified time, and the rudder position trails, according to the report. Lucas Aerospace designed the package, a self-contained unit configured to be a drop-in replacement for the existing Hercules/HTTB dual tandem rudder actuator. The HTTB had recently been modified to evaluate power-by-wire flight control systems developed by Lockheed, along with some 50 suppliers. Lucas' package was demonstrated on two flights in March 1992, which Lockheed, claiming success, noted was the first time the concept had been tested on a manned flight. Still, NTSB said that on at least one occasion the actuator had previously disengaged in flight, but "the company did not conduct a system safety review of the rudder bypass feature and its consequences to all flight regimes, nor of the (ground minimum control speed) test." The fact that neither pilot was trained as a flight test engineer contributed to the accident, the report said. "I do want to emphasize that the seven crew members were extremely qualified for the jobs they were doing," a Lockheed spokesman said in a prepared statement. "We still feel a great sense of loss for these colleagues and we praise their contributions to aviation. Beyond that, we prefer not to comment on the NTSB report, the investigation, or the accident." The highly modified L-100-20 Hercules transport was not programmed to become airborne, NTSB Chairman Carl Vogt said shortly after the accident (DAILY, Feb. 5, 1993, page 200). But an NTSB spokesman told The DAILY yesterday that "it is the analysis of the board that (the pilot) attempted to get the plane airborne at that moment," although to this day nobody knows why the takeoff was attempted. The report noted that the flight test plan specified that engine power be retarded if the rudder became ineffective. The aircraft was at full power but had not reached takeoff speed when it briefly became airborne, clipped a Navy clinic and crashed about 200 yards north of the runway, killing all seven aboard. Lockheed said it was reviewing the NTSB's data, adding that "action will be taken as appropriate." ------------------------------ Date: Thu, 31 Mar 1994 15:34:26 -0800 From: Phil Agre Subject: Rental cars and financial derivatives The 3/30/94 New York Times includes two articles that illustrate the vexatious trade-offs inherent in emerging computer-based systems. Matthew L. Wald, Two technologies join to assist lost drivers, New York Times, 30 March 1994, page A13. This article is about a computer system that Nynex is developing, and that Avis will be testing, in which rental cars are kept in close contact with the rental agency through wireless communication. The technology is sold as a way of protecting drivers such as the tourists who were attacked in Florida; the cars will be equipped with "panic buttons" and the like. The article also says that drivers will be able to call in for directions on wireless phones, with the phone operators having access to digitally encoded GPS information plotted against detailed maps, enough to be able to say "take the next left" remotely. So far so good. But, at least the way the article describes it, the system will also allow the company to track all drivers for all purposes, regardless of whether they are in danger or need directions. A natural suspicion is that this generalized tracking capability is a major part of Avis's actual motives for promoting the systems. Motives aside, the privacy concerns may be serious in any case. How might these concerns be weighed against the advantages? How might the system be designed to obtain the advantages without the disadvantages? The article contains no hint that such questions are being asked, and this is unfortunate. Barnaby J. Feder, Sophisticated software set for exotic financial trades, New York Times, 30 March 1993, pages C1, C5. This article concerns "a marriage made in techno-geek heaven" between computer people and high finance, specifically software for analyzing and administering complex financial transactions based on so-called "derivatives" (see Risks 15.66). One virtue of these systems is that they reduce the possibilities for error, which are pretty serious when these kinds of transactions are done by hand. At the same time, such systems allow derivatives to be traded in much larger volumes, and in much more complex ways. Much popular imagery associates derivatives with speculation, for example high-stakes gambling in commodity futures, but the real issue is almost the opposite. The usual purpose of these transactions is to engineer little islands of stability and predictability within the swirling chaos of global financial markets. Indeed the metaphor of "engineering" is frequently used -- the software discussed in the article is referred to as "financial CAD (computer-aided design)". The potential trouble comes when massive financial edifices are engineered badly. When a steel-and-concrete building falls down, the earth is there to catch it and a limited number of people get killed. But that's not how financial engineering works -- one collapsing structure has the capacity to take others down with it (again, see Risks 15.66). Obviously it's in their interest to be careful, but let's hope they know what they're doing. Phil Agre, UCSD ------------------------------ Date: 30 Mar 94 08:20:52 EST From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: White collar crime in Australia >From the Reuter newswire via Executive News Service on CompuServe (GO ENS): CANBERRA, March 24 (Reuter) - White-collar crime is the most costly crime in Australia, totalling as much as Australian $13.7 billion ($9.8 million) a year, according to a report on Australia's law enforcement agencies. Key points: o Committee included "representatives from the Australian Federal Police, the National Crime Authority, the Attorney-General's Department, the Finance Ministry and the Prime Minister's office." o Most white-collar crime is fraud. o Fraud "imposes the greatest economic cost on the Australian community of all forms of major and organised crime." o Annual cost of fraud A$6.9-A$13.7 billion (U$4.9-$9.8 billion) (about 2/3 of cost of all crime in Australia, estimated at A$11-20 billion) Michel E. Kabay, Director of Education, National Computer Security Assn ------------------------------ Date: 30 Mar 94 08:20:47 EST From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Hotline reassignment >From the Associated Press newswire via Executive News Service on CompuServe (GO ENS): Telephone Sex ST. JOSEPH, Mich. (AP, 25 March 1994) -- People calling a hot line for victims of domestic violence got a phone sex line instead when authorities didn't notice that the agency operating the hot line had closed. Police habitually distribute cards with numbers of support services to victims. Seems that the hot line was reassigned to a number advertising various aural sex services. No one bothered to check the accuracy of the card for two years. [Consequence of poor quality assurance.] Michel E. Kabay, Ph.D., Director of Education, National Computer Security Assn ------------------------------ Date: 30 Mar 94 08:20:56 EST From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Electronic purse >From the Associated Press newswire via Executive News Service on CompuServe (GO ENS): [presumably 30 Mar 1994] MARY BETH SHERIDAN, AP Business Writer, reports on new developments in electronic money. NEW YORK (AP) -- Visa International is developing a do-it-all credit card that could pay for highway tolls, telephone calls or chocolate bars from vending machines. The company said Tuesday it is joining with an international group of nine other financial companies to develop the product, called the Electronic Purse." Key points: o Consortium working on standards for interoperability. o Plastic smartcard with embedded processor. o Transfer money from their accounts to the smartcard. perhaps at automated teller machines. o Trials planned for late 1995. o Must equip phones, vending machines, stores with I/O devices. o Current costs $3-$8/card; expect drop to $1 in high volume. Michel E. Kabay, Director of Education, National Computer Security Assn ------------------------------ Date: Thu, 31 Mar 1994 09:47 -0400 From: Bob_Frankston@frankston.com Subject: Dials! My son (11) confronted a dial phone this past weekend and couldn't figure out how to use it. He tried pressing the "buttons" but nothing happened. We finally had to show him the concept of turning the dial. It took a little practice to get it smooth. I guess we've reached a milestone. What if he were confronted by the "anti-drug" pay phones with dials and had to dial 911? He'd be stuck. In designing UI's we make assumptions about cultural norms or icons. Most people see the phone dial as a very obvious interface. It isn't, it's just something most of us learned at an early enough age to assume it is a part of the natural world. ------------------------------ Date: Wed, 30 Mar 94 10:15:05 BST From: Geoff Cole Subject: re: Spelling Checkers It is the bane of my life that spell-checkers offer the following suggestions for my name: goof, gaffe and guff Geoff Cole geoff@entoil.co.uk ------------------------------ Date: Tue, 29 Mar 94 18:36:16 PST From: shafer@ferhino.dfrf.nasa.gov (Mary Shafer) Subject: Risks of spelling checkers (Girard, RISKS-15.71) The DECMate II spell checker offered NAUSEA for NASA. Singularly appropriate some days. Mary Shafer, SR-71 Chief Engineer, NASA Dryden Flight Research Center, Edwards, CA shafer@ferhino.dfrf.nasa.gov ------------------------------ Date: Wed, 30 Mar 94 13:12:45 CST From: Scott A. Siege Subject: Risk of Spelling Checkers I have read with interest the RISKs associated with spelling checkers and especially one in which a UNIX machine failed to recognize the word UNIX. A similar thing happened with a spelling checker for the Apple Macintosh which refused to recognize "Laserwriter" (Apple's printer) and instead suggested "Laserjet" (HPs printer). -Scott s-siege@uchicago.edu ------------------------------ Date: Wed, 30 Mar 94 19:17:59 EST From: simsong@next.cambridge.ma.us (Simson L. Garfinkel) Subject: NeXT NeXT is in the NeXT spell checker, but NeXTSTEP is not. ------------------------------ Date: Wed, 30 Mar 94 16:29:46 PST From: "Peter G. Neumann" Subject: Disclaimers in software We have had various past discussions on creative disclaimers. Someone very well known to me received the following, but I have anonymized everything to protect whomever. You have our permission to use [...] as an NTP server. Please do not configure more than two of your systems to communicate with [...]. Please understand that [...] makes absolutely no guarantees about the reliability, availability, accuracy, or security of this service. Also, please note that this service is likely to disappear fairly soon, as it is based on a satellite that is about to fall out of the sky. ------------------------------ Date: 31 Mar 1994 16:35:09 +0800 From: MARTIN@411.uptown.com (MARTIN) Subject: Junior Exec's Reverse Alchemy Next time you get called into the bosses office, spare a thought for Juan Pablo Davila, who WON'T be winning "Employee of the Month" at Codelco. An extract from an article in THE ECONOMIST (p.66.Feb 12, 1994): SANTIAGO: Juan Pablo Davila claims that last September he made a mistake. He punched several 'sell' figures into his computer as 'buy', and vice-versa. Mr Davila was a fairly junior executive at Codelco, Chile's mammoth state-owned copper company. But he handled all Codelco's minerals futures contracts. By the time he noticed his slip he had already lost $40m. So he kept on dealing; when his credit lines finally ran out in January, his losses had reached $207m. Mr Davila's mistakes pose troubling questions for Codelco. Why did nobody notice the losses? Did his superiors fraudulently extend Mr Davila's credit lines? Can any money be recovered? On February 5th Codelco's president resigned, admitting that the losses exposed a failure of internal controls... MARTIN HOWARD, HONG KONG 31/3/93 MARTIN@411.uptown.com Tel: (852) 527 2123 Unit E, 9 Floor, China Overseas Building 139 Hennessy Road, Wanchai, Hong Kong ------------------------------ Date: Thu, 31 Mar 1994 13:48:19 -0500 (EST) From: Brian Clapper Subject: Yet another SSN misuse A colleague informs me that, in conjunction with graduate courses he's taking at a local university, he was assigned an account on one of the University's computer systems. He was appalled to find out that his assigned computer ID was his social security number. When he asked whether he could change the computer account ID, he was told, "No. That's your account number." The system in question is on the Internet and apparently has a Usenet newsgroup feed, as well. I won't bother to list the risks. Brian Clapper Telebase Systems Inc., Wayne, PA ------------------------------ Date: Thu, 31 Mar 1994 17:57:54 -0500 (EST) From: Stanton McCandlish Subject: EFF Summary of Public Interest NII Summit 29 Mar 1994 [To many groups] EFF SUMMARY PUBLIC INTEREST SUMMIT: SHAPING THE NATIONAL INFORMATION INFRASTRUCTURE Hyatt Regency Hotel in Washington, DC, MARCH 29, 1994 OPENING REMARKS Welcoming remarks were delivered by Andrew Blau from the Benton Foundation, who expressed gratitude to the program sponsors and planning committee. Secretary of Commerce Ron Brown delivered pre-taped opening remarks on video, because he was in Russia at the time of the conference. Secretary Brown, who chairs the Information Infrastructure Task Force (IITF), restated the Administration's commitment to universal service, emphasizing that no one should be left standing on the side of the road. PUBLIC INTEREST SUMMIT PANELS DELIVERING THE GOODS: MEETING PUBLIC NEEDS? Moderator: V. Lane Rawlins, President, Memphis State University C. Everett Koop, Senior Scholar, Koop Institute David Lytel, White House Office of Science and Technology Jean Armour Polly, NY State Research and Education Network Anthony Riddle, Chair, Alliance for Community Media Connie Stout, Director, Texas Education Network Patricia Waak, National Audubon Society This panel discussed the ways in which the National Information Infrastructure (NII) can improve education, health care, and the environment by enhancing communication and decisionmaking within communities, as well as within state, national, and international boundaries. There was strong consensus on the panel and from the floor that teaching people to use the tools is as important as building the tools. Choosing the right regulatory model is a difficult issue, but David Lytel said that the Clinton Administration is committed to making sure that citizens can be information producers, as well as information consumers. He stated that the challenge is to make sure that the NII becomes more than just a large pipe for television reruns and movies, home shopping, electronic games, and gambling. The architecture of the NII must guarantee that needs outside the commercial marketplace, including cultural and other public benefits, are met. A LINK INTO EVERY HOME: HOW, WHAT, AND WHEN? Moderator: Allen Hammond, Director, Communications Media Center, NY Law School Ron Binz, Director, Colorado Office of Consumer Counsel Mark Cooper, Director of Research, Consumer Federation of America Deborah Kaplan, Vice President, World Institute on Disability Robert Larson, President/General Manager, WTVS-Detroit Michael Nelson, White House Office of Science and Technology Andrew J. Schwartzman, Executive Director, Media Access Project The panel explored the challenges in applying the concept of universal service to the NII to ensure access for everyone. The panelists discussed universal service funding mechanisms, the role of government in supporting a diversity of voices, and the need for public interest advocacy before the Federal Communications Commission. Mike Nelson said that the Administration's model for the NII is the Internet, and its goals for universal service are to provide subsidies to enable open access for as many people as possible, to adopt pro-competitive policies, to require nondiscriminatory prices, to prohibit network providers from controlling information, and to enhance interoperability and interconnection requirements. Addressing the difference between the common carriage regime for telephone companies and the market/consumer model for the cable industry, Andrew Schwartzman argued for the common carriage model instead of the cable model, because the cable model is passive and connotes people receiving only limited services such as video-on-demand and home shopping. Common carriage would help NII users to be speakers as well as listeners, and producers as well as consumers. Ron Binz offered the phrase "Information Superhypeway" and cautioned that a fully competitive telecommunications industry is not right around the corner. The key decision, according to Binz, is whether to rely on taxing voice communications service to fund the NII. Binz also characterized as "industry propaganda" the view that subsidies should be provided to enable access for as many people as possible. Mark Cooper challenged the widely cited statistic that 93% of the population enjoys telephone service. Instead, he stated that the 7% "unsolution" is really closer to 30%, which includes individuals with disabilities and low incomes. He argued that those who cannot afford access to the NII will be assured access if everyone who can afford to use the NII is required to pay for it. Deborah Kaplan took the discussion beyond the issue of funding to the issue of access. She argued that the 7% of the population that is underserved is a product of the market model. There is no one-size-fits-all solution, and policy input from low-income people is essential. She raised the concern that access to the NII for disabled individuals may be uniquely difficult, especially if the NII architecture is modeled on voice-based telephone service. Schwartzman emphasized the First Amendment dimension of universal service, including artistic speech, and the need to protect against any form of censorship. Bob Larson explained how public broadcasting's role in promoting local service responsibilities and public service duties is a model for what the NII can do to marshall local resources. The NII could augment public broadcasting's efforts aimed at reducing violence and improving the well-being of young people. SPEECH BY VICE PRESIDENT AL GORE The Vice President was introduced by Peter Goldmark, President of The Rockefeller Foundation, who emphasized the historical role of the NII in charting the future of democracy. Vice President Gore stated the Administration's commitment to wiring every classroom, clinic, and library in the United States to the NII within the next five years. Every person will benefit from the NII. However, while we already have the technology, we do not yet have the infrastructure. The National Telecommunication and Information Administration in the Department of Commerce recently announced the availability of funding for some of the aspects of the NII and already have received 3,500 inquiries. Reforming telecommunications law is essential. Universal service means lower prices for everyone. Open access means receiving and sending information across the NII. The future will look like the Internet if we make sure the NII is open and accessible like the personal computer. Networked communities are consistent with our democratic form of government and distinguish it from communism and fascism. We need to increase access to government information to enhance community decisionmaking. We are increasing the availability of government information. SeniorNet is providing services to senior citizens. The Environmental Protection Agency's toxics release inventory is empowering citizens to ameliorate environmental hazards in their communities. HUD has begun to put information about fair housing and fair lending on the net. We can empower our representative democracy. People closest to the problems are the smartest about the solutions. BUILDING COMMUNITIES AND THE ECONOMY Moderator: Linda Tarr-Whelan, President and Exec. Dir., Center for Policy Alternatives Morton Bahr, President, Communications Workers of America Cushing Dolbeare, President, Low-Income Housing Coalition Thomas Kalil, National Economic Council for Science and Technology Anthony Pharr, Counsel, Office of Communication, United Church of Christ Diana Roose, Research Director, National Association of Working Women Randy Ross, Vice President, American Indian Telecommunications After brief introductory statements, the panelists discussed what the NII means for generating jobs and economic benefits. The goal is to use the NII to create better, high wage jobs. Development of information policy must make sure that the NII is a tool for community planning. Telecommuting will have an impact on the national economy by enabling people to live and work anywhere, including in other countries. We should use the technology that exists now in order to do the kind of planning needed to make sure the new technologies produce advances in our national economy. MAKING DEMOCRACY WORK Moderator: Sonia Jarvis, Exec. Dir., National Coalition for Black Voter Participation Brian Banks, Policy Research Action Group Jim Butler, Director, AARP/VOTE, American Association of Retired Persons Mitchell Kapor, Chair, Electronic Frontier Foundation Sally Katzen, Chair, Information Policy Committee, IITF Ralph Nader, Center for the Study of Responsive Law Nadine Strossen, ACLU This panel addressed whether the NII can support increased civic participation, free speech and assembly, and privacy. Brian Banks stressed the NII's ability to bring about a reconfiguration of hierarchies; enhanced citizen participation in the decision making process would be the most fundamental change. Jim Butler revisited the NII's potential for community development, educational opportunity, and access to government databases. Mitchell Kapor focused on the potential for achieving the Jeffersonian principles of individual liberty and decentralization. The Internet has enormous democratic potential, but it is not easy to use. The emphasis should be on the Internet and interactivity, not on the Information Superhighway and Hollywood reruns. Everyone should become hands-on, start learning and interacting, and ask for help when needed. The networks should be easy to use, but we cannot wait for a national handout. Sally Katzen stressed the goal of economic sustainable development. The government should not be solely responsible for the nation's information systems. The toxics release inventory is a model that has worked well. Ralph Nader, who still uses a manual Underwood typewriter, questioned what all this new technology will do about such problems as violence in the schools. Will it just put more people into the Office of Management and Budget and lead to mega-billion dollar overselling of unused software? While there needs to be a window on government databases, there is not reason for them to be overprivatized or overmonopolized. Educational efforts, like liberal arts-type courses, could motivate people to participate. Nadine Strossen argued that the common carriage model is important to ensure universal access--but security and privacy are equally important. We have to make certain that there are no censorial controls over content. All of us must lobby for privacy protection -- and we must fight the clipper chip. Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist "In a Time/CNN poll of 1,000 Americans conducted last week by Yankelovich Partners, two-thirds said it was more important to protect the privacy of phone calls than to preserve the ability of police to conduct wiretaps. When informed about the Clipper Chip, 80% said they opposed it." - Philip Elmer-Dewitt, "Who Should Keep the Keys", TIME, Mar. 14 1994 ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.72 ************************ 2-Apr-94 0:33:41-GMT,30475;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA00967; Fri, 1 Apr 94 19:33:39 EST Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11107; Fri, 1 Apr 94 19:33:07 EST Received: by chiron.csl.sri.com id AA27580 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Fri, 1 Apr 94 16:23:48 -0800 From: RISKS Forum Sender: RISKS Forum Date: Fri, 1 Apr 94 16:23:45 PST Subject: RISKS DIGEST 15.73 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 1 April 1994 Volume 15 : Issue 73 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: A320 software goes on "3rd Party" maintenance (Pete Mellor) Re: Risks of spelling checkers (Joseph T Chew, Andrea Chen, Eric Sosman) Re: Mud Slide Cuts East Coast Phones (David Lesher) Aural Sex and Rudder Actuators (A. Padgett Peterson) More jail-door openings (Tom Markson, PGN) find/xargs strangeness (Peter J. Scott, Chris Dodd) P. R. China Computer Security Rules (John Ho) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Fri, 1 Apr 94 23:52:42 BST From: Pete Mellor Subject: A320 software goes on "3rd Party" maintenance While I was in Copenhagen earlier today, a Danish friend, who knows of my interest in the A320, drew to my attention an item in today's issue of the news magazine "Goddaj" (if I recall the spelling correctly - it means "Good Morning"). A translation of the article follows (courtesy of my Danish friend):- --------Translation of Article in "Goddaj", 1st April 1994 -------- Danish Firm Scores Notable "First" ---------------------------------- Thor Avionics, one of Denmark's most advanced high-tech firms, has secured a contract which makes it the first software house in the world to provide "third party" maintenance on a major safety-critical software system. In order to reduce the maintenance costs on its fleet of Airbus A320 aircraft (the first type of civil airliner in the world to have a computer-controlled "fly-by-wire" system), Air France has placed Thor under contract to provide all future maintenance on the software of this highly-automated aircraft. Wolf Larssen, director of Thor, said "This is the first contract of its type, and it won't be the last. Users of commercial software long ago discovered that there are great savings to be made by getting a "third party" firm to maintain their software. I am only surprised that it has taken users of safety-critical systems so long to discover the advantages. I expect other A320 operators to be placing similar contracts before too long." A "third-party" in this context means a firm which is independent of both the user and the supplier. Such firms, being "lean and mean" are usually capable of providing a much better and more cost-effective service than the original supplier, since they have fewer overheads and are less stifled by bureaucracy. In the commercial world, such contracts have usually gone to small, dynamic, organisations, and it seems that the world of safety-critical software will follow suite. "We had to beat some stiff opposition from Sextant Avionique, Matra, Logica, and similar large firms." said Mr. Larssen. "The fact that the software on the A320 will need to be maintained indefinitely means guaranteed jobs for highly qualified Danish workers for a long time to come." M. Theophile Gautier, spokesman for Air France, said "We have the utmost confidence in Thor to deliver the goods, both in terms of reduced cost, improved system performance, and increased safety." The automated systems on the A320, particularly the flight control and flight management systems, have sometimes been called into question following the various accidents involving this type of aircraft, although the accidents have generally been ascribed to pilot error. Even so, there is an obvious question mark over the ability of a third-party firm to maintain the level of safety. When asked about this, Mr. Larssen said "Our software maintenance and validation process is second to none. Although Airbus Industrie have refused to release the source code, so that we will have to strip out the binary and work from that, we anticipate no problems. Most of the modifications we will be making are fairly slight, so that regression testing can easily be done on a software flight simulator running on an Apple MacKintosh." A spokesman for the JAA (Joint Aviation Authority, which is responsible for certifying that any new or modified design of aircraft is airworthy) said "The basic design has already been certified. All that Thor will be doing are minor post-certification modifications. Thor themselves have been certified as conforming to the ISO-9000 quality standard and to SEI level 2, so it should not be difficult for them to meet the requirements for our own certification, which is based upon an industry standard referred to as RTCA-DO/178B." In response to questions about what the maintenance would actually involve, Mr. Larssen said "Occasionally, Airworthiness Directives are issued by the JAA which require changes to be made to the design of an aircraft in order to correct a fault. Where this change involved modifying the software, Thor will be responsible for doing this. The beauty of software is that the modified version can be installed on all existing aircraft in seconds, simply by inserting a new eprom. In addition to this corrective maintenance, we will also be offering Air France enhancements to improve the performance of the A320. The practice of "chipping", or modifying the firmware in the engine management system of an automobile such as a BMW in order to make it go faster, is well established. I don't expect that we could make your A320 perform like an F-111, but we could certainly extend the "safe flight envelope" beyond the rather conservative limits originally set by the manufacturer." -------------------- Article Ends ------------------------ I leave it to readers to draw their own conclusions! Peter Mellor, Centre for Software Reliability, City University, Northampton Sq London EC1V 0HB +44 (71) 477-8422, p.mellor@csr.city.ac.uk [This is quite a Thor-ny piece. Incidentally, I note that "goddaj" is really "good day" (albeit used in the morning, as in the case of Guten Tag), and April 1 is certainly a "goddaj". Unfortunately, occasional adjacent-key typing errors might easily replace the "j" with an "m", which might be an appropriate reaction. PGN] ------------------------------ Date: Fri, 1 Apr 94 09:45:46 PST From: jtchew@Csa3.LBL.Gov (Joseph T Chew) Subject: "I have a spelling checker, it came with my PC..." > NAUSEA for NASA. Singularly appropriate some days. Microsoft Word's persistence in attempting to substitute Colada for Collider certainly made me feel the need for a drink when writing about the SSC... --JOe ------------------------------ Date: Fri, 1 Apr 94 11:17:19 -0500 From: tada@MIT.EDU Subject: Re: Risks of spelling checkers The main risk is in relying too heavily on spell-checkers. As people produce more of their own documents, they no longer have someone who does most of the proof-reading, and rely on a program instead. Automation of other parts of document production has caused a change in the type of errors that can get through. Up until a few years ago, most errors in trade books were switched letters ("b" for "d") probably caused by manual typesetting. Now one finds many more mistakes of a wrong word, no doubt from a spell-checker substitution. Perhaps we can ask, who checks the spell-checkers? -michael j zehr ------------------------------ Date: 1 Apr 1994 01:00:42 -0800 From: dbennett@crl.com (Andrea Chen) Subject: Re: Risks of spelling checkers By definition, a spell checker is a product which eliminates a large set of errors in a text. It does not eliminate them all. I would suggest that you do not go onto "auto pilot" when using the spell checker. Instead use the same level of awareness that you do when your write. In fact it makes sense to examine the text around every place the spell checker stops. There are a lot of errors which can only be eliminated by human attention. As far as I can see your general problem would not be eliminated by getting rid of profanity. Suppose you had a "Ms. Gorse" in your document. A spell checker might offer "Goose". Your client (or boss) might be equally offended. ------------------------------ Date: Fri, 1 Apr 94 13:23:55 EST From: eric@tardis.hq.ileaf.com (Eric Sosman x4425) Subject: Risk of Spelling Checkers A company which sometimes competes with my employer sells a software package which includes a spelling checker. It flags as a misspelling and offers as the suggested alternative. The RISKs? None that I can think of, but it's a nice anecdote. Eric Sosman Interleaf, Inc. / Prospect Place eric@ileaf.com 9 Hillside Ave. / Waltham, MA 02154 (USA) ------------------------------ Date: Fri, 1 Apr 1994 10:28:32 -0500 (EST) From: wb8foz@netcom.com (David Lesher) Subject: Re: Mud Slide Cuts East Coast Phones (Re: RISKS-15.72) Note this took out a reported 200+ DS3 circuits. That's ~~100,000+ voice-grade circuits (if all were such). Netcom's DC POP was one of the DS1's. They had leased the circuit from WilTel, but WilTel in turn had subcontracted the facilities from MCI. Further, while MCI had the cable back up by 11pm, somehow WilTel did not communicate this to Netcom. Thus the POP was not restored until the next morning. (Irony here - WilTel got started pulling fiber through abandoned oil pipelines. Schedule 300 pipe provides much better than average protection against backhoe fade.) Classic RISKs: 1) Too many eggs in one basket. While MCI surely has reserve capacity, it does not seem to have 200 DS3's worth. No self-healing ring, it seems. 2) Lost-in-translation syndrome - Once more than two organizations are involved, the chances of getting any intact message from one end to the other goes down as an exponential function of the number of hops. ps: Ispell wants to turn "WilTel" into "Wilted"........ ------------------------------ Date: Fri, 1 Apr 94 08:05:49 -0500 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Aural Sex and Rudder Actuators (RISKS-15.72) It is interesting that both of these incidents have a common thread - no feedback loops. Way back in the '70s when I was part of the team that designed the full authority digital flight control system for the AFTI F-16, we had a similar problem: the system was so complex and so many people were involved that it was easy to miss the change that Jon made today would affect Harold's system - and this was during the design stage. In production, component substitution could have the same effect, some so subtle that it would not be noticed until a pilot found himself in an interesting situation. One of my tasks was to develop the simulation software used in a 40 foot Evans & Sutherland dome & as such with each revision of the flight control software, the appropriate changes had to be fed into the dome system. In order to maintain continuity we developed a "configuration control model" that simply scanned the source code for all uses of a variable or subroutine and provided a map of the points of contact for each variable. When a change occurred, it was a simple matter to report the change to each affected engineer/programmer. It was also an excellent tool for reporting when someone had accidentally used the wrong variable in an equation since it would suddenly show use in a routine it had not been used in before. This tool also made it possible to notify those responsible for affected modules when a component change was made since the tree for the variables used with the component was readily available. The process was really simple but deductive rather than inductive: changes were detected not by people submitting a change notice but by a comparison of "current" versus "last", active configuration management rather than passive. Several times changes were found before the paperwork arrived. The simple fact is that any large system, from a telephone number list to aircraft fight controls is subject to Chaos math: small omissions over time will increase in effect. Murphy says that unknown effects will be destructive. Multiple omissions multiply effects. The most effective answer I have found is active feedback loops, something computers are very good at. Today one way I protect sites from intruder attacks is by requiring modem registration and briefing of owners. I also conduct random sweeps of the telephone lines looking for unregistered modems. Without the second, the first would rapidly become obsolete. This has two advantages: 1) I find omissions quickly. 2) People are less likely to make omissions knowing that they will be noticed. Over the last few years I have seem many instances in RISKS of problems with aircraft flight controls making the wrong decision or telling the pilot the wrong thing and each time have wondered if active design or configuration management feedback loops could have prevented them. Padgett ------------------------------ Date: Fri, 1 Apr 1994 12:54:43 -0800 (PST) From: tom@twilight.com (Tom Markson) Subject: More jail-door openings I saw on San Francisco's channel 4 last night that a jail in Marin which houses such people as Polly Klaus' killer has been having problems with their cell doors. Apparently, without reason, they would just open. The prison said their was no danger in escape. They blamed the problem on "software errors". How about that? --tom ------------------------------ Date: Fri, 1 Apr 94 14:27:06 PST From: RISKS Forum The RISKS archives include the following items from the ACM SIGSOFT Software Engineering Notes (S vol i no j). Recent items also appear in the on-line RISKS. PGN ..... Prison problems Seven Santa Fe inmates escaped; prison control computer blamed (S 12 4) Oregon prisoner escaped; frequent-false-alarm alarm ignored (S 12 4) New Dutch computer system frees criminals, arrests innocent; old system eliminated, and no backup possible! (S 12 4) New El Dorado jail cell doors won't lock -- computer controlled (S 13 4) San Joaquin CA jail doors unlocked by spurious signal; earlier, inmates cracked Pelican Bay State Prison pneumatic door system (S 18 2:4) ------------------------------ Date: 1 Apr 1994 21:10:38 GMT From: pjs@euclid.jpl.nasa.gov (Peter J. Scott) Subject: find/xargs strangeness Man, just when I thought I understood this stuff. I have condensed this down to the following: euclid% euclid% mkdir something_scwewy euclid% cd !$ euclid% foreach i (a b c d) ? echo $i > $i ? end euclid% find . -type f -print | xargs -n1 more ./b ./c ./d --More--(Next file: ./a) # Hit ./a :::::::::::::: a euclid% Now, to my way of thinking, it should be executing the commands "more ./a; more ./b; more ./c; more ./d". Certainly I have had and come to expect this sort of behavior from xargs in the past. It seems to be a problem with "more", because I get decent behavior with, say, "echo" and "cat": euclid% find . -type f -print | xargs -n1 cat a b c d Yet: euclid% find . -type f -print | xargs -t -n1 more more ./a ./b ./c ./d BTW, if there are more than a screenful of files, I get prompted by more to scroll through the list of them before it actually runs more on the first file. I don't get this at all. This is on SunOS 4.1.3. Peter Scott, NASA/JPL/Caltech (pjs@euclid.jpl.nasa.gov) ------------------------------ Date: Fri, 1 Apr 94 15:05:31 -0800 From: Chris Dodd Subject: Re: Peter J. Scott: find/xargs strangeness] This is an example of a strange interaction of two bugs, one in `more' and one in `xargs'. All bugs are RISKS to some extent, its not clear how severe or unusual they need to be to make it into RISKS... There are two strange things occurring here. 1. When `more' is invoked with its standard input connected to something OTHER than a terminal, it treats `stdin' as the first file to display. 2. `xargs' doesn't close the input to the child it invokes. So what happens is, `xargs' invokes `more ./a', and `more' reads everything it can from its standard input, which connects to the `find'. When `more' finishes, `xargs' finds that its `stdin' is empty and exits. To exercise these bugs separately, try: echo a b c | more ./a echo a b c d | xargs -n1 cat - Chris Dodd dodd@csl.sri.com ------------------------------ Date: Fri, 1 Apr 1994 12:22:17 (xxT) From: [a known contributor who wishes to remain anonymous] Subject: P. R. China Computer Security Rules (long) connection to the Internet (CHINANET; sub CHINANET to LISTSERV@TAMVM1.TAMU.EDU). The Chinese have named their new project to connect China to the Internet the "Golden Bridge" project. The following document purports to be the newly developed "PRC Regulations on Safeguarding Computer Information Systems." It seems quite appropriate for RISKS. As you read this, keep in mind that 1) in China accused persons are guilty until proven innocent; 2) laws referred to in the document as ones applying in certain circumstances are often harsh, subject to change without notice, and so vaguely worded as to make easy the prosecutor's job, not of proving guilt (not necessary), but of arguing why the penalty should be maximized; 3) the "Public Security" laws referred to are the same laws that stipulate that the families of serious offenders will be billed for the single bullet used in judgement; 4) certain concepts (virus, special security products) are either poorly defined or all inclusive; 5) in China when there is doubt as to the legality of any particular act, illegality is assumed (this is important not only in court, but also in normal life, where people tend to be more conservative in part because of it.) As we welcome this brave new domain into our net.universe, it will be interesting, and perhaps surprising at times, to see how another set of explorers on the electronic frontier are approaching the flow of information. Golden Bridge, indeed. As read, sending email without filing a customs declaration, or accepting a shareware registration for an anti- virus product could both be construed as being illegal. There's a lot of room for improvement here, imho. =============================================================== P.R.C. Regulations on Safeguarding Computer Information Systems =============================================================== Source: Beijing XINHUA Domestic Service in Chinese, February 23, 1994 From: john@jho.com (John Ho), Asia Online Chapter I. General Provisions Article 1. These regulations have been formulated to safeguard computer information systems, to promote the application and development of computers, and to ensure smooth progress in socialist modernization. Article 2. The computer information systems referred to in these regulations are man-machine systems, composed of computers and their allied and peripheral equipment and facilities (including networks), that collect, process, store, transmit, and retrieve information according to prescribed goals and rules of application. Article 3. In safeguarding computer information systems, measures shall be taken to secure computers, allied and peripheral equipment and facilities (including networks), the operating environment, and data, as well as to ensure the normal functioning of computers, so as to safeguard the safe operation of computer information systems . Article 4. In safeguarding computer information systems, priority shall be given to the security of computer systems containing data on such important areas as state affairs, economic construction, national defense, and state-of-the-art science and technology. Article 5. These regulations shall apply to safeguarding computer information systems within the PRC's borders. Measures for safeguarding microcomputers that have not been hooked up shall be enacted separately. Article 6. The Ministry of Public Security shall be in charge of safeguarding computer information systems. The Ministry of State Security, the State Secrecy Bureau, and relevant State Council departments shall carry out work pertaining to safeguarding computer information systems within the lines of authority prescribed by the State Council. Article 7. No organization or individual may use computer information systems to engage in activities that endanger national or collective interests, as well as the legitimate interests of citizens; they may not jeopardize computer information systems. Chapter II. The Safeguards System Article 8. Computer information systems shall be established and applied in accordance with laws, administrative rules, and relevant state provisions. Article 9. Computer information systems shall be protected on the basis of security grades. The Ministry of Public Security, in conjunction with relevant departments, shall establish security grades and formulate specific measures for protection based on such grades. Article 10. Computer rooms shall conform to state norms and relevant state provisions. No work may be carried out in the vicinity of computer rooms that jeopardizes computer information systems. Article 11. Units using internationally networked computer information systems shall register their systems with the public security departments of people's governments at or above the provincial level. Article 12. Individuals who ship, bring, or mail computer information media into or out of the country shall file truthful declarations with the customs authorities. Article 13. Units that use computer information systems shall establish security management systems and assume responsibility for safeguarding their computer information systems. Article 14. Units that use computer information systems shall report any incidents relating to their systems to the public security departments of local people's governments at or above the county level within 24 hours of the incidents. Article 15. The Ministry of Public Security shall exercise centralized management over research into the control and prevention of computer viruses and other harmful data that jeopardizes public security. Article 16, The state shall implement a licensing system for the sale of special safety products for computer information systems. The Ministry of Public Security shall enact specific measures in conjunction with relevant departments. Chapter III. Supervision Over Security Article 17. Public security organs shall perform the following functions to supervise efforts to safeguard computer information systems: (1) Supervising, inspecting, and guiding the work of safeguarding computer information systems; (2) Investigating and dealing with illegal and criminal cases involving the endangerment of computer information systems; and (3) Other supervisory functions with regard to safeguarding computer information systems. Article 18. Upon detecting latent hazards in computer information systems, public security organs shall promptly advise the units that use such systems to institute safety measures. Article 19. Under urgent circumstances, the Ministry of Public Security may issue special circulars on specific security aspects of computer information systems. Chapter IV. Legal Responsibilities Article 20. In the event of any of the following violations of the provisions in these regulations, public security organs shall issue warnings or shut down the computers for screening purposes: (1) Contravening the system for protecting computer information systems based on security grades and jeopardizing computer information systems; (2) Violating the registration system for internationally networked computer information systems; (3) Failing to report incidents related to computer information systems within the prescribed time frames; (4) Failing to take remedial action within the prescribed time after receiving notification from public security organs mandating security improvement measures; (5) Other actions endangering computer information systems. Article 21. Public security organs, in conjunction with relevant units, shall deal with cases in which computer rooms do not conform to state norms or relevant state provisions, or in which work carried out in the vicinity of computer rooms endangers computer information systems. Article 22. The customs authorities shall deal with failure to file truthful declarations on computer information media shipped, brought, or mailed into or out of the country, pursuant to the "PRC Customs Law" and the provisions outlined in these regulations and other laws and regulations. Article 23. Public security organs shall issue warnings or impose fines of not more than 5,000 yuan and 15,000 yuan, respectively, on individuals or units if computer viruses or other data harmful to computer information systems are deliberately input into such systems, or if special safety products for computer information systems are sold without permission. They shall confiscate illegal proceeds and impose a fine that is 100 or 300 percent more than the sum of such proceeds. Article 24. Actions that violate the provisions in these regulations and constitute infractions of public security shall be punished pursuant to relevant provisions in the "PRC Regulations on Security Administration and Punishment"; if the actions constitute a crime, criminal responsibilities shall be investigated. Article 25. Any organization or individual who inflicts property losses on the state, collectives, or other individuals in violation of the provisions in these regulations shall assume civil responsibility in accordance with the law. Article 26. Interested parties who are dissatisfied with specific administrative actions carried out by public security organs pursuant to these regulations may apply for administrative reconsideration in accordance with the law or file administrative lawsuits. Article 27. Government functionaries who abuse their power to demand and take bribes or commit other illegal or delinquent acts while enforcing these regulations shall be punishable on criminal grounds if their actions constitute crimes or given disciplinary actions if their actions do not constitute crimes. Chapter V. Supplementary Provisions Article 28. The meanings of terms used in these regulations are defined as follows: Computer viruses mean a set of self-replicating computer commands or programming codes inserted during the course of programming or into computer programs that can impair computer functions, destroy data, or affect computer use. Special safety products for computer information systems mean special hardware and software products for use in safeguarding computer information systems. Article 29. Military-related computer information systems shall be safeguarded in accordance with relevant military laws and regulations. Article 30. The Ministry of Public Security may formulate implementation measures in accordance with these regulations. Article 31. These regulations shall take effect upon promulgation. ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.73 ************************ 2-Apr-94 21:16:06-GMT,30723;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA11376; Sat, 2 Apr 94 16:16:05 EST Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA18154; Sat, 2 Apr 94 16:15:54 EST Received: by chiron.csl.sri.com id AA13233 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Sat, 2 Apr 94 13:06:52 -0800 From: RISKS Forum Sender: RISKS Forum Date: Sat, 2 Apr 94 13:06:50 PST Subject: RISKS DIGEST 15.74 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Saturday 2 April 1994 Volume 15 : Issue 74 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: [Clearing the backlog on one subject] Re: Spell checking (J. Taggart Gorman, Pete Mellor, Castor Fu, Les Earnest) Re: Language ability is not entirely learned (Paul Colley) Re: Spelling, punctuation, poor language technology (Bill Stewart) Re: English spelling design (Christopher Upward) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 31 Mar 1994 13:57:32 GMT From: jharuni@london.micrognosis.com (Jonathan Haruni) Subject: Re: Spell checking (RISKS-15.71) The only risk I see in spelling checkers is that people may trust them too much, or even expect too much of them. This is a widepsread risk of every technology. 1) You suggest that "it is easy to go unconscious in front of the mouse and press 'replace' one too many times". Surely a program which replaces words of your document without any knowledge of their meaning or intention is not one with which you should go "unconscious", especially when applying it to a document which, as you suggested, could lose you your job. 2) Your use of "business" and "profane" are a bit misleading. What you really want is a checker which does not suggest words which are inappropriate to the purpose of your document (making money from customers). How is that possible ? Whatever a document says, there are valid words which express the opposite ideas. You cannot omit from the dictionary all the words which might cause offence to anyone doing "business". Even if you did, add or omit the word "not" in a suitable place in a business proposal, and you could lose a customer. Can a business document not contain profanities if it suits the purposes of the document ? 3) Can you really blame the SPELLING checker for suggesting a common English word in place of a proper name ? I have never seen a spell checker which did not allow you to augment the dictionary. The first thing a company should do is add all the names and addresses of every organization it deals with. Have you done that ? I suggest that you have bought a useful tool (spelling checker), failed to make the effort of tailoring it to your needs (adding your correspondents to the dictionary), and expected too much of it (to provide you with a document which fulfills your intentions, rather than merely one without spelling errors). Then you fed it a document with so many errors that you became complacent about its power (not paying conscious attention to its prompts for confirmation). In spite of all this, it corrected your spelling mistakes and you DID notice the "goddamn" suggestion when prompted, so you ended up with a better document. Where are the risks ? Jonathan Haruni. ------------------------------ Date: Fri, 1 Apr 94 17:09:51 PST From: taggart@scopus.com (J. Taggart Gorman) Subject: Re: RISKS of RISKS on spelling-checkers It seems that some RISKS contributors are engaged in an activity that should not be discussed on a computer-related list such as this: spellcasting. However, it is obvious that they are using their computers to help with their witchery, for they keep on mentioning using "spell-checkers". At least we know that modern technology is helpful to all, including spellcasters. On the side, I've never seen a "spell-checker" for sale in a computer store. Are they commonly available in occult stores? (Available on the Microsoft Occulta CD?) :) (Not April's Fools, but with a light content for the day.) Taggart Gorman taggart@scopus.com ------------------------------ Date: Sat, 2 Apr 94 21:02:14 BST From: Pete Mellor Subject: Re: Risks of spelling checkers (Girard, RISKS-15.71) > with the suggestion that the word "Goldman" (as in a large company we all > know) should be replaced with "goddamn". The word processor involved was MS ------From the Daily Mail, Friday April 1st 1994, p21------------ Don't you dare be sexist says the PC PC, by Suzanne O'Shea The new computer program promised to help users write better English. But buyers have ended up with more than they bargained for. As well as a guide to glitch-free grammar and scintillating syntax, they get a lesson in political correctness every time they switch on. The use of words such as `wife', `policeman' and `housewife' meets with a sharp rebuke from the software, which flashes up a message that they are `gender-specific' then provides `gender-neutral' options such as `spouse', `police officer' and `homemaker'. Anyone foolish enough to test the PC personal computer with words such as `little woman' or `girlie' is sternly informed that they are `sexist expressions'. No alternative is offered here, only the ominous message: `Avoid using this word.' Computer writer Mark Smithson, 51, of Bedford, risked the wrath of the {pounds} 250 Microsoft Word 6 package when he typed in the word `freeman'. The computer promptly spat back `citizen'. `I couldn't believe it,' he said yesterday. `Then I started going through lots of other sexist and "gender-specific" words and, sure enough, the same thing happened. `It's like Big Brother. Manipulating what people write is a form of censorship. I am the last person to be deliberately sexist but this is downright frightening.' In the politically correct world of Word 6 - produced by an American firm - users are advised to replace `mankind' with `humankind' or `humanity' - although `womankind' passes through without a hitch - and to replace `fireman' with `stoker'. Its scope is limited when it sees words which it has not been told are sexist. While `little lady' may result in the reprimand `sexist expression, avoid using this phrase', followed by the explanation that `this term is considered by many to be inappropriate and belittling when used to refer to women', the word `floozie' is freely allowed. No mention of the programme's political correctness was mentioned [sic: Perhaps Ms. O'Shea should use a style checker! - PM :-) ] in publicity material when Word 6 was launched in Britain recently. Neither is the feature listed in the 830-page manual. A Microsoft spokesman - sorry, spokeswoman, we mean spokesperson - defended the program yesterday. `It does not force users to change what they write,' she said. `It simply highlights words that might be regarded as sexist and suggests alternatives. `Microsoft is trying to bring its programmes in line with real life and how people actually work. This type of thing is a sign of the times, as people do say chairperson instead of chairman nowadays.' [Disclaimer: I don't *think* this is an April fool joke (if only because, if it were not true, Bill Gates would sue the Mail), but if it is, I didn't make it up! :-) Peter Mellor, Centre for Software Reliability, City Univ., Northampton Sq., London EC1V 0HB +44 (71) 477-8422 p.mellor@csr.city.ac.uk ------------------------------ Date: Fri, 1 Apr 1994 18:01:42 -0800 (PST) From: Castor Fu Subject: More spelling checker stories When cleaning up one day we found a portable spelling checker. To test the size of its vocabulary, we tried out some proper names. We were dismayed to find it suggesting "a**hole" [censored by PGN] as a correction for "Achille", my housemate's name. This was particularly unimpressive, as "Achilles", the more common spelling, was actually in its dictionary, but was not among any of the alternatives, which included a number of other unflattering possibilities. -Castor Fu castor@drizzle.stanford.edu ------------------------------ Date: 2 Apr 1994 03:26:54 GMT From: les@sail.stanford.edu (Les Earnest) Subject: Risks of spelling checkers (RISKS 15.72) The earliest spelling checker was evidently one that was part of a pen-based computer system for cursive writing recognition that I developed at MIT Lincoln Lab in the 1959-61 time period. It was set up to recognize the 10,000 most common English words. Sometime in 1961 a film crew from BBC came to the lab and asked to photograph the handwriting recognizer as part of a television program on advanced technology, to which I agreed. After setting up, they asked if the system could recognize the word "television." I agreed to give it a try but pointed out that it sometimes listed more than one word if it wasn't sure. After I wrote the word on the CRT with a light pen, the system paused only a second or two before responding: TEDIOUS TELEVISION The film crew loved it and zoomed in for a close-up! I've often wished that I had asked for a copy of their film. Les Earnest (Les@cs.Stanford.edu) Phone: 415 941-3984 Computer Science Dept.; Stanford, CA 94305 Fax: 415 941-3934 ------------------------------ Date: Sat, 26 Mar 1994 23:41:54 GMT From: colley@qucis.queensu.ca (Paul Colley) Subject: Language ability is not entirely learned (Ranum, RISKS-15.69) >Spelling mistakes are a result of inattention to detail, ignorance, or apathy. Which makes poor spelling sound like a deliberate decision. I assure you I am neither inattentive to detail nor apathetic about my poor spelling abilities. I like to think I'm not ignorant... In my defense, I'll note that there is some strong evidence that language is based, at least in part, on genetics. Thus some portion of language skill is beyond the control of the individual. Quoting from Jay Ingram's book, "Talk Talk Talk", pp.133-141, there is... "...a gene that makes it possible for most of us to be able to add an `s' to a word to make it plural, or choose `he' instead of `they' when it's appropriate, or add `ed' to a word when it happened in the past! Apparently if you inherit a faulty version of this gene you will never be able to do any of those automatically. [...] These people aren't aware that they have a problem making plurals or past tenses, [...] [...] This discovery [...] makes it much more difficult to argue that language is simply a byproduct of learning, [...] The defect occurs in non-English speakers also. The gene seems to only affect language, and only the ability to make plurals and past tenses. If there's a gene for plurals, there are probably genes for other components of language. Reference: Myrna Gopnik, linguist at McGill University, "Linguistic Properties of Genetic Language Impairment," address to the American Association for the Advancement of Science, February 10, 1992, Chicago. - Paul Colley colley@qucis.queensu.ca +1 613 545 3807 ------------------------------ Date: Sun, 27 Mar 94 03:46:51 EST From: wcs@anchor.ho.att.com Subject: Re: Spelling, punctuation, poor language technology Aside from all the flames about whether spelling and punctuation errors come from poor language design (:-) or poor user education or differences in values, there *are* some new technology-related problems. Many maga- zine articles, especially in the com- puter industry, are suffering from leftover hyphen- ations, which come from re-for- matting word-processed text and not checking whether -'s at the ends of lines are intentional dashes or are hyphens put in to accommodate line-breaks before including the - and space in the new text. "Wired" is one of the worst offenders, probably because most of its authors use a variety of computer systems to write on. Bill Stewart [RISKS readers will notice that I try to REMOVE hyphenations whenever I spot them. Other comments on this subject were received from brewer@cs.wmich.edu (Steven D. Brewer) and albaugh@agames.com (Mike Albaugh). PGN] ------------------------------ Date: Tue, 29 Mar 1994 18:38:29 +0000 From: c.upward@aston.ac.uk Subject: English spelling design I just picked up the Don Norman/Mark Jackson/Alayne McGregor exchange on 'its', 'it's', and English spelling design generally. Don is right about bad spelling design being the cause of endless problems of written English. But Halle & Chomsky were wrong about underlying deep consistency in English spelling. For one thing, their analysis ignored such fundamental inconsistencies as in 'speak/speech'. For another thing, they ignored the whole historical dimension, which Don Norman rightly alludes to. The truth is that for 1,000 years no one has been able to ensure consistency, deep or otherwise, in English spelling, ie since the Norman Conquest of England in 1066, English spelling, unlike that of most languages, has not been "designed with the user in mind", as Don Norman very sensibly puts it. Webster's contribution was a small step in the direction of greater consistency, which the British have still largely failed to follow. Various people have tried using extra symbols (Benjamin Franklin was one), but they have always run up against the problem of needing to teach all th millions (billions?) of potential readers what these new symbols stand for. As for the apostrophe,the deep INconsistency of English rears its head there too. Mostly the possessive apostrophe precedes final with singular nouns: 'the dog's kennel', but follows it in the plural: 'the dogs' kennels'. But sometimes we find the reverse: 'men's' is plural, but 'Achilles'' is singular. A different set of inconsistencies affects the possessive pronouns mentioned by Mark Jackson. As he rightly says, most don't use apostrophes, so that we write 'hers', 'ours', 'yours', 'theirs', and of course 'its', and not 'her's', 'our's' etc. But 'one's' is an exception: for some reason we DO write that with an apostrophe. However, the craziest inconsistency is 'whose', where we add an at the end! If Alayne McGregor implying that all languages are written as inconsistently as English, he is mistaken. English is unique - as are its problems of illiteracy. Both the USA and Britain have recently published major reports on its appalling extent. We do need to get to grips with this question of spelling design. Let me now attach a recent paper put out by the Simplified Spelling Society on the subect. Simplified Spelling Society World HQ c/o Bob Brown, 133 John Trundle Court, Barbican, London, EC2Y 8DJ, tel. 071-628 5876. US HQ c/o Ken Ives, 401 E 32, Apt 1002, Chicago IL 60616. CUT SPELLING A Streamlined Writing System for English a proposal for modernizing English spelling by removing redundant letters Enquiries to Chris Upward Chairman of the Society's Cut Spelling Working Group 61 Valentine Road, Birmingham, B14 7AJ, England Tel. 021-444 2837, Fax. 021-359 6153. THE BACKGROUND Why reform English spelling? English spelling is notoriously hard to master. It is a centuries-old writing system whose contradictions and eccentricities were never designed for a fully literate society. We all suffer from its clumsiness and inconsistency: it takes far longer to learn than more regular systems; it limits people's ability to express themselves; it causes mispronunciation, especially by foreign learners; most people acquire at best an erratic command of it (even skilled writers are prone to uncertainty and error); and many millions are condemned to functional illiteracy. It is therefore small wonder there is such concern about standards of literacy in English-speaking countries today. Yet many of those countries have in recent decades seen the benefit of modernizing equally antiquated systems of currency and weights & measures. Similar modernization of English spelling is badly needed. Is reform possible? Spelling reform is an unfamiliar idea to the English-speaking world, but other languages show it is feasible and indeed a normal way of preserving a writing system from obsolescence. The letters of the alphabet were designed to stand for the sounds of speech, but pronunciation evolves in the course of time, and confusion sets in when letters and sounds cease to match: the way we speak words now no longer tells us how to write them, and the way they are written no longer tells us how to speak them. That is the central problem of English spelling. In the past century many languages have modernized their spelling to improve this match between letters and sounds, and so aid literacy. To ensure continuity, only small changes are usually made, and while schoolchildren learn some new, improved spellings, most adults continue to write as before. It may therefore take a lifetime before everyone uses the new forms. Ideally, spelling reform needs to be an imperceptibly slow, but carefully planned and continuous process. Problems of regularizing Many schemes have been devised for respelling English as it is pronounced, but apart from some small improvements in America none has been adopted for general use. Several fully regularized systems have however been tried in the past 150 years in teaching beginners, with dramatic success in helping them acquire basic literacy skills, the best known recently being the i.t.a. (initial teaching alphabet). However, all these schemes have required learners to transfer to the traditional irregular spelling as soon as they can read and write fluently, and much of the advantage is then lost. Ideal though total regularization may ultimately be, the effect such schemes have on written English is so drastic as to be a major deterrent to their adoption. The following sentence, in the Simplified Spelling Society's New Spelling (1948), perhaps the best thought-out and most influential of these fully regularized orthographies, demonstrates the effect:"Dhe langgwej wood be impruuvd bie dhe adopshon of nue speling for wurdz". Less radical proposals have therefore been made since then, so as to avoid such visual disruption, suggesting for instance that at first only the spelling of one sound, like the first vowel in any, should be regularized; or a single irregularity, like , should be removed. However, the immediate benefit of such a reform would be slight. A new approach is called for if today's readers are not to be alienated, yet learners are to benefit significantly. STREAMLINING Cutting redundant letters In the 1970s the Australian psychologist Valerie Yule found that many irregular spellings arise from redundant letters. These are letters which mislead because they are not needed to represent the sound of a word. Writers then cannot tell from a word's pronunciation which letters its written form requires, nor where to insert them, while readers are likely to mispronounce unfamiliar words containing them. A group within the Simplified Spelling Society therefore decided to explore which letters are redundant in English, and the effect their removal has on the appearance of the resulting 'cut' text. This Cut Spelling (CS) is now demonstrated. Esy readng for continuity One first notices that one can imediatly read CS quite esily without even noing th rules of th systm. Since most words ar unchanjed and few letrs substituted, one has th impression of norml ritn english with a lot of od slips, rathr than of a totaly new riting systm. Th esential cor of words, th letrs that identify them, is rarely afectd, so that ther is a hy levl of compatbility between th old and new spelngs. This is esential for th gradul introduction of any spelng reform, as ther must be no risk of a brekdown of ritn comunication between th jenrations educated in th old and th new systms. CS represents not a radicl upheval, but rather a streamlining, a trimng away of many of those featurs of traditionl english spelng wich dislocate th smooth opration of th alfabetic principl of regulr sound-symbl corespondnce. FURTHR ADVANTAJS Savings Th secnd thing one notices is that CS is som 10% shortr than traditionl spelng. This has sevrl importnt advantajs. To begin with, it saves time and trubl for evryone involvd in producing ritn text, from scoolchildren to publishrs, from novlists to advrtisers, from secretris to grafic desynrs. CS wud enable them al to create text that much fastr, because ther wud be fewr letrs to rite and they wud hesitate less over dificlt spelngs. Scoolchildren cud then devote th time saved in th act of riting (as wel as that saved in aquiring litracy skils) to othr lernng activitis. Simlr time-saving wud be experienced by adults in handriting, typng, word-procesng, typ-setng, or any othr form of text production. Th reduced space requiremnt has typograficl benefits: public syns and notices cud be smalr, or ritn larjr; mor text cud be fitd on video or computer screens; fewr abreviations wud be needd; and fewr words wud hav to be split with hyfns at th ends of lines. Ther wud also be material savings: with around one paje in ten no longr needd, books and newspapers wud require less paper (alternativly, mor text cud be carrid in th same space as befor), and demands on both storaj and transport wud be less. And th environmnt wud gain from th loer consumtion of raw materials and enrjy in manufacturng and from th reduction in th amount of waste needng to be disposed of. Targetng spelng problms Less imediatly obvius is th fact that CS removes many of th most trublsm spelng problms that hav bedevld riting in english for centuris. Ther ar thre main categris: ther ar silent letrs, such as in isle or in business, wich ar so ofn mispelt eithr as ilse, buisness, or as ile, busness; th latr ar th CS forms. Anothr categry is that of variant unstresd vowls, as befor th final in burglar, teacher, doctor, glamour, murmur, injure, martyr, wich CS neatly alyns as burglr, teachr, doctr, glamr, murmr, injr, martr. Thirdly ther ar th dubld consnnts, so ofn mispelt singl today, as found in such words as accommodate, committee, parallel(l)ed; CS simplifys these to acomodate, comitee, paraleld. RULES OF CUT SPELLING Cutting rules These three problem areas of traditional spelling correspond to the three main rules of Cut Spelling (CS). Rule 1 Letters irrelevant to pronunciation About 20 of the 26 letters of the alphabet are sometimes used with no bearing on pronunciation at all. Some, like in love, in though and in answer, were once sounded, but fell silent centuries ago. Others were taken from foreign languages, like in yacht (Dutch), in honest (French), and

in psyche (Greek), but are always silent in English. Yet others were inserted by analogy ( in haughty to match naughty, in could to match would) or to show a dubious or imagined derivation ( in doubt, in scythe). Two vowel letters are often written when the pronunciation only needs one; thus in measure, in hearth, in friend, in people, in build are all redundant. CS removes letters such as these from hundreds of often common words; most strikingly, CS eliminates that most grotesque of all English spelling patterns, the . Rule 2a Unstressed vowels before Thousands of English words contain or after an unstressed vowel, though the pronunciation fails to tell us which vowel letter to write. In fact, it is often redundant and can be cut, as seen from such rhyming pairs as apple/ chapel, centre/enter: CS Rule 1 cut the silent in apple, centre, and the resulting appl, centr show that unstressed can be cut in chapel, enter too, giving CS chapl, entr. Likewise the forms rhythm, mustn't show that the unstressed can go in fathom and the unstressed in resistant, insistent, giving CS fathm, resistnt, insistnt. Sometimes two letters can be cut: CS reduces curtain, luncheon, fashion to curtn, lunchn, fashn. CS Rule 2 cuts a swathe through one of the areas of greatest uncertainty in English spelling. Rule 2b Vowels in certain suffixes Similar is the cut of vowel letters in some major suffixes: the plural of ax(e) is cut to CS axs, distinguishing it from the uncut plural of axis (axes); the verb form learned is cut to CS lernd, but the adjective is distinguished as lerned. Strange at first is the cut of <-ing> to just <-ng> in verbs whose root ends in a consonant (waiting, hating diverge as CS waitng, hating), but an important gain from this cut is that it allows numerous troublesome doubled consonants to be simplified by Rule 3. A notable simplification is that the confusing <-able, -ible> suffixes are mostly reduced to just <-bl>, turning eatable, edible into CS eatbl, edbl. Rule 3 Doubled consonants simplified Doubled consonants sound like single consonants, so the writer cannot tell when doubling is required: frequent errors are the inevitable result. CS simplifies nearly all of them, as in CS abreviate, embarass, omitd/comitd/benefitd, travld/ compeld and (by Rule 2) hopng/hoping for hopping/hoping. The main exceptions are disyllabic words ending in and words ending in ; furry, tinny, hiss, discuss therefore remain distinct from fury, tiny, his, discus. Substitution rules The key feature of CS is that it removes rather than replaces letters. However, 3 simple substitutions are also made: 1 When are pronounced /f/, they are spelt . This produces forms such as CS cof, tuf, fotografy, sulfr. 2 When are sounded as , they are spelt . This produces forms such as CS juj, jeolojy, jinjr. 3 When is pronounced as in flight, sign, it is spelt , producing aligned forms such as fly, flyt, sty, sy, syn. THE CUT SPELLING HANDBOOK This leaflet barely outlines the CS proposal for modernizing English spelling. A full account is given in a three-part Handbook. Pt I (pp1-160) discusses the rationale of CS, its main features, its advantages, its psychological, linguistic and educational implications, and ways in which it could be implemented; but above all Pt I gives a detailed analysis of the present irregularities of English spelling and how cutting redundant letters improves the crucial interface of writing and speech. Pt II (pp163-231) illustrates the various cuts and provides exercises for literate adults to practise converting traditional spelling to CS and writing CS for themselves. Pt III (pp233-297) is a dictionary of over 20,000 of the most common words with redundant letters, giving their simpler CS equivalents. At the end is a bibliography of works for readers planning further study of the complexities of English spelling and the possibilities for its simplification. Unfortunatly th first edition of th Handbook is now out of print. A secnd edition is now in prepration, but th publication date is not yet nown. Details: Christopher Upward CUT SPELLING: a Handbook to the simplification of written English by omission of redundant letters" 306pp, Simplified Spelling Society, 1992, #10 or US$20 to non-members + p&p #2 or US$10 outside Europe, ISBN 0 9506391 3 3 Christopher Upward Editor-in-Chief, Simplified Spelling Society Senior Lecturer, Modern Languages Department, Aston University, Aston Triangle, Birmingham B4 7ET, England. Christopher UPWARD Aston extension 4215, fax 021-359 6153 Home address and telephone 61 Valentine Road Birmingham B14 7AJ tel. 021-444 2837 ------------------------------ Date: ongoing From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.74 ************************ 13-Apr-94 23:26:10-GMT,31837;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA23691; Wed, 13 Apr 94 19:26:08 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA09902; Wed, 13 Apr 94 19:25:32 EDT Received: by chiron.csl.sri.com id AA14937 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Wed, 13 Apr 94 16:15:56 -0700 From: RISKS Forum Sender: RISKS Forum Date: Wed, 13 Apr 94 16:15:54 PDT Subject: RISKS DIGEST 15.75 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Weds 13 April 1994 Volume 15 : Issue 75 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: [Huge backlog. I've been a grindstone Cowboy and travelling.] E-Mail saves a man's life Risks of powerful computers to the quality of science (Dan Ruderman) Robot mower (Pete Mellor) God Grants Granite Gift to RISKS Punsters (Peter Wayner) The Soft Pork Underbelly of Efficient Markets (Peter Wayner) A creative, HONEST software disclaimer (Neil MacKay) E-mail problems (Andrew W Kowalczyk) Holiday Inn extra key requirements (Lance A. Brown) Fingerprinting & welfare (Mich Kabay) Re: More jail-door openings (Al Stangenberger) WAIS (Peter Wayner) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Sat, 2 Apr 94 13:24:39 PST From: "Peter G. Neumann" Subject: E-Mail saves a man's life RISKS is always delighted to find cases in which the benefits of computing technology manifest themselves in a critical way. Here is such a case. Jack Miller, a computer analyst from Paramus NJ, was experiencing severe chest pains and called his doctor, who put him on hold. As his condition worsened to the point that he felt a strange coldness and could barely breathe, he was just barely able to type a piece of E-mail to coworkers: HELP. FEEL SICK. NEED AID. Apparently he had intended to sent it just to a few nearby colleagues, but instead it appeared as an alert message on the screen of each of the 80 people in his department. Some of those who responded were trained in cardiopulmonary resuscitation, and his life was saved. [Source: an AP item in the San Francisco Chronicle, 2 Apr 1994, p.A1.] ------------------------------ Date: Wed, 30 Mar 94 14:54 BST From: dlr1002@cus.cam.ac.uk (Dan Ruderman) Subject: Risks of powerful computers to the quality of science Much of modern-day science relies on computer models for simulation and the testing of various hypotheses. The use of large scale simulations now permeates many fields, from the Monte Carlo algorithms employed by physicists and computer scientists to genetic mutation simulations performed by evolutionary biologists. As computers gain speed and data storage capacity, science's dependence on simulation will only increase. I see two grave risks in this trend. First, the uses I mentioned above both rely heavily on having a "good" random number generator. But it is well known that even the best pseudorandom number algorithms posses large amounts of redundancy (and thus predictability) when viewed in high-dimensional spaces. But this is exactly the regime in which they are mainly used in science to simulate many-body dynamics. The second edition of "Numerical Recipes" discards its previous random number generator for a "better" one. Should all the thousands of simulations which used the first version now be redone? The second potential danger is to the fundamental quality of scientific ideas. How long should you think about a problem before letting the computer take a brute-force crack at it for you? As computers become more powerful the temptation to stop thinking and start coding looms ever more prominently. As a high school computer nerd turned postdoc physics nerd, I am acutely aware of this seduction. One aspect of this problem is that we may not think as hard as we used to. Another may be the predominance of work being on computer simulations rather than basic ideas. Since these simulations generally have many adjustable parameters, the space of possible exploration is huge, and not all of it relevant. This also makes the interpretation of results that much more difficult to grasp, since there is a large number of parameters to visualize. Pedagogically speaking, simulations should be used sparingly either to illustrate an idea or to perform an essential computation which cannot be carried out analytically. A proliferation of mediocre models with many arbitrary parameters can only spell disaster for the industry. Dan Ruderman The Physiological Laboratory Cambridge CB2 3EG England ------------------------------ Date: Sun, 3 Apr 94 03:54:47 BST From: Pete Mellor Subject: Robot mower (designed by Belgians, built by Swedes, driven by no-one) The Daily Mail of 1st April 1994 carried a full-page report (p3) of a new design of mower called the Solar Turtle. This is a little robot that runs around your lawn on wheels, cutting the grass ALL ON ITS OWN! The picture that accompanies the article shows a low-profile object about 3 feet long by 2 feet wide, elliptical in outline, and with its top surface sloping down from about one foot at the front to 6 inches at the back. (I am guessing: the exact dimensions are not given.) It is so light that "it can be carried by a child." It is also (mercifully!) almost completely silent. Its flat upper surface is covered with an array of solar panels which provide it with sufficient power to trundle around even on dull days, and charge its little batteries so that it can keep going if it runs into a shaded patch of garden. Its maximum speed is 1.8 kph (slower in the shade). Three separate electric motors drive its two front wheels and rotating cutting blade. Since it is intended to operate continuously, the grass never gets a chance to grow. Therefore trimmings are very fine, and are simply left on the lawn as a mulch, so that no collector box is required, and it doesn't even require periodic attention from the gardener to empty it. A single machine can look after 2000 sq. ft. of lawn. Price {pounds} 1,500 to 2,000 (still TBA). Manufacturers are Husqvarna of Sweden, and the inventor is Andre Coles (Belgian). So far, it has been demonstrated at the Spring Gardening Fair at Olympia, London. Look out for it next at the Chelsea Flower Show. It will probably go on sale next year. (British outlet: Husqvarna Forest and Garden.) Risks? Well, what if it a) cuts your toe off, b) mows your prize dahlias, c) gets stuck, or d) gets nicked? This is where the relevance of all this to the RISKS forum becomes apparent. For the Turtle is controlled by (you've guessed it, folks!) "an on-board computer [which] analyses conditions 500 times a second, enabling it to adapt to the amount of light, humidity and temperature, and to negotiate slopes and particularly overgrown patches." a) Safety (1): If it hits anything (tree, chair, foot) "a shock detector stops it in its tracks". The picture shows a sort of white band around the front edge, which is presumably a collision sensor. Since it moves "backwards and forwards a few feet at a time", it presumably has a similar sensor at the rear. Its sensor seems to be a few inches off the ground. Could it give a sleeping cat a short back and sides? b) Safety (2): It will not operate outside an area delimited by a buried "boundary cable". An "electronic sensor" detects the cable, and "tells it to turn back". The article does not go into this, but (IMHO) this is a serious marketing weakness. The photo shows the Turtle standing proudly in the foreground with a smiling and highly photogenic young lady (who obviously never got her hands dirty with a bit of weeding in her life!) lolling in a deck-chair in the background. The scenery includes (as well as the happy Turtle user) about 50 acres of garden containing a lake, irregular patches of shrubbery, occasional trees, and artistically arranged lumps of rock. Even assuming the Turtle can negotiate the rocks, shrubs and trees without help, burying a boundary cable around that little lot must be a major logistical exercise. c) Reliability: This must depend on precisely how intelligent its program is. It can't simply stop when it hits a tree, so what does it do? Back up and charge again? Try a random turn? What happens if it hits your foot, and you then move out of the way? You can bet that even if you have more sense than to get in its way, your kids will have hours of fun trying to convince it that they are a tree! If it maintains a database of the terrain, this could seriously blow its tiny mind! :-) On the other hand, it must somehow avoid mowing the same little patch over and over again. Does it remember where it's been? (Software Engineering coursework assignment: "Design an algorithm using a pseudo-random number generator to ensure that a Turtle covers the whole of a piece of lawn 2,000 sq. ft. in area in a given time irrespective of the shape of the perimeter or the presence of interior obstructions." - That should keep the students busy! :-) d) Security: If the Turtle is picked up, "a loud alarm goes off ... and is turned off only when an individual code is punched in. And it cannot operate outside the electronic boundary." ("I say, Alice! What's the code for this ****** Turtle? I can't turn the frigging alarm off!") Also, if it's *carried* outside the boundary cable, how does it detect this? Mmmm ... After all that, risks to the public? Err ... getting fat through not having to mow the lawn? :-) [There is a disclaimer in the Mail article which states that this is NOT an April Fool joke! :-) ] Peter Mellor, Centre for Software Reliability, City University, Northampton Sq. London EC1V 0HB +44 (71) 477-8422, p.mellor@csr.city.ac.uk ------------------------------ Date: Tue, 5 Apr 1994 15:25:20 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: God Grants Granite Gift to RISKS Punsters The financial pages will be burning up with stories about a relatively small investment fund called "Granite." The fund was set up by "really smart guy" named David Askin to provide "RISK-free" investment in the the mortgage backed securities market. As early as middle March, Askin was pretty sure that his fund was still worth $600 million. Now it may not be worth anything. Poof. In two weeks! How could this happen? Everyone understands how money can disappear in the stockmarket. But, the Granite fund was different. Askin et al. used very sophisticated models to figure out which morgage-backed securities were cheap and which were dear. He would buy the cheap ones and sell out the expensive ones. Eventually, the market would drive the price of the cheap and dear securities together. Then the fund would close out the position and make money based upon the original spread. The great "strength" of plan was that it was supposedly interest-rate neutral. If the rates went up, then both the cheap and the dear securities would lose value in sync. They're both bonds so they tend to lose value as interest rates rise. So any loss in the value of the "cheap" securities that the fund actually bought was offset by a gain the value of the short investment in "dear" securities that fund sold short. The same process would work in reverse if interest rates dropped. The main problem seems to be that no one was willing to buy any mortgage-backed securities as the bond rates went through the roof. The markets just froze. Plus, prices weren't behaving according to the very careful models that he originally created. Bam. Interested parties should check out the various articles in the NYT (April 5, A1), Time magazine (cover), and other sources to find out more details. The message for the comp.risks readers is the same old story of technical hubris that we've grown to love. But it is even better than almost any other case I've read about. People who use computers and mathematics on Wall Street usually have a stronger arrogance than those who use the computers to guide planes, run home security systems, run 911 systems or steer satellites. Why? Derivative securities, like those bought by Granite, are sheer creations of mathematicians. It is very tempting to believe that they're free from real-world problems like wind, noise, pets or other gremlins that keep plenty of engineers up late. I've worked on Wall Street doing these sorts of things. The whole mathematical foundation of the work made things both very fun and very certain. I've always thought that mathematics was a very clubbish pursuit. The proofs were the rites of initiation. Once you made it in you could be sure that you and the other members of this club really did have a superior view of the world. Unlike the all-male, all-female, all-whatever clubs, you had actually _proven_ the truths you held up as self-evident. The mathematicians running these games are probably just as sure. But, when the Bear putsch came to shove and the world tried to get out of the stock market at the same time, all of the mathematical models started breaking down. I can assure you that the people who bought into this fund probably thought that they were buying a sure thing. They had probably worked through the math themselves. There are probably lawyers combing the prospectus hoping that the Granite partners were so sure of themselves that they didn't put the usual disclaimers in the prospectus. At this point, I'm wondering about of the dangers of using mathematics for a guarantee of even things mathematical. The theorem that all maps can be colored with four colors is widely known as the first example of computer-based proofs. Many people don't remember that the theorem was originally considered settled and true back at the turn of the century. People believed the "proof" for several decades. Then someone stumbled upon a loophole and it became famous again. --Peter "I will build my Church/Turing theorem on this Granite" Wayner ------------------------------ Date: Thu, 31 Mar 1994 23:30:20 -0500 From: Peter Wayner Subject: The Soft Pork Underbelly of Efficient Markets The Under Pork Belly of Efficient Markets, or How to Launder Money Using Cattle Futures The great promise of electronic networks and virtual communities is a collection of very efficient markets. In the future, information will be moved, products will be sold and trades will be executed in a blink of an eye. This efficiency is usually considered to be a pretty good thing by everyone in business, in economics or in line at the video store. The underside of this efficiency, though, is a blurring of the line between legitimate and illegitimate business. A good way to understand this effect is to study the case of how to launder money using the futures markets. Laundering money is an age old problem for people who want to move funds from person A to person B without leaving a suspicious trail. Cash is the nieve approach and it has plenty of problems: it is bulky, it can be lost or stolen, and most importantly it often leaves people asking "Hey, where did that come from?" The futures markets, though, make it simple to move funds in a way that is indistinguishable from ordinary commerce. If it is done correctly, the recipiant, person A, looks like a lucky stiff or a market savvy investor. Person B is usually out of the picture or out of luck. The same games can be played with almost any other market, but futures markets are so efficient that the process is actually feasible and easy to do. The basic transaction in futures is to buy or sell a contract for the delivery of x pounds/barrels/tons/feet of some commodity at y dollars/yen/marks etc. If you buy a contract, then you're obligated to actually cough up y dollars when the contract comes due. Most people don't hold on to the contracts long enough for them to actually take delivery. They sell another contract and the futures market maintains a clearing house that is responsible for matching up the contracts and cancelling them out. It's a great system. Very efficient and very useful for farmers, manufacturers and others who actually produce and consume commodities. Futures markets are great for laundering money, though, because they can generate big losses or big gains in a short amount of time. It is quite possible for $100 to turn into a $5000 gain overnight. The downside is that it can often turn into a $5000 loss in the same amount of time. In fact, the market is a zero sum game. If you make n dollars, then there is someone out there who just lost n dollars. The sum total of the losses and the winnings equals zero. This zero sum nature is the key to laundering the money. Person A and Person B get together and guess that the price for a commodity is going to go up. That means that who ever buys a contract will make money. So Person A, the intended recipient buys a contract and Person B sells a contract. If they're right, then Person A gets the money and Person B loses the same amount. Bingo. The money moved from B to A and no one can trace how it got there. Person A looks smart or lucky and Person B looks out of luck. There was no direct connection between the two. There are thousands of other people out there winning and losing money at the same time. The marketplace's central clearing house arranges it so each wins and loses their rightful share. You may wonder why B bothered to sell a contract and lose money. This is the safeguard against guessing wrong. No one is correct all of the time. Even the people who try and rig the markets and corner them get burned as often as they succeed. The best investors in the futures markets, the ones who make money time after time, are the arbitrageurs. They spot inefficient pockets and try and remain neutral to the overall shifts in the market. Person B sells the contract so that if the market goes down, i.e., the wrong way, then A and B together have lost no money. It's a zero sum. Now they just have to play the game a bit longer or for stakes that are twice as high. You can think of the process as flipping a coin until you have encounter a heads. Ideally, you play this game with two players with relatively deep pockets. This means that A can cover the short term loses. This is a bit of a disadvantage because many money laundering operations must move cash from the rich to the poor. You can cover up this problem by using the same broker for A and B. The broker executes the trades and then assigns the winning trade to A and the losing trade to B. They fill in the order books after the fact. Using the same broker for A and B can be problematic because it may look too suspicious if the mirrored trades appear on the same ledger. The beauty of this system is that it can look quite indistinguishable from normal business practices. Many companies actively enter the futures markets to hedge themselves against foreign currency movements. Others actively enter the futures markets to guarantee themselves a good supply of their raw materials. The essential point of this lesson is that fast, efficient markets make it possible to move money easily. The futures markets were designed so that is no real other half to every trade. It's literally you against the world with every trade. The RISKS, of course, is that accountability can vanish as the size of the crowd grows to be as big as the world. There is no way to catch up with this. The futures market are so great because there is no need to deal one on one. The effects of speed are not only apparent in big financial markets. Credit cards and overnight delivery are a dangerous combination. You could steal cards, order a fortune of stuff, arrange for it all to be delivered overnight and then jump town quickly before people notice the card was gone. Suddenly, merchants must deal with the fact that something that used to be complete legitimate (exchanging cash for goods) is now a potential theft. Of course, there are other crimes that lose their edge. It is much harder to escape the law by heading to a new town. Computerized fingerprint files are very, very efficient. I think everyone felt that perfect, computerized markets would bring about the right mixture of accountability and efficiency. It would be a perfect mixture of Big Brotherly scrutiny would take care of everything. Every trade, after all, is recorded in the futures market. Yet, the best mechanism for anonymous fund transfer yet discovered exists here in the midsts of all of this record keeping, legal scrutiny and oversight. ------------------------------ Date: Thu, 31 Mar 94 21:11:41 EST From: Subject: A creative, HONEST software disclaimer To add one more to your creative software disclaimers; I read this one in WIRED magazine issue #2.01. It is reprinted without permission. It concerns Haventrees Software's EasyFlow program. If EasyFlow doesn't work: tough. If you lose millions because EasyFlow messes up, it's you that's out the millions, not us. If you don't like this disclaimer: tough. We reserve the right to do the absolute minimum provided by law, up to and including nothing. This is basically the same disclaimer that comes with all software packages, but ours is in plain English and theirs is in legalese. We didn't want to include any disclaimer at all, but our lawyers insisted. Certainly clarifies their position. In a strange, twisted, punkish kind of way I admire them. :-) Neil... ------------------------------ Date: Fri, 1 Apr 94 19:46 EST From: Andrew W Kowalczyk Subject: E-mail problems With all the tribulations you have gone through in trying to mail stuff properly through the various E-Mail systems I thought you might enjoy this joke that was related by columnists Nicholas Petreley and Laura Wonnacott in the March 28, 1994 issue of InfoWORLD: A fellow goes into a bar and says to the bartender, "Hey, I just heard this great E-mail gateway programmer joke." The bartender replies indignantly, "Now, wait a minute. I used to be a gateway programmer. See that guy at the end of the bar? The guy at the other end? Those two guys at the table over there? They are all gateway programmers. Now, do you still want to tell that joke?" And the fellow says, "Well, not if I have to explain it five times." Andy Kowalczyk, Allstate Life Insurance Co., 1415 Lake Cook Road P2A, Deerfield IL 60015-5213 (708)317-6206 AKOWALCZ+aLIFDR1%Allstate_Corp+p@MCImail.com ------------------------------ Date: Thu, 31 Mar 1994 23:50:59 -0500 From: "Lance A. Brown" Subject: Holiday Inn extra key requirements Last weekend, March 27th I checked into a local Holiday Inn for an overnight stay and was given only 1 credit card style mag-stripe key. A few hours later I went back to the desk and requested another key for my wife. The clerk asked for my name and room number, pulled something up on her computer, swiped a key through a card read (writer?) and handed it to me. No photo ID or other ID requested. I asked if it is standard to not request ID for extra keys and was told that is true. I then asked her if she realized anyone could get a key just by knowing the name of a person and what room they were in. She seemed quite startled by this. The RISK is quite obvious. Lance Brown lab@biostat.mc.duke.edu ------------------------------ Date: 01 Apr 94 07:26:21 EST From: "Mich Kabay [NCSA]" <75300.3232@CompuServe.COM> Subject: Fingerprinting & welfare >From the Associated Press newswire via Executive News Service on CompuServe (GO ENS): Welfare Fingerprints, By KATHLEEN HOLDER, Associated Press Writer SACRAMENTO, Calif. (AP, 31 Mar 1994) -- Expanding the use of fingerprinting to flush out welfare cheats, Los Angeles County will soon start taking the prints of applicants for federal dependent children benefits. Officials said the requirement, which won state approval Wednesday, will be the nation's first use of fingerprinting to prevent fraud by applicants for Aid to Families with Dependent Children, the main federal-state welfare program." The author explains the background and details. Key points: o electronic fingerprint scans of applicants are stored in computer database. o fingerprint taken as unique authenticator of identity. o Los Angeles has been using these techniques since 1991 for state general assistance. o Needed and received a waiver from federal govt to add requirement to federal regulations for AFDC. o These techniques will be implemented state-wide if they work. o Several advocates for poor people's rights object to the stigma of fingerprinting. o "In the first six months after Los Angeles County began running fingerprint checks for general assistance in 1991, the county reported cutting its costs by $5.4 million, or more than half." o "More than 3,000 people lost their aid for suspected fraud, and more than 200 applicants were denied assistance because they refused to submit their fingerprints." Michel E. Kabay, Director of Education, National Computer Security Assn ------------------------------ Date: Fri, 1 Apr 1994 20:43:04 -0800 From: Al Stangenberger Subject: Re: More jail-door openings (Markson, RISKS-15.73) > a jail in Marin ... There's something wrong with this -- Polly Klaas's accused killer is housed in Santa Rosa, Sonoma County. Not Marin. I don't think Marin's new jail is finished yet. Al Stangenberger, Dept. of Env. Sci., Policy, & Mgt., 145 Mulford Hall - Univ. of Calif., Berkeley, CA 94720 forags@nature.berkeley.edu (510) 642-4424 ------------------------------ Date: Fri, 8 Apr 1994 13:36:38 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: WAIS Q: What is WAIS? A: It stands for Wide Area Information Server. It's a pretty popular standard for accessing text based information on the Internet. Anyone can use readily available software to create an index for a collection of texts and then make this available to the world on the Internet. Q: How do you use it? A: Get the right software, choose some data bases, type in some keywords and press the button. WAIS will come back with a list of documents and their matching quotient. You can then choose to read the entire text of the documents. Q: Why would RISKS readers care about this? A: Comp.risks digests are indexed with a WAIS server. You can type in "plane crash" and get more than enough information to keep you wondering about one, two and three engine planes that fly-by-wire using code written in Fortran and encrypted with Clipper to prevent terrorist hackers. Q: How can I get the software? A: There are many different ways to access WAIS. Many GOPHER servers offer it as an option. You won't even leave GOPHER to type your query. You can also use TELNET to "quake.think.com" and log in as "wais" to use their link. The interface isn't great, but it is not bad. The best options seems to be to get a copy of the specialized software written for different platforms. One package, which I've used occasionally is called "MacWAIS." It is available via anonymous ftp from ftp.tidbits.com. You need to have a Macintosh computer with an Internet connection using MacTCP to use this. There are other copies for NeXTs, PCs and other machines at ftp.think.com in the "/wais" directory. Q: Are there any tricky parts? A: Well, it is pretty easy in some respects. You just type and go. I've occasionally had trouble getting a good list of servers that are available. The WAIS folks were clever enough to make it possible to use WAIS to search through the lists of servers. You just type in some keywords and back comes a list of servers that have that keyword in their description. So, if you want to access RISKS, try searching the directory of servers for the keyword RISKS. Once you find it, you will be able to save the result on your machine and it will automagically know about the RISKS server. Another solution is to search through the directory of servers using ".src". Several people have recommended this to me, but I've had trouble getting it to work well for a number of reasons. First, it only searches the description string of each server. If the author/creator of the server was parsimonious with the description, then you might not even find the world ".src" in there. I've tried all kinds of keywords, but I've often felt like there are still many sources out there that I just can't find. This problem may be fixed or solved by now. (Please write if it has.) ------------------------------ Date: 13 April March 1994 [LAST MODIFIED] From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. [See RISKS-15.75 for WAIS info.] FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.75 ************************ 19-Apr-94 0:31:14-GMT,29911;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19754; Mon, 18 Apr 94 20:31:13 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA14043; Mon, 18 Apr 94 20:29:34 EDT Received: by chiron.csl.sri.com id AA19690 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Mon, 18 Apr 94 17:13:59 -0700 From: RISKS Forum Sender: RISKS Forum Date: Mon, 18 Apr 94 17:13:57 PDT Subject: RISKS DIGEST 15.76 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Monday 18 April 1994 Volume 15 : Issue 76 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** ***** INCLUDES Mosaic INFO for RISKS. Contents: "Friendly Fire" --- U.S. F-15s take out U.S. Black Hawks (PGN) The Green-Card Flap Data-storage technique provides copy protection (Meine van der Meulen) Yet another example of software modification risks (Jim Dukelow) Re: Risks ... to the quality of science [randomness] (Steen Hansen) MIT student arrested for BBS used for pirate software (Fredrick B. Cohen) Credit-Card Fraud (Greg Philmon) NII and the US Card (Bill Murray) Reckless Baby Bell Marketing (Alan Miller) Re: P.R. China Computer Security Rules (Tom Albertson, Dan Sorenson) Delayed Dial Tone causes unintentional 911 calls (Chonoles Michael Jesse) Information resource (Michael Enlow) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 18 Apr 94 14:51:28 PDT From: "Peter G. Neumann" Subject: "Friendly Fire" --- U.S. F-15s take out U.S. Black Hawks [This item may be old news now, but is included for the archives.] Despite elaborate precautions designed to prevent such an occurrence, two American F-15C fighter planes shot down two U.S. Army UH-60 Black Hawk helicopters in the no-fly zone over northern Iraq on 14 Apr 1994, in broad daylight, in an area that had been devoid of Iraqi aircraft for many months. One Sidewinder heat-seeking missile and one Amraam radar-guided missile were fired. The fighters were operating under the communication control of an AWACS plane, which was the first to detect the helicopters, and instructed the F-15s to check the situation out. The helicopters were carrying U.S., British, French and Turkish officers from the U.N. office in Zakho, in northern Iraq, and were heading eastward for a meeting with Kurdish leaders in Salahaddin. Both towns are close to the Turkish border, well north of the 26th parallel that delimits the no-fly zone. All 26 aboard were killed. Both helicopter pilots apparently failed to perform the routine operation of notifying the AWACS plane after their last takeoff. Both helicopters apparently failed to respond to the Identification: Friend or Foe (IFF) requests from the fighters. Both fighter pilots apparently did not try voice communications. A visual flyby apparently misidentified the clearly marked ("U.N.") planes as Iranian MI-24s. Furthermore, a briefing had apparently been held the day before for the appropriate personnel of all of those aircraft (F-15s, UH-60s, and AWACS). There was speculation as to whether the pilots of both helicopters might have neglected to turn on their transponders, or whether the frequencies were set incorrectly, or whether both transponders failed (or perhaps some hybrid scenario). There was speculation that the fighter pilots did not try all three of the IFF modes available to them. There was also speculation that the Black Hawks may have visually resembled Russian helicopters because they were carrying extra external fuel tanks. But the AWACS plane personnel should have been aware of the entire operation, because they were acting as battlefield coordinators. Perhaps someone panicked. An unidentified senior Pentagon offical was quoted as asking "What was the hurry to shoot them down?" [Sources: various press reports in The New York Times and other papers, 15 Apr 1994 and 18 Apr 1994.] "Friendly fire" (also called fratricide, amicicide, and "misadventure") is not uncommon. An item by Rick Atkinson in The Washington Post (15 Apr 1994) noted that 24 percent of the Americans killed in action -- 35 out of 146 -- in the Persian Gulf war were killed by U.S. forces. Also, 15 percent of those wounded -- 72 out of 467 -- were similarly victimized. RISKS noted earlier the British Warrior armored vehicles that, mistaken for Iraqi T-55 tanks, were zapped by U.S. Maverick missiles, killing 9 men and wounding 11 others. Atkinson's article noted that this is an old problem, citing a Confederate sentry who shot his commander, Stonewall Jackson, in 1863, during the Civil War; an allied bomber that bombed the 30th Infantry Division after the invasion of Normandy in July 1944; and a confused bomber pilot who killed 42 U.S. paratroopers and wounded 45 in the November 1967 battle of Hill 875 in Vietnam. The old adage was never more appropriate: With friends like this, who needs enemies? The Black Hawk incident also brings back memories of the Soviet shootdown of the Korean KAL 007 flight and the Vincennes' shootdown of an Iranian Airbus. ------------------------------ Date: Mon, 18 Apr 94 15:12:17 PDT From: "Peter G. Neumann" Subject: The Green-Card Flap RISKS received a huge amount of mail relating to the husband-and-wife Phoenix immigration-law-firm, Canter & Siegel. Offering their legal services, they posted an advertisement on 5000 newsgroups, and gave information on a forthcoming lottery that will give out 55,000 green cards (granting permanent residency in the United States). C&S received at least 30,000 responses, mostly protesting their use of the Internet for advertising. Internet Direct suspended the C&S account for violation of the customer service agreement. I.D. had to put up with the thousands of pieces of objections. [This gives a new meaning to OBJECT-oriented E-mail.] C&S threatened to sue for I.D. for $250,000 for the lost responses. At least one site crashed repeatedly because of mail saturation. This reminds me once again of all the varied problems that I have with the fly-by-night it's-not-quite-the-Internet providers. One of them rejects mail after you hit your quota of external mail for the month. Some include the entire mailing list on each RISKS mailing, as noted earlier. Many do not permit FTP, but offer thousands of users the opportunity to invoke the almost-costfree availability of my pro-bono but not timefree services. Is regulation an answer? I shudder at the thought. I cannot begin to summarize the RISKS mail on this subject, and certainly would risk losing most of our subscribers if I ran the whole collection. The issues include the usual stuff about whether the no-advertising policy even exists, whether it is a per-newsgroup question or an Internet policy question, who actually controls the Internet, and all those topics familiar to RISKS folks. Perhaps we are waiting in expectation of the ultimate scam from New Haven, which might be considered a violation of Con-netiquette. ------------------------------ Date: Thu, 14 Apr 1994 13:26 +0100 (MET) From: MEULEN@tno.nl Subject: Data-storage technique provides copy protection Data storage technique provides copy protection Summarized and translated from "Intermediair", 1 April 1994, Vol. 30, Nr. 13, p. 35. Universities of Plymouth (in the U.K.) and Washington DC developed a technique to write five times as much information on magnetic media as floppy discs or bank cards. The magnetic layer is composed of small magnetic particles. Every bit is "remembered" by polarising several thousands of them in the same direction. This is done to overcome noise, due to the random orientation of the particles. The new technique only uses a fifth of the number of particles used in conventional techniques. It reads the information on the medium directly after writing it. By comparing the real magnetisation with the expected one, a chip determines the deviations in the medium. Based on that, information about these deviations is also written on the medium. Later, this enables flawless read out. An extra feature of this technique is that the information about the deviations is unique for every medium, comparable to a fingerprint. This means that when a bank cheques this fingerprint, it can detect fraud copies of bank cards. Meine van der Meulen TNO-Industrial Safety Department meulen@tno.nl ------------------------------ Date: Fri, 15 Apr 1994 13:16 -0800 (PST) From: js_dukelow@gate.pnl.gov Subject: Yet another example of software modification risks The following is a slightly edited version of a report from the latest issue of the Department of Energy Operating Experience Weekly Summary, which is a vehicle for rapid dissemination to other DOE organizations and contractors of occurrences at DOE facilities. "On January 17, 1994, the earthquake in Southern California caused widespread power outages in the western portion of the United States, and commercial power was lost at a DOE chemical processing facility. When commercial power was lost, a standby diesel generator automatically started and supplied power to critical loads. During a power transient caused by starting a large load on the diesel generator, four electric motors dropped off line and did not respond to a start command even though individual controllers indicated a ready-to-start condition. Facility personnel had to completely de-energize and then re-energize the motor controllers before the motors could be re-started. "After commercial power was restored, facility personnel determined that the porblem could not be duplicated for partially loaded generator conditions or with commercial power supplying the standby motor control center. Investigators determined that all the affected motors were connected to the same standby motor control center which was equipped with new digital motor protectors. Facility personnel developed a series of test procedures to determine the cause of the problem. After extensive testing, they determined that the motor protectors developed a software lockup after a power transient. During a simulation of the loss of commercial power, investigators determined that there was a correlation between voltage swings caused by starting a large load on the standby generator and the software lockup of the motor protector. The motor protector lockup resulted in the motor tripping off and not restarting until control power was removed and re-applied. "Facility personnel contacted the motor protector vendor with the results of the tests conducted at the facility. Vendor personnel confirmed the test results and reported that they had isolated the problem to specific units with firmware version F3, introduced in the fourth quarter of 1991. The vendor reported that units manufactured from 1987 through the third quarter of 1991 were not affected. "The vendor also reported that the units operated properly if the control voltage is maintained within plus or minus ten per cent of nominal voltage. If the control voltage surges beyond this range, the motor protector may trip the motor and require a power down to reset itself. The vendor offered to modify the affected units to eliminate the power reset after a voltage surge. "DOE facility personnel are advised to inspect their facilities for the suspect motor protector and take appropriate corrective actions." The risk associated with this event is that a software modification in 1991 rendered the standby electrical power system partially unable to fulfill its safety function. The root cause of this situation was that software engineer(s) involved in this modification (which was perhaps the initial digitally-controlled version of this component) were not fully aware of the actual operating environment (in this case, voltage swings greater that +/- 10% when the standby power system was doing what it was designed to do) of the digitally-controlled component. Jim Dukelow Battelle Pacific Northwest Laboratories js_dukelow@pnl.gov ------------------------------ Date: Thu, 14 Apr 94 08:09:46 -0400 From: Steen Hansen Subject: Re: Risks ... to the quality of science (Ruderman, RISKS-15.75) Some years ago I upgraded the operating system of a minicomputer. A few weeks later a faculty member became very upset: his research results had changed. Apparently the upgrade changed the random-number generator, which made his statistical programs give a different result. He demanded the original generator be put back in again. Steen Hansen, Computer Specialist, Ohio State University hansen+@osu.edu (614) 292-9317 (Stores/Food: Tue/Thu/Fri) (614) 292-5174 (Dentistry: Mon/Wed) ------------------------------ Date: Fri, 15 Apr 94 17:11:42 PDT From: Fredrick B. Cohen Subject: MIT student arrested for BBS used for pirate software An MIT student was arrested today for having a BBS at the school that was used by the participants to store and fetch commercial software. This one made the national news because of the promenance of the institution and the information superhypeway, but this sort of arrest has been going on for years in the "hacker" bulleting boards of the US. There is now a substantial history of these operators being convicted, but I have to question whether MIT should be arrested for allowing the BBS to reside on its computers. After all, if the BBS superuser can be arrested for unknowingly having the software on their BBS, why can't the institution be arrested as well? But the issue goes far deeper than this. At its core, we have the multitudes of people trying to tell us that the information superHW should have public access points and public spaces, but what happens when a public space is used for crime? The criminal is not arrested; instead, the person who provided the space is arrested. If we are to have public space on our info superHW, we had better stop arresting those who provide it for the crimes perpetrated in it. Otherwise, there will be a chilling effect on those who would provide it. How does this relate to RISKS? It should be obvious. If you have a party, and someone who attends commits a crime, you may be sent to jail for it. No precedent? Huh! If someone is drinking at your house or bar, and you fail to prevent them, and they drive away and get in an accident, you may be liable. I anxiously await your responses on the policy issues at play here. FC ------------------------------ Date: Thu, 14 Apr 1994 05:50:38 -0700 From: philmon@netcom.com (Greg Philmon) Subject: Credit-Card Fraud A friend recently applied for a credit card from a major issuer. Later he received a call from the bank informing him that his card was in a batch that was stolen somewhere along the delivery route. Over $4000 had been charged to his card in a 24 hour period. This was once quite common. However, most card issuers now use an automated system to "activate" the card. Usually it involves dialing an 800 number and entering some "secret" information (e.g. your birth date, ssn, etc). As it turns out, my friend's wife had received a phone call from someone claiming to work for the issuer. He said that they wanted to verify his application and asked for the his full name and SSN, which she gave. The automated authorization system of this issuer asks for the last four digits of your SSN. I'm really curious what sort of success rate was achieved by the thieves. Did they get fifty percent of the card owners to give their SSNs? More? Greg Philmon | philmon@netcom.com | CIS: 71161,3445 | MCI: 588-5358 ------------------------------ Date: Sat, 16 Apr 94 16:06 EDT From: WHMurray@DOCKMASTER.NCSC.MIL Subject: NII and the US Card Last week in the security track of the CardTech/SecureTech Conference, I heard a presentation by a representative of the U.S. Postal Service on the "US Card." This is a piece of the national information infrastructure intended to mediate all government services to and controls over the citizen. It will contain health care data, financial data, tax data, and identity data. It will contain a private key (digital signatures only), a PIN, and other identifying data. (While emphasizing that "open to new applications" was a requirement of the system, he was silent on arrest record, voter registration, gender preference, and previous condition of servitude.) Use of the card will be "voluntary." The government is doing this for us because it will enable them to give us better service, because the citizens require "one card," and to protect us from the "twenty million 'little brothers'" that we now recognize as the "real threat to our privacy." (He did not claim that this would protect us from terrorists, child molestors, drug dealers, or religious cults.) (All of this was delivered with a perfectly straight face and without challenge from the audience.) Of course if we do not like it, we can do away with it, right? The official stated that the Postal Service is prepared to issue a ahundred million of these cards within months of getting the go ahead. Along with the net, "voluntary" fingerprinting of the poor, CLIPPER, and the FBI's digital telephony initiative, what more could any citizen, not to say government, ask for? Law and order is just around the corner. Aren't you glad to hear that Orwell had it all wrong? William Hugh Murray, Information System Security, 49 Locust Avenue, Suite 104 New Canaan, CT 06840 1-0-ATT-0-700-WMURRAY; WHMurray@DOCKMASTER.NCSC.MIL ------------------------------ Date: Thu, 14 Apr 1994 11:04:55 -0500 (CDT) From: millera@mcs.com (Alan Miller) Subject: Reckless Baby Bell Marketing The following is most of a letter I sent to my local Baby Bell recently after receiving a marketing letter aimed at increasing calling card use. I think the risks of the mailing are fairly obvious from the letter... ajm I simply wanted to inform you that I was disturbed to find in my mail an unexpected letter from you that contained my Ameritech Calling Card PIN. My objections to this letter are as follows: 1) Since I was not expecting the letter, if it had been removed from my mailbox or the U.S. Mail before I received it I would have had no way of knowing that something was wrong until I got my next phone bill (complete with calls I hadn't made). 2) Increasing the possibility of delivery problems, the address on the envelope was, if not wrong, at least very nonstandard. In particular, it had two different forms of the town name, both on separate lines. If something this easy to catch made it through processing (presumably for many letters), what other errors might do the same? My monthly phone bill is properly addressed. 3) [Given a name and address, anyone with reason (PIN possession) can get my phone number] 4) [I can call customer service and get a new PIN assigned if necessary] 5) Finally, the presence of my PIN on the letter is not necessary on what is obviously a letter intended to increase awareness of calling cards. A note that I could contact Customer Service would have served just as well, without any of the security risks. Since card number theft is a serious and reportedly increasing problem, I am surprised to see Ameritech sending mailings that include information that consumers are told to guard carefully. If this mailing does result in an increase in calling card fraud, is Ameritech intending to absorb all fraudulent charges resulting from the careless distribution of PINs? The letter also makes me wonder about the security of my account with Ameritech. How simple would it be for someone looking for the ability to make a few free phone calls to simply look up and write down a few number+PIN combinations? ------------------------------ Date: Wed, 13 Apr 94 09:40:10 PST From: Tom Albertson Subject: Re: P.R. China Computer Security Rules Our contacts with the PRC government say that these rules do not exist. While this may be only a denial of something still in the works, its quite possible these are the work of someone with a regional axe to grind. Would you be willing to put me in touch with the anonymous poster, or would you debunk this on your own? If the rules are not legitimate, I don't think it was correct to post without some corraboration (I thought the unwritten rules of journalism called for two reliable sources for unsubstantiated materials?) Tom Albertson tomalb@microsoft.com PH 206-936-6764 ------------------------------ Date: 2 Apr 94 07:32:12 GMT From: viking@iastate.edu (Dan Sorenson) Subject: Re: P.R. China Computer Security Rules Note: this is somewhat political in nature, but I believe the RISKS are known to all in any position of responsibility or power. China opens the "Golden Bridge" to the Internet, and I see China still writes laws like the following: >Article 2. The computer information systems referred to in these regulations >are man-machine systems, composed of computers and their allied and >peripheral equipment and facilities (including networks), that collect, >process, store, transmit, and retrieve information according to prescribed >goals and rules of application. And in all likelihood this law would cover a supermarket scanner and cash register. I'm not surprised. Read any bill before Congress here in the USA and you will find a similar lack of understanding, broadness of definition, and lack of detail. Perhaps a better example shows up daily in the newsgroups rec.guns and talk.politics.guns, where laws as passed are picked at and it is generally determined that the law outlaws anything not specifically mentioned as exempt. The RISK? When people write the rules we have to live by, often times the spirit of the rule is lost in the letter, and the RISK of abuse is increased. One has to wonder at some of the latest anti-discrimination laws that wouldn't allow, say, a trucking company to not hire an applicant in an iron lung. I'm sure you can see your own pet versions of laws gone awry by creative interpretation. Finally, we're left with the axiom "You can't make it foolproof because fools are so clever." I submit that fools, lawyers, and government share this same affliction, and if we're not careful we shall as well, no matter our level of power over others. * Dan Sorenson, DoD 1066 viking@iastate.edu z1dan@exnet.iastate.edu * ------------------------------ Date: Fri, 1 Apr 94 17:49:08 EST From: chonoles@acc1.acc.vf.ge.com (Chonoles Michael Jesse) Subject: Delayed Dial Tone causes unintentional 911 calls Mostly, the problems with telephone numbers in the form x91-1xxx is the possibility that the first digit was ignored because of a delayed dial-tone. If the exchange is busy, and there are many people calling, the exchange may not have enough "digit registers" to allocate. Then there is a delay before the dial-tone appears. [Similar to what happened with the rock-concert ticket giveaway and on Mother's day, etc.]. Since most callers often don't listen for the dial-tone and dial anyway, dialing a number in the form of x91-1xxx might get them 911. As the number of central office codes (COCs), (the first three digits of a 7-digit number) is used within an area code increases, then these x91-1xxx numbers need to be allocated. The central offices that handle the x91 COCs need to have extra "digit registers' to lessen the chance for this problem. Michael Jesse Chonoles chonoles@acc.vf.ge.com mjc@eniac.seas.upenn.edu [This is another variation on an old problem addressed in many past issues of RISKS. PGN] ------------------------------ Date: Sun, 17 Apr 1994 21:48:54 -0700 From: Mike Crawford Subject: Seeking lit ref: we trust calculators over ourselves I seek a literature reference. The usual methods have failed so far - perhaps someone can give me even an author, more precise subject or partial title words? I will persist by looking up the references in papers referring to student use of calculators, but maybe this will ring a bell with you? There was a study done, perhaps in the seventies, of the human tendency to trust machines rather than our own judgement. Subjects were given calculators, and pages of simple arithmetic problems. The calculators were wedged so that they gave incorrect answers sometimes. Even though the problems were simple enough that the subjects could figure them out in their heads, the study showed that people will trust the machine even though our own judgment tells us that the machine is wrong. I want to use this as a reference in a paper I am writing on computer network security, and another I am writing about why high-aenergy physicists should not be so trusting of their results if they have been subjected to extensive processing by complex, and poorly understood computer programs. Thus, network administrators trust security software even when security experts tell them it is easily penetrable, and physicists trust the results of their calculations even when software experts tell them that their software is bogus. ;-) (C'est Moi! My own advisor does not believe me when I tell him the results of my own work are wrong. After all, they _were_ calculated on a computer!) Author of the Word Services Apple Event Suite. Mike Crawford crawford@scipp.ucsc.edu Free Mac Source Code: ftp sumex-aim.stanford.edu | get /info-mac/dev/src/writeswell-jr-102-c.hqx ------------------------------ Date: Wed, 13 Apr 94 00:26:45 -0700 From: m_enlow@enlow.com (Michael Enlow) Subject: Information resource We wanted to let you know about some great info we are making freely available on the Internet. My name is Michael Enlow. I am a retired private/legal investigator and author of several books regarding private investigation/electronic surveillance technology. I wish to extend my services to the Internet to share and exchange information on security and privacy protection issues. We are making a lot of very informative info available FREE on the Internet. This includes back issues of my newsletter "Inside Secrets", my schematics and plans, resources, guides, and other information. For details on accessing these FREE services, send an e-mail message to INFO@ENLOW.COM you can also FTP to ENLOW.COM or FTP.ENLOW.COM, and login as anonymous (put your email address as the password). There is a listserver in place to send you files if you do not have access to FTP. Your comments and suggestions are welcome. Thanks for your time. ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories; risks-15.75 gives WAIS info. "Mosaic http://www.csl.sri.com&" gets you CSL for info; check for recent issues in case you suspect a disruption. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.76 ************************ 20-Apr-94 2:28:16-GMT,28577;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA17342; Tue, 19 Apr 94 22:28:15 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06977; Tue, 19 Apr 94 22:28:10 EDT Received: by chiron.csl.sri.com id AA20934 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 19 Apr 94 19:21:10 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 19 Apr 94 19:21:07 PDT Subject: RISKS DIGEST 15.77 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 19 April 1994 Volume 15 : Issue 77 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Risks ... to the quality of science: Clifford Truesdell (Michael Tobis) Dial-in Electric Meter Readings Sans Safeguards (Scott Rose) Stun belts -- who has the remote? (Jak Kirman) Risks of Data Compression (Joe Decker) TV Guide Contest (Agris Taurins) Re: MIT student arrest (Dwight Silverman, Sidney Markowitz) Re: Green-Card Flap [Risks, Lawyers] (Ed Clarke) "Naissance d'un virus" by Ludwig/Condat (Rob Slade) IFIP SEC '94 Program (Willis H. Ware) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 18 Apr 94 22:27:56 -0500 From: tobis@skool.ssec.wisc.edu (Michael Tobis) Subject: Re: Risks ... to the quality of science (Ruderman, RISKS-15.75) This issue was addressed in a remarkable essay by the eccentric and curmudgeonly fluid dynamicist Clifford Truesdell. The essay is called "The Computer: Ruin of Science and Threat to Mankind", in _An Idiot's Fugitive Guide to Science_, Springer_Verlag, 1984. If the title is not temptation enough, the following is a list of subheadings in the essay, capitalization intact: 1. Spatial Flight would have been Impossible without Computers. 2. Spatial flight would have been impossible without the Classic Equations of Motion 3. Calculation without Classic Standards is Dangerous. A Computer is Incapable of Setting its own Standards. 4. Computers have Harmed Science Already. 5. Mathematics is the Science of Infinities. Computation is Essentially Finite. 6. Computers Bring Power and the Abuses of Power. Advocates of Computing Seek to Destroy Mathematics. 7. Computing Promotes Factual Fraud. It has Harmed Experimental and Applied Science in the Past and is Copntinuing to do so. By its Emphasis on Application of the Already Known, it can Delay Basic Discovery and thus Reduce the Field of Applications in the Future. 8. Classic Theories used Inductive and Deductive Models. Computing Encourages Floating Models. 9. Computing Promotes Logical Fraud. Computers Programmed to Confirm False Theory can Destroy Mankind. 10. Summary: Computers are Here to Stay. They Endanger Thought, Language, Science, and the Survival of Man. Like any other Dangerous Tool, they should be Put under Strict Controls. [OK, perhaps it's a bit overdrawn, but I think anyone who intends to use computers to model nature should have a look at this remarkable jeremiad. mt] ------------------------------ Date: Tue, 19 Apr 1994 09:00:25 +0100 From: Scott Rose Subject: Dial-in Electric Meter Readings Sans Safeguards My electric utility-- Madison Gas and Electric-- has embarked upon a new meter-reading scheme that seems not to have been given a whole lot of thought. Many of the electric meters in my neighborhood are not accessible from outside the house, so the chances of meter-reader getting the data on a particular visit are quite low in this era of double-income households. In the old scheme, the meter-reader left a business-reply postcard after ostensibly determining that the customer wasn't home to allow access to the meter (in practice, the meter reader just leaves the card without notice, apparently having determined that the route can be finished more quickly without those pesky delays associated with actually determining that the customer isn't home, but that's a flame for another forum). The meter-reader fills in the meter number section of the card-- a six-digit number that uniquely identifies the meter-- the customer fills in the usage section of the card and drops it in the mail, and MG&E picks up the roughly $.30 tab for the reply card postage. The new scheme is similar, except that instead of leaving a mail-in card, the meter-reader leaves a phone-in card. Customers each got a sample card in the mail the other day, and I decided to give it a trial run. Here's how the session went: I dialed the number printed on the card and listened while the friendly voice described how to punch in my six-digit meter number after the beep. Having failed to determine my meter number, I punched in "111111". The friendly voice asked me to verify that my street address was a particular four-digit number (that is now lost to memory) by pressing a particular key. It wasn't, of course, but I... ah... did. This is just a test run, right? The friendly voice asked me to enter my meter reading. I punched in "1111". The friendly voice thanked me for my cooperation and wished me a nice day. Is it relevant that the rest of the day *was* relatively nice for me? The upsides for The Company are quite apparent: the customer picks up the $.06 cost of the call, while the Company saves both the postage and keypunch costs. The Big Risk that was apparent to me in this system was that the friendly voice presented me with my street address and asked me to verify it, rather than the reverse. It's nice that they gave a bit of thought to verifying input, but isn't this approach a bit like presenting a computer user with the account password after the user name is typed and asking if it's correct? While it is true that there is no computer account to be hacked on the other side of this authentication mechanism (which is a strong malice motivator in the case of computer accounts), it is also true that there are hearts full of mischief in this world and big electric bills to be paid or protested if this system is implemented as proposed. BTW, in the same mailing was a proposal for an alternate meter-reading scheme. The customer simply provides The Company with a copy of the key to the home, and the meter-reader simply lets self into the home to read the meter as necessary. Who can spot the risks in this one? -Scott Rose ------------------------------ Date: Thu, 14 Apr 94 00:10:31 +0100 From: Jak Kirman Subject: Stun belts -- who has the remote? AP and NBC reported recently on the use of REACT belts by police. Strapped around a prisoner's waist, the belts can deliver a 50,000-volt, 4-6 mA current to the prisoner's back muscles, enough to incapacitate the prisoner. They are activated by "a remote control like a garage-door opener". These belts are used on prisoners in transit and in court. The reports supplied no details concerning the communication between the remote device and the belt. I wonder how much thought the designers gave to the possibility of unauthorized activation of the belt, e.g. by friends of the victim or simply out of malice. Judging by the footage on the NBC clip, it would be very hard indeed to get the belt off a prisoner who was being zapped by some unknown person. If the remote device actively transmits start and stop commands, it might also be possible for an associate of the prisoner's to inhibit or curtail authorized activation; this would put the prisoner at a substantial advantage in an attempt at escape, since prisoners wearing the belt are not hand-cuffed, and are presumably not expected to make a run for it. Can anyone supply technical details that would clarify the risks? Jak Kirman jak@cs.brown.edu ------------------------------ Date: Mon, 11 Apr 94 11:06:05 PDT From: joe@synaptics.com (Joe Decker) Subject: Risks of Data Compression An article in the most recent issue of _Weatherwise_ magazine contained a description of a system under development to send weather radar images to general aviation via data compression. One technique apparently used to minimize bandwidth was to not provide distinctions between the highest radar reflectivity levels, the idea being (according to the article) that you wouldn't want to be in a light plane in any of them. This neglects the RISK that you already are in one of them. A more insidious RISK was not noted in the article. Many image compression methods result in images with misleadingly high amounts of detail. Such images could mislead pilots into making decisions based on false detail in the decompressed images. Image compression in safety-related applications clearly demands caution. joe decker @synaptics.com @alumni.caltech.edu ------------------------------ Date: Tue, 19 Apr 1994 23:36:49 GMT From: neodata!taurins@sterling.com (Agris Taurins) Subject: TV Guide Contest Is it just me, or has anyone else noticed the TNG contest in the April 23-29 issue of TV Guide? As contests go, it's nothing terribly special. The winner(s) get flown out to Hollywood to watch the final episode. The most interesting item follows, directly out of the "Official Rules": ...To enter the sweepstakes electronically: Send your responses by April 29, 1994, to tvgtrek@delphi.com. Include name, address and telephone number, along with the answer to each of the seven questions. Sponsor not responsible for computer malfunctions; late, lost, or misdirected mail. Earlier in the rules it states "Enter as often as you wish but limit one entry per envelope." The only "out" them might have is another line stating that "No mechanical reproductions will be accepted." But since they've explicitly stated that they're accepting electronic entries, I would think that it doesn't apply. How many mailer daemons do you think will be spinning out there? How soon will it be (if it hasn't happened already) before the mail spool on delphi overflows? Agris Taurins (402) 697-8006 taurins@neodata.uucp ...uunet!sparky!neodata!taurins ------------------------------ Date: Mon, 18 Apr 94 21:52:54 CDT From: Dwight.Silverman@chron.com (Dwight Silverman) Subject: Re: MIT student arrest (Cohen, RISKS-15.76) Frederick B. Cohen, writing in the RISKS digest, muses about the case involving the MIT student arrested for having a BBS at that made commercial software available. Cohen implies that the student was unaware of the nature of the material at the site, an implication that I cannot let go unchallenged. According to news reports about details in the indictment, the student not only was aware of what was being posted, but posted a public notice asking that the existence of the site not be trumpeted. The indictment, according to the reports, indicated he was more than just a "patsy." Should MIT be "arrested," as Cohen suggested, because of the presence of this site on their machines? No, anymore than a phone company can be arrested because of telephone fraud. I've also seen comments on the Internet that those who uploaded the software should be arrested, as well. That's probably true, but it's not that easy. Again, according to news accounts, many of those who contributed to "Cynosure," as it was called, used anonymous account services to do so. The RISK? Appear to be breaking the law, and you'll end up in a lot of trouble. It doesn't get much simpler than that. Dwight Silverman, The Houston Chronicle dwight.silverman@chron.com ------------------------------ Date: Mon, 18 Apr 1994 19:14:07 -0700 From: sidney@apple.com (Sidney Markowitz) Subject: Pointer to details on arrest of MIT student (Cohen, RISKS-15.76) [sidney markowitz SK8Board Punk Rocket Scientist Advanced Technology Group, Apple Computer, Cupertino, CA 95014] Here is a pointer to information about the case of the MIT student who was arrested recently. Although it is a solicitation for a legal defense fund, it contains presentations from both sides of the case and will be of interest to anyone who is interested in the broader political, moral and RISKy issues that are involved. In particular, this is not a simple case of software piracy or computer "hacking". The student is not being accused of copying copyrighted software, but only of operating a BBS that others used for that purpose. He is being charged under wire-fraud laws, being applied in a manner that is unusual, to say the least. The following can be accessed via Mosaic or other World Wide Web client using the URL address http://martigny.ai.mit.edu/dldf/home.html Here's a quote extracted from the home page so you can see what is available there. In the actual Web version, the bulleted items at the end are hot links to their respective files. The David LaMacchia Defense Fund was organized to ensure that David LaMacchia gets a fair trial. LaMacchia has been indicted by the federal government for conspiracy to commit wire fraud. "This is the first time in Massachusetts that the wire fraud statute has been used in a computer bulletin board case," said Stephen Heyman, deputy chief in the US attorney's office. That makes the case interesting, law-making, and very expensive. An unfortunate side-effect of our common law system, where laws are made by decisions in particular cases, is that an individual involved in a constitutional test case is faced with the certainty of staggering legal bills as well as the possibility of imprisonment and fines. Contributions to the Fund will be used to defray a portion of LaMacchia's legal expenses. The Fund spends nothing on advertising, salaries, promotions, etc.; 100% of contributions are used for legal defense. The Fund takes no position on the merits of either side's case. Information from both sides * The Indictment * U.S. Attorney's April 7, 1994 press release * Response of Defense Counsel, April 8, 1994 * Issues Primer (from Defense Counsel), April 11, 1994 ------------------------------ Date: Tue, 19 Apr 94 11:20:50 EDT From: clarke@watson.ibm.com (Ed Clarke) Subject: Re: Green-Card Flap [Risks, Lawyers] (PGN, RISKS-15.76) PGN omitted the quantity of mail that indirect.com received; 100 megabytes! They crashed of course as most systems would when presented with that kind of a mail overload. You also did not mention that this was the second time that they'd tried this trick ( only about a hundred groups last time ) and that they deliberately did not return the signed agreement that forbids this kind of abuse. Posting their local phone number and FAX !!!! number was kind of cute though. Many more calls and faxes are going to the Tenn. Bar Association since that's where they are licensed. By the way, you can add my (home) system to the "crashed" list. I get about 35 meg of compressed news per day, it jumped to 45 meg compressed and I ran out of inodes. Loss of news is similar to a crash. My down stream sites aren't going to see it, so it's loss of service anyway. The minor 5000 crossposts could be absorbed (at my site), but the huge amount of complaints in every bloody group killed me. Reminds me of the ping-pong ball demonstration of nuclear fission that was shown on TV when I was a kid. One ball gets tossed into a room full of ping-pong balls on mouse traps ... boom! Ed Clarke clarke@acheron.UUCP clarke@watson.ibm.com ------------------------------ Date: Tue, 19 Apr 1994 10:06:47 -0600 (MDT) From: "Rob Slade, Ed. DECrypt & ComNet, 604-984-4067" Subject: "Naissance d'un virus" by Ludwig/Condat BKNAISDV.RVW 940113 "Naissance d'un virus", Ludwig translated by Condat I have previously reviewed Ludwig's original book (cf BKLUDWIG.RVW) and, basically, everything applies to this as well. I have only two brief comments to make on the translation. I am rather surprised that a publishing house with the stature of Addison- Wesley took this on. I note that the promotional material which came with the book states that the original was banned for export from the United States. Even allowing for marketing hyperbole, they must have known that it would give rise to some kind of difficulties. As, indeed, it did: a recent court challenge has attempted to ban distribution of the book. I haven't yet heard the outcome. (I also note that the book is supposed to help you choose antiviral software: didn't they even read it first?) The second addresses the issue of the educational value of the book. As previously noted, the text sections leave a great deal to be desired in terms of pedagogy. The viral code, however, is intact, and unchanged. All the comments are still in English. (I am very amused to note that the French translation of "computer virus"-- What? No, of course not. Don't be naive.--is CPA, standing for either "codes sources autopropageables" or "codes parasites autopropageables". This side of the pond CPA means a different sort of parasite.) copyright Robert M. Slade, 1994 BKNAISDV.RVW 940113 Vancouver Institute for Research into User Security Canada V7K 2G6 Robert_Slade@sfu.ca rslade@cue.bc.ca p1@arkham.wimsey.bc.ca p1@CyberStore.ca ------------------------------ Date: Fri, 08 Apr 94 11:29:46 PDT From: "Willis H. Ware" Subject: IFIP SEC '94 Program [Excerpted from long message by PGN] The Tenth International Conference on Information Security - IFIP SEC'94 FOR FULL BROCHURE, CONTACT THE FOLLOWING: FAX: IFIP SEC'94 SECRETARIAT +599 9652828 OR AIRMAIL TO: IFIP SEC'94 SECRETARIAT POSTOFFICE BOX 4 0 6 6 WILLEMSTAD - CURACAO NETHERLANDS ANTILLES CARIBBEAN OR EMAIL TO: < TC11@IAIK.TU-GRAZ.AC.AT > Organized by Technical Committee 11 of the International Federation for Information Processing, IFIP/TC 11 - in cooperation with the Special Interest Group on Information Security of the Dutch Computer Society - and hosted by the Caribbean Computer Society. I F I P S E C ' 9 4 M A Y 2 3 - 2 7 , 1 9 9 4 I T C P I S C A D E R A B A Y C U R A C A O, D U T C H C A R I B B E A N I N T E R N A T I O N A L P R O G R A M Dynamic Views on Information Security in Progress ***ABOUT THE TENTH INTERNATIONAL INFORMATION SECURITY CONFERENCE This event is the Tenth in a series of conferences on information security. Something to celebrate. The organizers have compiled a truly exceptional, unique, and especially upgraded conference in a setting suitable for celebrating its Tenth birthday. Over 75 sessions will cover just about all aspects of information security, on a senior and advanced level. The formal language of SEC'94 is English. The proceedings are published by Elsevier North Holland in its acclaimed series. ***INVITED PRESENTATIONS*** Computer based cryptanalysis: man versus machine approach by Dr. N. Balasubramanian, former director of the Joint Cipher Bureau/ Cryptographic Services of the Department of Defense of the Government of India. Establishing a CERT: Computer Emergency Response Team by Kenneth A. van Wyk, manager Assist team, Defense Information Security Agency of the Department of Defense, United States Privacy aspects of data travelling along the new 'highway' by Wayne Madsen, scientist Computer Science Corp., United States Issues in designing and implementing a practical enterprise security architecture by Ross Paul, manager information security, the Worldbank, United States (key note's and other invited speakers to be announced by special bulletin) IFIP TC 11 position paper in discussion: Security Evaluation Criteria by H. Schoone, Netherlands Special TC 11 Working group sessions: 11.8 Computer Security Education, chair: Em. Prof. Dr. Harold Highland 11.1 IT Security Management, chair: Prof. S.H. von Solms (S. Africa) 11.5 System Integrity and Control, chair: William List (UK) Special Appearance: Information Warfare: waging and winning conflict in cyberspace by Winn Schwartau (US) Panel discussion: Panel discussion of the editors of Elseviers Journal Computers and Security chaired by John Meyer, Elsevier (UK), editor Extended UNIX tutorial: Unix meets Novell Netware by Kevin H. Brady, Unix Systems Lab. (US) Extended virus tutorial: Technologically enabled crime: shifting paradigms for the year 2000 by Sara Gordon (US) Viruses: What can we really do ? by Prof. Henry Wolfe (New Zealand) Future trends in virus writing by Vesselin V. Bontchev (Bulgaria/Germany) Viral Tidings by A. Padgett Peterson (US) Integrity checking for anti viral purposes by Yisrael Radai (Israel) Special appearance: *title to be announced* Prof. Eugene Spafford (US) ***REFEREED PRESENTATIONS*** Operations Security: the real solution to the problem - A. Don Temple (US) Security in virtual reality: virtual security - Amund Hunstad (Sweden) Prohibiting the exchange attack calls for hardware signature - Prof. Reinhard Posch/Wolfgang Mayerwieser (Austria) Towards secure open systems - Dr. Paul Overbeek (Netherlands) A security officer's workbench - Prof. Dennis Longley/Lam For Kwok (Australia/ Hong Kong) An introduction to Citadel: a secure crypto coprocessor for workstations - Dr. Elaine Palmer (US) On the calculation and its proof data for PI 10-9th - Shengli Cheng et al. (P.R. of China) Securenet: a network oriented intelligent intrusion prevention and detection system - Ass. Prof. Dimitris Gritzalis et al. (Greece) A methodology for the design of security plans - Drs. Fred de Koning (Netherlands) An open architecture for security functions in workstations - Stefan Santesson (Sweden) Security systems based on exponentiation primitives, TESS - Prof. Thomas Beth (Germany) The structure and functioning of the COST privacy enhanced mail system - Prof. Sead Muftic, Nada Kapidzic, Alan Davidson (Sweden) The need for a new approach to information security - Dr. Jean Hitchings (UK) A Practical database encryption system - Prof. C. Chang/Prof. D. Buehrer (Taiwan, ROC) Security analysis and strategy of computer networks - Jie Feng et al. P.R.o.China) Information Security: legal threats and opportunities - Dr. Ian Lloyd (Scotland) Secure communication in LAN's using a hybrid encryption scheme - Prof. Mahmoud El-Hadidi, Dr. Nadia Hegazi, Heba Aslan (Egypt) Secure Network Management - Bruno Studer (Switzerland) Ramex: a prototype expert system for computer security risk analysis and management - Prof. Peter Jarratt, Muninder Kailay (UK) The need for decentralization and privacy in mobile communications networks - D.I. Frank Stoll (Germany) Is lack of quality software a password to information security problems ? - Dr. Peter Fillery, Nicholas Chantler (Western Australia) Smart: Structured, multidimensional approach to risk taking for operational information systems - Ing. Paul van Dam, et al. (Netherlands) IT Audit: the scope, relevance and the impact in developing countries - Dr. K. Subramanian (India) Program structure for secure information flow - Dr. Jingsha He (US) Security, authentication and policy management in open distributed systems - Ralf Hauser, Stefano Zatti (Switzerland/Italy) A cost model for managing information security hazards - Love Ekenberg, Subhash Oberoi, Istvan Orci (Sweden) Corporate computer crime management: a research perspective - Dr. James Backhouse (UK) A high level security policy for health care establishments - Prof. Sokratis Katsikas, Ass. Prof. Dimitris Gritzalis, et al. (Greece) Moss: a model for open system security - Prof. S.H. von Solms, Dr. P van Zyl, Dr. M. Olivier (South Africa) The risk-based information system design paradigm - Dr. Sharon Fletcher (US) Evaluation of policies, state of the art and future research directions in database security - Dr. Guenther Pernul, Dr. A.M. Tjoa (Austria) Exploring minimal ban logic proofs of authentication protocols - Anish Maturia, et al. (Australia) Security concepts for corporate networks - Prof. Rolf Oppliger, Prof. Dieter Hogrefe (Switzerland) The security process - Jeanette Ohlsson (Sweden) On the security of lucas function - Dr. C.S. Laih (Taiwan RoC) Security considerations of content and context based access controls - Donald Marks, Leonard Binns, Peter Sell, John Campbell (US) Anonymous and verifiable databases: towards a practical solution - Prof. Jennifer Seberry, Dr. Yuliang Zheng, Thomas Hardjono (Australia) A decentralized approach for authorization - Prof. Waltraud Gerhardt, Burkhard Lau (Netherlands) Applying security criteria to a distributed database example - Dr. Marshall Abrams, Michael Joyce (US) A comparison of international information security standards based on documentary microanalysis - Prof. William Caelli, Em. Prof. John Carroll (Australia/Canada) Security in EDI between bank and its client - Pauli Vahtera, Heli Salmi (Finland) Secure information exchange in organizations - D.I. Ralph Holbein (Switzerland) A framework for information system security management - Helen James, Patrick Forde (Australia) The security of computer system management - Xia Ling et al. (P.R.o.China) Development of security policies - Jon Olnes (Norway) Factors affecting the decision to report occurences of computer abuse - John Palmer (Western Australia) Secure manageable remote access for network and mobile users in an open on-line transaction processing environment - Dr. James Clark (Singapore) ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories; risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.77 ************************ 22-Apr-94 15:56:22-GMT,28120;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA29219; Fri, 22 Apr 94 11:56:21 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA22902; Fri, 22 Apr 94 11:52:46 EDT Received: by chiron.csl.sri.com id AA23405 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Fri, 22 Apr 94 08:46:51 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 22 Apr 94 8:46:49 PDT Subject: RISKS DIGEST 15.78 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 22 April 1994 Volume 15 : Issue 78 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Computerized Traffic-Light Problems (Debora Weber-Wulff) Risks of winning (Stanley Chow) Computer Generates False Tsunami Warning in Japan (George Pajari) NYC subway fare cards double-deduct; UI at fault (Andrew Marc Greene) A consumer risk from Thomson Consumer Electronics Re: we trust calculators over ourselves (John Powell) Re: Risks ... to the quality of science (A. Padgett Peterson) Re: Risks of Data Compression (John Kennedy) Re: Math and money laundering (Erann Gat, Peter Wayner) Re: Information resource (Edward Reid) Re: Green Card Posting (Caveh Jalali, Ned Kittlitz, Mark Brader) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: 20 Apr 1994 15:51:25 GMT From: weberwu@tfh-berlin.de (Prof_Weber-Wulff) Subject: Computerized Traffic-Light Problems The Tagespiegel reports today (20 April 1994) on the new, computerized traffic light management system that the city installed at the large traffic circle Ernst-Reuter-Platz. The 1.8 million mark (1.1 million $) system went on line on Monday, and mastered the first wave of traffic well. After that, the traffic jams swelled to beyond normal proportions. Irate drivers complained by telephone and mail, but officials insisted that since it was now computer-controlled, it was okay. Apparently someone threatened legal action, and the city traffic board dispatched people with stopwatches to test the system. Sure enough, it was stuck in the early morning pattern, which was fine for handling inbound traffic, but disastrous in the afternoon rush hour. They have to go back to hand-switching the timing until they figure out what went wrong. Debora Weber-Wulff, Professorin fuer Softwaretechnik und Programmiersprachen Technische Fachhochschule Berlin, Luxemburgerstr. 10, 13353 Berlin, Germany ------------------------------ Date: Wed, 20 Apr 1994 10:57:00 -0400 From: "stanley (s.t.h.) chow" Subject: Risks of winning I just caught this on TV news last night: A person won two consecutive keno games in the Montreal Casino. Since this is considered extremely unlikely, the police have been called in to investigate. The two games should have paid $400K, but the winner has not yet been paid. He is instead doing the talk show circuit with how he analysed the numbers. Supposedly, in the history of Nevada, the Keno jackpot has only been won once, which made his winning back to back somewhat unlikely. This happened on the electronic keno and has been shut down. The mechanic game is carrying on. A one line comment by the reporter claimed that "a bug" in the computer repeated the sequence of number exactly every 4,000 games. This may be a case of someone picking a poor random number generator; but may well be the basis for police action. I understood that electronic slot machines are free running, merrily generating random numbers all day long, and pulling the lever merely selects the current number. This seems quite robust. Stanley Chow InterNet: schow@BNR.CA (613) 763-2831 Bell Northern Research Ltd., PO Box 3511 Station C, Ottawa, Ontario Me? Represent other people? Don't make them laugh so hard. ------------------------------ Date: Wed, 20 Apr 94 10:55:17 PDT From: George Pajari Subject: Computer Generates False Tsunami Warning in Japan RISKS readers will find this all too familiar... >From the April 19th, 1994 edition of NHK's "Today's Japan", broadcast on KCTS (Seattle's PBS affiliate) 0100h PDT April 20th (as remembered): Japan's weather bureau installed a new computer system for automatically generating tsunami warnings after earthquakes. The story implied that the machine was connected to various sensors around Japan and was configured to generate and communicate these warnings automatically. During installation testing simulated data was input to verify the operation of the system. Unfortunately the machine had already been connected to the system that communicates tsunami warnings to the government and media and no one disconnected this communications link when the tests were run. The predictable happened. The machine "detected" a potential tsunami, sent out the appropriate warning and at least two broadcast stations interrupted their normal programming to announce the impending tsunami. Obviously this caused some concern among the populace. The problem was detected five minutes after the warning was first communicated but this was still sufficient time for the the warning to be broadcast. pajari@Faximum.COM George Pajari / Faximum Software / Tel: +1 (604) 925-3600 / Fax: ... 926-8182 1497 Marine Drive, Suite 300 / West Vancouver, BC / Canada V7T 1B8 ------------------------------ Date: Fri, 22 Apr 1994 09:10 -0400 From: Andrew_Marc_Greene@frankston.com Subject: NYC subway fare cards double-deduct; UI at fault [Source: The New York Times, 22 Apr 1994, p. B2] The NYC subway has been introducing swipe cards which can be bought in five-ride increments. According to today's _Times_, citing an article in Thursday's _Newsday_, many riders are swiping improperly, causing a fare to be deducted from their card but not opening the turnstile. There's a display which instructs the rider to swipe again, but these are New Yorkers and have already decided to try another turnstile. Apparently, the designers anticipated this problem and put in a solution -- if you swipe again at the same stile it doesn't deduct a second fare -- but didn't anticipate that harried/hurried Nyawkas wouldn't stop to read the display. - Andrew Greene ------------------------------ Date: Thu, 21 Apr 94 17:05:33 XXT From: [a source within TCE] Subject: A consumer risk from TCE Thomson Consumer Electronics (TCE) is about to release a home entertainment product called the Digital Satellite Service (DSS) under the RCA brand. In short, this product is a small satellite dish (18" in diameter) that will allow customers to order video/audio programs from service providers. At this time the service providers are DirecTV (Hughes) and Hubbard (USSB). The system works as follows. Upon purchase of a DSS system, the customer will receive a "smart-card" and then subscribe to one or more service providers. The customer can then view programs and order pay-per-view programs. The smart-card controls and tracks all purchases made with the DSS system. Information stored includes programs purchased, whether or not the programs were viewed, and the time the programs were viewed. This information is then transmitted (via telephone) to the service provider for billing purposes. The RISK? The service providers have the ability to build large databases of information on household viewing habits (e.g., John Smith views adult movies every Wednesday night between 10:00pm and 11:00pm). This information could then be sold to direct marketing firms, etc. There are laws that prevent cable companies from selling or releasing an individual's subscription information, but, to the best of my knowledge, the service providers for DSS are under no such obligation. ------------------------------ Date: Fri, 22 Apr 94 09:54:55 PDT From: "John Powell" Subject: Re: we trust calculators over ourselves (Crawford, RISKS-15.76) I had a similar situation last year when leaving a super expensive garage in downtown Chicago. The rates were 22.00 for 7-9 hours, and 40.00 for 9-24 hours. I had been there 8 hours and 50 minutes (I obviously was watching the clock closely with these stakes). When the attendant ran my timecard through the computer, it came up with $40.00 as the rate. The next 10 minutes I caused a significant backup as I refused to pay $40 when the sign clearly stated the rate as 22. I got him to agree that the sign was right, and that I was there for less than 9 hours, but he still insisted that I owed him 40 ('cause the computer said so). I asked him to call a manager, he responded "I am the manager!!!!!". I spent the next several minutes describing to him the concept of rounding, and that the software obviously stunk and was written by thieves (or idiots or both). With these rates, the "thief" part was a given! After a while he got the message that I was not going to pay more than 22, and decided to let his office figure it out later. After I paid him the $22, I asked for a receipt. "I am sorry sir, but that is printed by the computer!!!". Another 2 minutes were spent figuring out how to write a manual receipt (which he had, but had never used!!). John Powell ------------------------------ Date: Wed, 20 Apr 94 08:14:59 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson, Information Security) Subject: Re: Risks ... to the quality of science (Tobis, RISKS-15.77) >This issue was addressed in a remarkable essay by the eccentric and >curmudgeonly fluid dynamicist Clifford Truesdell. The essay is called "The >Computer: Ruin of Science and Threat to Mankind" Something I have been noticing for some time is the loss of capabilities along certain lines of thought due to the dominance of others. Actually the first evidence to me was when the hordes of Radio Shacks came out and all of the small shops disappeared. Suddenly it was difficult to find the "low volume" pieces amid the cheap plastic sound reproduction devices. Later I became involved in a study of magnetic amplifiers and discovered that research in this country had essentially died out around 1957. I suspect that the rise of the transistor and integrated circuit which made no provision for the "L" in a "RLC" circuit. Young electronic engineers look at me strangely when I ask if they have heard of "Eli the ice man." Think I'll hold onto my collection of steam engineering books 8*). > 5. Mathematics is the Science of Infinities. Computation is Essentially > Finite. I suspect this is the real threat. In all of the cases mentioned above, dominance of the field has resulted in a reduction of the field as promising technologies are shunted aside for reasons other than technological. In the mid 1800s Samuel Colt might not have achieved prominence if it were not for the Czar's purchase of the entire output of Smith & Wesson for several years. What if Motorola had not been inundated by orders for CPUs by General Motors in 1980 and the IBM-PC had been 68000 based with a 32 bit flat memory model ? What if CPM/86 had been available (PC-DOS was actually choice four of three)? Should we "Think of it as Evolution in action" or "blind chance" ? Padgett ------------------------------ Date: Thu, 21 Apr 1994 23:26:29 -0700 From: John Kennedy Subject: Re: Risks of Data Compression (Decker, RISKS-15.77) In a previous incarnation, I designed the graphical output of a weather radar system. As you can imagine, it was filled with concessions for the viewer's pleasure (mostly researchers, but some airports too). At best, the output was lossy. Take a float, run it through an algorithm, convert it to a signed byte (+/- 127), and scrunch that down until you had about 16 possible different colors, many of which were set to the same value (usually about 8 different colors total). Why? Storms were easy to spot, useful data crunching really couldn't be done with the eye because it was a slice through a cloud formation (particular in real-time PPI displays), etc. The expectations of researchers hadn't caught up with the physical & economic reality involved with the displays. The end result was easy to use picture that could tell you where the wind was moving, usually involving about 8 different colors, often with lots of empty space (clear days were very boring). This data would compress quite well without data loss. I wouldn't have expected anyone to match high (towards) and low (away) velocity colors since they could mean a great deal to a pilot, especially in a small plane, but you certainly wouldn't like being in either situation. The algorithms and noise present in the uncompressed data should warn anyone away from using the data too literally. You'd be surprised at the number of sites that planted a radar-blinding pole right by the dish, resulting in a large pie-shaped wedge taken out of every piece of data they ever generated. John Kennedy ; Communications Services; USENET admin ------------------------------ Date: Thu, 14 Apr 94 11:26:21 PDT From: gat@aig.jpl.nasa.gov (Erann Gat) Subject: Math and money laundering (Wayner, RISKS-15.75) The following two articles appeared immediately following one another in RISKS 15.75: >From: pcw@access.digex.net (Peter Wayner) >Subject: God Grants Granite Gift to RISKS Punsters >Subject: The Soft Pork Underbelly of Efficient Markets The first article was about the inability of mathematical models to deal with the hairy edges of reality in the financial markets. The second article was about a way to use the futures markets to launder money in a way that was (the author claimed) essentially untraceable. The irony of this juxtaposition is striking (so striking, in fact, that I am wondering if this is a coincidence or a masterful display of editorial subtlety) because the money-laundering scheme proposed by Peter Wayner won't work, despite the seemingly rock-solid mathematics that underlies it. Wayner proposes to use the zero-sum property of the futures market to transfer money from A to B through the use of balanced trades. A and B respectively buy and sell an identical futures contract and then wait until market volatility has caused A to lose (and B to gain) the amount of money to be transferred, at which point A and B simultaneously get out of the market. Some subtle clues leading to a reductio ad absurdum proof that this scheme is flawed can be found in the original text. For example, Wayner suggests that A and B use different brokers so that the coincidental trades will not be on the same set of books. So the scenario he proposes goes something like this: A and B agree to a symmetric trade to be liquidated when the market reaches some predetermined price point, at which point money will have effectively transferred from A to B. After the initial agreement, there is no further communication between A and B. In fact, neither has any way of knowing whether or not the other party has in fact executed their side of the bargain, and it doesn't really matter. B's financial position depends only on the state of the market, which is not affected by whether or not A is playing (assuming the amounts of money involved are not extremely large). In fact, B doesn't have to talk to A at all. There doesn't even have to be an A. B can just *pretend* that there is an A out there somewhere who has agreed to transfer money to B using Wayner's scheme, play the market, and make money. Or can he? The critical flaw in this scheme is in the following paragraph where Wayner describes (fleetingly) what happens when the market doesn't do what A and B expected it to: >Person B sells the contract so that if the market goes down, i.e., the wrong >way, then A and B together have lost no money. It's a zero sum. Now they just >have to play the game a bit longer or for stakes that are twice as high. You ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >can think of the process as flipping a coin until you have encounter a heads. This little detail reveals this to be just another incarnation of a well known gambling system where bets are successively doubled on an even bet until you win. The problem with the scheme is that even a short run of losses requires a TREMENDOUS amount of capital to finance the exponentially increasing stakes required to stay in the game. In fact, you *can* make money using this scheme for a little while. The problem is that when you make money you don't make very much. When you eventually (and inevitably) encounter a long run of losses or unexpected market moves, you lose really big. Laundering money through electronic markets works only if you can reliably predict the direction of the market. If you can do that, you don't have to launder money. On this particular RISK I think we can all rest easy. Erann Gat gat@robotics.jpl.nasa.gov ------------------------------ Date: Tue, 19 Apr 1994 22:59:28 -0400 From: pcw@access.digex.net (Peter Wayner) Subject: Re: [gat@aig.jpl.nasa.gov (Erann Gat): Math and money laundering] Double or Doublecross? Your choice. First, forget about thinking like a mathematician, a gambler or an upstanding citizen of Wall Street. You are some guy A who wants to move money to some guy B and you want to do it in as untraceable a way as possible. You're willing to pay extra for something that looks respectable and guys on Wall Street look real respectable in their braces and bespoke suits. The old standbys, gold and gems, are fine, but they are hard to move safely. Plus you need an "explanation" for how you got them. Strange business contracts are okay, but they demand some sort of front operation which takes time and money to run effectively. So you turn to the futures market for the first try. Lets say you want to move n dollars. Luckily, both A and B have enough cash and borrowed funds on hand to sustain a loss of up to (2^i)n dollars. Let i=4 for the rest of this example, i.e. 16n dollars of loss reserves. In 15 out 16 times, the progressive doubling system will work. The transaction will be close to untraceable. The only way that anyone would be able to prove that the transaction occurred would be if they could assemble both trading records and then match the trades. This can be shielded very effectively by trading in different countries with different exchanges and relying on arbitrageurs to keep the markets in line, but it tends to cost much more in transaction noise. In 1 out of the 16 tries, things will go wrong. You might say they would go terribly wrong if you're a nervous criminal B who is afraid that A is going to doublecross him. Now A needs to get 16 n dollars fast. This is the big reason why A doesn't want to play the game alone or try and trick B into playing without A. If A mirrored the trades, the 16n dollars aren't in the pockets of a casino or the state lottery. They're just in A's pockets not B's. In reality, A and B are back where they were before futures markets were invented. They just need to move 16 times more money. Your reaction to this depends upon the marginal cost of going back to the old fashioned money laundering tricks. I think at this point you just take a bigger truck to haul the gold. You do some trades with Van Goghs and Rembrandts instead of Cassats or Sisleys. In general, many of the transaction costs for security and other stuff are pretty fixed. Just remember that auction houses like Southeby's try to take 10% commissions, but they can be negotiated to be much lower for expensive works. Exciting record breaking prices attract attention and news. The futures game is not perfect by any means. There _are_ transaction costs and problems in logistics. It works best if A+B can lock in exactly the same price on their trades. But when it is done, you can look at the world and say, "Gosh, I was completely at RISK! Thank God my Martingale scheme worked after all!" All the really smart mathematicians and sober IRS guys who never gamble because they know the odds will just accept it and think you're crazy to be doing this with your money. It comes with a built in insanity plea. So, if your going to do this, choose i to suit your cash/RISKS profile. If you have more cash available, then you have a better chance of success. But hey, that's life. ------------------------------ Date: Wed, 20 Apr 94 11:08:33 EDT(-0400) From: ed@titipu.resun.com (Edward Reid) Subject: Re: Information resource (RISKS-15.76) The message from Michael Enlow announcing an "information resource" is junk mail which apparently has been broadcast widely on the Internet. My wife and I both received copies of this message. Neither of us has expressed any public interest in the topics Enlow mentions. Melynda attempted to reply to the email, asking why it had been sent to her unsolicited; in reply she received a listing of information from a mailer daemon. I wrote the "From:" address in the header asking the same question and have received no reply. I suspect that it was sent to RISKS by accident, simply by picking up the submission address in some dragnet for email addresses. Enlow claims to be retired, but the listing sent by the "info" daemon lists two apparently active businesses. The info listing does not contain any advertising or solicitation. I have not retrieved any of the files listed, so I cannot comment on their value or on whether they contain advertising, except for one file which is clearly labeled as a catalog. The other files, from their titles, would appear to promote private investigation in general but not a specific business. Enlow's information resource may valuable, but I object to his use of junk email to publicize that resource. That fact that he did not reply to my individual request makes me suspect his motives. Edward Reid, PO Box 378, Greensboro FL ed@titipu.resun.com (normal) ------------------------------ Date: Tue, 19 Apr 1994 21:31:55 +0800 From: Caveh.Jalali@eng.sun.com (Caveh Jalali) Subject: Re: Green Card Posting [The 19 Apr 1994 New York Times Business Day section has a lengthy story entitled An Ad (Gasp!) in Cyberspace, by Peter H. Lewis, about the Green Card ad as its lead story. Here are some relevant details, via PGNed abstracting... For earlier details, see RISKS-15.76 and 77. PGN] Laurence A. Canter was quoted as saying, "We will definitely advertise on the Internet again. It appears to be a very profitable venture and a very viable vehicle for advertising a variety of things. I'm sure other businesses will be advertising on the network in the very near future." Jeff Wheelhouse, system administrator for Internet Direct, Inc., was quoted as saying. "They will not be back on our system," He also said he would not be deterred by Mr. Canter's threat to sue Internet Direct for $250,000 unless he is reconnected. "They crashed our computer about 15 times -- that's when we stopped counting -- because of the volume of incoming complaints," Mr. Wheelhouse said. "I lost an entire week dealing with this." Wheelhouse said Internet Direct would remain firm, despite Canter's threat to sue Internet Direct for $250,000 and restoration of their electronic mail privileges. That amount was what prompted Canter to say, "Conservatively, that's the amount of business we feel we will get out of this from the ad." "The Internet is changing," Mr. Canter said. "People don't like the invasion of what has been their private world. But as long as it's set up the way it is, where anyone has access to it, it's a public forum, and they have to accept anything that comes into it. "In fact," Mr. Canter added, "I've received a lot of calls from people who want to know how to do it." So pleased is he with the response, in fact, that he said he planned to write a book on how to advertise on the Internet. [However, this suggests a grand strategy. Run an offensive ad, get chopped off, and then sue for the profits you did not make. PGN] ------------------------------ Date: Wed, 20 Apr 1994 12:28:47 -0400 (EDT) From: Ned Kittlitz Subject: immigration posting overload and lawsuit [...] Rather than being wronged parties, it seems that C&S is flirting with a federal rap in the tradition of the Morris internet worm. An estimate of international expenditures of sysadmin time due to the C&S posting might be interesting. E. N. Kittlitz (kittlitz@sw.stratus.com, kittlitz@world.std.com) ------------------------------ Date: Wed, 20 Apr 1994 05:55:32 -0400 From: msb@sq.com Subject: Speaking of green cards The most fun response to the Green Card Flap that I saw was in rec.games.bridge, where someone said "I don't understand why this was posted here; in this newsgroup we're only concerned with red and black cards"! (There were followups, but you'd have to be into duplicate bridge to appreciate them.) ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.78 ************************ 26-Apr-94 21:03:01-GMT,31086;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA19225; Tue, 26 Apr 94 17:02:59 EDT Received: from [192.12.33.73] by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA21224; Tue, 26 Apr 94 17:02:44 EDT Received: by chiron.csl.sri.com id AA02155 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Tue, 26 Apr 94 13:50:08 -0700 From: RISKS Forum Sender: RISKS Forum Date: Tue, 26 Apr 94 13:50:06 PDT Subject: RISKS DIGEST 15.79 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Tuesday 26 April 1994 Volume 15 : Issue 79 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Fax programming -- risk to politicians (Tom Keenan) Data Escape from Prison (Mich Kabay) Industrial espionage (Mich Kabay) Trojan @ U. Michigan (Mich Kabay) $14 million QA failure (Mich Kabay) Security and Privacy panels (John Rushby) Strange Stalking (Flint Waters) UK Industrial Spy Law (Peter Sommer) Combination Locks I Have Known (Neil McKellar) Unusual Newspaper Error (Stewart Rowe) Risks of advertising on the net (Jerry Leichter) Updated addresses for Canter & Siegel (Paul Robinson) Re: MIT student arrested for BBS used ... (Tim Shepard, Douglas Rand) Re: NYC subway fare cards double-deduct (Mark Brader, Dan Lanciani, Padgett Peterson) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Mon, 25 Apr 94 18:40:56 MDT From: "Tom Keenan" Subject: Fax programming -- risk to politicians According to the April 25/94 Globe and Mail: Canadian Human Resources Minister Lloyd Axworthy is embarrassed by the leaking of a sensitive working paper to the press. It concerns government plans and "specifically indicated that Quebec wasn't going to get full control over job training any time soon." Unfortunately, an operator did not press the 0-2-1 fax code that would have sent it to English speaking provincial government offices. By hitting 1-2-1 instead, the working paper went to eight French language newspapers in Quebec, two of which eventually published stories on it. Some are questioning whether it was indeed an error or the work of a saboteur. Reporters "marvel that a document of particular sensitivity to Quebec accidentally went to Quebec newspapers only." Several years ago a similar faux pas occurred in the Canadian parliamentary press gallery when a young woman sent a detailed account of her romantic exploits of the past weekend by email to a female friend. She accidentally filed it with every newspaper's parliamentary reporter, but they were gentlemen and did not publish it. Dr. Tom Keenan, I.S.P. Dean, Faculty of Continuing Education University of Calgary 2500 University Dr. NW Calgary, AB T2N 1N4 CANADA Voice: (403) 220-5429 FAX: (403) BUG-EXIT = 284-3948 ------------------------------ Date: 26 Apr 94 12:13:52 EDT From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Data Escape from Prison >From the Associated Press newswire via Executive News Service (GO ENS) on CompuServe: Inmates-Computers, By MARIA S. FISHER, Associated Press Writer KANSAS CITY, Kan. (AP, 18 Apr 1994) -- The letter startled Nick Tomasic. It was from a prison inmate; other fellow prisoners, assigned to computerize records, had taken a Social Security number from an accident report and tried to sell it. Tomasic is the district attorney for Wyandotte County. It was his number. The author makes the following key points: o 29 states and the federal government use prisoners for data entry. o The National Correctional Industries Association in Belle Mead, NJ scoffed at the potential risk of misuse, saying that in 12 years, there have been no cases of abuse. o Tomasic warned that criminals could determine addresses and phone numbers of witnesses and victims during data entry. o In Johnson City, KS, Sheriff Kent P. Willnauer is looking into allegations that a prisoner passed Social Security numbers and other data to a confederate who opened fraudulent bank accounts. o Kansas State government officials insist that the data entry program saves taxpayers hundreds of thousands of dollars and that there is no danger to privacy or safety of residents. Michel E. Kabay, Ph.D./ Dir. Education / Natl Computer Security Assoc. ------------------------------ Date: 26 Apr 94 12:13:39 EDT From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Industrial espionage >From the Reuter newswire via Executive News Service (GO ENS) on CompuServe: CHINESE PAIR HELD IN TECHNOLOGY THEFT, By Robert Boczkiewicz DENVER, April 15 (Reuter) - A federal judge cited national security concerns Friday when he refused to free a Chinese citizen who remains under house arrest charged with stealing software technology." According to the author, the FBI arrested Wang Liaosheng and Jing Cui for an alleged theft of source code from Ellery Systems, Inc of Boulder, CO. Wang, a former employee of this firm, allegedly sold information to Beijing Machinery Import & Export (Group) Corp for $550,000. The pair face charges of computer and wire fraud and could be punished by a maximum of 15 years in prison and $500,000. Michel E. Kabay, Ph.D./ Dir. Education / Natl Computer Security Assoc. ------------------------------ Date: 26 Apr 94 12:13:46 EDT From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Trojan @ U. Michigan >From the Washington Post newswire via Executive News Service (GO ENS) on CompuServe: Message Posted On Internet Spurs Probe; Jokes, Threats Directed At African Americans By John Burgess, Washington Post Staff Writer, 25 Apr 1994 The sordid side of the emerging electronic culture got a very public airing at the University of Michigan this month. Officials there are investigating an incident involving a stolen computer password and a death threat against African Americans that was sent over the global Internet computer network. The author continues with the following key points: o the perpetrator is still unknown. o On April 5, someone using a University of Michigan email address sent the offensive message to 30 newsgroups on the Net. o "Purporting to come from a group called the Organization for the Execution of Minorities, the posting was a lengthy collection of jokes and riddles directed against black Americans. It also contained rambling threats of death and injury." o The host system was immediately flooded with angry protests from around the Net. o The supposed originator protested his innocence and repudiated the message and its content. o Campus computer security specialists think the student may have been a victim of a classic Trojan Horse which collected logins and passwords by spoofing the login screen and writing the ID/password pairs to a file for retrieval. o International users also received the posting and criticized Americans for racism. Michel E. Kabay, Ph.D./ Dir. Education / Natl Computer Security Assoc. ------------------------------ Date: 26 Apr 94 15:28:10 EDT From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: $14 million QA failure >From _The Globe and Mail_ [Canada], Mon 94.04.25 p. A3: "Pensioners to keep overpayments: Ottawa to write off $14 million mistake by computer." According to the Canadian Press report, 8,000 pensioners received overpayments because the computer programs at the Canada Pension Plan did not correctly combine pensions. "...[I]t took years to uncover the mistake and figure out what to do about it." [MK comments: what amuses me is the headline which blames the mistake on the computer. Quality Assurance, where art thou?] Michel E. Kabay, Ph.D. / Dir. Education / Natl Computer Security Assoc. ------------------------------ Date: Sun 24 Apr 94 17:07:28-PDT From: John Rushby Subject: Oakland posting for risks Last chance to register for 1994 IEEE SYMPOSIUM ON RESEARCH IN SECURITY AND PRIVACY May 16-18, 1994 Claremont Resort, Oakland, California The program for this, the main conference on computer security research, was posted in RISKS-15.43, 30 Jan 1994. I won't repeat the whole thing, but here are the details of the very exciting panels that have been arranged. These were missing from the earlier posting. Monday 2:00--3:30 PANEL: Firewalls Moderator: Steve Kent (BBN) Panelists: Steve Bellovin (AT&T) -- "Firewalls are good" Phil Karn (Qualcomm) -- "Firewalls are bad" Tuesday 2:00--3:30 PANEL: What Security Needs To Learn From Other Fields Moderator: Teresa Lunt Panelists: Nancy Leveson (U. Washington) -- safety Fred Schneider (Cornell) -- dependability Jeffrey Voas (Reliable Software Technology) -- testing Brian Snow (NSA) -- security perspective There's still time to register. The easiest way to get the program and registration form is by WWW from http://www.csl.sri.com (follow the link under conferences), or by anonymous ftp of the file /pub/oakland94.txt from ftp.csl.sri.com. If all else fails, send email requesting the form to John Rushby (Rushby@csl.sri.com). ------------------------------ Date: Tue, 26 Apr 1994 14:00:00 +0000 (M) From: Flint Waters Subject: Strange Stalking We just finished a pretty strange case. A woman came in a reported that her estranged husband was stalking her. The officer that took the call started an investigation for the alleged stalking and contacted our County Attorney, (DA to most folks). While investigating the matter the suspects lawyer turned over email from the wife to the husband soliciting contact. It started to look like a normal domestic situation where the complaint matches the mood. Sgt Banks brought me the email so I could verify it and move on to other things. As I started looking into it things got strange. One of our campus systems is an Alpha running VMS and we have a special NEWUSER procedure which allows staff to create their own accounts, providing they know all of the important information about themselves. As I investigated the accounts I found that the suspect and victims account were created within a few minutes of each other. I placed a trap on the logins to both accounts and soon learned that every access to her account was immediately preceded or followed by an access to his account and from the same computer. Over the next several months I tracked the access to both accounts and watched as the suspect turned over more and more email from his wife. This guy was pretty creative in that he wrote long letters to himself and even changed his writing style to mimic hers. We had a pretty solid interference case for the false evidence he was creating but it was only a misdemeanor. We really wanted to put together a felony due to some other crimes the suspect had committed, which were pending prosecution. Finally, the wife decided to take a computer course on campus. The first day of class the students were told to create accounts on the campus computer system. Our victim went to the computer lab and followed all of the appropriate steps only to find she couldn't create an account because her authorization had been used already. Confused she went to her assigned User Consultant and complained that she was denied access. The consultant, not knowing about my investigation, disusered the fraudulent account and helped the victim get a new one. The gig was up since I was certain the suspect would realize we were watching him now. Fortunately, denial of computer service is a felony in Wyoming. We then pursued the arrest warrant. Several days later our suspect was arrested at his office on campus. When arrested he asked if he could call his attorney. When we said yes, he led us down the hall to a locked computer lab. He entered the code on the door and walked to the phone which sat two feet from the very computer that had been used to generate many of the fraudulant messages. By now our case was pretty solid. The suspect was charged with Computer Crimes: Crimes Against Computer Users which carried a three year felony term, ten years if intent to commit fraud is proven. Kinda heavy but pretty funny when you face the guy and he lies through his teeth. He thought he was dealing with a couple of Barney Fife's and he treated us like we were stupid. Obviously we didn't know what we were talking about and he had received all of the mail from his wife. We booked him and went back to work. As it turned out, the joke was on us. On the day of the preliminary hearing the suspects lawyer arrived with a sworn affidavit from the wife. She decided that she had not been stalked and that her husband had not denied her of any computer service. It appears a reconciliation is in the works. Naturally we decided not to pursue prosecution with a hostile victim and our case was dropped. Really a shame considering the hours we had invested. The suspect has some federal time hanging over him on some other crimes but I really would have liked to see him lie on the stand about his computer feats. Oh well. I never thought I'd have a computer-domestic disturbance. ------------------------------ Date: Sat, 23 Apr 94 10:59:15 GMT From: hcorn@virtcity.demon.co.uk (Peter Sommer) Subject: UK Industrial Spy Law INDUSTRIAL SPY'S LEGAL LOOPHOLE TO BE CLOSED Britain's industrial spies enjoy a legal loophole. If they access a computer to which they are not authorised, they can be found guilty under the Computer Misuse Act, 1990. If they manage to deceive an authorised user into giving them information from that computer, they almost certainly commit no offence. The UK government signaled on March 24th 1994 that it would introduce remedial legislation. However the precise form is still unclear and there appears to be no date for implementation. English Law knows no concept of information theft - you can steal pieces of paper and data media containing information but there is no specific law protecting commercial secrets. The law is more concerned with catching the means of industrial espionage: bugging and tapping are criminal offences, respectively under the Wireless Telegraphy and Interception of Communications Acts. The Computer Misuse Act punishes unauthorised access without, in section 1, caring what the reason was. Recent coverage by the BBC-TV's leading current affairs show Panorama and by the London Sunday Times has revealed that 200 UK pounds is the average rate charged by private detectives to assemble a dossier of an individual's bank balances, medical records and tax status. Nearly all of the information comes via abuse of this loop-hole. The technique is variously called the pretext call, the voice-hack, the imposter and the masquerade. The private detective assumes whatever "official" identity is necessary to mislead the bank clerk or government employee. Recently one "detective agency" has been circulating leading figures in the UK with offers to obtain critical data on any individuals in whom they were interested. If any offence is being committed, it is probably by the computer owners, who, under the Data Protection Act, have an obligation to take appropriate steps to secure data under their control. (Eighth Principle, Data Protection Act, 1984). Data Protection obligations apply within the European Union. A case in a magistrate's court (lowest level) last December suggested that there might be a way of extending the Computer Misuse Act to cover such third parties. Malcolm Farquharson induced a female employee of a cellular phone company to obtain details of cellular phone numbers and their ESNs (Electronic Serial Numbers) so that he could fraudulently clone phones. The numbers were held on a computer to which the female employee had authorised access. Farquharson, but not the employee, was found guilty and sentenced to six months in prison although he had never touched the computer. However legal experts believe that this case would not survive appeal to a higher court. The UK Home Office say that the loophole will probably be closed by means of an amendment to the Data Protection Act but have so far produced no wordings nor a timetable. On April 10th, Home Secretary Michael Howard said that the Government was considering a new offence of gaining information by deception. Even when the loophole is closed the abuse is likely to continue - enforcing a law where a telephone-based perpetrator is already doing a good job pretending to be someone else is never going to be easy. Peter Sommer at the Virtual City London N4 4SR United Kingdom hcorn@cix.compulink.co.uk CompuServe: 100012,2610 ------------------------------ Date: Tue, 26 Apr 1994 13:56:55 -0600 Subject: Combination Locks I Have Known From: Neil McKellar I have owned four combination locks in my life. All of them were made by 'Dudley', a Canadian company. Admittedly, these are not top of the line locks. They were, however, the brand of lock officially "endorsed" by my school in grade 7 when I first got a locker. That was in 1979. I owned that lock until 1991 when it was broken into at the local gym. I immediately went out and bought the first 'Dudley' lock I picked out of a basketful in front of the local bookstore checkout counter. By mere coincidence, this lock had the same combination as my old one. I treated this as fortunate happenstance. Later, I lost the new lock and was forced once again to replace it. Again, I selected the first lock in the basket. This time it had a different combination which I promptly forgot when the lock lay idle for six months. So this time, I purposely searched through the basket for a lock with MY combination on it. I found one in less than thirty seconds. The locks are of the tumbler variety with markings from 0 to 59. I've tried my lock and I can be off by one marking when dialing the combination. Still, considering that I have successfully obtained 3 of 4 locks with the same combination, I'm tempted to go home tonight and try to "find" the combination I lost. Perhaps I'll even time myself. Neil McKellar (mckellar@cs.ualberta.ca) ------------------------------ Date: Fri, 22 Apr 1994 16:55:29 -0400 From: "Stewart Rowe" Subject: Unusual Newspaper Error Perhaps one of your readers can explain how the Midwest edition of *The New York Times* today had a photo on the front page with the caption. "Joseph P. Kennedy Jr. being arrested at the White House yesterday", with no further explanation or story anywhere in the paper? Stewart Rowe usr2210a@tso.uc.edu ------------------------------ Date: Tue, 26 Apr 94 08:23:08 EDT From: Jerry Leichter Subject: Risks of advertising on the net In their Internet advertising, Canter and Siegal are ignoring some fundamental characteristics of the net as currently constituted. I think they'll find their attempt at Internet advertising will fairly quickly become ineffective - though many people may be annoyed along the way. The relevant characteristics of the Internet are (a) the anonymity; (b) the low cost of generating any particular kind of message. What, after all, prevents anyone from taking a C&S ad, modifying it slightly - changing the addresses and phone numbers, for example - and posting it back as widely as the original? If only a few people do this, it will be impossible to tell which are the real ads and which are fakes - short of calling a phone number and finding that it terminates, say, at the Bar Association rather than C&S. Of course, ads that mention price will raise even more severe problems. If the spoof suggests a completely unreasonable price, the business can probably disclaim it. But what happens when the spoof suggests a reasonable-looking price that happens to leave the advertiser with no profit? He is left the the choice of accepting the price, and losing money, or disclaiming the ads, damaging his own reputation. Traditional printed ads can, of course, also be spoofed. However, attempts to do so are rare. First, it's very expensive to do; second, the traditional at least attempt to verify the identity of advertisers. Neither of these constraints apply on the net. It's true that a careful reading of the header lines will often reveal which are the true ads, and which are the fakes. But why should the people who the ad is trying to reach bother to check header lines? The whole point of an ad is to communicate information quickly. The same reasoning shows that digital signatures wouldn't help. Who would bother to check them? Only those who have an established relationship with the sender of the ad would likely even have a quick ability to verify the signature - and that's not the population a broadly distributed ad is trying to reach. When the spoofers are traceable - and it's well known that it's often impossible to trace a message, much less *prove* that a particular individual sent it - the legal situation might get rather interesting. Even ignoring the very broad protection the courts have recently granted to parody, why is the spoofer's message any less legitimate than the original? If the spoof ads look entirely different, refer to "Carver and Siegalman", and have different addresses and phone numbers, just what right to "Canter and Siegal" have to complain? They are not being directly referred to or identified. If they have a problem establishing a unique identity in the noise of the marketplace - and no one ever said that all marketplace participants have to be genuine - that's not the law's concern. -- Jerry ------------------------------ Date: Fri, 22 Apr 1994 14:24:08 -0400 (EDT) From: Paul Robinson Subject: Updated addresses for Canter & Siegel This list should help in setting up kill files or to watch for later posts: Sender: LISTSERV list owners' forum Poster: Wes Morgan Subject: Updated addresses for Canter & Siegel [mispeling curekted] It appears that Canter & Siegel, the law firm which recently flooded both Usenet and LISTSERVs with their "Green Card Lottery" posting, have secured access to the net through many sources. For those of you interested in blocking their access to your list, here is the current collection of addresses for that firm. cslaw@delphi.com cslaw@win.net cslaw@witchcraft.com cslaw@pipeline.com cslaw@netcom.com cslaw@indirect.com (currently disabled) lcanter@delphi.com lcanter@win.net lcanter@witchcraft.com lcanter@pipeline.com lcanter@indirect.com (currently disabled) 76636.443@compuserve.com They also, apparently, have sites of their own; those sites are lcanter.win.net and msiegel.win.net. In an article in Tuesday's _New York Times_, Mr. Carter basically said, "this was immensely profitable; we will be doing this in the future." Forewarned is forearmed... --Wes ------------------------------ Date: Wed, 20 Apr 94 15:47:49 -0400 From: Tim Shepard Subject: Re: MIT student arrested for BBS used ... (Cohen, RISKS-15.76) I've been closely following the accounts of this case in the Boston Globe and The Tech (a student-published newspaper at MIT). Until your report, I had not heard any assertions that the student had actually been arrested. According to an article in The Tech on Friday April 8th, 1994: "A federal grand jury charged an MIT student yesterday on a felony charge for allegedly allowing the piracy of over $1 million in business and entertainment software using Athena workstations." According to an article in The Tech on Tuesday April 12th, 1994: "David M. LaMacchia '95, who was indicted last Thursday for conspiracy to commit wire fraud, will be arraigned this Friday at the U.S. District Courthouse in Boston, according to LaMacchia's lawyer Harvey Silverglate." Other than Cohen's article, and a couple of followup articles in RISKS DIGEST, I've seen no report that he had been actually arrested. I cannot imagine why he would need to be arrested. (I would expect that if he already has a lawyer, and the lawyer knows of the scheduled arraignment three or more days beforehand, he would most likely show up in court. Maybe I missed something. What was your source?) -Tim Shepard ------------------------------ Date: 25 Apr 94 17:50:35 From: drand@osf.org (Douglas Rand) Subject: Re: MIT student arrested for BBS used ... (Cohen, RISKS-15.76) In his post, Fredrick Cohen states "An MIT student was arrested today for having a BBS at the school that was used by the participants to store and fetch commercial software." and goes on to paint the student as practically an innocent bystander caught up in other peoples crimes by happenstance. If one is to believe any of the reportage on the real incident, the student was anything but innocent. All the reportage in the Boston Globe, not known for its great sympathy with law enforcement, made it quite clear that the student actively advertised his BBS as a place to upload and download pirated software. He went out of his way to personally solicit software on at least some occasions (according to the reports). In this, he would be guilty of various crimes regardless of the means he used to carry the crimes out. While I feel a little sorry for him, in that he probably felt he was carrying on some idealistic fight, I don't feel particularly sorry for him, and he deserves to be prosecuted. Let's save our righteous indignation for the truly innocent, wrongly accused and persecuted by people in power. Doug Rand Open Software Foundation, Motif Development ------------------------------ Date: Mon, 25 Apr 1994 18:57:58 -0400 From: msb@sq.sq.com (Mark Brader) Subject: Re: NYC subway fare cards double-deduct (Greene, Risks-15.78) Okay, so how exactly is it possible in this system for the turnstile to (a) deduct the fare from the card, and (b) identify whose card it was, so that it won't deduct it again if the same card is re-swiped -- and yet not figure out that it now has to unlock itself? By the way, what happens if the turnstile does unlock, and the rider hands the card back across the barrier to someone else? Will the second rider get admitted without a second fare being deducted, because the same card was used? Mark Brader, msb@sq.com SoftQuad Inc., Toronto [Also related comments from dan@wais.com (Dan Aronson) and sullivan@geom.umn.edu (John Sullivan). PGN] ------------------------------ Date: Fri, 22 Apr 94 17:53:16 EDT From: ddl@das.harvard.edu (Dan Lanciani) Subject: Re: NYC subway fare cards double-deduct; UI at fault (Greene) I can't let this pass without comment. Clearly this system was designed by someone obsessed with the RISKs of free rides. The only way I can imagine this kind of failure mode occurring is if they are doing something along the lines of with the improper swipe somehow interrupting the process in the middle. Now, granted, they probably teach in transaction school that you must always make these things fail in your favor, but it seems a bit overkill for a subway. In any case, with the chance to swipe again, I suspect a true cheat would find a way to substitute a different card (if even that is really necessary)... Dan Lanciani ddl@harvard.* ------------------------------ Date: Fri, 22 Apr 94 14:08:39 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Double your pleasure in the subway (Greene, RISKS 15.78) Wonder if they put a limit on the "swipe again" - sounds like a new kind of "family plan". Padgett ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.79 ************************ 28-Apr-94 23:48:18-GMT,30955;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA06694; Thu, 28 Apr 94 19:48:17 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA25558; Thu, 28 Apr 94 19:47:36 EDT Received: by chiron.csl.sri.com id AA05644 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Thu, 28 Apr 94 16:41:03 -0700 From: RISKS Forum Sender: RISKS Forum Date: Thu, 28 Apr 94 16:41:01 PDT Subject: RISKS DIGEST 15.80 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Thursday 28 April 1994 Volume 15 : Issue 80 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ** E-mail risks-request@csl.sri.com for old RISKS info, or see the next issue. Contents: DMV Computer upgrade goes awry... (Marshall Clow) Time-series wins jackpot (Mich Kabay) Drunk in charge..... (Kearton Rees) Stress Analysis of a Software Project [long] (Jerry Leichter) ---------------------------------------------------------------------- Date: Wed, 27 Apr 1994 11:03:47 -0700 From: mclow@coyote.csusm.edu (Marshall Clow) Subject: DMV Computer upgrade goes awry... DMV careens into $44 million dead-end By Gary Webb, Knight-Ridder News Service (From the San Diego Union, April 27, 1994, page A-3) SACRAMENTO - The California Department of Motor Vehicles has informed a flabbergasted legislative committee that it has spent $44.3 million on a computer modernization program that will never work. "This is unconscionable to me!" Assemblywoman Valerie Brown, D_Santa Rosa spluttered. "I can't even explain this to people!" DMV Director Frank Zolin muttered: "I'm having a difficult time explaining it myself." [...] "The department's position is that the software maker isn't responsible, the hardware maker isn't responsible, and the taxpayers are just going to eat the cost", Transportation Committee Chairman Richard Katz, D-Panorama Ciry, said after the Monday hearing. [...] The DMV started the project in 1988 and has been quietly spending millions of dollars a year on it with little oversight - and even less success. ... Dan Foulk, a Sacramento computer consultant who has been working with the DMV on the ill-fated venture, called it "a combination of errors from the beginning". Faulk said that the plan - to invisibly convert a circa-1965 database to a modern relational database using Tandem Cyclone mainframes - was "too giant a leap of technology" and involved insurmountable incompatibilities beween hardware platforms and program code. [...] The $7.5 million the DMV was requesting in next year's budget was to be used to start redesigning the database from scratch, records show. But Zolin said that it is "not exactly" a back-to-square-one proposition. "We've learned a lot from mistakes we made", he said. ============== (Excerpt from the San Jose Mercury News, April 27, 1994 online version:) Ernst & Young, an accounting and consulting firm hired to oversee the five-year project, was fired by the state in June 1990 after just eight months on the job. DMV then took on the task of project management itself -- a herculean undertaking that legislative analysts now say was well beyond the department's ability. ... We've all seen this before, this is just larger and more public than many. Marshall Clow, mclow@san_marcos.csusm.edu ------------------------------ Date: 28 Apr 94 14:40:25 EDT From: "Mich Kabay / JINBU Corp." <75300.3232@CompuServe.COM> Subject: Time-series wins jackpot "Casino finally pays big keno winners: Montreal computer analyst hopes $620,000 jackpot will give others hope. By Andre Picard, Quebec Bureau. The _Globe and Mail_ (Canada), 28 Apr 1994, p. A6 [MK comments in brackets] Montreal -- Daniel Corriveau said he hopes that his 'victory over the system will give hope to others.' The computer analyst and his family received more than $620,000 [1C$ = U$0.75], including interest, from the Montreal casino yesterday, weeks after they overcame odds of one in six billion and beat an electronic keno game three times in a row." The author explains the following key points: o Corriveau used an "antique 286" computer to analyse 7,000 combinations from the keno game, [which uses an electronic pseudo-random number generator]. o Corriveau noticed that the electronic game was repeating numbers in a predictable pattern. o Corriveau and several family members bet on what they predicted would be due to come up; they won three times in succession. o The Casino managers shut the game down and called the police. o The Surete du Quebec [provincial police] fraud squad investigated; Corriveau and his family even took polygraph tests. o The president of Loto-Quebec, the Crown Corporation which owns the Montreal Casino, admitted that the problem was theirs: they had failed to test the electronic game before using it. o The keno game is missing its clock, [used to reset the pseudo-random number generator]; therefore it started all over again every time it was powered off. o Police are continuing their investigation to find out if the clock was missing when the game was delivered or whether it has been stolen. [Sigh... quality assurance rears its missing head once again. And bravo for the successful time-series analyst. Wonder if he'd like to have a go at the Clipper Chip?] Michel E. Kabay, Ph.D. / Dir. Education / Natl Computer Security Assoc. ------------------------------ Date: Wed, 27 Apr 94 13:32:25 From: krees@minster.york.ac.uk Subject: drunk in charge..... I am a member of a mailing list covering motorcycling and related topics. Recently much discussion revolved around the issue of drinking (alcohol) and driving, and what, if any, the limit of alcohol allowed in the blood should be. Discussion seemed to revolve around the point that the effect that alcohol has varies with a number of individual factors. One comment however I think is of interest to this forum. The comment was made that alcohol in whatever quantity, affects your ability to judge whether you are fit to perform an act such as driving. The example used to illustrate this was that electricians never touch any of their work that might involve high-voltage electricity after they have been drinking, because of the possible consequences. Extending this argument to computing. How many people would be happy flying in a plane, or placing their trust in a software controlled system if they knew that it had been written, reviewed or tested after a Friday lunchtime in a pub. To the electrician the possible are obvious and immediate. To programmers etc. the consequences may be neither obvious nor immediate. Should there be an offence of "drunk in charge of a computer"? Probably not. But I think that this sort of issue be addressed, and any legal implications considered, possibly in professional codes of conduct? Kearton Rees, High Integrity Systems Eng. Group, Computer Science Dept., University of York, Heslington Road, York, YO1 5DD. krees@cs.york.ac.uk Tel.: 0904-433385 ------------------------------ Date: Tue, 26 Apr 94 08:42:32 EDT From: Jerry Leichter Subject: Stress Analysis of a Software Project [long] The following, which claims to be an internal Silicon Graphics memo, has already seen fairly broad network distribution. I have no way of verifying that it is what it claims to be, but (a) I'm told by someone with close dealings with SGI that it fits with what he's heard; (b) if it's a fake, someone put a huge amount of effort into producing it. I forward it to RISKS as a wonderful record of what goes wrong with large software projects, and why. It would be as useful if all the names, including the company and product names, were removed. This memo should not be seen as an indictment of SGI, which is hardly unique. There is good evidence that Sun, for example, had very similar problems in producing Solaris; and I watched the same thing happen with the late, unlamented DEC Professional series of PC's, and something like it almost happen with firmware for DEC terminals a number of years back. I hope that Tom Davis's position hasn't been badly hurt by the broad distribution of his memo - but based on the traditional reaction to bearers of bad news, especially when the bad news becomes widely known, I can't say I'm sanguine about it. -- Jerry ------- Begin Document ------- Software Usability II October 5, 1993 Tom Davis Last May, I published my first report on software usability, which Rocky Rhodes and I presented to at Tom Jermoluk's staff meeting (with Ed, but without Tom). Subsequently, I made it available to quite a few other people. This sequel is to satisfy all those people who have urged me to bring it up to date. I begin with a summary; details follow. Please read at least the summary. SUMMARY Release 5.1 is a disappointment. Performance for common operations has dropped 40% from 4.0.5, we shipped with 500 priority 1 and 2 bugs, and a base Indy is much more sluggish than a Macintosh. Disk space requirements have increased dramatically. The primary cause is that we attempted far too much in too little time. Management would not cut features early, so we were forced to make massive cuts in the final weeks of the release. What shall we do now? Let's not look for scapegoats, but learn from our mistakes and do better next time. A December release of 5.1.2 is too early to fix much -- we'll spend much more time on the release process than fixing things. Allow enough time for a solid release so we don't get: 5.1.2.1, 5.1.2.2, 5.1.2.3, ... Let's decide ahead of time exactly what features are in 5.1.2. If we pick a reasonable set we'll avoid emergency feature cuts at the end. Nobody knows what's wrong -- opinions are as common as senior engineers. The software environment is so convoluted that at times it seems to rival the US economy for complexity and unpredictability. I propose massive code walk-throughs and design reviews to analyze the software. We'll be forced to look closely at the code, and fresh reviewers can provide fresh insights. For the long term, let's change the way we do things so that the contents and scheduling of releases are better planned and executed. Make sure marketing and engineering expectations are in agreement. INTRODUCTION We've addressed some of the problems presented in the original May report, but not enough. Most of the report's warnings and predictions have come true in 5.1. If we keep doing the exact same thing, we'll keep getting the exact same results. I'm preparing this report in ASCII to make it widely available. It's easy to distribute via news and mail, and everyone can read it. An ASCII version of the May 12 report can be found in: bedlam.asd:/usr/tmp/report.text The included quotations are not verbatim. Although the wordings are inexact, I believe they capture the spirit of the originals. BLOAT UPDATE "Do you want to be a bloat detective? It's easy; just pick any executable. There! You found some!" -- Rolf van Widenfelt In the May report, I listed a bunch of executable sizes, and pointed out that they were unacceptable if we intended to run without serious paging problems on a 16 megabyte system. Between May and the 5.1 release, many have grown even larger. IRIX went up from 4.8 megabytes to 8.1 megabytes, and has a memory leak that causes it to grow. Within a week, my newly-booted 5.1 IRIX was larger than 13.8 megabytes -- a big chunk of a 16 megabyte system. It's wrong to require our users to reboot every week. There are too many daemons. In a vanilla 5.1 installation with Toto, there are 37 background processes. DSOs were supposed to reduce physical memory usage, but have had just the opposite effect, and their indirection has reduced performance. Programs like Roger Chickering's "Bloatview" based on Wiltse Carpenter's work make some problems obvious. The news reader "xrn", starts out small, but leaks memory so badly that within a week or so it grows to 9 or 10 megabytes, along with plenty of other large programs. But what's really embarrassing is that even the kernel leaks memory that can't be recovered except by rebooting! Showcase grew from 3.2 megabytes to 4.0 megabytes, and the master and status gizmos which are run by default occupy another 1.7 megabytes. Much of this happened simply by recompiling under 5.1 -- not because of additional code. The window system (Xsgi + 4Dwm) is up from 3.2 MB to 3.6 MB, and the miscellaneous stuff has grown as well. As I type now, I have the default non-toto environment plus a single shell and a single text editor, jot. The total physical memory usage is 21.9 megabytes, and only because I rebooted IRIX yesterday evening to reduce the kernel size. Luckily, I'm on a 32 megabyte system without Toto, or I'd be swamped by paging. Much of the problem seems to be due to DSOs that load whole libraries instead of individual routines. Many SGI applications link with 20 or so large DSOs, virtually guaranteeing enormous executables. In spite of the DSOs, large chunks of Motif programs remain unshared, and duplicated in all Motif applications. PERFORMANCE UPDATE "Indy: an Indigo without the 'go'". -- Mark Hughes (?) "X and Motif are the reasons that UNIX deserves to die." -- Larry Kaplan The performance story is just as bad. I was tempted to write simply, "Try to do some real work on a 16 megabyte Indy. Case closed.", but I'll include some details. In May, I listed some unacceptable Motif performance measurements. Just before 5.1 MR, someone reran my tests and discovered that the performance had gotten even worse. Some effort was expended to tune the software so that instead of being intolerable, it was back to merely unacceptable performance. We no longer report benchmark results on our standard system. The benchmarks are not done with the DSO libraries; they are all compiled non-DSO so that the performance in 5.1 has not declined too much. Before I upgraded from 4.0.5 to the MR version of 5.1, I ran some timings of some everyday activities to see what would happen. These timings were all made with the wall clock, so they represent precisely what our users will see. I run a 32 megabyte R4000 Elan. Test 4.0.5 5.1 % change ---- ----- --- -------- C compile of a 25 sec 35 sec 40% small application C++ compile of a 68 sec 105 sec 54% small application Showcase startup, 13 sec 18 sec 38% May report file Start a shell <2 sec ~3 sec ~50% Jot 2 MB file <2 sec ~3 sec ~50% What's most frightening about the 5.1 performance is that nobody knows exactly where it went. If you start asking around, you get plenty of finger-pointing and theories, but few facts. In the May report, I proposed a "5% theory", which states that each little thing we add (Motif, internationalization, drag-and-drop, DSOs, multiple fonts, and so on) costs roughly 5% of the machine. After 15 or 20 of these, most of the performance is gone. Bloating by itself causes problems. There's heavy paging, there's so much code and it's so scattered that the cache may as well not be there. The window manager and X and Toto are so tangled that many minor operations like moving the mouse or deleting a file wake up all the processes on the machine, causing additional paging, and perhaps graphics context swaps. But bloat isn't the whole story. Rocky Rhodes recently ran a small application on an Indy, and noticed that when he held the mouse button down and slid it back and forth across the menu bar, the (small) pop-up menus got as much as 25 seconds behind. He submitted a bug, which was dismissed as paging due to lack of memory. But Rocky was running with 160 megabytes of memory, so there was no paging. The problem turned out to be Motif code modified for the SGI look that is even more sluggish than regular Motif. Perhaps the problem is simply due to the huge number of context swaps necessary for all the daemons we're shipping. The complexity of our system software has surpassed the ability of average SGI programmers to understand it. And perhaps not just average programmers. Get a room full of 10 of our best software people, and you'll get 10 different opinions of what's causing the lousy performance and bloat. What's wrong is that the software has simply become too complicated for anyone to understand. WHAT WENT WRONG IN 5.1? The one sentence answer is: we bit off more than we could chew. As a company, we still don't understand how difficult software is. We planned to make major changes in everything -- a new operating system, new compilers, a new user environment, new tools, and lots of new features in the multi-media area. Not only that, but the new stuff was promised to do everything the old software had done, and with major enhancements. (Early warning: version 6.0 promises to be even more disruptive.) About 9 months ago, Rocky and I pointed out the impossibility of what we were attempting. Rather than reduce the scope of the projects, a decision was made to hire a couple of contractors (who know nothing about our system) to handle the worst user interface problems in the Roxy project. In addition, promises were obtained from various executives that a significant effort would be made to improve software performance. Management was basically afraid to cut any features, so we continued to work on a project that was far too large. The desperate attempt to do everything caused programmers to cut corners, with disastrous effects on the bug count. And the bug count was high simply because 5.1 was so big. Only when the situation was beyond hope of repair did we start to do something. Features and entire products were removed wholesale from the release, and hundreds of high-priority bugs were classified as exceptions, so that we could ship with "no priority 1 and 2 bugs". We did, however, ship with over 500 "exceptions". The release was deemed too crummy to push to all our machines, but was restricted to the Indys, the high-end machines, and a few others where new hardware required the new software. Due to the massive bug count, virtually no performance tuning was done. When the schedule is impossible as it was in 5.1, the release process itself can get in the way. The schedule imposes a code freeze long before the software is stable, and fixing things becomes much more difficult. If you know you're going to be late, slip before the code freeze, not after. We're trying to wrap up the box before the stuff inside is finished, and then trying to fix things inside the box without undoing the wrapping -- it has to be less efficient. Management Issues: There was never an overall software architect, and there still is not, and until Way Ting was given the job near the end, there was no manager in charge of the 5.1 release, either. I wrote a note in sgi.bad-attitude about the "optimist effect", which I believe is mostly true. In condensed form: Optimists tend to be promoted, so the higher up in the organization you are, the more optimistic you tend to be. If one manager says "I can do that in 4 months", and another only promises it in 6 months, the 4 month guy gets the job. When the software is 4 months late, the overall system complexity makes it easy to assign blame elsewhere, so there's no way to judge mis-management when it's time for promotions. To look good to their boss, most people tend to put a positive spin on their reports. With many levels of management and increasing optimism all the way up, the information reaching the VPs is very filtered, and always filtered positively. The problem is that the highly filtered estimates are completely out of line with reality (at least in recent software plans here at SGI), and there are no reality checks back from the VPs to the engineers on the bottom. I think it's great to have aggressive schedules where you try to get things out 20% or so faster than you'd expect. The problem is that in 5.1, the engineers were expected to get things out 80% faster, and it was clearly impossible, so many just gave up. We certainly didn't win any morale prizes among the engineers with 5.1. It's the first release here at SGI where most of the engineers I talked to are ashamed of the product. There are always a few, but this time there were many. When engineers were asked to come in over the weekends before the 5.1 release to fix show-stopper bugs, I heard a comment like: "Why bother? SGI's going to release it anyway, whether they're fixed or not." I'm not blaming the engineers. Most of them worked their hearts out for 5.1, and did the best they could, given the circumstances. They'll be happy to buy into a plan where there's a 20% stretch, but not where there's an 80% stretch. They figure: "It's hopeless, and I'll be late anyway, and I'm not going to get rewarded for that, so why kill myself?" Marketing - Engineering Disconnect "Marketing -- where the rubber meets the sky." -- Unknown There's a disconnect between engineering and marketing. It's not surprising -- marketing wants all the whiz-bang features, it wants to run in 16 megabytes, and it wants it yesterday. Although engineering would like the same things, it is faced with the reality of time limits, fixed costs, and the laws of nature. It's great to have pressure from marketing to do a better job, but at SGI, we often seem to have deadlocks that are simply not resolved. Marketing insists that Indy will work in 16 megabytes and engineering insists that it won't, but both continue to make their plans without resolving the conflict, so today we're shipping virtually useless 16 MB systems. Similarly for feature lists, reliability requirements, and deadlines. Well, at least we met the deadline. WHAT TO DO -- SHORT TERM (5.1.2) "We should sell 'bloat credits', the way the government sells pollution credits. Everybody's assigned a certain amount of bloat, and if they go over, they have to purchase bloat credits from some other group that's been more careful." -- Bent Hagemark There are problems in both performance and bugs, and we'd like to fix both. In addition, the first thing we should do is decide exactly what's going into release 5.1.2. If we are serious about a December all-platforms release, there may be very little we can do other than keep stumbling along as we have been. Three months isn't much time to do anything, considering the overhead of a release, where perhaps half of the time will be spent in "code freeze". After 5.1, many engineers are exhausted, and it's unreasonable to expect them to start hard work immediately. 500 outstanding priority 1 and 2 bugs is a huge list, and we haven't even begun to hear about customer problems yet. What Should be in Release 5.1.2: I'm afraid the answer is going to be "everything that didn't make it into 5.1". I know that won't be the case, but I hope that we will carefully select what goes in now, rather than hack things out in a panic in December. The default should be "not included", and we should require a good reason to include things. Let's make sure that there's a minimal, solid, working set before we start adding frills. Improving Performance: "SGI software has a cracked engine block, and we're trying to fix it with a tune-up." -- Mark Segal As stated above, we don't even know exactly what's wrong. We probably never will, but we should start doing things that will have as much of an impact on the problem as possible. I don't think we have time to study the problem in detail and then decide what to do -- we've got to mix the research with doing something about it. Before we begin, we should have definite performance goals -- lose less than 5% wall-clock time on compiles of some known program over 4.0.5, have shells come up as fast as in 4.0.5, or whatever. Some people claim that we need new software debugging tools to look at the problem, and that may be true, but it's not a short-term solution, and it runs the risk of causing us to spend all our time designing performance measurement tools, rather than fixing performance. In fact, I don't really believe that simple "tuning" will make a large dent. To get things to run significantly faster, we've got to make significant changes. And we can't beat the "5% rule" by just speeding up all the systems by 5% -- if everything is exactly 5% faster, the overall system will be exactly 5% faster. There's a strong tendency to look for the "quick fix". "Get the code re-arranger to work", or "Put all the non-modifiable strings in shared code space", for example. These ideas are attractive, since they promise to speed up all the code, and they should probably be pursued, but I think we're not going to make a lot of progress until we identify the major software architectural problems and do some massive simplification. Remember that DSOs were the last "quick fix". There's got to be more to it than tuning; there must be some amazingly bad software architecture -- from a novice's point of view, a 4 MB Macintosh runs a far more efficient, interesting system than a 16 MB Indy. The Mark Segal quote above sums it up. Code walk-throughs and design reviews are in order for most of our software. The attendees should include not only people working in the same area, but a small cross-section of experienced engineers from other areas. Get a pool of, say, 20 experienced engineers and perhaps 3 at a time would sit in on code reviews together with the other people working in that area. Code reviews will help in many ways -- the engineer presenting the code will have to understand it thoroughly to present it, others will learn about it, and outside observers will provide different ways to look at the problems. The most important thing should be the focus -- we're trying to make the code better and faster, not to make it more general, or have new features, or be more reusable, or better structured. For complex problems, the walk-through should also include some general design review. Are these daemons really necessary? Do we really need this feature? And so on. Fixing Bugs: The code walk-throughs will obviously tend to turn up some bugs, so they'll serve a dual purpose. With 500 or so priority 1 and 2 bugs, we must prioritize these as well. A bug that causes a system crash only on machines with some rare hardware configuration is properly classified priority 1, but it's probably less important than a bug in a popular program like Showcase that causes you to lose your file every tenth time, which would normally rank as priority 2. The effort involved in the fix should also be taken into account. For bugs of equal frequency of occurrence, it's probably better to fix 20 priority 2 bugs than 1 priority 1 bug if the priority 2 bugs are 20 times easier to fix. A bunch of bugs can be eliminated by getting rid of features. Let's have the courage to cut some of the fat. WHAT TO DO -- LONG TERM "Software quality is not a crime." -- Unknown (seen on a poster in building 7) It's easy to go on forever here, but I'll try to limit it to a few key ideas. We don't have to do all these at once, but we'd better start. Have an overall SGI software plan. Let's get an architect, or at least a small group of highly technical people, not just managers, to agree on plans for releases. In fact, since the release is a company-wide project, there ought to be company-wide participation in the decisions of what's in a release. The group should include marketing, documentation, engineering, and management and should come up with a compromise that's reasonable to all. In every case, some attempt must be made to check reasonableness all the way to the bottom. There's a long series of excuses, "Well, that's what my junior VPs told me.", or "That's what my directors/managers/lead engineers/engineers told me." We get killed by the optimist effect, and a disinclination to listen seriously to anyone but our direct reports. Try to imagine the guts it takes for an engineer to go to his director and say: "My manager's out of his mind -- I can't possibly do what he's promised." Let's try to concentrate on performance and quality, not on new features, especially for the 5.1.2 release. I know from my own experience that when I write good code, I spend 10% of the time adding features, and 90% debugging and tuning them. It's the only way to make quality software. In SGI's recent releases, the opposite proportions are often the rule. It's much easier to add 100 really neat features that don't work than to speed up performance by 1%. Aim for simplicity in design, not complexity. Make a few things work really well; don't have 1000 flaky programs. Be willing to cut features; who's going to be more pissed off: a customer who was promised a feature that doesn't appear, or the same customer who gets the promised feature, and after months of struggling with it, discovers he can't make it work? Get better agreement between the top level VPs and the lowest engineers that a given schedule is reasonable. For new development, continue the formal design reviews and code walk-throughs. These shouldn't just happen once in the development cycle -- things are bound to change, and code reviews can be very valuable, even for our experienced programmers. ACKNOWLEDGEMENTS I take full responsibility for the opinions contained herein, but I'd like to thank Mark Segal, Rosemary Chang, Mary Ann Gallager, Jackie Neider, Sharon Fischler, Henry Moreton, and Jon Livesey for suggestions and comments. ------------------------------ End of RISKS-FORUM Digest 15.80 ************************ 29-Apr-94 22:35:40-GMT,29599;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA07634; Fri, 29 Apr 94 18:35:34 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA14389; Fri, 29 Apr 94 18:33:59 EDT Received: by chiron.csl.sri.com id AA07511 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Fri, 29 Apr 94 15:27:25 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 29 Apr 94 15:27:24 PDT Subject: RISKS DIGEST 15.81 Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 29 April 1994 Volume 15 : Issue 81 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for information on RISKS (comp.risks) ***** Contents: Boot Prom commits Denial of Service Attack (Dave Wortman) Cyrix 486 CPU Bug (Dave Methvin) Call Identifier (tm) forgets list of received calls (Robert Chesler) Re: Unwanted FAX received via voicemail (Declan A. Rieb) Re: Stress Analysis of a Software Project (Tom Davis via Joan Eslinger, A. Padgett Peterson) Inspecting Critical Software (David Parnas via Jan Arsenault) Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. ---------------------------------------------------------------------- Date: Fri, 29 Apr 1994 12:52:08 -0400 From: Dave Wortman Subject: Boot Prom commits Denial of Service Attack A major power outage here on Tuesday demonstrated the risks of excessive automation and administrative convenience. Our computing environment consists of a heterogeneous network of Sun, Dec and IBM workstations and related fileservers. When a Sun workstation boots up, a hardware prom issues a rarp request to establish the workstations network address and to identify a server that can provide it with a bootprogram and then the Unix kernel. The boot prom uses the trivial file transfer protocol (tftp) to request the boot program. It initially issues a tftp request to the server it has identified, but if that tftp request times out then it broadcasts a tftp request on its local network looking for any server that can provide it with a bootprogram. It keeps repeating this process until it receives a boot program. One the Suns the prom has no builtin knowledge of its network address or the network address of the server. There are some good reasons for keeping the boot prom ignorant of its network environment and using a broadcast protocol, including the administrative convenience of not having to do anything to workstations when the server changes and providing a degree of robustness in a multi-server environment. In recent years there have been security problems related to the tftp protocol so in our environment the Dec workstations run security monitoring software that keeps a log of failed tftp attempts to help detect potential intruders. The security software writes a log file of failed tftp requests and also puts a message on the affected machines console. What got us into trouble after the power outage was that the Sun workstations came back online but the corresponding Sun servers came up in a wedged state in which they responded to the initial rarp request but then failed to respond to any workstations tftp request for a boot program. After the initial tftp request to the Sun server timed out, our network was flooded with tftp requests from many Sun workstations all trying to find any server that could boot them. In the meantime the Dec workstations on the network had rebooted successfully and were being used by a number of professors and students. However, these machines soon became unusable due to the effort required to deal with the flood of tftp requests. The security monitoring software contributed to this problem by writing messages to each machines console window (ignorable but consumptive of resources) and by almost filling up a critical file system with its log files. If this filesystem had filled up, the machines would have been totally unusable. Even if we hadn't been running the security monitoring software, usability of these workstations would have been impaired by the handling of the tftp requests. There are several things that could have been done better: - the question of whether falling back to a broadcast protocol for booting is the right approach should be reexamined. On most systems the set of servers that could successfully respond to a boot request is a) small, b) well-known, and c) changes very slowly over time. - the boot proms should use some form of backoff strategy when the tftp requests consistently fail to avoid overloading the network. - our security logging software needs to be more robust in dealing with its log files. Waiting until a log file write fails due to a full filesystem is too late if the full file system will cause other processes to crash. This is tricky since we don't want a introduce a mechanism that would allow an intruder to overwhelm the security software with failed attempts and then proceed to do dirty work once logging has been suspended due to log file overflow. A curious legal question comes to mind: could the manufacturer or the proprietor of the workstation containing boot prom be held guilty of a "denial of service attack" on our Dec workstations? If an individual had issued all of those tftp requests we certainly would be considering the question. ------------------------------ Date: Fri, 29 Apr 94 07:40 EST From: Dave Methvin <0003122224@mcimail.com> Subject: Cyrix 486 CPU Bug I'm an editor at Windows Magazine. In our May issue I wrote a news story reporting a bug in the Cyrix Cx486DX CPU. The Cyrix Cx486DX was designed to be completely software-compatible with Intel's i486DX processor. However, Ed Curry of Lone Star Evaluation Labs (LSEL) found a bug relating to floating-point operations while doing some in-depth compatibility testing. Cyrix shipped thousands of chips with this bug before April 1994, but has now fixed the problem. The bug occurs when a register load instruction (such as MOV reg,mem) is followed by an instruction that clears the floating-point status register (FCLEX). If the memory location being referenced is in the CPU's internal cache, the MOV instruction works fine. If, however, the MOV requires an external bus cycle, executing the FCLEX instruction aborts the cycle. As a result, the register is not loaded properly. The risk here is that someone may run software on the Cx486DX that generates incorrect results where an i486DX would work fine. The Cyrix position is that this is a minor bug and that we (Windows Magazine and LSEL) are making too much of it. However, LSEL has seen the bug in their test code compiled under OS/2 and Windows NT. The test code performs typical engineering and scientific calculations, so it's not contrived or artificial. We have not found the problem in any shrink-wrapped application. Most MS-DOS and Microsoft Windows insert a FWAIT instruction before any floating-point instruction, so they generally won't exhibit the problem. What does the Risks readership think? Are we making too much of this? Is anyone out there using PC with a Cx486DX? ------------------------------ Date: Fri, 29 Apr 94 13:28:10 -0400 From: rob@chesler.absol.com (Robert Chesler) Subject: Call Identifier (tm) forgets list of received calls I accepted a no-installation-cost trial of Caller ID and found it somewhat useful for correlating call times with answering machine messages, but found 90% of my received calls were out of my area and thus had no number actually displayed, only the date and time. Last night I noticed that the box had cleared out its memory. No call had been received on that line between the time I had last checked it and the time I noticed it with an empty list. The risk here is that if some message was sent to the box through the phone line to clear its list, then the box would be less useful for someone using the box to catch a crank caller or even log when important calls or messages were received. If the caller ID protocol includes such a message, then such a message could undoubtedly be faked if someone got physical access to a residence's network interface or telephone company signalling. I'm sure that boxes more advanced than the promotional box that was given to me might have precautions or a printed log, but I would imagine that the promotional boxes are widely used. --Robert ------------------------------ Date: Tue, 26 Apr 1994 15:09:57 -0600 (MDT) From: "Declan A. Rieb" Subject: Unwanted FAX received via voicemail The voicemail system I use allows incoming FAXs to be saved and handled as messages. Upon receipt, the system notifies the user that there is an incoming fax message, and you can even query for the number of pages. When a message exists in the "voice mailbox", one can have the system forward it to a real FAX machine (either a preselected "primary" FAX or any other phone number.) Requesting such a forward places the FAX message into a queue, meaning it may actually be sent at some future time. Last week I received a 5-page FAX message. It did not come from a local caller (one on the same telephone switch.) All I knew was that it was five pages. I sent it off to my primary printer, and an hour or so later went to pick it up. No FAX for me there. I tried again. No FAX for me. FAX machine broken? After a day of this, I sent the FAX to a machine and promptly went to watch. Out came a list of imported tequila prices, and several blank pages! I recalled seeing several such lists at the other FAX machines...But none were addressed to me! Surely they weren't mine...but a closer inspection showed that the FAX phone number listed was indeed mine (perhaps a missing area code?) Whoa! that kind of business is illegal here! And I've been spreading the things around the area. At least I didn't have my name on them, but the phone number was mine! Welcome to the wonderful world of hi-tech. It used to be that FAX machines were relatively rare, and "dialing" a wrong number would mean the FAX doesn't get sent. Now, EVERY phone here can receive a FAX, and we can send multiple copies out without knowing what it is we sent! Yes, I'll be a bit more careful in the future. [A surprising number of readers chided me for NOT having appended a "You mean a FAX PAS? PGN" appendum. THANKS! PGN] ------------------------------ Date: Fri, 29 Apr 1994 19:35:15 GMT From: wombat@kilimanjaro.engr.sgi.com (Joan Eslinger) Subject: Re: Stress Analysis of a Software Project (Davis/Leichter R-15.80) The memo Jerry Leichter posted was an actual Silicon Graphics memo. However, life for Silicon Graphics and Tom Davis is not quite so bleak as some might think. Tom Davis wrote the original memo to point out problems and ask everyone to help fix them. It was very effective. I installed a beta version of the new 5.2 release on my Indy in January, and only rebooted the machine a couple of weeks ago because I was moving to another building. Sure, I had to add another swap file on-the-fly about once a month because my emacs processes grew so large :-), but the system did not crash. And performance is quite snappy. "Watch the skies." Since the memo has been popping up all over the net, Tom has written a reply to it, included below. There isn't really a RISKS tie-in, unless you count the risk of having only the "bad" half of a story get wide distribution. Joan Eslinger / Silicon Graphics / wombat@sgi.com -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- I am the author of the original memo below, which was intended for internal Silicon Graphics use only, and was not for anyone outside the company. But since it has been leaked to the net, and is beginning to be used by competitor's sales people, I feel a response is required. I don't believe that these problems are unique to Silicon Graphics. >From discussions with friends who are insiders in many different companies, I am certain that similar memos could be written about the software of each of our competitors. What I like about working for Silicon Graphics is that at least here, something is being done about it -- I worked for companies in the past where the response would have been to stick our heads in the sand in hopes that the problems would just fix themselves. If I hadn't thought that the memo would catalyze some change here, I wouldn't have written it. The details appear as comments to my original article below. Luckily, the article is 6 months old, and we have had a chance to make some significant progress. Typically, what happens is that each faster generation of hardware is followed by software that more than compensates for the increased speed, but as a result of this memo, Silicon Graphics has been able to skip one of the slowing software cycles, making, instead, a performance and quality based release. The next release is going to be similar, and in the meantime, we get an extra hardware boost from the faster R4600 processors. -- Tom Davis Silicon Graphics General comments: As a fairly direct result of this memo, SGI decided not to continue "business as usual" in software development. The approach we took to the problem was the following: With the 4.0.5abcdefghi... fiasco, and the fact that the 5.* releases were still for specific machines, our developers were desperate for an all-platforms release. We decided to make such a release relatively soon -- and 5.2 actually MRed in February. The 5.2 release had two goals -- primarily, all-platform, and given that it went out in February, do as much performance-tuning and bug-fixing as time allowed. In that period, the performance on 16MB systems was essentially doubled, which improved performance on larger systems as well, but to a lesser degree. Significant numbers of bugs were fixed as well. Some people hoped that a few quick fixes would bring back all the performance in 5.2, but a little investigation indicated that was a list of things to be done, and that another quality release would be required. The 5.3 release, not officially scheduled, but which should be MRed around October or November is that quality (performance and bug-fix) release. We'll add a few new features, but they will be the exception rather than the rule. The longer time before the 5.3 release should give us time to do a thorough job of solving our problems. For 5.3, there's also time to set up solid performance and bug-fixing goals, and these are already being discussed. And most important -- the worst problems were with 16 MB systems that paged their brains out. They are better now, but not great. But we don't sell them. One of the 5.3 goals is to improve performance (or reduce sizes enough) that it will be acceptable on a 16 MB machine. The kernel memory leaks are all fixed, and many of the important programs have been reduced in size. For 5.2, 5 or 6 of our most heavily-used programs were subjected to close scrutiny to find out where the performance went, and many were significantly improved. A lot more work is planned for 5.3 to reduce the sizes of the executables. Work is continuing on the DSOs to split them up properly so that they don't all have to be loaded, and to improve their performance and start-up time. We're working to make "quick-starting" happen more automatically. > PERFORMANCE UPDATE I don't think it's unusual to do benchmarks with non-standard compiler settings. Both we and our competition have done so for a long time. We do ship all the libraries, et cetera, necessary to duplicate these results so customers for whom speed is the only objective can pay the cost of larger executables in exchange for the added speed. Unfortunately, I can't re-run some of these tests, but 5.2 is definitely better than 5.1. I think the 5.1 fiasco has caused a lot of our management to see the light, and in conversations with people at all levels, it's clear that nobody wants to see anything like it happen again. The 5.2 and future 5.3 releases seem to be steps in the right direction. But there's still a lot of work to do, and we in engineering can use every minute between now and the 5.3 release to improve things. The 5.3 release is being planned with reasonable beta-cycles, and with enough time between now and "code freeze" to make significant improvements. > Management Issues: I think this sort of disconnect is not too unusual -- there is always enormous pressure to announce a very low entry price-point, and the 16MB system provided that. Everybody does this with the full knowledge that on a minimum system, you won't be able to run many interesting applications, and almost everyone will have to purchase a bit more memory. It's just that in the case of Indy, there were so many new features that the proposed minimal system was embarrassingly slow. The "fix" is simply not to ship the 16MB systems which will insure that everyone will get a very usable machine. All we really lose is our low entry price point, and the gain is that we won't have to deal with the few irate customers who bought a minimal system. Although some of our performance loss is due to more complicated features, the vast majority is due to the fact that more memory is required, and without it, the systems page with a consequent dramatic reduction in performance. The 4.0.X -> 5.X change on our large machines was measurable, but not nearly so noticeable as on the smaller ones. We're still not completely there (as far as I can tell) with respect to better software management. The good thing is that many of our higher-level managers are acutely aware of the problem now -- Forest Baskett and Tom Jermoluk are extremely concerned, for example. It's too bad it took a shock like 5.1 to make everybody take notice, but at least they did, and we're doing the right sorts of things to correct it. [Moderator deleted the entire interstiated message from RISKS-15.80. PGN] ------------------------------ Date: Fri, 29 Apr 94 08:22:09 -0400 From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson) Subject: Re: Stress Analysis of a Software Project (Davis/Leichter R-15.80) For years, people have been postulating projects that are too complicated to comprehend and we have seen several examples of what happens when this occurs. IMHO the only solution is to separate functions into stand-alones that utilize a common and understandable foundation and which are understandable. Where many have felt that a single integrated system is best, I have often been called in to "put out fires" and the first thing I do is to separate the problem into "atoms", the least divisible pieces. It is astounding how often problems that cannot be seen when tightly wrapped in a package becomes obvious when viewed by itself. Sometimes you just can't see the tree for the forest. > Some people claim that we need new software debugging tools to look at > the problem, and that may be true, but it's not a short-term solution, > and it runs the risk of causing us to spend all our time designing > performance measurement tools, rather than fixing performance. This is disturbing. Unless you have the tools to properly examine a system you cannot tell what is really going on and the reccuring theme of the memo seems to be that no-one knows. Without the proper tools, the job will never be completed. Again I can only speak from personal experience but cannot count the times when called in to fix a problem that supervisors have gotten very antsy waiting for something to happen while the envelope is being defined. Have found that unless the system is understood, it *can't* be fixed (see "little silver hammer" syndrome). The problem with the engineers also appears symptomatic. Engineers are supremely good at taking a concept and making it work. They are not generally good at determining that a concept is flawed in the first place, instead often they will continue to work as if the concept were correct and they were just lacking in skill. This leads to precisely the morale problems described. The major problem with engineers is that they accomplish the impossible so often that the marketeers come to expect it from them. The real problem seems to be simply "no-one in charge" and is all too common in large organizations. History is rife with examples of companies, states, countries that became too concentrated at the top and fell victim to the huns/vandals/Standard Oil as they rose to power. "Think of it as Evolution in Action" - Jerry Pournelle Padgett ------------------------------ Date: Tue, 26 Apr 94 20:43:34 EDT From: arsenau@mcmail.cis.mcmaster.ca Subject: Inspecting Critical Software, a course by David Parnas Inspecting Critical Software: An Intensive 3-day Course offered by The Faculty of Engineering, McMaster University, Hamilton, Ontario, Canada Taught by Prof. David Lorge Parnas, with the support of TRIO June 7, 8, 9, 1994 1. Background Software is critical to the operation of modern companies and is frequently a key component of modern products. Some pieces of software are particularly critical; if they are not correct, the system will have serious failures. Standard methods of software inspection are not systematic. This course teaches a procedure for software inspection that is based on a sound mathematical model and can be carried out systematically by large groups. The software inspection procedure combines methods used at IBM, work originally done at the U.S. Naval Reserve Laboratory for the A-7E aircraft, and procedures applied to the inspection of software at the Darlington Nuclear Power Generating Station. The method has been refined and enhanced by the Software Engineering Research Group at McMaster University's Communication Research Laboratory. It can be applied to software written in any imperative programming language. 2. What Will Participants Learn? Participants in the course should return to their workplace with an understanding of the way that mathematics can be used to document and analyze programs. They will also return with documentation of a piece of their employer's code that can be used to explain the work to others. 3. Programme Day 1 Predicate Logic and Program-Functions/Relations 1) Overview and Case Study A discussion of previous applications of the method. 2) Predicate Logic The inspection method is based on predicate logic, which will be reviewed in this section. 3) Tabular Expressions This session will be devoted to the writing of readable predicates using two-dimensional notations rather than classical one-dimensional expressions. There will be numerous examples. Participants will be taught to read and write tabular expressions. 4) Describing Program Function This session will be devoted to writing program descriptions using predicates and tables. Day 2 Inspection of Dijkstra's Dutch National Flag Program Participants will be given a copy of E.W. Dijkstra's explanation of a program along with several sample programs. They will be asked to apply the inspection method and approve or reject each program. The instructor and some assistants will be available as consultants during this process. Day 3 Morning: Inspection of a "Real" Program Working in small groups, the participants will take a section of a program from their company and inspect it using the method learned so far, producing documentation as they go. Day 3 Afternoon: Report on the Inspection Results, Discussion of Testing The first part of the afternoon will be devoted to a series of reports by the participants on the results of their efforts in the morning. The remainder of the afternoon will be devoted to a discussion of the interaction between testing and inspection. We treat testing, not as an alternative to inspection, but as complementary to inspection. We discuss the way that the documentation produced in the inspection process can be used in the testing process. 4. Learning By Doing The course is language-independent. In fact, on the third day, participants will inspect code written in any language that they use in the workplace. This course presents an approach to active design reviews that has the reviewers writing precise documentation about the program and explaining their documentation to an audience of other reviewers. A significant part of each day will be spent using the ideas that have been presented to determine whether or not programs do what they are supposed to do. On the last day, participants will inspect a small program that they brought with them from their company. Participants should leave the course with improved ability to inspect software. 5. Who Should Attend? Participants should be experienced programmers and not afraid of learning a little mathematics. The mathematical basis for the method is classical and takes up only a few hours in the course. However, it is fundamental to understanding the method. It is expected that the participants will be used to reading code written by others and it will be helpful if they can read Pascal. 6. What Should You Bring With You? For the exercise on the third day, each participant should bring a small program, perhaps 50 lines that are critical to some project. It need not be "mature" code, but it should compile and have survived some testing or use. If there are several participants from the same company, they may work in small groups on slightly larger programs. You may want to bring a reference manual and some conventional documentation about the program with you. It will help if one of the participants is familiar with the program. 7. The Instructor The course will be taught by Prof. David L. Parnas, an internationally recognized expert on Software Engineering. Dr. Parnas initiated and led the U.S. Navy's Software Cost Reduction Project, where the tabular notation was first used, advised the AECB on the use of these methods at Darlington, worked with IBM's Federal Systems Division, leads the Software Engineering Research Group at McMaster University and is a Project Leader for the Telecommunications Research Institute of Ontario. Information about costs, registration, etc. can be obtained from: Jan Arsenault, Faculty of Engineering, JHE-201A, McMaster University, 1280 Main Street West, Hamilton, ON, Canada, L8S 4L7. Telephone: 905 525 9140 x 24910 email: arsenau@mcmail.cis.mcmaster.ca ------------------------------ Date: 15 April 1994 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc. The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ End of RISKS-FORUM Digest 15.81 ************************ 30-Apr-94 0:02:43-GMT,49022;000000000000 Received: from RUTGERS.EDU by aramis.rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA12996; Fri, 29 Apr 94 20:02:41 EDT Received: from chiron.csl.sri.com by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA27703; Fri, 29 Apr 94 19:52:31 EDT Received: by chiron.csl.sri.com id AA07725 (5.65b/IDA-1.4.3.12 for McGrew@RUTGERS.EDU); Fri, 29 Apr 94 16:46:02 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 29 Apr 94 16:45:59 PDT Subject: RISKS DIGEST 15.82 (00) Reply-To: risks@csl.sri.com To: RISKS-LIST.;@csl.sri.com Message-Id: RISKS-LIST: RISKS-FORUM Digest Friday 29 April 1994 Volume 15 : Issue 82 (00) FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: SUMMARY OF RISKS VOLUME 15 (2 Sep 1993 to 29 Apr 1994) [LONG] (archived in file RISKS-15.00 and RISKS-15.82) ---------------------------------------------------------------------- The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. Undigestifiers are available throughout the Internet, but not from RISKS. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA) with SUBSCRIBE RISKS or UNSUBSCRIBE RISKS as needed. Users on US Military and Government machines should contact (Dennis Rears). UK subscribers please contact . Local redistribution services are provided at many other sites as well. Check FIRST with your local system or netnews wizards. If that does not work, send requests to (not automated). CONTRIBUTIONS: to risks@csl.sri.com, with appropriate, substantive Subject: line, otherwise they may be ignored. Must be relevant, sound, in good taste, objective, cogent, coherent, concise, and nonrepetitious. Diversity is welcome, but not personal attacks. PLEASE DO NOT INCLUDE ENTIRE PREVIOUS MESSAGES in responses to them. Contributions will not be ACKed; the load is too great. **PLEASE** include your name & legitimate Internet FROM: address, especially from .UUCP and .BITNET folks. Anonymized mail is not accepted. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ARCHIVES: "ftp crvax.sri.comlogin anonymousYourName cd risks: Issue j of volume 15 is in that directory: "get risks-15.j". For issues of earlier volumes, "get [.i]risks-i.j" (where i=1 to 14, j always TWO digits) for Vol i Issue j. Vol i summaries in j=00. "dir" (or "dir [.i]") lists (sub)directory; "bye" logs out. CRVAX.SRI.COM = [128.18.30.65]; =CarriageReturn; FTPs may differ; UNIX prompts for username, password. WAIS and bitftp@pucc.Princeton.EDU are alternative repositories. risks-15.75 gives WAIS info. FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info regarding fax delivery. PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL RISKS COMMUNICATIONS; as a last resort you may try phone PGN at +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM . ------------------------------ RISKS 15.01 2 September 1993 Is there a roboticist in the house? (Ken Birman) Computer Problems Slow Airline Flights Southern U-S (David Fowler) AFSS Computer Crash Knocks Out Service for 12 Hours (July 93) (Dave Barrett) Risks du jour: malpractice; chemical industry vulnerabilities (Phil Agre) Newspaper tide tables (Marc Auslander) Software design [C.A.R. Hoare] (Paul Smee) Re: Cisco backdoor? (Paul Traina, Al Whaley) Easy Access to Video Rental Records (David Jones) Answers to phone-related questions (Lauren Weinstein) Risks of Discussing RISKS (Dennis D. Steinauer) Re: Mars Observer tank testing (Kevin Maguire) Conference on Technology Conversion (Gary Chapman) RISKS 15.02 3 September 1993 BETTER airline/travel-agent computer hide-and-seek (Mark Seecof) Lost Canadian crime statistics data (Luis Fernandes) Risk of incorrect Daylight Saving conversion (Arthur David Olson) The Risk of Discussing "the risks of discussing risks" in RISKS (Jeffrey S. Sorensen) The risks of CERT teams vs we all know (Fredrick B. Cohen) Potential risk in terminal buffer storage (Robert S. Richardson) Electronic documents (Mich Kabay) Re: Dorothy Denning and the cost of attack against SKIPJACK (Bill Murray) Re: Mars Observer tank testing (Donald Arseneau) Re: Dial 1 first (Mark Brader) COMPASS '94 CALL FOR PAPERS (John McLean) RISKS 15.03 9 September 1993 Robot Disarms Man (David Fowler) The risks of Naive Users (Amos Shapir) The first programming errors (Jon Jacky) Offshore Data Havens (John R. Bruni) Re: The risks of CERT teams vs we all know (Jeff Schiller, Frederick Roeber) Re: Lost Crime Stats (Rodney Boyd) Into the void at the supermarket (Andrew Klossner) Re: What Constitutes an Exhaustive Attack? (A. Padgett Peterson) Fixing what's known to be broken (Tom Lane) Caller ID Blocking and 911 (Monty Solomon) Bank mailing problem (Lauren Weinstein) Technology export curbs (Mich Kabay) Re: Security holes and risks of software like Sendmail (Marcus J Ranum) CfP: 1994 Z User Meeting Announcement (Jonathan Bowen) Call for Papers, Decision Science Conference (ACSLHL) RISKS 15.04 10 September 1993 EuroDigital (Brian Randell) Brussels Branch Of BNP Hit By Computer Fraud (jxm) Screen savers hide what's running below them (Alan Munn) Where should we look for risks? (Steve Talbott) Re: Security holes and risks of software ... (Geoffrey H. Cooper, John Carr) Re: "Offshore Data Havens" (Fred Baube, Gary Preckshot) Re: The risks of Naive Users (Mark Brader) Re: More Gripen Griping (Mark Stalzer) RISKS 15.05 30 September 1993 An oxymoron? (Jim Horning) Unfriendly fire (Tim Steele via Jim Thompson) RISKS BY FAX (Lauren Weinstein) Risks of Flying Toasters? (Jim Griffith) Ilyushin Il-114 crash (Urban Fredriksson) Cancer Treatment Blunder (Brian Randell) RFI from phones (was "EuroDigital") (Mich Kabay) Fungible microprocessors (Mich Kabay) Re: Security holes and risks of software ... (A. Padgett Peterson, Josh Osborne, John Hascall) DCCA-4 Advance Program (Teresa Lunt) [long] RISKS 16.06 5 October 1993 RISKs of trusting e-mail (Theodore M.P. Lee) Stocks and Wands (Paul Dorey) Dead for 3 years, but computer kept paying bills (Alan Frisbie) Newton Tale of Woe (Steven Sargent via Paul M. Wexelblat) RISKS of unverified driving records (Mich Kabay) Redundant data (Mich Kabay) Conditioning and human interfaces (Robert Dorsett) Portable phones and fire detectors (Trevor Kirby) Re: Cancer Treatment Blunder (Paul Smee) Re: Security holes and risks of software ... (Bob Bosen) Bank of America fires employee after reading his e-mail? (David Jones) E-mail for denial of services and corruption (Fredrick B. Cohen) Software Quality vs Staff Size (Mike Willey) RISKS 15.07 6 October 1993 ISDN telephone glitch in Hamburg (Klaus Brunnstein) Japan: IT Security, JCSEC criteria (Klaus Brunnstein) Re: The FBI investigating college pranks (Fredrick B. Cohen) Re: Conditioning and human interfaces (Robert Dorsett) Re: Answers to the mail problem (Fredrick B. Cohen) Trusted portions (Fredrick B. Cohen) Think of it as an opportunity, not a problem (A. Padgett Peterson) Re: Risks of Unverified Driving Records (Robert J Woodhead, Jim Cook, Rex Black) CFP "Ethics" Workshop Cuba Feb.1994 (Klaus Brunnstein) RISKS 15.08 7 October 1993 Control faults cause train crash (Hank Cohen) WSJ report on potential problems with 757/767 Autopilots (PGN) Typing error causes stock to fall 20% for `a few moments' (Lorenzo Strigini) Epitope suit uses computer bulletin board (Tom Hanrahan) Libraries (Phil Agre) The Panoptic Sort (Phil Agre) "Change" and October 1993 CACM (Jim Huggins) Mailing list fun (Mark Brader) Virus distributed during college computer sale (Jim Huggins) Re: Bank of America fires employee ... (Robert Ellis Smith) Re: RISKs of trusting e-mail (Bob Frankston) Re: The FBI investigating college pranks (Valdis Kletnieks) Separating parts in privileged applications (Yves Royer) A reference on Ethics (Peter B Ladkin) Re: Cancer Treatment Blunder (David Crooke, Jerry Bakin, PGN) RISKS 15.09 8 October 1993 Risks of disrupting air traffic control ("Mile High Club") (Richard Marshall via Tom Blinn) Sound of the Fury, Part II (Peter Wayner) Risks of "security" on Apple Newton (Doug Siebert) Re: Control faults cause train crash (Dik T. Winter, Marc Horowitz) Re: Conditioning and human interfaces (Nick Rothwell) Re: Separating parts in privileged applications (Paul Karger, Steen Hansen, A. Padgett Peterson) Re: "Change" and October 1993 CACM (Selden E. Ball, Jr., James K. Huggins) Re: Libraries and Imagined Communities (Mark Gonzales) Re: Cancer Treatment Blunder (Bob Frankston, Rogier Wolff, Jon Jacky) Re: RISKS of unverified driving records (Jim Horning, Jim Hudson) RISKS 15.10 8 October 1993 Wiretap Laws and Procedures (Dorothy Denning) [long] RISKS 15.11 11 October 1993 Yet another spacecraft vanishes (Landsat 6) Auto-response missile system (Brian Kenney, Andrew W. Hagen) ITAR issues in PGP & Moby Crypto subpoenas (L. Detweiler) Wiretap Laws and Procedures (Mark Day, David HM Spector) Risks of using phone bill payment systems (Peter A. Grant) Draft Swiss AntiVirus regulation (Klaus Brunnstein) Risks of "security" on Apple Newton (Berry Kercheval) Re: Disrupting Air Traffic Control (Peter B Ladkin, Peter Wayner) Give us all your passwords (Steve VanDevender) Politics is private property in the panopticon society (Jeffrey S. Sorensen) Re: Control Faults cause train crash (Clive Feather) Re: RISKS of unverified driving records (Geoff Kuenning) Libel and Liability for incorrect databases (Terry Gerritsen via Sarah Elkins) RISKS 15.12 14 October 1993 Networking on the Network (Phil Agre) [long] RISKS 15.13 14 October 1993 Software safety on UK national news (Jonathan Bowen) Warning labels on medication (Bob Campbell) Corrigenda: RISKs of trusting e-mail (Theodore M.P. Lee) Risk of brain-dead mailers... (Graham Toal) Draft Italian Antivirus Law (Luca Parisi) Collins autopilots have a mind of their own (Peter B Ladkin) Lufthansa in Warsaw (Peter B Ladkin) Lest you think that all is rotten in the state of aviation this week (PBL) Dr. Strangelove (was Re: auto-response missile system) (Barry Brumitt) Re: ITAR issues in PGP & Moby Crypto subpoenas (Dorothy Denning) Privacy (Phil Agre) Mathematics of Markets (Mark Brader) Book on Risk Perception (Anthony E. Siegman) Re: CFP "Ethics" Workshop Cuba Feb.1994 (a.e.mossberg) Re: Cancer Treatment Blunder (Sean Matthews, Bear Giles) New Journal: High Integrity Systems (Russ Abbott) RISKS 15.14 18 October 1993 Cable company shows unorthodox children's TV (John Gray) Risks of Virtual Reality (John Mainwaring) Re: Wiretap Laws and Procedures (Bob Leigh, Robert Firth) Hubble mirror errata (Henry Spencer) Re: Privacy Risk for Toronto Dominion Bank customers (Dave Parnas) Digital Signatures as ID Numbers (Karl J. Smith) File on Four (Pete Mellor) Australian government to replace DES (Kevin Burfitt) The FAA and HERF (Winn Schwartau) [longish but interesting] RISKS 15.15 19 October 1993 Confirmed reservation ... for non-existent flight (Mathai Joseph) Physical Security of ATM Password (Jeff Schultz) Re: RISKs of trusting e-mail (Lars-Henrik Eriksson, Frederick M Avolio) Re: Porn, Wiretapping, DES, HERF (Phil Karn) Re: The FAA and HERF (Ted Wong, Jack Boatman) Re: Digital Signatures (Robert J Woodhead) Re: Risks of Virtual Reality (Robert Carolina) Re: Wiretap Laws and Procedures (Steve Bellovin) Re: Australian government to replace DES (Steve Bellovin) Re: Software safety on UK national news (Pete Mellor) Re: Libraries and Imagined Communities (Bruce Hamilton) Re: Separating parts in privileged applications (Bob Frankston, Tom Thomson) RISKS 15.16 19 October 1993 Social Psychology & INFOSEC (Mich Kabay) RISKS 15.17 21 October 1993 A chip, off the old block (PGN) Fiber Optic Cable "Meltdown" in Connecticut (E.M. Culver) NII confidential report "on sale" (Martyn Thomas) US Has It Too (Re: Russian Doomsday Device) (Li Gong) Media Explosion => Loss of Community ? (Fred Baube) Re: Auto rentals, law suits, and the risks (Jerry Leichter) Dangers of anonymous remailers [Anonymous] Privacy Digests (PGN) SunOS and Solaris vulnerabilities (PGN, CERT Advisory) RISKS 15.18 27 October 1993 Saab Story: Cars rolling off the assembly line (Vernon L. Chi) Yet another date overflow bug (David Lamb) OZDISK - Big Brother Down Under? (Mike Bell) Russian Hacker Activity (David Fowler) Thank you (Lauren Wiener) Re: CERT and "security incident" handling (Doug Moran, A. Padgett Peterson, Scott Schwartz, Bruce R. Lewis, Nick Rothwell) Re: The FAA discovers HERF (Dennis Chamberlin) RISKS 15.19 27 October 1993 Optic fibre fragment kills Telecom worker (Robin Kenny) Lanocaine (sp?) (Bob Frankston) Ethernet addresses as "port" ids (Bob Rahe) File on Four on safety-critical software (Pete Mellor) Cracking feature in the small press (Jim Haynes) Re: FAA and HERF - a pun-ctilio (Peter B Ladkin) Re: Clipper (Fredrick B. Cohen) Re: Chip thefts (Mich Kabay) Re: Dangers of Anonymous Mailers (Steven S. Davis) Re: Swiss AntiViral legislation (Claudio G. Frigerio via Klaus Brunnstein) Computer-Aided Verification (CAV'94) (David Dill) RISKS 15.20 1 November 1993 Breakdown in computerised voter support, Oslo (Reidar Conradi) Norwegian hackers fined (\ystein Gulbrandsen) White House distributes STONED 3 virus (Andrew Klossner) Police feedback (Graeme Jones) Taurus Project (E. Kelly) Magnetic Fields in Subway Cars (Bob Drzyzgula) Report on Software Product Liability (Charles Youman) Re: Dangers of Fibre Optic cable (John Gray) Re: CERT Reports and system breakins (Mike Raffety) Re: CERT (was "security incident handling") (A. Padgett Peterson) Re: Ethernet addresses as "port" ids (A. Padgett Peterson) 3rd SEI Conference on Software Risk, 5-7 April 1994, Pittsburgh (Ellen Ayoob) Workshop on IT Assurance and Trustworthiness (Marshall D. Abrams) ISOC Symposium on Network and Distributed System Security (Danny Nessett) RISKS 15.21 2 November 1993 Investment program turns into doomsday machine (Meine van der Meulen) Direct E-Mail: J.S. McBride & Co. (anonymous) "RSI does not exist" (Gavin Matthews) Public relations (Phil Agre) Procrustus (Bob Frankston) Re: Magnetic Fields in Subway Cars (Peter Debenham, Andrew Marchant-Shapiro) Re: Fiber Optic Cable Hazards (Bonnie J Johnson) Re: Breakdown in computerised voter support, Oslo (H?vard Hegna) Re: Ethernet addresses as port ids (Bob Rahe) ESORICS 94: Call for Papers (Yves Deswarte) RISKS 15.22 8 November 1993 Direct Subscribers: Can you instead read RISKS as a newsgroup? (RISKS) Prague computer crime (Mich Kabay) Phiber Optik, Master of Disaster, sentenced (Mich Kabay) Mass. state police confuse car owners with gun carriers (Brian Hawthorne) Overenthusiastic automated investment programs (John R Levine) RISKS of unaccountable computerized elections (Dave Hart) Re: Safety-critical software (David Parnas) Re: InterNet Mailing List (JS McBride [2]) Security of the internet (Bill Murray, PGN) Yu, "Automated Proofs of Object Code..." available (Jim Horning) "Research Directions in Database Security" ed. by Teresa Lunt (Rob Slade) Re: CERT Reports and system breakins (Phil Karn, A. Padgett Peterson) Call for Participation, FIRST Incident Response Tools Working Group (Michael S. Hines) RISKS 15.23 6 November 1993 Another plane lands on the taxiway (Lord Wodehouse) Pax Technologica? Not in Somalia (Peter Wayner) Teachers Beware! (Peter G Spera) Clerk stole from ATMs he was told to top up ... (Apte Kishor Hanamant) Notice of Fire Hazard with Dell Notebook Computers (Bob Robillard) "Eye of the Storm" (*another* Desert Storm virus?) (Rob Slade) Re: White House and STONED 3 virus (Andrew Klossner, Jon Grantham) Re: Ethernet addresses as "port" ids (Brian Bulkowski) Re: CERT Reports and system breakins (Allan Duncan) Re: Fiber Optic Cable Hazards (Gordon Mitchell) Re: "RSI does not exist" (Pete Mellor) Re: Magnetic Fields in Subway Cars (Bob Frankston, Kenneth R Foster, Ian Turton, Peter Gorny, Bruce Limber, Russ Cage, Graeme Thomas) RISKS 15.24 9 November 1993 Smart Houses? No Thanks! (Jim Brown) Ada, a standard no more? (Luis Fernandes) Pets & data communication (Bruce Clement) Orange County DACS outage (Matt Holdrege) Review of Bruce Sterling's Hacker Crackdown (Peter B Ladkin) Alvin and Heidi Toffler's War and Anti-War (Jeffrey D. Young) Re: Car owners confused with gun owners (Martin Minow) Software control problems in Block 40 F-16s (Peter B Ladkin) Investment program turns into doomsday machine (Rogier Wolff) Re: Notice of Fire Hazard with Dell Notebook Computers (Don Porges) Internet Security (William Hugh Murray) Stupid language games (Richard Schroeppel) Networking on the Network (Richard Schroeppel) Anonymous postings (anonymous? No, Daniel Lieber) Properties of Anonymizing Service (Anthony E. Siegman) Risk-happy drivers foil anti-lock brakes (Dyane Bruce) RISKS 15.25 10 November 1993 RISKS of camping... (E.M. Culver) No change in Ada policy (Robert I. Eachus) Groundhog Day, D-Day, Remembrance Day, and all that (Mark Brader) Not so easy to be anonymous (Robert L Ullmann) Snakes of Medusa and Cyberspace: Internet identity subversion (L. Detweiler) RISKS 15.26 13 November 1993 Gripen crash report (Urban Fredriksson) SAS MD-81 crash report, December 1991 (Martyn Thomas) MASS state police confuse car owners with gun carriers (NOT) (Simson Garfinkel) Re: No change in Ada policy (Anonymous, Parnas) Risk-happy drivers foil anti-lock brakes (Mark Brader) _Naissance d'un virus_ soon to be published (Jean-Bernard Condat) Re: pseudospoofing (Andrew Marchant-Shapiro) I'm Me (Nick Szabo) Re: anonymizing service (Karl Lui Barrus) Re: Not so easy to be anonymous (Seth Chazanoff) Re: Stupid language games (Dave Parnas) Re: Networking (Phil Agre) "Friendly Fire" in system design (Steve Taylor) Re: Teachers Beware! (Andy Cunningham) FBI Operation "Root Canal" Documents Revealed (Dave Banisar) RISKS 15.27 17 November 1993 Re: The Snakes of Medusa and Cyberspace (mathew, Alex Glockner, Perry E. Metzger, Jamie Dinkelacker, Arthur Abraham, Peter Leppik, Brad Hicks, Neil McKellar, Leonard Mignerey, L. Detweiler) RISKS 15.28 17 November 1993 Power problems stops Milano Stock Exchange for 4 hours (Lorenzo Strigini) Lawyer discovers the RISK of computer efficiency (Martin Minow) Living Will Database (Brian Hawthorne) Review of "Second Contact" by Resnick (Rob Slade) UK government to scrap safety laws (Jonathan Bowen) Tablespoons, or, handwriting recognition may be hazardous to your poem (Mark Brader) Visa introduces transaction UIDs (Bob Frankston) Re: CERT Reports and system breakins (Steve Bellovin) Re: MASS state police confusion (Eric N. Florack) Re: Ada Usage (Harry Erwin, James H. Haynes) Re: Groundhog Day, D-Day, Remembrance Day, and all that (mathew) A Myth is as good as a Smile (PGN) Call-for-Papers for 17th Nat`l Computer Security Conference (Louise Reiner) RISKS 15.29 23 November 1993 Logic Bomb planted in retribution for nonpayment (Mich Kabay) Brazilian computer snarls in corruption probe (Mich Kabay) Digitized Photos (Mich Kabay) Magnetic Fields & Leukaemia (Mich Kabay) Who owns the unused cycles? (Bear Giles) Not-voting-by-phone Boulder over (Bear Giles) Tablespoons, or another risk? (Steve VanDevender) Charge cards from mail order houses (Ted Wobber) United Parcel Service signatures (Jim Carroll) Re: Massachusetts state police confusion (Brian Hawthorne) Re: Ada Usage (Douglas W. Jones, Robert I. Eachus) Re: UK government to scrap safety laws (Keith Lockstone) RISKS 15.30 1 December 1993 Risks of automated betting (Russ Corfman) Computer Changeover May Cost $16M (Lin Zucconi) Mercury passwords can be compromised (Keith Lockstone) Computerized Pornography (Brian Randell) Picking from Trash (Re: Charge cards from mail-order houses) (Li Gong) GRE goes "adaptive" (Cris Pedregal Martin) More news on the Lufthansa A320 accident in Warsaw (Peter B Ladkin) Memory error corrupts file (James Michael Chacon) New Moderator for the Computer Privacy Digest (Dennis G. Rears) Re: Safety-critical software (Pete Mellor) Re: Ada Usage (Tucker Taft, Mathew Lodge) RISKS 15.31 3 December 1993 London Underground train departs driverless with 150 passengers (Martyn Thomas) Voting by Fax (Bear Giles) Computer Fax Problems (Andrew Blyth) A study of National Cryptography Policy (Marjory Blumenthal) "Using McAfee Associates Software for Safe Computing" by Jacobson (Rob Slade) New Docs Reveal NSA Role in Digital Telephony Proposal (Dave Banisar) Re: Computerized Pornography (Charlie Stross) Re: Lufthansa Airbus Warsaw Crash 14 Sep 93 (Udo Voges) Re: Mercury passwords can be compromised (Peter Debenham) Re: United Parcel Service signatures (Andrew Marc Greene) CFP: 13th Symp. on Reliable Distributed Systems (Rick Schlichting) RISKS 15.32 7 December 1993 FAX sends instead of receives (John McKay) Risks of conference calls "lack of announcement" Apple Computer Distributes a CD-ROM with a "Trojan Horse" (Saul Tannenbaum) French Wiretaps (Mich Kabay) Tokyo bank fraud (Mich Kabay) German Radicals use Computers (Mich Kabay) NJ credit thefts (Mich Kabay) Counterfeits (Mich Kabay) AIDS data stolen in Florida (Mich Kabay) Unauthorized changes of address (George Zmijewski) Massive credit card fraud (Mich Kabay) Lufthansa Warsaw crash - A Clarification (Peter B Ladkin) Reminder for DCCA-4: Fourth IFIP Working Conference (Flaviu Cristian) RISKS 15.33 7 December 1993 Review: "Digital Woes" by Lauren Ruth Wiener (Pete Mellor) Review: "Terminal Compromise" by Winn Schwartau (Rob Slade) RISKS 15.34 13 December 1993 Computer glitch postpones 'Tommy' (David Tarabar) Electronic Money (Brian Randell) Financial Newswire Fraud (Thomas J Scoville) Canadian study on computer fraud (Mich Kabay) Risks of being a programmer (Jon Jacky) The risk of distributed servers with only partial uninterruptible power (Bob Cunningham) Risks of inband communication triggering call forwarding (Simson L. Garfinkel) Mail forwarding as easy as Call forwarding (Kiser) Re: Massive credit card fraud (Pete Mellor) Apple has poked around on your hard disk before (Grady Ward) Re: Corrupted Polling (Brian Randell) Re: Digital Woes (Harry Erwin) COMPASS '94 Call for Papers and Call for Tutorials (John Marciniak) RISKS 15.35 22 December 1993 Airport lessons for InfoSec (Mich Kabay) Sham CD-ROMs (Mich Kabay) Smart Cars and Highways (Mich Kabay) Risky Demo Offer (Rex Wheeler) "Re-Chipping" Stolen Mobile Phones (Brian Randell) Interactive TV: electronic democracy, risks to privacy, etc. (John Gray) Trouble with funny place names (Mark Brader) Mexico Turns Off Quake Warning System (Frank Carey) Wireless Laptop Eavesdropping (Andrew Duane) Re: Harry Erwin on Digital Woes (Lauren Wiener) Question About Singapore Lottery Crime (Sanford Sherizen) ISOC Symposium on Network and Distributed System Security (Dan Nessett) RISKS 15.36 2 January 1994 Risks of high pitched tones (Lance J. Hoffman) Can SETI signals bear viruses? (Brandon A Cantillo) Report on Strasbourg A320 Crash emphasises HCI (Peter B Ladkin) Be careful not to let your engine control computers overheat (Peter B Ladkin) LapLink Wireless (Mark Eppley via Bob Frankston) Re: Airport lessons for InfoSec (Robert Dorsett) Re: "Re-Chipping" Stolen Mobile Phones (Andrew Beattie, Li Gong) An Exception (Harry Erwin) RISKS 15.37 3 January 1994 Hacker nurse makes unauthorised changes to prescriptions (John Jones) Customs Data Diddling (Mich Kabay) Credit cards again (Mich Kabay) Tax Frauds (Mich Kabay) Re: Can SETI signals bear viruses? (Robert Ayers, Dave Weingart, James Abendschan) "When H.A.R.L.I.E. Was One" by Gerrold (Rob Slade) Request for help with RISKy situation (Alan Wexelblat) RISKS 15.38 15 January 1994 $500k phone fraud (Chuck Weinstock) Wild agents in Telescript? (Phil Agre) "Industry Defies Clinton on Data Encryption" -- John Markoff Encryption Export Control, and Cantwell Bill (Sharon Webb) (Mis)Information spreads like wildfire (Mabry Tyson) Software Management Risks (Harry Erwin) RISKS 15.39 21 January 1994 Hidden risks of earthquakes (Clive D.W. Feather) Phony air traffic controller (Fernando Pereira) Poulson/PacBell (Mich Kabay) Links to Internet to be limited by DoD (Bob Kolacki) India - Software Glitch Causes PSLV Failure (S. Ramani) Verify your backups (Louis Todd Heberlein) Safety in Telescript (Luis Valente) Slippery Folks in the Oil Business (Peter Wayner) Risks of Domain Names (Matt Cohen) Re: Mail forwarding as easy as Call forwarding (John M. Sulak) Cellular phone security features...NOT! (Matthew Goldman) Harvard Case of Stolen Fax Messages (Sanford Sherizen) Re: Hacker nurse makes unauthorised changes to prescriptions (Li Gong) Spontaneous recovery from "NOMAIL" setting? (Ron Ragsdale) Re: Proposal for new newsgroup on safety-critical systems (Jonathan Moffett) Privacy Digests (Peter G. Neumann) ISSA Conference Announcement (Dave Lenef) RISKS 15.40 24 January 1994 Re: Spoofing Air Traffic Control (John Stanley, Wolper) Re: Spoofing Telescript (Barry Margolin, Adrian Howard, Paul Barton-Davis, Geoffrey Speare, John Pettitt) Re: Spoofing SETI (Someone at NASA?, Bear Giles, Mark Staltzer, Steven King, Steve Elias, Charles Bryant, David Honig, Mark Thorson, Jon Mauney, Andrew Klossner, Dan Keith, Adam BJ Quantrill) RISKS 15.41 26 January 1994 Lightning on the Ethernet (eddy, not flo) E-Mail Fraud (Lori Carrig) Update on voter fraud in Costella County, Colorado (Bear Giles) Laptop Computer Could Explode (F. Barry Mulligan) Opening of European borders delayed by InfoSys problems (Bertrand Meyer) Canada loses satellites -- anyone have more info? (Alan Wexelblat) Risks of dynamic binding (Andrew Shapiro) New museum on cryptography (Jeremy Epstein) Is Global Authentication Impossible? (Li Gong) Re: Phony air traffic controller (Mark A. Bowers, Cameron Strom) Re: Smart Cars and Highways (Jerry Leichter) Re: Telescript risks (Bob Blakley III) Re: Can SETI signals bear viruses? (Andrew Klossner) RISKS 15.42 28 January 1994 CFP '94: THE FOURTH CONFERENCE ON COMPUTERS, FREEDOM AND PRIVACY [long] RISKS 15.43 29 January 1994 [misdated 30 Jan] Where has your Floating Point floated to? (Dave Wortman) Canadian TeleSat Anik E-2 Down (Colin Perkel, Luis Fernandes) Re: Lightning on the Ethernet (Jon Peatfield) Re: Spontaneous recovery from "NOMAIL" setting (Al Stangenberger, Ron Ragsdale, Peter M. Weiss) Re: Verify your backups (Rob Horn, Dick Hamlet) Crypto policy report available online (Lance J. Hoffman) 1994 IEEE Symposium on Research in Security and Privacy (Catherine Meadows) RISKS 15.44 2 February 1994 Canada to monitor phone calls, fax, etc.? (Walter C. Daugherity) Risks of cliche collisions on the information superhighway (Phil Agre) Irrational risk research (Phil Agre) Czech computer fraud (Mich Kabay) Clipper Petition (Dave Banisar) "Digital Woes" by Lauren Wiener (Rob Slade) RISKS 15.45 8 February 1994 A Rise in Internet Break-ins Sets off a Security Alarm (NYT excerpt) CERT Advisory - Ongoing Network Monitoring Attacks (CERT) "Misunderstanding" a CERT advisory (Klaus Brunnstein) RISKS 15.46 8 February 1994 Medical privacy violation (Mich Kabay) Revised Documents on FTP server without version number (David W. Crawford) Campaign Against Clipper (Dave Banisar) Re: Clipper Petition (David Gursky) Don't trust the phone company (Tom Bodine) Modern discussion of computer risks in old book (Lauren Wiener) RISKs of network surveys (Craig DeForest) National Cryptology Museum (Larry Hunter) 10th ACSAC Call for Papers (Vince Reed) RISKS 15.47 9 February 1994 "Sounding the Alarm: Noisy medical alert systems" (B Fitler) (Semi-)electronic locks (Pete Kaiser) Safety in Telescript, Part Deux (Luis Valente) Risks of email exacerbating typos (M. Hedlund) Patents Hearing as it relates to Software (Paul Robinson) Network surveys et al. (Steve Holzworth) Re: Don't Trust The Phone Company (Lars Poulsen) Re: "Misunderstanding" a CERT advisory (D.R. Newman) Re: Clipper Petition (Pete Kaiser, John Mainwaring) Re: Altered White House Documents (Robert Firth, Larry Nathanson) EFF Wants You (to add your voice to the crypto fight!) (Stanton McCandlish) RISKS 15.48 9 February 1994 Notes on key escrow meeting with NSA (Matt Blaze) Re: Campaign and Petition Against Clipper (Dorothy Denning) RISKS 15.49 10 February 1994 FireFly in the ointment? (Don Watts) Aging software ages suddenly! (Don Watts) Clinical diagnosticians and diagnostic clinicians (David Honig) UK bank preparing for electronic money trial (John Gray) What goes around, comes around (Paul Robinson) Electronic rumours (Mich Kabay) Medicare Transaction System & the Electronic Superhighway (Mich Kabay) Re: Risks of cliche collisions on the information superhighway (Mark Jackson) Re: White House documents (Bill Casti via David Crawford) Re: Cantwell and Spoofed Representatives? (Jon Leech) Re: Sounding the Alarm (Robert J Horn) Re: Verify your backups (Timothy Miller, Dan Lanciani, Martin Minow) EMI article in IEEE Spectrum (Robert J Horn) RISKS 15.50 10 February 1994 Re: Dorothy Denning's contribution to RISKS-15.48 on EES/Clipper/etc. (Barbara Simons, Marc Rotenberg, George T. Talbot, Lance J. Hoffman, Fredrick B. Cohen, A. Padgett Peterson, Geoff Kuenning) RISKS 15.51 10 February 1994 FLASH: Vice President Gore Questions Current Key Escrow Policy! (Stanton McCandlish) CMU elections suspended due to computer problems (Declan B. McCullagh) TCAS blamed for near collision over Portland (Lauren Wiener) Pacific Bell Customers Get Unpleasant Messages (Lin Zucconi) Two recent UK tales: Gas payment notices; info network problem (Peter Ladkin) FBI falsely obtained wiretap in KC (Paul) Re: "Misunderstanding" a CERT advisory (Espen Andersen) Re: Altered White House Docs (A. Padgett Peterson, Pete Mellor, Jim Hoover) About Computer Software and Patents (Paul Robinson) RISKS 15.52 11 February 1994 Cygnus Support frees its security software to beat Internet break-ins (John Gilmore) Re: Campaign and Petition Against Clipper (Dorothy Denning, Marcus J. Ranum, Carl Ellison, Paul R. Coen) Re: Notes on key escrow meeting with NSA (Roy M. Silvernail) Re: Coincidences (Sniffers, Breakins, and EES) (A. Padgett Peterson) Re: Verify your backups (Li Gong) Re: Electronic Keys vs. The Old Kind (Morgan Price) New List on Computer/Telephone Problems/Bugs/Viruses/Dangers (Paul Robinson) RISKS 15.53 12 February 1994 Electronic tax filing: MAKE.MONEY.FAST ??? (Ed Ravin) Celebrity Risks -- Bill Gates (Jack B. Rochester) Computers and Health (Computer User Family) Microsoft Software Development Network registration (James Briggs) Re: FireFly in the Ointment (Andy Kostic, Marco Barbarisi) Re: Sounding the Alarm (Anthony E. Siegman, Georg Feil) Re: Don't trust the phone company (Joe Konstan, Spencer W. Thomas, Michal.Jankowski, Nancy Griffeth and others) RISKS 15.54 14 February 1994 Voice-mail phreaking (Mich Kabay) Electronic Food Stamps (Mich Kabay) Another ATM "front end" fraud - this time caught (Jonathan Haruni) [Lighter Side] Risks of computer-literate babies (Robert J Woodhead) New Novel/Thought experiment... (Peter Wayner) Recent Articles of Interest (Bob Frankston) Re: Celebrity Risks -- Bill Gates (John Bush) Card Fraud and Computer Evidence (Ross Anderson) RISKS 15.55 15 February 1994 YAMIC [Yet Another Mistaken Identity Case] (Robert Herndon) William Safire on Clipper: ESSAY: SINK THE CLIPPER CHIP Over 10,000 Sign Petition to Oppose Clipper (Dave Banisar) Canada to monitor phone calls,fax,etc.? (Sahel Alleyasin) No switch on new Sun Microphone (Olin Sibert) Electronic Mail vs Paper Mail (mathew) FIRP report comments (Stephen D Crocker) RISKS 15.56 17 February 1994 Smart Cards for London Buses (Mich Kabay) NII Testimony (Robert Ellis Smith) Losing ATM transactions (N.S. Youngman) Telephone charges fail to fit the bill (Marcus Marr) Re: E-mail risks (Bill Fitler, Rex Black) 737 crash near Panama (Tim Steele) Re: YAMIC [Yet Another Mistaken Identity Case] (Jim Cook) Who says the Clipper issue is complicated? (D.J. Bernstein) Re: Classified justifications; escrowed keys (Carl Ellison) CFP, First Smart-Card Research & Advanced Application Conference (JJVandewalle) RISKS 15.57 22 February 1994 Extra line in Chemical Bank program doubles ATM withdrawals (John Sullivan) What else happens when the airbag in your car detonates? (William Caloccia) SimHealth (Mike Zehr) Risks of "doing it right" (David Wittenberg) The ultimate couch potato (Bruce Balden) Telephone Card Audit Trails (F.Baube[tm]) E-Mail Courtesy (Dan Yurman, Peter Cherna, Greg J B) E-mail to Bill (Aaron Barnhart) CompuServe Offers Credit Info (John Murray) Electronic Food Stamps (LoQuan Seh) Re: YAMIC [Yet Another Mistaken Identity Case] (Bryan J Dawson) John Perry Barlow WiReD article on Clipper (Martin Minow) RISKS 15.58 23 February 1994 E-Mail blunder at Olympics (David G. Novick) Dog Gets Card With $10G Limit (marc via PGN) Computer error adds to ad valorem tax for 300,000 people (James E. Burns) Embezzler caught by computer trail (James E. Burns) Software testing at Sizewell (Brad Dolan) Clipping Clinton and the Executive Branch... (Peter Wayner) Clipper: Love your country, don't trust its government (David Honig) Re: CompuServe Offers Credit Info (Steve Bellovin) Social RISKS of Universal IDs (John Oram) Re: SimHealth (Gerd Meissner, Bob Frankston) Re: Telephone Card Audit Trails (Jonathan I. Kamens) Re: E-Mail Courtesy (Jim Haynes, Bob Frankston) Re: Electronic Food Stamps (Colby Kraybill) Re: International Internet Association (Jeff Porten) RISKS 15.59 26 February 1994 Microsoft Dinged for $120 Million Leaving intelligence to the experts: lie detectors and Clipper (John M. Sullivan) Janitor interrupts UPS (Lisa Balbes) Portuguese drug ring ensnared by pager technology (Fernando Pereira) Snag hits Reserve Bank of India's clearing operations (S. Ramani) "Wire Pirates" - article in March 1994 Scientific American (Martin Minow) Van Eck Radiation Helps Catch Spies (Winn Schwartau) Re: Software testing at Sizewell (Dave Parnas) Re: SimHealth (Bill Stewart) Re: The ultimate couch potato (Bear Giles) FLASH: FBI's Draft Digital Telephony Bill: EFF Summary and Analysis (Daniel J. Weitzner) RISKS 15.60 28 February 1994 $1M deposited in bank error (PGN) Another Olympic E-mail Penetration (PGN) The dangers of electronic mail (Rob Hasker) Ex-employee arrested in computer-file theft (Lance Gatrell) How about bounties for inspecting safety-critical software? (Michael Chastain) Reloadable and Smart Cards en route to worldwide acceptance (Gordon Webster and Sree Kumar) FBI Digital Telephony Proposal and PCS mobile phone networks (M. Hedlund) Re: Van Eck Radiation ... (James H. Haynes, Fredrick B. Cohen, Vadim Antonov, Bob Brown, John R Levine, Bill Bolosky) RISKS 15.61 3 March 1994 More on the $1M deposited in bank error (Raju Varghese) Internet Trojans (Mich Kabay) Biometrics (Paul Robinson) Re: Aldrich Ames and the Clipper Project... (Peter Wayner) Some Thoughts on Clipper, NSA, and one key-escrow alternative (Jim Bidzos) Algorithms have unclear boundaries (Mike Crawford) Response from Cambridgeshire Constabulary (Lawrence Kestenbaum) Re: Threatening E-mail (Peter B Ladkin) Re: Bounties for Safety-Critical Software (Peter B Ladkin) RISKS 15.62 3 March 1994 Joe Camel's 10,000,000 best friends (Phil Agre) Double Posting of Credit Card Charges (Bryan Apple) Video Tech & Privacy... what's becoming possible (David Honig) RISK of computer-controlled landings (Simson L. Garfinkel) Headline: "Child molesters use computer talk as bait" (David Tarabar) Conviction for spreading virus? (Laurel Kristick) 'We {Will} Find you...' (Paul Robinson) Local TV News Report Misses The Boat (Dan Danknick) Educating on the RISKS of the Internet (Jeremy Epstein) Will they ever learn? [Passwords] (Roger Binns) One time Passwords and Encryption (A. Padgett Peterson) Of Locks and Legends (Dave Pierson) Impact fuel cutoff anecdote, risk (Bob_Wise) NTIA Releases Notice of Inquiry on Privacy Issues (Beth Givens) SIGSOFT 94 Call For Papers (Dave Wile) RISKS 15.63 7 March 1994 Yet Another Mistaken Identity (Mike Zehr) Philadelphia 911 Crash (Steve Pielocik) Service a computer, go to jail (Kriss A. Hougland) Court Case casts doubt on cashpoint credibility (Brian Randell) `Hacker' alters Drug Protocol in British Hospital (Peter B Ladkin) Will Australia be doomed to repeat Clipper? (Rhys Weatherley) A Well Oiled Mac (Jon Golob) SCIENCE article critical of computer models (Jon Jacky) Re: Autopilot landings in `zero visibility' (Peter B Ladkin) The risks of user ID's (Jason Haines) RISKS RISKS: Bug in mailing RISKS-15.61 (Mike Sullivan, PGN) RISKS 15.64 10 March 1994 Irony & embarrassment (Gene Spafford) Another twist on Harding e-mail breach (John C. Rivard) Maybe appalling grammar is bad language design (Don Norman) Wrong credit card in the mail (Stephanie Leif Aha) Troubled water crossing bridge (Harald Hanche-Olsen) Calling-Number-ID catches obscene caller (Richard R Urena) X windows makes patient breathless (Govinda Rajan and Mathew Lodge) Trouble in comicland? (Arthur Goldstein) Getting help on the Internet (Phil Agre) Re: Clipper (Keith Henson, Carl Ellison, Stanton McCandlish) COMPUTER RISK! [Early April Fooling?] (Simon Travaglia) RISKS 15.65 11 March 1994 Using Caller ID to catch obscene callers (anonymous) Hard-drive headache (Robert Telka) Digital Detritus (Eric Sosman, Stephen D Crocker) Re: Maybe appalling grammar is bad language design (Mark Jackson, Alayne McGregor) RISK to freedom of information (Philip Overy) Re: Clipper (Mark Eckenwiler, Daniel B. Dobkin) 13th Intrusion-Detection Workshop (Teresa Lunt) First announcement of COMPASS '94, program and info (Teresa Lunt) RISKS 15.66 17 March 1994 Hit the Wrong Key, become a Verb... (Peter Wayner) Aldrich Ames, Master Hacker? (Peter Wayner) "Clipper Compromised?" brief in Network World (Christopher Wysopal) Sly Imposter Robs S.F. Man of Good Name (Mike Crawford) Fire knocks out phone service in LA (George Feil) Ease of Administering Phone Systems Leads to Risk of Sabotage (George Pajari) Nessy - same new trick (Bob Frankston) Super-ID and Surveillance (Mich Kabay) Caught with their pants down [de-picted by rabbit admirers] (Mich Kabay) Neo-nazi T.A.D. eavesdropping (Mich Kabay) Derivatives (Phil Agre) Followup report on TCAS incident in Portland (Lauren Wiener) Caller ID utility (Robert Morrell Jr.) New Security Paradigms Workshop: CFP and Correction (Catherine A. Meadows) RISKS 15.67 18 March 1994 Hazards on the Superhighway (Erskine Widemon) The RISKS of whale removal (Tom Mahoney via Mark Stalzer) The Handmaid's Tale, Giuliani-Style (Chris Kreussling) IRS Surveillance (J. Cooper) Risk Conference - Two for the price of one! (Patrick J. O'Toole) 911 (again) (Richard Johnson) Re: Clipper Compromised (Dorothy Denning) It's Apple and it's grammar. (John Oram) L.A. phone fire (a.k.a. "Risks of believing ...) (Lauren Weinstein) RSAREF/RIPEM Free and Legal Worldwide (Jim Bidzos) CERT ADVISORY - MD5 Checksums (CERT) [Full text in RISKS-15.67MD5] RISKS 15.68 22 March 1994 Gambling (Phil Agre) I really like this guy's attitude (Alan Wexelblat) Phone Machines Call Each Other, Part Deux (Russell S. Aminzade) IRS Surveillance (Part II) (Zajac) Dutch legislators trying to pull a fast one? (Ralph Moonen) Funny Money article in THE SCIENCES (Mich Kabay) Human Genome Project & Privacy (Mich Kabay) SGML--archiving style + content (Mich Kabay) Risk of bringing plastic cards through UK customs (Ross Anderson) RISKs of safe ATMs (Sidney Markowitz) Re: Hard-drive headache! (David M. Miller) Re: The RISKS of whale removal, copyrights (Matthew B. Landry, Mark Stalzer) Comment on my earlier posting on punctuation and spelling errors (Don Norman) Re: Caught with their pants down (Sean Malloy) RISKS 15.69 25 March 1994 Another ATM failure (with a happier ending) (Mark Connolly) Bugs hold up farm cheques (Mich Kabay) Nut behind the wheel (Mich Kabay) Digital Telephone Switches and Modems (Bob Oesterlin) Grammatik bug mistaken for racial putdown (Marni Elci via Roy Beimuts) Re: Denver Baggage Handling (John Gersh, Marcus J Ranum, Bear Giles) Re: Funny Money article (Sean Eric Fagan, Curtis Jackson, Tobias Ulmer) Re: RISKs of safe ATMs (M. Hedlund) Re: Comment on earlier [Don Norman] posting (Marcus J Ranum) CFP: 2nd ACM Conference on Computer and Communications Security (Li Gong) RISKS 15.70 28 March 1994 April Fools on the Senate (John Dvorak and Chris Casey via Arthur R. McGee) Risks to government (Robert Davis) IRS persistence (Dave Methvin) BT Billing computers innocent (Marcus Marr) Insurance claims ignore patients name (David Bazell) The RISKs of Canadian Poodles using 911 (John Oram) Ottawa, Canada, Radio contest overloads phone system (Henry Troup) 911 as wrong number - they don't seem to care anymore (Jeff Hibbard) Re: Denver Baggage Handling (Jan Vorbrueggen) Re: The RISKS of whale removal (David G. Novick) Re: Banknotes and photocopiers (Tom Standage, Padgett Peterson) RISKS 15.71 29 March 1994 Risks of washroom automation (Paul Colley) Pay-per-View failure lets adult station go unscrambled (Mike Carleton) Role-playing Addiction (Mich Kabay) Software theft statistics (Mich Kabay) Risks of spelling checkers (John Girard, PGN) Busy-waiting woes (Darren Senn) Recent useful newspaper pieces on crypto policy (Lance J. Hoffman) Re: L.A. Phone Fire (Nevin Liber) Re: Canadian Poodles using 911 (Shawn Mamros) Re: Banknotes and photocopiers (Mike Sullivan) Re: IRS persistence (Robin Kenny) Preliminary Program 7th IEEE Computer Security Foundations Workshop (Li Gong) RISKS 15.72 31 March 1994 Mud Slide Cuts East Coast Phones (PGN) Briton Survives "Monster" Attack due to computer glitch (Will Deatrick) Risk Evasion Measures Create New Risks (Stephen A. Stough) Rental cars and financial derivatives (Phil Agre) White collar crime in Australia (Mich Kabay) Hotline reassignment (Mich Kabay) Electronic purse (Mich Kabay) Dials! (Bob Frankston) Re: Spelling Checkers (Geoff Cole, Mary Shafer, Scott A. Siege, Simson L. Garfinkel) Disclaimers in software (PGN) Junior Exec's Reverse Alchemy (Martin Howard) Yet another SSN misuse (Brian Clapper) EFF Summary of Public Interest NII Summit 29 Mar 1994 (Stanton McCandlish) RISKS 15.73 1 April 1994 A320 software goes on "3rd Party" maintenance (Pete Mellor) Re: Risks of spelling checkers (Joseph T Chew, Andrea Chen, Eric Sosman) Re: Mud Slide Cuts East Coast Phones (David Lesher) Aural Sex and Rudder Actuators (A. Padgett Peterson) More jail-door openings (Tom Markson, PGN) find/xargs strangeness (Peter J. Scott, Chris Dodd) P. R. China Computer Security Rules (John Ho) RISKS 15.74 2 April 1994 Re: Spell checking (J. Taggart Gorman, Pete Mellor, Castor Fu, Les Earnest) Re: Language ability is not entirely learned (Paul Colley) Re: Spelling, punctuation, poor language technology (Bill Stewart) Re: English spelling design (Christopher Upward) RISKS 15.75 13 April 1994 E-Mail saves a man's life Risks of powerful computers to the quality of science (Dan Ruderman) Robot mower (Pete Mellor) God Grants Granite Gift to RISKS Punsters (Peter Wayner) The Soft Pork Underbelly of Efficient Markets (Peter Wayner) A creative, HONEST software disclaimer (Neil MacKay) E-mail problems (Andrew W Kowalczyk) Holiday Inn extra key requirements (Lance A. Brown) Fingerprinting & welfare (Mich Kabay) Re: More jail-door openings (Al Stangenberger) WAIS (Peter Wayner) RISKS 15.76 18 April 1994 "Friendly Fire" --- U.S. F-15s take out U.S. Black Hawks (PGN) The Green-Card Flap Data-storage technique provides copy protection (Meine van der Meulen) Yet another example of software modification risks (Jim Dukelow) Re: Risks ... to the quality of science [randomness] (Steen Hansen) MIT student arrested for BBS used for pirate software (Fredrick B. Cohen) Credit-Card Fraud (Greg Philmon) NII and the US Card (Bill Murray) Reckless Baby Bell Marketing (Alan Miller) Re: P.R. China Computer Security Rules (Tom Albertson, Dan Sorenson) Delayed Dial Tone causes unintentional 911 calls (Chonoles Michael Jesse) Seeking lit ref: we trust calculators over ourselves (Mike Crawford) Information resource (Michael Enlow) RISKS 15.77 19 April 1994 Risks ... to the quality of science: Clifford Truesdell (Michael Tobis) Dial-in Electric Meter Readings Sans Safeguards (Scott Rose) Stun belts -- who has the remote? (Jak Kirman) Risks of Data Compression (Joe Decker) TV Guide Contest (Agris Taurins) Re: MIT student arrest (Dwight Silverman, Sidney Markowitz) Re: Green-Card Flap [Risks, Lawyers] (Ed Clarke) "Naissance d'un virus" by Ludwig/Condat (Rob Slade) IFIP SEC '94 Program (Willis H. Ware) RISKS 15.78 22 April 1994 Computerized Traffic-Light Problems (Debora Weber-Wulff) Risks of winning (Stanley Chow) Computer Generates False Tsunami Warning in Japan (George Pajari) NYC subway fare cards double-deduct; UI at fault (Andrew Marc Greene) A consumer risk from Thomson Consumer Electronics Re: we trust calculators over ourselves (John Powell) Re: Risks ... to the quality of science (A. Padgett Peterson) Re: Risks of Data Compression (John Kennedy) Re: Math and money laundering (Erann Gat, Peter Wayner) Re: Information resource (Edward Reid) Re: Green Card Posting (Caveh Jalali, Ned Kittlitz, Mark Brader) RISKS 15.79 26 April 1994 Fax programming -- risk to politicians (Tom Keenan) Data Escape from Prison (Mich Kabay) Industrial espionage (Mich Kabay) Trojan @ U. Michigan (Mich Kabay) $14 million QA failure (Mich Kabay) Security and Privacy panels (John Rushby) Strange Stalking (Flint Waters) UK Industrial Spy Law (Peter Sommer) Combination Locks I Have Known (Neil McKellar) Unusual Newspaper Error (Stewart Rowe) Risks of advertising on the net (Jerry Leichter) Updated addresses for Canter & Siegel (Paul Robinson) Re: MIT student arrested for BBS used ... (Tim Shepard, Douglas Rand) Re: NYC subway fare cards double-deduct (Mark Brader, Dan Lanciani, Padgett Peterson) RISKS 15.80 28 April 1994 DMV Computer upgrade goes awry... (Marshall Clow) Time-series wins jackpot (Mich Kabay) Drunk in charge..... (Kearton Rees) Stress Analysis of a Software Project [long] (Tom Davis via Jerry Leichter) RISKS 15.81 29 April 1994 Boot Prom commits Denial of Service Attack (Dave Wortman) Cyrix 486 CPU Bug (Dave Methvin) Call Identifier (tm) forgets list of received calls (Robert Chesler) Re: Unwanted FAX received via voicemail (Declan A. Rieb) Re: Stress Analysis of a Software Project (Tom Davis via Joan Eslinger, A. Padgett Peterson) Inspecting Critical Software (David Parnas via Jan Arsenault) ------------------------------ End of RISKS-FORUM Digest 15.82 ************************