The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 17 Issue 95

Monday 1 April 1996


o A note on E-mail, e-mail, and email
Peter G. Neumann
o The Queen's Speech
Lindsay F. Marshall
o Argentine Hacker
David Kennedy
o The story of jjq
Jean-Jacques Quisquater
o Sony TV remote controls affect Apple Performa 6300
Daniel P.B. Smith
o Computer-generated will rejected by court
George Richmond
o Customer Billing Software Failure Leads to Firm's Demise
o Wrong approach to Java security
Jacob Palme
o Comments on subscriptions, uncertainty
D.J. Bernstein
o Re: An uncertainty principle for risks
Richard Cook
o Re: On-line vote-taker overwhelmed
Allan Noordvyk
o Info on RISKS (comp.risks)

A note on E-mail, e-mail, and email

Peter G. Neumann <>
Mon, 1 Apr 1996 12:00:00 PST
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]

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

The Queen's Speech

"Lindsay F. Marshall" <>
Mon, 1 Apr 1996 09:07:35 +0100 (BST)
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.

[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

Argentine Hacker

David Kennedy <>
01 Apr 96 02:02:50 EST
U.S. uses first computer system wiretap
UPI Financial  29/3/96 13:27

<>    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

The story of jjq

Jean-Jacques Quisquater <>
Fri, 29 Mar 1996 00:57:37 +0100 (MET)
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)

Sony TV remote controls affect Apple Performa 6300

"Daniel P.B. Smith" <>
Tue, 26 Mar 1996 16:57:08 -0500 (EST)
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

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

[Also reported by (Jean Renard Ward).  PGN]

Computer-generated will rejected by court

George Richmond <>
Sat, 30 Mar 1996 10:53:40 -0500
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  (716) 689-6362

Customer Billing Software Failure Leads to Firm's Demise

Peter G. Neumann <>
Thu, 28 Mar 96 16:50 xxt
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.

Wrong approach to Java security

Jacob Palme <>
Wed, 27 Mar 1996 13:55:39 +0100 (MET)
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.

Comments on subscriptions, uncertainty

D.J. Bernstein <>
28 Mar 1996 05:49:55 -0000
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.)


[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

Re: An uncertainty principle for risks (RISKS-17.94)

Richard Cook <>
Tue, 26 Mar 1996 11:20:22 -0600
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

On-line vote-taker overwhelmed

Allan Noordvyk <>
Tue, 26 Mar 96 09:38:52 -0800
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

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

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  Fax: 604.279.5468

Please report problems with the web pages to the maintainer