From: risks@CSL.SRI.COM (RISKS Forum)
Newsgroups: comp.risks
Subject: RISKS DIGEST 14.06
Date: 18 Nov 92 00:37:56 GMT
Reply-To: risks@csl.sri.com
Distribution: world
Organization: The Internet

RISKS-LIST: RISKS-FORUM Digest  Tuesday 17 November 1992  Volume 14 : Issue 06

        FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
   ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

  Contents:
"Computer programming error" reverses election (Nathan K. Meyers)
Detecting Voting Problems (Fred Baube)
Inaccurate stock system believed to cause British Air large losses (John Jones)
England fights on against system failures: LAS, aging systems (James H. Paul)
Stock price too high? (David Wittenberg)
$Million per second -- CHIPS (John Sullivan)
Re: Tandem's clocks (Don Stokes)
Photography from orbit (Daniel Burstein)
Smart cars? (Steve Mestad)
Warrants without notification (Steve Mestad)
Re: Two hackers caught tapping into Boeing, federal computers (Graham Toal)
Registering your color copier/printer (Carl M. Kadie)
Self-configuring devices (David A. Honig)
November Scientific American Article on Risks (Greg Phillips)

 The RISKS Forum is moderated.  Contributions should be relevant, sound, in 
 good taste, objective, coherent, concise, and nonrepetitious.  Diversity is
 welcome.  CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive 
 "Subject:" line.  Others may be ignored!  Contributions will not be ACKed.  
 The load is too great.  **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS,
 especially .UUCP folks.  REQUESTS please to RISKS-Request@CSL.SRI.COM.     

 Vol i issue j, type "FTP CRVAX.SRI.COM<CR>login anonymous<CR>AnyNonNullPW<CR>
 CD RISKS:<CR>GET RISKS-i.j<CR>" (where i=1 to 14, j always TWO digits).  Vol i
 summaries in j=00; "dir risks-*.*<CR>" gives directory; "bye<CR>" logs out.
 The COLON in "CD RISKS:" is essential.  "CRVAX.SRI.COM" = "128.18.10.1".
 <CR>=CarriageReturn; FTPs may differ; UNIX prompts for username, password.

 For information regarding delivery of RISKS by FAX, phone 310-455-9300
 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com).

 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.

----------------------------------------------------------------------

Date: Tue, 17 Nov 92 08:27:49 -0800
From: Nathan K. Meyers <nathanm@hp-pcd.cv.hp.com>
Subject: "Computer programming error" reverses election

McMinnville, OR (AP, 17 Nov 1992) -- The Yamhill County clerk discovered a
computer programming error that reverses the election results of the county's
district attorney's race.  Incumbent District Attorney John Mercer didn't lose
in the November election -- he won by a landslide.

Clerk Charles Stern said the computer error occurred because the program failed
to list the candidates in alphabetical order, as they were on the ballot.
Mercer had supposedly lost to Bernt "Owl" Hansen, 16,539 votes to 8,519 votes.
On Monday, the clerk's office told him Hansen's votes were actually his votes.

Mercer said he was astounded at the turn of events.  "The feedback I was
getting everywhere during the campaign was very positive.  And that's why it
was such an emotional extreme to see that I'd lost," Mercer said.  "But this is
really just as shocking the other way."
                                            Nathan Meyers  nathanm@cv.hp.com

  [Stern Warning: Once Bernt, Twice Mercerized.  (in the proper 2:1 ratio) PGN]

------------------------------

Date: Tue, 17 Nov 92 10:03:44 EET
From: flb@flb.optiplan.fi (F.Baube x554)
Subject: Re: Detecting Voting Problems (Stevens, RISKS-14.05)

In high school I campaigned for a Democrat in a town near Buffalo with a
Republican "machine".  He said the the single most important thing to do on
election day is to get someone to EVERY voting machine at the very hour the
polls open, to cast their own votes but also to *test* the machines.  And if
ANY problem is found, you demand the machine's closure, and telephone the Board
of Elections just to make sure.

In our case every voting machine in town was set up to allow only straight
party-line voting.  Hurried calls to the county Board of Elections [run by the
Democrats] got the machines closed until they were set right, later the same
morning.

To keep this relevant, in the example RAY cited it was quite evident that the
voting system was not working properly, but in general can *-electronic-*
voting and tabulating systems be checked by users for correct operation ?  If
so, RISKS readers can offer their services for the morning of polling day, to
the party of their choosing.  If not, don't be surprised when "accidents"
occur.
                       fred :: baube@optiplan.fi

  [Better make it the WHOLE DAY, not just the morning.  And keep your eyes
  open for those curiosities about which you should by now be aware, as
  well as others as yet unexposed.  PGN]

------------------------------

Date: Mon, 16 Nov 92 17:35:30 GMT
From: John Jones <jgj@cs.hull.ac.uk>
Subject: Inaccurate stock system believed to cause British Air large losses

                   Time-out costs BA dear 

   Its computer system may have cost the airline millions in lost earnings, 
   missing spare parts and legal expenses.  Chris Blackhurst, Independent
   on Sunday, 15th November, 1992

That was the headline over an article relating to a computer system called
`Total Inventory Management Engineering' (Time) which British Airways (BA)
introduced in July 1987, at a cost of 10M UK pounds.  Time, designed in-house,
governs BA's aircraft parts and stock control operation, handling 250,000 parts
worth 400M pounds.

It is suggested that problems have arisen because when Time was installed it
was initialised with inaccurate current stock levels taken from the original
manual stock system (known to be as much as 45% out), and these have apparently
never been corrected.

The article claims that this has affected BA in a number of ways:

a) General Electric took over servicing aircraft engines for BA in 1991.  BA
initially claimed the transfer of 53M pounds worth of spare parts.  General
Electric have nearly finished counting them, and have found only 30-35M pounds
worth.

b) In October 1991, BA submitted an insurance claim for a fire at its Gatwick
(London) warehouse.  The claim included 50M pounds worth of spare parts.  The
loss adjuster's report hints that BA's figures are not entirely reliable, and
valued the lost spares at 28M pounds.

c) The prosecution of 12 people on theft of aircraft parts and conspiracy was
based substantially on evidence from Time.  9 were acquitted, some of whom are
bringing legal proceedings against BA for wrongful arrest.  During
cross-examination, the person managing Time admitted that when it was installed
in 1987 40,000 items, including 94 complete aircraft engines each valued at
250,000 pounds, were found to be missing.  (The article is not too clear on
this point, but I presume it means to imply that concern over accuracy of the
data produced by Time contributed to the collapse of cases against some
individuals.)

d) Lack of confidence in the reliability of Time has lead to it being ignored
in some instances.  In one particular case, an engineer did not consult it when
refitting a cockpit windscreen.  As a result, he used the wrong bolts, and the
windscreen blew out in flight, almost sucking the pilot to his death (June
1990).

BA dispute the interpretation of events referred to in this article, suggesting
that there is no disagreement with General Electric, and that in the case of
the fire an initial `guesstimate' had later been revised.

John Jones, Department of Computer Science, University of Hull, UK.

------------------------------

Date:    Tue, 17 Nov 1992 17:57:18 -0500 (EST)
From: PAUL@NOVA.HOUSE.GOV (James H. Paul)
Subject: England fights on against system failures

The British magazine _New Scientist_ has in its issue of November 14, 1992,
two articles of interest.  The first relates to the recent discussion of
the London Ambulance Service.  The article states that the review began
last week and a report is due in February.  The article begins:

   "An overcomplicated system and incomplete training for control
    staff and ambulance crews are the likely causes of the collapse
    of London's computerised ambulance dispatch service two weeks
    ago.  One software company says that the London Ambulance Service
    (LAS) underestimated the pressure placed on staff at the control
    center, and that it makes working there `like a wartime action room.'"

The article continues with general observations about system complexity and a
description of the process of ambulance dispatching that the system was
intending to automate.  The computer consultant working on the review panel,
Paul Williams ("from the City firm Binder Hamlyn"), is described as having 13
years experience but he has never reviewed a safety-critical system.  He
intends to compensate with "expert help from his firm and the computer
industry."
                                            [The Tied Typer of Hamlyn?  PGN]

The second article is a four-page discussion entitled "Battling on with veteran
computers."  The major theme is the problems that are created by trying to keep
aging software and hardware going.  Examples discussed include the Patriot
missile system, IBM's Customer Information Control System package, the recent
upgrade to the Space Shuttle on-board computer system (we're up to a whole
megabyte of memory now!), porting the software for power distribution in
Britain from archaic Ferranti Argus 500 machines to modern equipment --

(I interject here a wonderful vignette:

   "The software for the initial system was written in a language
    called April, which disappeared long ago.  But the problem was
    not the rarity or age of the language, it was the lack of 
    documentation.  Three years after the system was delivered [1969],
    the CEGB [Central Electricity Generating Board] decided to develop
    its own software.  Today the system is maintained by a lone 
    programmer who has been working on the system in assembler for 20
    years.  Ask Derek Roberts, the group head of control facilities at
    the national centre of the National Grid Company what would happen
    if that person fell under a bus, and he pauses.  Then he replies:
    `we don't like to think about that.'"

We now return to our regularly scheduled programming.)

and the early flight control system for the Boeing 747-400.  According to the
article, so long as there are three copies of any aircraft type still flying in
the US, the avionics manufacturer is required by law to continue support -- so
Honeywell (which bought Sperry Flight Systems some time ago) is still cranking
out gauges and regulators for DC-3s.

Something new to add to everyone's burgeoning files.

------------------------------

Date: Tue, 17 Nov 92 15:07:49 EST
From: "David Wittenberg" <dkw@chaos.cs.brandeis.edu>
Subject: Stock price too high?

According to Marketplace on American Public Radio, a stock on the New York
Stock Exchange (I don't remember the company) closed above 10000 on 16 Nov.
This is the first time any stock has been above $10000, and as you might
expect, the stock exchange's computers couldn't handle the 5 digit price.

The price rise wasn't incredibly fast, as the stock was up 400 for the day, so
one hopes they saw this problem coming and dealt with it, but the report I
heard had no further details.

There's nothing particularly surprising about this report, as we've seen lots
of similar examples.  After a while it's more depressing than surprising to see
the same mistake over and over again.
                                                  --David Wittenberg

------------------------------

Date: Sun, 15 Nov 92 18:57:32 CST
From: sullivan@geom.umn.edu
Subject:  $Million per second -- CHIPS

The NewYorkTimes Magazine had an article on October 18 about CHIPS, the
financial clearinghouse for major American banks, which handles one
trillion dollars electronically every day.  Although 85 percent of all
transactions are still made in cash, and only 2% electronically, the
electronic payments make up 85% by value.

The article examines some of the possible risks in this system.  The
hardware is run off of storage batteries, in a room with a Halon fire
extinguishing system.  But on Oct 1981, "a hardware breakdown took out
both New York computers" and "processing was interrupted for five minutes"
until backup systems (on an "independent communications grid") in New
Jersey were brought up.  Users "would never have known" if they hadn't
been told.

Messages are verified/encrypted in such a way that someone intercepting a
message couldn't just change a dollar amount.  Once, in 1989, some
criminals (with inside help at a Swiss bank) used CHIPS to help steal
$20M(illion).  They wired money from the Swiss bank (entering a fake
deposit on the books) to Australia, and quickly spread it around.  Though
they have been caught, only $8M has been recovered.  The electronic system
merely helped them disperse the large amount quickly.

The bigger worry is a loss of confidence.  Unlike in the similar European
system, all debts are netted at the end of the day.  Each bank either owes some
amount to the center, or is owed money.  If one bank fails to meet its
obligations, all transactions involving it that day are supposed to be
"unwound".  This could, of course, lead some other bank to no longer be able to
meet its own obligations for the day, causing a cascade.  CHIPS does allow each
bank to set a limit on how much it is willing to be owed by all other banks;
this limit is monitored continuously, and so a cautious bank could avoid
problems.

The Federal Reserve runs a similar system, and once had to make an overnight
loan of $24 billion to the Bank of New York "in order to settle the day's
accounts on transfers of Government securities that got fouled up in a software
snafu."  Of course, these days such securities are really just electronic
entities stored with the Fed, so the overnight loan was well collateralized,
and evidently the situation was fixed the next day.  The article says this
could not happen on CHIPS, because each transfer must be originated by the
payer.  [I don't know what this implies about the Fed system.]

The article concludes that "what all the experts fear is what they do not
know."
                       -John Sullivan@geom.umn.edu

------------------------------

Date: Thu, 12 Nov 1992 17:16:06 +1300
From: Don Stokes <Don.Stokes@vuw.ac.nz>
Subject: Re: Tandem's clocks (RISKS-14.01)

		BANK SYSTEM IN CHAOS AS MICROCODE BUG STRIKES
		By Randall Jackson

November 1, 3pm: a date and time users of Tandem's CLX systems around the world
won't forget in a hurry.  That's when a microcode bug struck, sending system
timers incoherent and causing chaos in applications such as EFTPOS and
automatic telling machines.  The bug was discovered first in New Zealand, which
is the first country to greet the new day.

"Literally, a bit seemed to fall off the field and the timers went incoherent
and began talking to themselves," says Ken Hennessy, chief manager at
Electronic Transfer Services (ETSL), which manages EFTPOS in New Zealand.
"They took the date back to December 1983."

There are five CLX installations in New Zealand, including Westpac, whose ATM
system crashed at the same time as EFTPOS.

Hennessy says Australia was the next affected, then Asia.  "I believe Japan was
a hell of a mess.  "We had been in touch with Australia because ETSL operates
contracts there, and they started to notice the problem.  They contacted Tandem
and the Americans became involved.  "By midnight, Tandem had worked out a way
of getting around the problem."

That was important, because Tandem was able to advise all its users in
America and Europe and prevent systems crashing there.

Hennessy says EFTPOS in Wellington was up and running again by 6.30pm.  "We
turned the clocks back two years to give us a clearance into 1990 at least.
Then we had to raise each host and hope it didn't cause problems of
irreconcilability.  It didn't, because it was day-to-day, month-to-month.  "Our
Auckland node came up at 9:40pm and in the early hours of Monday morning we got
back to 1992."  Hennessy says that there were two fixes: rolling the clocks
forward past 3pm then shifting them back so 3pm wasn't hit, or waiting until
3pm rolled around, and doing a cold start.

Typically, New Zealand businesses affected on a Sunday were supermarkets and
petrol stations.

Foodstuffs Wellington retail systems manager Alistair Garvie syas the loss of
EFTPOS was a major inconvenience.  "One of out largest stores does 25% of its
business through EFTPOS, and customers were complaining about having to pay
cheque fees instead," he says.

BP spokesperson Beppie Holmes says there was some inconvenience but the company
was able to revert to paper based transactions.  "Where it did affect us was in
our ability to provide cash to customers, which has an effect on residual
business," she says.

Tandem New Zealand manager John Simms says it took about four hours to work out
an answer to the problem, then communicate it to customers.  "There was a
microcode defect that caused the internal clock to be read incorrectly.  It
affected different applications in different ways," he says.  "It was a field
where at rollover the bug caused the data to be interpreted wrongly.  "We got
our customers to cold load and then reset correctly."

Simms says Tandem acted quickly to provide a fix.  "It would happen again in
2001 if we hadn't fixed it," he says.

			From Computerworld New Zealand, November 9, 1992:

Don Stokes, Network Manager, Computing Services Centre, Victoria University of
Wellington, New Zealand +64-4-495-5052  don@vuw.ac.nz (wk)  don@zl2tnm.gen.nz

------------------------------

Date: Tue, 17 Nov 92 12:02 GMT
From: Daniel Burstein <0001964967@mcimail.com>
Subject: Photography from orbit

The following material is from "Space Digest" v15 #425,
distributed as "Space@ubvm.cc.buffalo.edu"

The article deals with the newly available, from the RUSSIANS, satellite photo
imagery with resolutions of 1.5 meters.  This is good enough, to pick out
individual cars in parking lots (although not to read the apocryphal license
plates).

They expect a bit more sharpness after some technical problems get resolved.

This is a curious "RISK."  On the one hand, it makes all sorts of overhead
photographic info available.  On the other hand, it also makes it (almost)
available to the general public.

Is it a "RISK" to find out how many Japanese fishing trawlers are out there?
What about which cars are parked overnight at the take-a-buck hot sheets motel?

article follows:

4- RUSSIAN MILITARY SPACE OBSERVATION DATA ON THE MARKET

   [Ran across a couple of interesting notes, with interesting ramifications.]

   Central Trading Systems in Arlington, Texas has a new product.  Digitized,
very high resolution Russian "Earth Observations" data.  This data showed up
about a month ago when some demonstration data was circulated within the
industry to see if there was some interest in buying it.  Folks who've analyzed
the data say it's in the 1.5-2 meter resolution range.

   At that resolution, you can pick out the Christmas tree in front of the
White House, or pick out individual cars in the Pentagon parking lot on the
demo tapes data.  Some rumors circulating in the industry claim the data could
have even a higher resolution quality, but the data has been poorly digitized
from photos.  This data is obvious from a former "strategic asset" of the
Soviet Union.

   Central Trading systems, can't identify what satellite generated the photo
data, but that the Russians call it a "DD5" system, for Digital Data 5.  As a
representative of the data seller Central Trading Systems is offering global
coverage with an extensive data archive of digital images.  If the scenes are
in the archive, customers can have the images on data tapes within 2 weeks,
delivered by Federal Express.  If new scenes are required, they can be
delivered with 45 days, weather permitting. Central Trading Systems thinks the
data is delivered digitally in Russian, transferred to photos, and then
re-digitized.  His offers the possibility that resolution can improve as more
advanced digitizing and image processing systems are applied.

   Cost for the data is $3180 (including shipping and handling) for a 13 x 13
Km, 8-bit scene, of 40 mps at 1600 bpi.  Demand is reportedly high.

   As a side note, on 2 October, a top Russian space commander stated the
Russian military space program will only survive by sharing its expertise and
hardware.  Col General Vladimir Ivanov was quoted in a Krasnaya Zvezda
interview as recommending Russian military space systems be used for commercial
and civilian purposes.  In particular, he was reported to have stated
"Reconnaissance satellites can be successfully used for long-distance probing
of the Earth's surface and for ecological monitoring without impairing their
main task."

   [Commentary: New competition in the Earth Resources market area.  There are
reportedly warehouses of high-resolution Earth observation data on both sides
of the ex-Iron curtain.  Different organizations have been selling ex-Soviet
observation data in the 10-meter resolution class, but the data availability
and market response has been poor, partially because the data was only
available sporadically or only in photographic form.  (For obvious reasons, the
preference is for data in digital format.)

    But if true, a marketable archive of global 2 meter or better data could be
a market gold mine. And the Krasnaya Zveda quote could indicate regular
availability to high-resolution data from Russian military systems could become
official policy and routine.

   SPOT and Landsat data is about an order of magnitude more coarse, with some
gaps in the digital data coverage available.  The Russian data prices are also
very competitive. I expect if the initial expectations are proven for this
Russian data, then it will capture a large share of the market within a few
years.

   Again, there can be a substantial commercial market pact from an ex-Soviet
system.  Due to policy considerations, the US government has been reticent to
release high-resolution Earth Observation data, and has encouraged the use of
100-meter resolution Landsat Data for commercial or non-critical government
needs.  It was only last month the US Department of Defense even officially
revealed the existence of the office which controlled such space assets.

   Similarly, SPOT, which has a very large ownership share by the French
government, has not striven to achieve the maximum resolution in its system.  A
higher resolution has been expected in the French military HELIOS observation
system under development.

   Perhaps the sale of high-resolution Russian data will encourage the release
of high resolution data by Western governments.  But this will also decimate
the existing SPOT or Landsat/EOSAT data markets, when they still have not
reached a critical mass for full commercial viability.  The best result would
be the encouragement of the construction of commercial Western systems with
equivalent capability, which is well within the capability of the industry.

   As it stands now, there are still significant unknowns in the future of
commercial Earth observations data.  This new source of data, if it is proven
as reliable and accurate, could substantially change some of the market
assumptions for Earth resources data.]

------------------------------

Date: Tue, 17 Nov 92 14:27:14 -0600
From: stevem@diehard.ssc.gov (Steve Mestad)
Subject: Smart cars?

>From the December issue of Popular Mechanics, Tech Update column 

(paraphrased)

Workers are installing on all 2400 Greyhound buses an on-board radar system 
made by VORAD Safety Systems.  One radar beam will scan ahead for obstacles
while a second will probe the driver's blind spot.  Steering, braking, speed
and obstacle closing rates will be recorded by a 'black box'.

VORAD is already testing a system on passenger cars that links the radar and
cruise control, enabling the car to maintain a constant distance away from the
vehicle ahead.  (no longer paraphrasing the magazine) "The next step, says
VORAD, is to connect the radar directly with the brakes, to decelerate the car
before the driver has time to react to an obstacle."

The RISKS seem obvious enough to me...

Steve Mestad, Physics Research Division, Superconducting Super Collider Lab
2550 Beckleymeade Ave., MS 2003 Dallas TX 75237       stevem@diehard.ssc.gov

------------------------------

Date: Tue, 17 Nov 92 14:15:38 -0600
From: stevem@diehard.ssc.gov (Steve Mestad)
Subject: Warrants without notification

>From the Dallas Morning News Friday Nov 13 issue, in the Line One column
(an advocate column of sorts):

Person's problem:  (paraphrasing salient points)

Person went to renew their driver's license during lunch; paid; was
photographed and taken to the back.  There they were informed of an outstanding
warrant and told to either pay the fine or be arrested.  Person admitted to old
speeding ticket which was allegedly paid.  Previous queries of driving record
and traffic stops did not reveal anything about the warrant nor was any
notification received by mail.

Response from Texas Dept of Public Safety: (again paraphrased)

Signature on citation is promise to contact/appear in court by date on
citation.  Failure results in issuing the warrant.  Issuing trooper enters
warrant into the Warrant Data Bank (WDB).  Warrants are placed in WDB are for
traffic citations issued only by the Dept.  Anytime license record is checked,
outstanding warrants will be indicated.  Some police depts. do not serve
warrants on license checks so a person may not be notified at a stop.  Warrant
information is not provided on driver's record checks.  With the start of the
WDB, the Dept. no longer sends mail to advise of issuing a warrant.

Steve Mestad, Physics Research Division, Superconducting Super Collider Lab
2550 Beckleymeade Ave., MS 2003 Dallas TX 75237       stevem@diehard.ssc.gov

------------------------------

Date: Mon, 16 Nov 92 0:09:48 GMT
From: Graham Toal <gtoal@ibmpcug.co.uk>
Subject: Re: Two hackers caught tapping into Boeing, federal computers

I recently heard from someone who *works* on British Airway's flight booking
system that it is only lack of access that keeps hackers out - the system it
runs is completely unprotected - a multitasking system where every task can
access the memory of other tasks.  And they're scared to make major changes to
it in case it falls over.

So he told me.  Season with salt as desired.

------------------------------

Date: Sat, 14 Nov 1992 18:29:52 GMT
From: kadie@cs.uiuc.edu (Carl M. Kadie)
Subject: Registering your color copier/printer

The coin collecting column in the Books section of the Chicago Tribune of
Sunday, Nov 8th is about counterfeiting paper money. Among other things it
says:

  Meanwhile, Canon USA has reported that it soon will add either one or two
  counterfeit deterrents to its new color copiers in an attempt to thwart
  would-be forgers.

  One technology places an invisible code on every copy made so that police
  could trace the machine that duplicated a dollar bill or other documents. The
  company also might produce machines that print black copies of greenbacks and
  other bank notes because of information programmed into the machine's
  computer memory.

I see a risk that these "invisible codes" will be used not only to track
counterfeiters but also whistleblowers, government critics, and those who only
want to be able to communicate privately. The risk increases if (when?) the
authorities require that each color copier/printer's "invisible code" be
registered.

I'm also unhappy with the idea that my printer will try to enforce laws about
what I can and cannot put on paper. How accurate will it be? Also, the scheme
creates the risk that more color copies of money will be produced. Who could
resist trying to fool the censor-in-the-machine?

Carl Kadie -- kadie@cs.uiuc.edu -- University of Illinois at Urbana-Champaign

------------------------------

Date: Sun, 15 Nov 92 09:56:57 -0800
From: "David A. Honig" <honig@ruffles.ICS.UCI.EDU>
Subject: Self-configuring devices

Just discovered a feature that will probably amuse other readers of RISKS.

A certain very-popular-workstation-tape-storage-device will reload its firmware
upon finding a firmware-reconfiguration tape within its maw upon power-cycling.
Presumably it reads whatevers loaded upon start up and upon finding the right
code, interprets the data as destined for its EEPROMS.  Totally convenient but
amusing to a reader of RISKS.
                                              David Honig

------------------------------

Date: Tue, 17 Nov 92 9:48:30 EST
From: g 6367 Capt G Phillips <phillips@rmc.ca>
Subject: Scientific American Article on Risks

The November 92 issue of Scientific American has an interesting article on the
risks of computers and proposes three different mechanisms to limit them.
Nothing there that regular readers of this forum won't have seen before, but
spelled out in clean language that anyone can understand.

Note that this is a case of circular reference, since the article ends by
recommending this forum as a good place to learn more about risks.

Greg  Captain W. Greg Phillips, Royal Military College of Canada 613-541-6367 

------------------------------

End of RISKS-FORUM Digest 14.06
************************