The RISKS Digest
Volume 18 Issue 68

Monday, 16th December 1996

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…


California tax-form attacks: a new tax on businesses
Communications errors delay response to San Francisco fire
Brian Slesinsky
Power surges in Third World countries
Frank Conlon via Don Wagner
Re: repetitive strain injury suit
Joshua Goodman
November, 1996 CACM article on InfoWar Defense - highly critical
Fred Cohen
You can't rewrite history in Internet Explorer 3
Tim Nott
*Java Security* by Gary McGraw and Edward W. Felten
When is an upgrade not an upgrade?
Ian Barker
Beware of Year2000 Sharks: A Story for Non-Believers
Re: .pdf files, RISKS of using Adobe Acrobat Reader
Kenneth Albanowski
Gene Wirchenko
Re: Combatting cookies
Hal Lewis
Frank Stuart
Pete Kaiser
Women into Computing Conference 1997, last call for papers
Richard Nealon
Privacy Digests
Info on RISKS (comp.risks)

California tax-form attacks: a new tax on businesses

"Peter G. Neumann" <>
Mon, 16 Dec 96 8:50:42 PST
A California Franchise Tax Board computer apparently went berserk, resulting
in thousands of extra copies of 1996 tax forms being sent to California
businesses — including a San Diego dentist who reportedly received about
16,000 copies of the 1996 forms.  [Source: An AP item in the *San Francisco
Chronicle*, 14 Dec 1996, A16.]

Communications errors delay response to San Francisco fire

Brian Slesinsky <>
Sat, 14 Dec 1996 17:22:19 -0800
>From Saturday's San Francisco Chronicle (Dec 14, page A20, also available

San Francisco fire officials acknowledged yesterday that communications
errors delayed the arrival of vital equipment at last month's huge fire at
Pier 48 — the second time this year that the department has had problems
getting firefighters to major blazes."  [...]  According to [Deputy Chief]
Gamble, a dispatcher — alerted to the waterfront fire at 2:48 p.m. --
initially sent only four pieces of equipment by computerized message when he
should have sent seven. Gamble said the dispatcher mistakenly entered into
the computer that the alarm had come from a street box, triggering a
relatively minimal first response.  The second error occurred when the first
units at the scene immediately called for help. At that point, Gamble said,
the dispatcher told the computer to send the next wave — only to discover
six minutes later that the units never got the message.  Gamble explained
that because the dispatcher gave the computer the wrong message on the first
alarm, the computer wouldn't accept the second."  [...]

  The RISK seems to be a user interface that makes it too easy to make
  mistakes entering data, and "business rules" that assume that whatever was
  previously entered into the computer is correct.
Brian Slesinsky

Power surges in Third World countries

D B Wagner <>
Sat, 14 Dec 1996 06:13:14 -0500
Don Wagner, Reverdilsgade 3,, DK-1701 Copenhagen V DENMARK
  [Don sent in another item too, but this one seemed appropriate here.  PGN]

>--------------- Forwarded Message ---------------

From:   Frank Conlon,
To:     D B Wagner, 106026,3213
Date:   Fri, Dec 13, 1996, 2:31

RE:     H-ASIA: Using laptop in the PRC

Date:         Thu, 12 Dec 1996 17:14:10 -0800
Reply-To: Frank Conlon <>
Sender: H-Net list for Asian History and Culture <>
From: Frank Conlon <>
Subject:      H-ASIA: Using laptop in the PRC
To: Multiple recipients of list H-ASIA <>

                   H-ASIA, December 12, 1996

Response to query on laptop usage in PRC from a non-Sinologist

>From Frank Conlon <>

With reference to Susan Blum's query, I cannot say anything at all about the
PRC, but will mention the strategy I followed whilst in India in 1990-91
using a laptop.

It may be too late or to unwieldy to use my approach, but what I did was buy
several extra storage batteries and a charger.  Except in Bombay city which
had a relatively stable power system, I never, that is NEVER, plugged my
computer directly into an electric source.  During my previous visit we had
purchased a top of the line, industrial strength surge protector made in the
U.S.A.  It lasted 6 days before the Delhi Electric Supply Undertaking sent a
spike through the line and blew the little hummer into the next world, if
there is a next world for surge protectors and transformers.

Instead, in 1990-91, since I had a computer that used batteries which could
be replaced and charged in a separate charging device, I just kept cycling
batteries through the charger and replacing them as needed.  Because I was
going to be there for almost a year, I purchased a substantial surge
protector in India--the sort folks there buy for their televisions and
refrigerators there.  Being manufactured in India meant that they were
engineered with a realistic grasp of the vagaries of most Indian power
supplies.  As the power surges came it buzzed and spat, but the battery
charger blissfully escaped unscathed.

Now if you are travelling around a lot, that might be inconvenient, and
perhaps such devices are not readily and cheaply available in China, but my
computer and data reached home safely, and the surge protector made a
handsome gift to one of the many folks who had done favors for me during my

Bon voyage, bon chance.

Frank Conlon, University of Washington

Re: repetitive strain injury suit (PGN, RISKS-18.68)

Joshua Goodman <>
Fri, 13 Dec 1996 20:23:40 -0500
Repetitive Strain Injuries are a very common risk from computing; they can
easily lead to disabling injuries.  The fact that these people sustained
million dollar injuries give you an idea of how bad it can be...  However,
RSIs can be avoided with proper typing technique, ergonomics, stretching,
etc.  For instance, simpler than installing foot-pedals is to train oneself
to hit ctrl, shift, etc. with the index finger of the opposite hand.  For
tips about typing technique, and other information about RSIs, see, which is pretty good (OK, as the author I'm
biased) although a bit Harvard specific.  Another good page (OK, maybe
better) is

November, 1996 CACM article on InfoWar Defense - highly critical

Mon, 16 Dec 1996 09:42:54 -0800 (PST)
***** FLAME ON *****

Dateline: Livermore - Dec. 16 9:02AM


Yes, Neil Munroe aimed right, but as usual, he missed the Info-Warfare target.

He correctly identifies the problem - disruption (a.k.a., corruption and
denial of services) - but he misses the target by talking about privacy,
privacy, and more privacy.

The phone system could be brought down... but we have to protect privacy
The power grid could go down... but we have to protect privacy
Planes could crash... but we have to protect privacy

Questions: Suppose we had absolute and perfect privacy but still had the
current inadequate level of information assurance.

    Could the phone system still be brought down? Yes
    Could the power grid still be brought down? Yes
    Could air traffic still be brought down? Yes
    Does privacy protection solve the information assurance problem? NO!

Question: Suppose we had absolute and perfect information assurance.

    Could we still have perfect privacy? Probably

So what is the relevance of the "... but we have to protect privacy" when
the issue is not privacy but assurance (integrity and availability)?

If we aim at information assurance and we keep hitting privacy, we will
never achieve our goal.

The target is NOT privacy!
This issue is NOT ABOUT PRIVACY!!

The right target is integrity and availability - a.k.a. information assurance.

How many times have I heard this misdirection? Hundreds at least. What's the
cause?  I don't know.

    It could be that people think of computers as infallible and that
    for that reason integrity and availability cannot be of concern.

    It could be that people just don't understand.

    It could be that the media attention and publicity is all aimed
    at privacy. I've even seen media stories of computer viruses causing
    computer crashes and heard the media people comment on how privacy
    problems have to be addressed in order to solve this.

Get a clue!

How come the editors at the ACM couldn't figure this one out and tell the
author to hit the right target?

    They must not have a clue!

How come the author calls the privacy advocates to find out about
information assurance?

    He must not have a clue!

How come the FBI seems to think they need to tap phones to protect NII

    They certainly don't have a clue!

How come the president puts people without a clue in charge?

    The president doesn't have a clue either!

As clueless Louis once said:
    "If you want to make sure your phone works,
        make sure your number isn't in the yellow pages."

***** FLAME OFF *****

This article was sponsored by the "get a clue" foundation:
 - people with clue trying to get it to you.

[Extensive disclaimers omitted.]

Fred Cohen can be reached at tel:510-294-2087 fax:510-294-1225

You can't rewrite history in Internet Explorer 3

Tim Nott <>
Mon, 16 Dec 96 14:02 GMT0
Microsoft Internet Explorer 3 for Windows 95 maintains two special
folders. One, the 'Temporary Internet Files' folder, actually contains four
MS-DOS directories, used to cache HTML documents, GIFs, JPEGs and other
files downloaded from the Web. The other is the 'History' folder, which does
a similar caching task, but for URLs. Although each URL appears as a
separate entity in the folder they are actually stored in two .DAT files.

Clearing the History folder removes the entries visible in the Explorer
folder, but does not delete, or reinitialise the DAT files. These are still
visible using File Manager, and can be opened with a text editor to show all
the 'deleted' URLs. The files cannot be deleted by normal means including
first resetting attributes) from within File Manager or Explorer.
Presumably they are overwriten 'as needed' by new URLs.  Risks? We know
where you've been today...

Tim Nott  Figeac  France

*Java Security* by Gary McGraw and Edward W. Felten

"Peter G. Neumann" <>
Mon, 16 Dec 96 13:44:57 PST
Gary McGraw and Edward W. Felten
Java Security: Hostile Applets, Holes, and Antidotes --
  What Every Netscape and Internet Explorer User Needs to Know
John Wiley & Sons, New York, New York, 1997
ISBN 0-471-17842-X

This book is mandatory reading for every user and developer of Webware.
It considerably extends what readers of RISKS have already learned,
and puts the entire topic into a coherent and readily accessible form.

When is an upgrade not an upgrade?

Ian Barker <>
Mon, 16 Dec 1996 10:22:08 GMT
A few days ago a non-technical neighbour of mine asked me to pop over and
check out the new Pentium PC she had bought for her family and herself.  She
is not particularly familiar with computers and this was her first PC.  Her
main concern was that the computer dealer was going to "come back in a few
days" to upgrade the Pentium Chip from a 133Mhz to 166Mhz and she wanted to
make sure she wasn't wasting her time installing any new software if the
upgrade was going to trash her hard disk.

The new machine was running Microsoft Windows '95 and the dealer had
helpfully renamed the "My Computer" icon on the desktop to say "Pentium 133"
- presumably as part of their standard installation process.  Fair enough.

My neighbour told me the dealer had told her that the machine was "running
at 95 percent full power" and that he would return in a few days to "switch
it to 166Mhz".  She *knew* it had 16MB of memory because the machine counted
it as part of the boot-up process when the machine is switched on.

When the dealer's technical guy arrived (1 week later) he didn't have any
parts or boards with him and he proceeded to rename the "My Computer" icon
from "Pentium 133" to "Pentium 166".  He fiddled around with the CD ROM (my
neighbour had asked him to fix an unhealthy vibration).  I hadn't told the
technical guy that I was computer literate (I have my own software company)
and he - wrongly - assumed that my neighbour's lack of knowledge was typical
of all in the house.

The dealer's employee completed his inspection of the CD ROM and put on his
coat ready to go.  My neighbour's inquiries of "Is the PC running OK now?"
were answered with assurances that all the work was completed and he was
ready to leave - all this without once opening the PC case.

One assumes that either the dealer has been charging customers for Pentium
166 chipped PCs and installing the cheaper processors or the dealer's
employee has been up to no good himself.  Either way, my neighbour would
have been no wiser - as far as she would have been able to tell the upgrade
had been carried out as agreed.  Technology is so advanced in her opinion
that she thought it possible to upgrade the PC merely by sitting at the
keyboard and typing.  The processor inside the machine was actually a true
Intel Pentium 133 (I checked!) but it could have been a Pentium 90, Cyrix or
indeed just about anything else and a non-technical user would have had very
little obvious way of checking.

The risks?

Just because a PC says it has a Pentium 133 inside it doesn't actually mean
that it has.  Just because someone says with authority that everything is as
it should be it doesn't actually mean that it is.  And always get a second
opinion if you are about to spend a lot of money on something you don't
really understand.

Needless to say my neighbour (and her rather large and incensed husband)
took the PC back to the dealer and demanded her money back (which was
finally paid by cheque even though she paid cash).

Ian Barker

Beware of Year2000 Sharks: A Story for Non-Believers

Year2000InfoNet <>
Sat, 14 Dec 1996 07:32:01 -0500

I offer the following story as a different slant on the effect Year2000 may
have on companies.  The Year2000 Shark may be after your customers too...

I was sitting in the waiting room of a tire-repair shop.  The room was
dingy, and the owner/manager behind the counter was covered in tire carbon
from head to foot.  Into this scene walked a well-dressed arrogant-looking
fellow with a meek assistant.  He walked up to the counter and assertively
asked the manager if he knew whether his credit-card authorization system
was Year2000-compliant. Needless to say, the manager was clueless.

The salesman offered to test the store's CC unit with a test card.  No
sooner had the manager given the slightest nod of agreement, the salesman
was swiping his card through the unit and pointing triumphantly at the
message that popped up saying the card was invalid.  "This card," he said,
"has an expiration date of January 30, 2000.  This system is not
Year2000-compliant.  May I ask where you got this system and how much you
paid for it..."

That manager was helplessly snowed by the circumstances.  If there was some
way for him to require that salesman to legitimize himself (and his test
card), it didn't occur to him.  I thought about stepping in, but wanted to
see where things went first.  The manager succeeded in fending off the
salesman's push for an immediate sale, so I figured he'd be OK.

THE MORAL: Even companies who have dealt with the Year2000 problem
effectively need to ensure that their customers do not fall prey to such
sharks or wily competitors who may seize the opportunity caused by the lack
of information. I'm not a marketing person, but I imagine marketing staffs
around the business world will be "strategizing" on this very soon, if they
haven't already started...

The Year2000 Information Report thanks Jud Williford, Manager, Application
Architectures/Technology Architecture Planning, Information Technology
Division, Federal Express Corporation for submitting this article for
publication.  Jud can be reached at, Tel: (901) 922-2349,
Fax: (901) 397-4494.  This article appears in the latest issue of the
Year2000 Information Report.  (416) 650-9475

Re: .pdf files, RISKS of using Adobe Acrobat Reader (Ehrich, R-18.67)

Kenneth Albanowski <>
Fri, 13 Dec 1996 21:21:06 -0500 (EST)
[It is] even harder to read on monitors with 80x8 pixel resolution, or 2x8
pixel resolution (Braille readers) or without a monitor at all (Speech
synthesis). Not to mention simply difficult to read if your monitor doesn't
match the aspect ratio of the original page.

As far as I can see, the risks are monumental. From my viewpoint, a format
like HTML (which was designed to be accessible to everyone and every piece
of software) is far, _far_, superior to a system which hands you dressed up
photographs of each page in turn.

It may be simple for companies to produce .pdf documentation, but by doing
so they sharply curtail the usefulness of the information.

Kenneth Albanowski (, CIS: 70705,126)

Re: .pdf files, RISKS of using Adobe Acrobat Reader (Ehrich, R-18.67)

Gene Wirchenko <>
Sat, 14 Dec 1996 04:49:47 GMT
I'm sure glad I don't use a user-hostile system like a Mac.  Instead, I use
a user-hostile IBM compatible.  My fun has been with Microsoft Visual FoxPro

The Language Reference manual supposedly is a language reference manual, but
it isn't.  It has information on the syntax of the command, what the

Fortunately, that is available in the on-line documentation.  Needing a
language reference manual, you might want to print all of the on-line docs.
So you print it out.  (Cost?)  Then you find that the heading isn't printed.
With most of the commands, the syntax diagram just down from the top has the
item name, but with some retained for backward compatibility, they are only
documented with something like "This feature retained for backward
compatability.  Use 

Re: Combatting cookies (Schneier, RISKS-18.67)

hal lewis <>
Fri, 13 Dec 1996 19:51:01 -0800
I wish I knew why my solution---making the cookie file read-only---isn't
just as good.  Nobody ever writes to my cookie file, and nobody ever aborts
a transmission (to my knowledge) just because they can't write to my cookie
file. Am I missing something here?

Hal Lewis

  [Also proposed by
     Michael Schuerig <> and
     "Stirling Westrup" <sti@Hydro.CAM.ORG>.  PGN]

Re: Combatting cookies

Frank Stuart <>
Fri, 13 Dec 1996 23:14:33 -0600 (CST)
Making Netscape's cookies file a symbolic link to /dev/null is also an
effective way to disable cookies under UNIX.

Frank Stuart

  [Also proposed by
     Brian Clapper <> and
     Rik Faith <>.
  A much more elaborate scheme was proposed by
     Zygo Blaxell <>,
  replacing the set-cookie string with an equal-length random string.
     Carl Maniscalco <>
  suggested a freeware utility called "Cookie Monster".  PGN]

Re: Combatting cookies

Mon, 16 Dec 96 08:07:56 +0100
I also have "alert me" to cookies turned on in my Netscape browser, and last
Friday I brought up a page that attempted to set twenty-nine cookies.

Anyone who does this to me is running a risk: the risk that I won't return
to that page.

Incidentally, so far I've encountered nothing anywhere to make me permit a


Women into Computing Conference 1997, last call for papers

Richard Nealon <>
Mon, 16 Dec 1996 13:45:47 +0000

To be held at De Montfort University, Milton Keynes, UK.
10th July - 12th July 1997

*** PAPER SUBMISSIONS DUE 6 January 1997 ***


Computing and information technologies are now ubiquitous and of vital
importance in the global society.  Gender related issues in computing
continue to be critical in realising the potential of these technologies.
Computing as a discipline has a clear gender imbalance.  Recent figures show
recruitment of women into the discipline is continuing to decline.

To date, significant determinants of women's success in the computing field
have been explored primarily in terms of societal, cultural and
organisational work factors.  The perspective of women computer
technologists and engineers has often been overlooked.  Tensions between the
different groups exist but there has been insufficient dialogue between
these different groups to date.  This conference will address this situation
and provide an opportunity for a greater understanding between all those
working in and associated with computing.

Papers are invited within the broad area of Gender related computing
research.  This includes but is not limited to:-

1.  Telematics -the field of computer mediated communication.
2.  Women systems/software engineers - a contradiction in terms?
3.  Professionalism, legislation and the role of women.
4.  Women Returners
5.  'Man Machine' Interface to 'human Computer' Interface to what?
6.  Feminist perspectives in computing research.
7.  Education - computing education and the use of computers in education.

An underlying theme of the conference is to be social responsibility and
therefore we wish to encourage papers emphasising this and ethical issues.
Papers taking different cultural, national and societal aspects are
particularly welcome as are globally oriented papers.

In addition, we are looking for sister organisations throughout Europe to
participate in the conference.  The aim is to report on European Women's
Organisations, initiatives and relevant research.  We will be maximising
participation through the use of video conferencing services at De Montfort

For further details, or if you would like to register an intention to submit
or participate in the conference, please email :
We will then add you to our mailing list for registration

Further information on Women into Computing can be found at:

Further information on the Centre for Computing and Social
Responsibility can be found at:

Centre for Computing and                | Dept of Computer Science,
Social Responsibility                   | De Montfort University,
e-mail:                  | The Gateway
WWW   :         | LEICESTER, UK   LE1 9BH

Privacy Digests

"Peter G. Neumann" <>
16 Dec 1996
Periodically I remind you of TWO useful digests related to privacy, both of
which are siphoning off some of the material that would otherwise appear in
RISKS, but which should be read by those of you vitally interested in
privacy problems.  RISKS will continue to carry general discussions in which
risks to privacy are a concern.

* The PRIVACY Forum is run by Lauren Weinstein, with some support from the
  ACM Committee on Computers and Public Policy.  He manages it as a rather
  selectively moderated digest, somewhat akin to RISKS; it spans the full
  range of both technological and non-technological privacy-related issues
  (with an emphasis on the former).  For information regarding the PRIVACY
  Forum, please send the exact line:

     information privacy

  as the first text in the BODY of a message to:

  You will receive a response from an automated listserv system.  To submit
  contributions, send to "".

  Information and materials relating to the PRIVACY Forum may also be
  obtained from the PRIVACY Forum Archive via ftp to "",
  gopher at "", and World Wide Web via:
  "".  Full keyword searching of the PRIVACY
  Forum Archive is available through the World Wide Web access address.

* The Computer PRIVACY Digest (CPD) (formerly the Telecom Privacy digest) is
  run by Leonard P. Levine.  It is gatewayed to the USENET newsgroup
  comp.society.privacy.  It is a relatively open (i.e., less tightly moderated)
  forum, and was established to provide a forum for discussion on the
  effect of technology on privacy.  All too often technology is way ahead of
  the law and society as it presents us with new devices and applications.
  Technology can enhance and detract from privacy.  Submissions should go to and administrative requests to

There is clearly much potential for overlap between the two digests,
although contributions tend not to appear in both places.  If you are very
short of time and can scan only one, you might want to try the former.  If
you are interested in ongoing discussions, try the latter.  Otherwise, it
may well be appropriate for you to read both, depending on the strength of
your interests and time available.

Please report problems with the web pages to the maintainer