Subject: RISKS DIGEST 17.95 RISKS-LIST: Risks-Forum Digest Monday 1 April 1996 Volume 17 : Issue 95 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** A note on E-mail, e-mail, and email (Peter G. Neumann) The Queen's Speech (Lindsay F. Marshall) Argentine Hacker (David Kennedy) The story of jjq (Jean-Jacques Quisquater) Sony TV remote controls affect Apple Performa 6300 (Daniel P.B. Smith) Computer-generated will rejected by court (George Richmond) Customer Billing Software Failure Leads to Firm's Demise (PGN) Wrong approach to Java security (Jacob Palme) Comments on subscriptions, uncertainty (D.J. Bernstein) Re: An uncertainty principle for risks (Richard Cook) Re: On-line vote-taker overwhelmed (Allan Noordvyk) ABRIDGED info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, 1 Apr 1996 12:00:00 PST From: Neumann@CSL.sri.com (Peter G. Neumann) Subject: A note on E-mail, e-mail, and email Considering the date, and considering that no genuine April Fools' piece has appeared yet, it seems appropriate to be quite serious about a seemingly frivolous subject that comes up repeatedly in RISKS, in one guise or another. I offer the following item, which may be reproduced freely, subject to the stated RISKS guidelines at the end of this issue. May Your April Fools' Day March Along Augustly. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++ The Hyphenater's Handbook (but *not* The Hyphen-Haters Handbook) ++ ++ Chapter excerpt, "e is for electronic" -- Peter G. Neumann, 1996 ++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Up until last year, I have used the term "E-mail" in RISKS to denote "electronic mail". I would like to be able to let the letter of an acronym reflect the upper- or lower-case appearance of the word or term it denotes (as in "DoD"), and to separate acronyms and text with a hyphen in hybrid representations (as in "e-mail"). However, lower-case acronyms that mimic natural linguistic expressions (such as "ram" and "pin") thereby become confusing, while upper-case acronyms beg for lower-case plurals to distinguish them from the final S as an acronym (as in HTTPs versus HTTPS). We also must live with multiple meanings (as in MAC, not to mention Mac, Macs, MACs, and MACS). Thus, there seems to be no easy algorithm that is also sensible. So great care is required in choosing risk-free acronyms. This note is a discourse on why the hyphen is desirable for disambiguation, although it is clearly anathema to hyphen-haters. Two representations are given -- one without hyphens ("NO-"), and one with hyphens ("YES-"). Some suggestive interpretations of the latter are included [with occasional retrointerpretations of the former in square brackets]. (I think I might simply have to go back to "E-mail" from now on!) NO- YES- Interpretation --------- ---------- -------------- eat e-at The "@" symbol [which causes many programs to choke] educe e-duce The tyrannical leader of a moderated e-mail newsgroup egad e-gad 1. An electronic crowbar used to disrupt systems; 2. To surf the net nonspecifically (to e-gad about); 3. A mild e-mail oath. egest e-gest An electronic adventure or exploit [well discharged] ego e-go To initiate or restart a program [especially if self-validating] egrep e-grep A command to search for a given string expression [note the ambiguity between grep and egrep] elan e-lan An electronic local-area network [*elan* suggests *dash*, not *hyphen*!] elan vital e-lan vital After Bergson, the vital force immanent in, or at least desirable in, local-area networks. elapse e-lapse An omission in an electronic communication elate e-late Relating to delayed electronic operations elater e-later Lazy evaluation, as in a c-u-e-later allocator [click-beetle used to cue next slide (very obscure)] election e-lection An altered electronic version of text [particularly for voting data] elicit e-licit Legal, as in a valid argument or nonrepudiatable message elite e-lite Optimized version -- e.g., a starkly compressed e-mail message, or a minimum-toehold process elocution e-locution Peculiar expression that results from use of spelling and grammar checkers email e-mail Electronic mail [Distinguishing itself from every other term on this list, the unhyphenated version has no natural meaning whatever, but spelling checkers might suggest Emile or Ismail.] emend e-mend To make a hex or binary patch emerge e-merge To combine different input streams emigrate e-migrate To move electrons externally emission e-mission Sometimes known as a C4I task emu e-mu Electronic microunit [found mainly in crossword puzzles] enfold e-n-fold Replicated *n* times electronically [SEE FOOTNOTE below] enucleate e-nucleate To cluster disparate data [or to remove the kernel!] enumerate e-numerate Someone who is literate about computer representations epact e-pact An agreement on programs for leap-year adjustments [Note: the epact is the excess of the solar year over the lunar year.] equality e-quality A property of a computer system or network equip e-quip Humor embedded in e-mail erector e-rector The head of a remote-access university escarp e-scarp The protected side of a firewall [This is a case in which the e is gratuitous, as in estop, enow, and the next example.] especial e-special An anomalous event of some particular interest estray e-stray Random electromagnetic interference estrange e-strange An anomalous output or internal state eta e-ta An abbreviated e-mail goodbye (ttfn) evaluate e-valuate To assess an electronic system event e-vent An air-conditioning duct for a computer system every e-very A technocomparative term evocation e-vocation Job of someone who works with computers evolute e-volute A system with a resilient spiral shell structure eyes e-yes ACK! or positive acknowledgment [the eyes have it] VIRTUAL REALITY TERMS: eastern e-astern The virtual view to the rear Eden E-den A virtual retreat [e.g., a paradise] edentate e-dentate Using a tooth-valued logic [toothless projective logics include and-eaters] elope e-lope A fast gait experienced in virtual reality emir e-mir A feeling of peacefulness, resulting from use of a Russian VR program [Eastern potentates like it] emotion e-motion Screen dither epic e-pic A digital image such as a .gif file [classical!] eryngo e-ryngo Electronic drummer [obscure: with aphroditic rhythms resulting in candid C-HOL-ly root privileges!] escape e-scape A virtual view [particularly, an elusion or avoidance] evert e-vert A background shade of green on video screens [particularly confusing while viewing tennis matches at Chrissie Field in San Francisco] eyewash e-yew-ash A logical grafting of two different tree structures ewig e-wig Computerized enhancement of a balding image [German: *ewig* = eternal] __________ FOOTNOTE on e-n-fold: Prefixing *n* as an index clearly needs a hyphen, as the following examples illustrate: nacre n-acre An n-acre oyster bed [whose mother was Pearl?] nark n-ark An n-ark fleet of drug-enforcement agents narrow n-arrow An n-arrow quiver [narrow with n=1] nascent n-ascent An n-ascent astronaut [nascent only if n=0] near n-ear An n-ear audience; n need not be an even integer; someone could be listening with half an ear. neon n-eon Referring to multiple eons [a glowing sign of the times] Using other symbols as indices also suggests further examples, such as an i-rate mortgage lender or an i-deal N-antes French card game. Other cases are left as an exercise for the reader. PGN ------------------------------ Date: Mon, 1 Apr 1996 09:07:35 +0100 (BST) From: "Lindsay F. Marshall" Subject: The Queen's Speech I heard a news report on the wireless saying that Queen Elizabeth did not deliver the intended speech to the Polish parliament, because of a "computer error". Apparently the queen was supposed to include a sentence referring to Polish Jews in the 2nd World War. She didn't. The official explanation was "computer error" -- but I also heard it described as a "typographical error". There have been lots of little articles about it, but no more detail of what went wrong. http://catless.ncl.ac.uk/Lindsay [Phonetically, the Subject line sounds like The Queen's Peach. The verb "to peach" suggests verbal entanglement. I hope Lindsay will be able to give us a computer-related plum on this topic, and not s-pear us any details. PGN ------------------------------ Date: 01 Apr 96 02:02:50 EST From: David Kennedy <76702.3557@compuserve.com> Subject: Argentine Hacker U.S. uses first computer system wiretap UPI Financial 29/3/96 13:27 By MICHAEL KIRKLAND >> WASHINGTON, March 29 (UPI) -- U.S. officials used an unprecedented court-ordered wiretap of a computer network to charge a young Argentine man with breaking into Harvard, U.S. Navy and NASA computers, the Justice Department said Friday. At a news conference at the Justice Department, U.S. Attorney Donald Stern of Boston called the operation "cybersleuthing." << o Other systems penetrated, Univ Mass, Cal Tech, Northeastern and systems in Mexico, Korea, Taiwan, Brazil and Chile. >> "The search procedure was specifically designed to let another computer do the complex searches in a way that provided privacy protection for the innocent users of the network," Reno said. << o The investigators used a program called I-Watch for Intruder Watch run on a government computer located at Harvard. The program searched the net for the targeted criminal among 16,000 university users. [DMK: A search for info on this program revealed I-watch may be a product from Ipswitch, Inc. of Lexington MA.] >> I-Watch was able to "identify certain names that were unique to the intruder," Heymann said, as well as locations and accounts -- his "computer habits." Because the search was conducted by I-Watch, the communications of the legitimate users were never seen by human eyes. I-Watch was left undisturbed in its work through November and December until it had narrowed down the thousands of possibilities to one unauthorized computer cracker, Julio Cesar Ardita, 21, of Buenos Aires, officials said. << o Ardita's home was raided on 28 Dec and his PC and modem seized. He remains free because the charges against him are not among those when the US-Argentina extradition treaty applies. o Charged with: "possession of unauthorized devices" (illegal use of passwords), (18 USC 1029) unlawful interception of electronic communications (18 USC 2511) and "destructive activity in connection with computers." (18 USC 1030) [DMK: citations mine, not UPI's] >> The information he accessed is considered "confidential," Stern said, but "did not include national security information." <<[DMK: "C2 in 92!"] >> Ardita's alleged cracking was first detected last August when the Naval Command Control and Ocean Surveillance Center in San Diego detected a computer intruder, officials said. << ... >> The Naval Criminal Investigative Service did an analysis of the intruder's "computer habits," including signature programs used to intercept passwords. << ... >> Eventually, an intruder who called himself "griton" -- Spanish for "screamer" -- was detected using four computer systems in Bueons Aires to crack the Harvard computer, and the illegal accessing of the other sites was discovered. << Dave Kennedy [US Army MP][CISSP] Volunteer SysOp Natl. Computer Security Assoc Forum on Compuserve ------------------------------ Date: Fri, 29 Mar 1996 00:57:37 +0100 (MET) From: Jean-Jacques Quisquater Subject: The story of jjq During May 1991, I received a lot of e-mails sent to me but whose content was not for me. It was coming from Langley (I'm saying no more to protect the players). Some messages were really personal. At that time I was busy (my lab was closed at the end of June) and I didn't do anything at the beginning. After several days I sent an answer to these messages and the answer came back to me! I sent a message to the postmaster: no answer. And many messages were related to very interesting internal seminars and other information related to no-more-paper-in the-printer, also. At the end of the month, I received a complete list of e-mails at that mysterious location and I understood. I sent an e-mail to the system manager and the messages stopped without any explanation (big bug for big brother). The explanation: three years ago a friend of me was able to work there, and sending e-mails was a pain for him. My friend obtained an alias to be able to send e-mail more easily to me. And the alias was jjq for a difficult address with many !%@'s. It was in use for six months. The alias was never removed, and when Jamesa J Quark (not the correct name) was working for the curious location, they used an account for him with jjq and all the e-mails were sent to me. It is incredible that it was always working: many paths and names were changed, but it was very robust. Jean-Jacques Quisquater (jjq) ------------------------------ Date: Tue, 26 Mar 1996 16:57:08 -0500 (EST) From: "Daniel P.B. Smith" Subject: Sony TV remote controls affect Apple Performa 6300 George Bigham posted this item to SEMPER.FI (a mailing list for Mac developers) and has given me permission to pass it on to RISKS. "Hold onto your hats, Mac Technonerds! 1) Larry and Tracey came into the Mac Department today...saying that their Sony TV Remote Control turns their new Performa 6300 on and off. The Performa was purchased [here] last Thursday. 2) Also they reported that the sound on the Performa turned off on them inexplicably last week, and now the menu bar blinks instead. 3) I asked them how far away from the store they lived, and could they bring the remote and CPU in (service department is open on Sundays). They did that. 4) Their Sony remote turned on and off every Performa in the store, not just their own! 5) Also, the "Mute" button on the remote clicked an "X" in the "Mute" box 6) Store tech. guy says Infrared is not tunable, and disconnecting it would also turn off the headphones and the volume control. He taped over the infrared port and is contacting Apple for further instructions. 7) The Sony TV Remote Control unit is Model # RM-V21. It only powers the Performa on and off when set to the "TV" channel. But it mutes the Performa on "TV," CBL," and "VCR." Other channels are "AV1" and "AV2." Of course YMMV (Your Mileage May Vary). George Bigham P.S. If this info were generally known, think of the havoc that could be played out in a lab of Performas by some miscreant with one of these remote devices! Lots of unsaved ClarisWorks files would get lost, to say the least." Daniel P. B. Smith dpbsmith@world.std.com [Also reported by jrward@world.std.com (Jean Renard Ward). PGN] ------------------------------ Date: Sat, 30 Mar 1996 10:53:40 -0500 From: grichmon@localnet.com (George Richmond) Subject: Computer-generated will rejected by court Page 1 of the *Buffalo News* of 28 Mar 1996 reports a case that shows what bad things can happen when a computer program pretends to substitute for legal knowledge. A man using a borrowed program (make unspecified, price stated to be $9.95) wrote a will leaving most of his estate to a favorite sister, and token amounts to a brother and several other sisters and nephews. He printed out the will, signed it and sent it to the favorite. She saw the blank lines for witnesses, and signed her own name, and then had her husband and son sign. The man subsequently died. Erie County Surrogates Court of course rejected the will on two grounds: will must be signed in presence of witnesses and witness may not inherit. Now the estate will be divided among those the testator sought to disinherit. There is no way to know if the program contained instructions about signing and witnessing, or if the testator failed to notice them. George Richmond 183 Wedgewood Drive Williamsville, NY 14221-1466 grichmon@localnet.com (716) 689-6362 ------------------------------ Date: Thu, 28 Mar 96 16:50 xxt From: Neumann@CSL.sri.com (Peter G. Neumann) Subject: Customer Billing Software Failure Leads to Firm's Demise In the April issue of "TVRO Dealer" (a satellite TV trade publication) is an article detailing how an attempt by a large satellite-TV programming service to switch to a new software billing system ultimately led to the demise of the firm. It makes for interesting reading. ------------------------------ Date: Wed, 27 Mar 1996 13:55:39 +0100 (MET) From: Jacob Palme Subject: Wrong approach to Java security The discussions around Java security seems mainly to be how to design security features to make it technically impossible to use Java to distribute viruses and other disruptive software. Is this really the right approach. Java becomes more and more crippled and useless the more of these security features are added, and the wrong-doers will probably still find new ways of cheating the security. In the area of public domain software, security is handled in a different way: By storing the software in large well-kept depositories, in which any virus-containing or otherwise malicious software is rapidly removed. Thus, the risk of viruses is very small, even though I have downloaded hundreds of public domain programs, I have never been infected with a virus that way! The main way in which public domain software becomes safe is because vigilant users rapidly note and warn about viruses, so that if a virus-infested program appears, it can be removed within usually less than a day. Thus, if you choose to download software which has been stored more than one or two days, you are usually safe. PICS might be the best way to get a similar function on the web. PICS, like public-domain software repositories, can be used to mark (with PICS) or remove (with software repositories) the malicious items. And the main advantage with this is that Java can be used to develop much more useful functions than with the present crippling Java security measures. ------------------------------ Date: 28 Mar 1996 05:49:55 -0000 From: djb@koobera.math.uic.edu (D.J. Bernstein) Subject: Comments on subscriptions, uncertainty 1. There is a pleasant alternative to three-way subscription handshakes: any address that ends with /yourlistnickname should be allowed to freely subscribe to your mailing list. For example, under various mailers, I could set up djb-in/risks, or djb+boxes/risks, or djb=whatever/risks. 2. Any message that causes a mailing list subscription or unsubscription should be forwarded to the subscription address. The manager need not keep a central log. 3. It is easy to eliminate the race condition in Dick Mills's car radio display: instead of one button that toggles between time and frequency, the radio should have one button that switches to time and one button that switches to frequency. Toggles are bad. Idempotence is good. (And inaction should never be the only way to obtain the default.) ---Dan [Incidentally, the U.S. Postal Service has long had a seriously flawed policy on changes of address -- forwarding mail for up to a year without notifying the original address that an address request has been made. Bogus requests thus sail through undetected, which is not particularly noticeable to you if you happen to be travelling. The future automated postal system is expected to take care of this by notifying both the old address and the new address of the change, thus providing a little security in redundancy, but still not enough if you are travelling. In the present system, you might try to talk your postmaster into denying all change requests unless made in person by YOU (at least if you live in a small town with friendly employees!). Good luck. And don't try this at home. It is most likely a felony. PGN ------------------------------ Date: Tue, 26 Mar 1996 11:20:22 -0600 From: ri-cook@uchicago.edu (Richard Cook) Subject: Re: An uncertainty principle for risks (RISKS-17.94) Dick Mills wrote recently regarding a digital car radio: >I tried to think of a way to redesign the toggle and automatic functions to >be infallible. I couldn't. This made me despair. If we can't make such a >mundane device behave perfectly, what can we achieve? He then goes on to propose a rule: >Any object, capable of any behavior, is capable of unexpected behavior. >Disregard of this simple principle is the root cause of all other risks. >It could be an alternative way to define the *meaning* of the word risk. I disagree. The behavior was expected by the designer and intentionally included in the design. The failure here is not a narrow one of incorrectly setting the timing of automatic mode shifts that change the meaning of a button push. This device's behavior should not be inductively expanded to encompass all artifacts from pocket knives to spreadsheets. Failure to produce reliable,robust design should not be equated with some immutable characteristic of the universe, nor should bad design be regarded as an unfortunate but unavoidable consequence of technology. To take such a position is to embrace nihilism. The behavior Dick is describing is the _predictable_ result of an _active_, _deliberate_ design tradeoff on the economic dimensions (in a broad sense) of display and control design. The incorporation of two different devices (clock and radio) in a single device, the use of a single display element to show the operation of either device, the use of a single control (the push button) to perform multiple functions (switching between display of the clock and the display of the currently selected frequency channel...and also probably the setting of the frequency channel) is result of a decision to tradeoff complexity of operation for savings in cost of display, visibility of display elements, cost of control, and the size and accessibility of control surfaces. This is the sort of thing Don Norman describes in "The Design of Everyday Things". In prior generation systems (which I have described elsewhere as _systeme verite'_ and _systeme abstraction_) these problems did not occur. The ability to use a single control for multiple functions and to use a single display element for multiple annunciations is characteristic of the current (_systeme ordinateur_) world where microprocessors are interposed between the control/display surfaces and the underlying process or system. In _verite'_ systems, where there were only mechanical components, and in _abstraction_ systems, where there were electromechanical components but the one-to-one mapping between control and display is fixed and static, these effects did not occur. The shift to microprocessor based systems removed the externally imposed constraints on design that previously limited designers to producing systems whose functional capability was constantly shown to the user as a fixed display/control space. The dimensions (in an information sense) and availability of controls and displays in these systems remained unchanged with time. This did not prevent misuse of these sorts of systems but it did prevent the sorts of phenomena that Dick describes. [We described an case similar to the one Dick wrote about in the operation of an intravenous infusion controller where a single switch performed multiple functions and produced mode errors.] In _ordinateur_ systems, the fixed relationships are not externally imposed and so designers are free to use a single control for multiple functions and a single display for multiple annunciations. What constrains them is their ability to see how the tradeoffs they make in design will impact the user and to appreciate the ways in which these tradeoffs will have unintended (but, in principle foreseeable!) consequences. The issue, I think, is that the development of _ordinateur_ systems relaxes the externally imposed constraints on design and requires a form of design discipline in order to avoid exactly the problem that Dick raises. The risk is not that devices behave erratically or capriciously -- they do not -- rather the risk is that our expanded ability to manipulate control and display surfaces will not be matched by a thoughtful, inclusive, explicit design discipline of equal sophistication. The fault, to paraphrase WS, lies not in our artifacts but in our design tradeoffs. Richard I. Cook, MD ............. Cognitive Technologies Laboratory Department of Anesthesia and Critical Care ** University of Chicago ------------------------------ Date: Tue, 26 Mar 96 09:38:52 -0800 From: Allan Noordvyk Subject: On-line vote-taker overwhelmed I recently attempted to vote on the formation of a controversial newsgroup (identity withheld to prevent RISKS becoming embroiled in an irrelevant to-it issue) by sending e-mail in the usual CFV manner, and received the following e-mail bounce in reply: ----- The following addresses had delivery problems ----- (unrecoverable error) ----- Transcript of session follows ----- procmail: Quota exceeded while writing "/usr/spool/mail/voting" 550 ... Can't create output: Error 0 Obviously the votes are being collected faster than the tally program (or human) can count and empty them from the mail box file and, as a result, the user's disk space quota has been exceeded. (I've alerted the site's postmaster). I expect this heavy voter participation has to do with strong appeals for votes from proponents on both sides of the debates through newsletters, person-to-person e-mail, and other channels. Then again, maybe someone on one side or the other just mail-bombed the address. The risks? - My vote and probably many others didn't get counted. - Will one side or the other repudiate the vote because of this? - Did the neutral, volunteer, vote-taker know what he or she was getting it to? - Did he or she warn the post-master (probably - since an e-mail alias or new account would have to be set up)? - Will sites be reluctant to host controversial votes in the future? Allan Noordvyk, Software Artisan, ALI Technologies Richmond, Canada 604.279.5422 x 317 allan@ali.bc.ca Fax: 604.279.5468 ------------------------------ Date: 18 March 1996 (LAST-MODIFIED) From: RISKS-request@csl.sri.com Subject: ABRIDGED info on RISKS (comp.risks) The RISKS Forum is a moderated digest. Its USENET equivalent is comp.risks. SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on your system, if possible and convenient for you. BITNET folks may use a LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS. [...] DIRECT REQUESTS to (majordomo) with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] INFO [for unabridged version of RISKS information] 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, nonrepetitious, and without caveats on distribution. Diversity is welcome, but not personal attacks. [...] ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Particularly relevant contributions may be adapted for the RISKS sections of issues of ACM SIGSOFT Software Engineering Notes or SIGSAC Review. * Submissions: By submitting an item that is accepted for publication in RISKS, the author grants permission for unlimited public distribution and redistribution in electronic or other form. * Reuse: Blanket permission is hereby granted for reuse of all materials in RISKS, under the following conditions. All redistributed items must include the Risks-Forum masthead line. All reuse must be accompanied by the following statement: Reused without explicit authorization under blanket permission granted for all Risks-Forum Digest materials. The author(s), the RISKS moderator, and the ACM have no connection with this reuse. As a courtesy, reusers of individual items (as opposed to forwardings of entire issues) should notify the authors, and should pay particular attention to any subsequent corrections. RISKS ARCHIVES: "ftp ftp.sri.comlogin anonymous[YourNetAddress] cd risks or cwd risks, depending on your particular FTP. [...] [Back issues are in the subdirectory corresponding to the volume number.] Individual issues can be accessed using a URL of the form http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue] ftp://ftp.sri.com/risks The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS PRIVACY: For info on the PRIVACY Forum Digest and Computer PRIVACY Digest, see the unabridged INFO file at RISKS-Request (send one-line message INFO to risks-request@CSL.sri.com as noted above). ------------------------------ End of RISKS-FORUM Digest 17.95 ************************