The RISKS Digest
Volume 4 Issue 23

Wednesday, 3rd December 1986

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…


The persistence of memory [and customs officials]
Richard V. Clayton
America's Cup - floppies held to ransom
Computing Australia via Derek
Some thoughts regarding recent postings: blame and causality
Eugene Miya
Microcomputer controlled cars (not Audi)
Miriam Nadel
Re: Welcome to the system
Ronda Henning
Re: Automated trading
Scott Dorsey
Active control of skyscrapers
Herb Lin
Sanity in Automating Keyword Abstracting
Paul Ryan
Info on RISKS (comp.risks)

The persistence of memory [and customs officials]

Richard V. Clayton <>
Wed, 3 Dec 86 07:27:13 est
The 27 November issue of New Scientist has an article (page 20) about
a heroin smuggling ring convicted with the help of evidence obtained
from a pocket computer.  The smugglers used the computer, a Psion
Organizer, to store information about deals; after the deal was done,
the information was erased.  However, the Organizer uses EPROM
storage, so information wasn't erased, but flagged as being
unavailable.  After seizing the computer, customs officials took it to
Psion where in-house software recovered the information.

America's Cup - floppies held to ransom

03 Dec 86 18:30:18 +1000 (Wed)
I thought RISK readers might be interested in some of the lighter risks
associated with the use of high technology in twelve metre yachting.
Not only must keels be covered!

CUP INFO RANSOMED  (From Computing Australia, 1 December 1981)

A stolen package of floppy disks holding sensitive telemetry data from one
of the America's Cup syndicates has been recovered after being held to
ransom through a hacker's bulletin board.  

The theft of the 17 disks came to light on a bulletin board called Inter-State
Connect, where a note was posted originally asking $10,000 for them.

It is not known which syndicate had the disks stolen as no name appeared
on them and none of the yachting teams have admitted ownership.

The disks were stolen in Fremantle and turned up in Melbourne where computer
security analyst, Stuart Gill, negotiated the retrieval of the disks through
a shadowy organisation of hackers known as TechHack.

TechHack became involved in the negotiations after being accused of mounting
the ransom operation.  In order to clear its name, TechHack acted as the
intermediary between Gill and the hacker responsible for the ransom notice.

Computing Australia has obtained a printout of the negotiations which took 
place on the bulletin board.

It reads:

    As at 21/10 we require the sum of $2,500 for the exchange of the disks
    Confirm there are 17 and you are aware from our Perth contact that they
    are Kosher.  We cannot continue talking for much longer as we don't 
    think you are serious.

In the end, the stolen property was retrieved with no exchange of money.

It is believed a number of syndicates approached Gill for copies on the disks
on the pretext of establishing where they came from.


Some thoughts regarding recent postings: blame and causality

Eugene Miya <eugene@AMES-NAS.ARPA>
Wed, 3 Dec 86 10:13:07 pst
Peter, your recent note on the frequent but rarely discussed topic of "where
to place the blame" concerns me.  It seems that we in computers and computer
science have some what ill-defined concepts of CAUSALITY (where DO we put
the blame?), (non)determinism, and our poor use of reductionism.  Other
similar postings on modeling and empirical data as final proof also concern me.

Consider, the mistake we make when we confuse WORK and EFFORT:  we get
Brooks' mythical man-month.  (Brooks' classic example was 1 woman => 1 baby
in 9 months, therefore 9 women => 1 baby in 1 month.)  And there are many
people who don't see that this generalizes in high-performance computing in
terms of mythical MFLOPS:  some programs are not decomposible into parallel
parts.  And I suspect this is also manifest in the way we use redundancy in
fault-tolerant computing (multiple CPUs in hot-start configuration which
could be used for parallel computation but are used for reliability

I think we misunderstand causality for two reasons:

  1) Our empirical foundations tend to be a bit weak.  (We put theory quite
  high in esteem.)  In part, mathematical theory is our solution, but it also
  a source of bias.  I know many will disagree with this latter conclusion
  including PJD.  We try to envision problems outside of the complexities of
  the `real' world (modeling and simulation).  Where as theoretical physics
  had experimental physics to fall back on, computer science does not have a
  good equivalent.

  2) Some of our ideas do not tend to generalize across computers as
  mathematical concepts generalize across the mathematical sciences.
  We are not really JUST a mathematical science.  The recent econometric
  postings enforce some of this.

I heard an interesting thing about the way computing is done in third-world
countries (I heard the USSR was/is in this category) where computing is
expensive and thinking is cheap:

  Theoretical CS is held is high esteem because when a mistake is made in
  hardware or in a project it becomes glaringly visible to all.  When mistakes
  are made in theoretical CS (and probably math to a lesser degree), there are
  so few people who understand these ideas, and some ideas are so specific,
  that only a few people can criticise them (fewer/less negative reinforcement
  and punishment).

Consider the discussion on testing: computer people talk about testing with
respect to the correctness of a specification, but we don't talk about
testing with respect to the `real' world.  Testing of accounting programs is
one thing, but testing of models of the physical world like fluid dynamics
or population quality of life are different things.  Perhaps I should use
the word measurement here.  There are numerous cute computer models with
graphics like the LLNL crushed cone shown at the 1984 SIGGRAPH or similar
fluid dynamics works here.  (References provided on request.)  I fear that
we computer types have a greater chance of losing touch with reality.  This
would also make us among the poorest judges in our own discipline for things
such as the Turing Test because the Test is ultimately an empirical endeavour.

Anyway, these are some initial thoughts I have composed over the past few
days about computing's poor basis in empiricism.

--eugene miya

Microcomputer controlled cars (not Audi)

Controls Wizard <>
Wed, 3 Dec 86 08:23:12 PST
There's been a lot of discussion about the Audi problems and I remembered a
similar incident.  The Sept. 1984 issue of Consumer Reports included a
review of the Mitsubishi Starion.  Under the heading "Defect of the Month"
they described uncontrollable acceleration that was only stoppable by
turning off the ignition.  The problem was eventually solved by replacing
the engine microprocessor and the problem was reported to the National
Highway Traffic Safety Administration.  It seems to me that NHTSA should be
getting the Audi complaints and telling Audi that they should look at the
source of the problem.  Precedents are a good way of convincing people that
there's a problem.  Miriam Nadel

Re: Welcome to the system

Wed, 3 Dec 86 10:59 EST
I know of a similar case that never made it to court.  The computer security
administrator at Roche, the drug company had been plagued by a hacker who
auto-dialed the entire Roche phone system in sequence.  It took a lot of
phone calls from company management to convince the phone company that this
was not just someone with fast fingers and a touch-tone phone.  They laid a
hacker trap on one of the PC`s and traced the call.  Once the suspect was
found, it was even harder to get him arrested since he was in New York and
Roche is in New Jersey, which somehow got the FBI involved.

The perpetrator was brought into the police station and had the riot act and
the fear of God scared into him.  He was not charged — because there wasn't a
no trespassing sign on the hacker trap identifying the system as private
property of Roche.

                  [A tough Roche to phone?  (All Roche leads to phone?)
                  Yes, this has been a common problem in the past...  PGN]

Re: Automated trading

Scott Dorsey <kludge%gitpyr%gatech.csnet@RELAY.CS.NET>
Sun, 30 Nov 86 14:04:18 est
  I'm afraid to say that most of the programs all use very similar
algorithms with almost identical buy/sell setpoints.  That's where
the problem probably lies.  
  The solution is to predict the changes in the market that would
result from these (very predictable) programs operating at the same
time, and I am sure that some smart fellow will be making a lot of
money that way...

Active control of skyscrapers

Wed, 3 Dec 1986 09:20 EST
I'm told that the John Hancock Building in Boston is built like this.

Sanity in Automating Keyword Abstracting

Paul Ryan <dgis!ryan@lll-tis-b.ARPA>
Mon Dec 1 16:30:30 1986
The Defense Technical Information Center (DTIC) acts as the central
repository of scientific and technical information for the Department of
Defense (DoD).  One of the four online databases which DTIC maintains is the
Technical Reports Database.  It has recently come to our attention that the
29 September 1986 issue of the RISKS Digest [RISKS-3.70] was informed of a
"new policy" by DTIC that stated that technical report titles be designed
with keywords positioned in the first five words of the title.  THIS IS NOT
Apparently, this erroneous information was forwarded to this forum as an
example of the risk to accurate dissemination of information caused by
faulty programming (or programmers?).

The policy of this organization regarding technical report titles is that they 
should reflect the author's effort to describe the content of the report.  

In trying to determine from where such an inaccurate statement might have
developed, our conclusion is that the individual (outside this organization)
who proposed the "policy statement" misapplied a long standing DTIC search
retrieval capability.  Our automated retrieval system has a search algorithm
which is constructed from the first five words of the title.  It allows a
searcher to identify a report title and bibliographic citation from our
online collection of 1.5 million titles.  The search retrieval algorithm
works for any word of the first five words of the title whether they be
prepositions, articles, or keywords in identifying the bibliographic
citation associated with a title.

For further information please contact:  R Paul Ryan, Director, Office of
User Services, Defense Technical Information Center, Cameron Station,
Alexandria, VA 22304   Phone (202) 274-6434   AV 284-6434

Please report problems with the web pages to the maintainer