The RISKS Digest
Volume 16 Issue 05

Wednesday, 11th May 1994

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…


Are we betting on horses or computers? (off-track betting)
Reva Freedman
Amusing computer-related anecdote about local cable service
H Morrow Long
MTV Sues Curry
Adam Curry
China Airlines A300 Crash
Mark Stalzer
Re: Elevators, Car bumpers and Cryptography...
Peter Wayner
Re: Bellcore cracks 129-digit RSA encryption code
Fred Cohen
Amos Shapir
Re: ACM Nightline
Robert Morris
Don't always believe those E-Mail addresses
A. Padgett Peterson
EFF's Kapor announces new cyberspace TV show
Kapor via Stanton McCandlish
Automation: request for input
Ken Funk
Info on RISKS (comp.risks)

Are we betting on horses or computers? (Risks of off-track betting)

Tue, 10 May 94 15:46:02 CDT
Illinois has off-track betting on horse races. You can place your bet at
one of these legalized bookie joints, then watch the race on TV and
collect your winnings. If you place your bet early in the day, you don't
even have to wait around for the race. You can watch the race at home and
come back later to collect. That's the theory, anyway.

On Saturday, April 23, the computer system handling the betting for some of
the remote sites crashed after the fourth race. People at the betting parlors
were told that they couldn't place any more bets. But what about those who had
placed their bets and left? When winners returned on Sunday to collect, they
were surprised to learn that, from the racetrack's point of view, they had
never placed a bet, and were offered only a refund of the cost of their

So were losers, if they had kept their tickets and happened to hear about the
computer crash. However, the fact that refunds were available was not listed
in the newspaper with the race results, mentioned on the telephone hot line,
or mentioned on cable TV broadcasts of the races.

On Monday a class-action lawsuit was filed. By Tuesday, racetrack management
had decided to pay up.

The system, designed by Amtote International, had only been in operation for a
month. On the other hand, state officials had sued Amtote before for
deficiencies in the previous system. No description was given of the original
failure, but newspaper reports (Chicago Tribune, 4/26/94 and 4/27/94) said
that a hardware problem caused the backup system to fail.  The new system was
designed to be "user-friendly." I hate to say it, but the most user-friendly
component in this incident was the lawyers!

Reva Freedman

Amusing computer-related anecdote about local cable service

H Morrow Long <long-morrow@CS.YALE.EDU>
9 May 1994 17:21:07 -0400
A very interesting program was on Storer cable channel 70 last night [they
call themself Comcast now, and serve the areas of West Haven, New Haven, and
Hamden].  For a long time, only the following message was flashing at the top
of the screen:

 | Software Failure.      Press left mouse button to continue.  |
 |           Error:  0000 0003  Task:  002006f0                 |

Talk about having your software problems out where the world can see them.
Didn't look like anyone was minding the store(r).  I guess someone there had
to press the left mouse button this morning...

H. Morrow Long, Mgr of Dev., Yale Univ., Comp Sci Dept, 011 AKW, New Haven, CT
06520-8285,  (203)-432-{1248,1254}  Long-Morrow@CS.Yale.EDU

   [In the old days, it was not unusual for a mouse to nibble into
   a cable.  Now we have cable nibbling at the mouse.  Turn(er)about
   is fare prey.  PGN]

MTV Sues Curry

Adam Curry <>
10 May 1994 03:44:36 -0400
                             [IMAGE] MTV SUES CURRY
Last update: May 10 1994
_New Jersey, May 10 1994_

I had planned to keep the following quiet until more information was available,
but since several journalists have already caught wind of it, I decided to get
it out into the open so my side of the story is heard as well.

The domain I maintain and operate on the Internet, was founded
approximately one year ago. At that time I registered with the
InterNIC, purely because it was a cool address to have, and it was available.
What a great "vanity plate"!

The site quickly became a frequently accessed "hangout" on the net, with an
average of 35000 accesses daily from Mosaic clients alone. During the start up
months I had many conversations with executives at MTV Networks about my
endeavours, which btw, were all financed out of my own pocket, and vps from MTV
Programming as well as Viacom New Media were aware of what I was doing on the
internet, and although they stated "MTV has no interest in the internet" they
gave me their blessing and supported my efforts.

This was enforced when I set up several email accounts on for use in
MTV's on-air programming. Ever since the summer of '93, was
used for trivia quiz questions, that were then aired on MTV's "Most Wanted" a
program I hosted at the time. Solicitations were made on the air, and the
address was shown on the screen. For MTV's annual Valentines video dedications,
viewers were offered the choice of calling in their dedications, or sending
them via email to

I never charged MTV Networks for this service, I purely saw it as a cool
feature to introduce to MTV's programming, spreading the "gospel", so to speak.

Then I started to get a lot of press about, and some people started to
wake up at 1515 Broadway (MTV's HQ in New York City). And I was served with a
"Cease and desist" on the use of MTV's attorneys claimed that there
could be "confusion" for users of the internet, when connecting to *anything*
that had the letters mtv in the address, and then receiving music and
entertainment information. I was obviously hurt by this move, but did see what
point they were driving at, an asked if we could settle this matter amicably.

The situation cooled down for a couple of months, but when I resigned on-air
from my job as a VJ, which MTV chose not to air btw, things started to get

Long story short, MTV Networks has filed a lawsuit against me, for copyright
infringement of their "trademark", that being their "MTV" call letters, as
well as having information online that was MTVN "property". In this case they
are referring to several press releases I put up on, such an
announcement about Beavis and Butthead's "experience" cd release. Understand
that MTVN sent me these releases over their own internal computer network for
this very purpose! Again, I was only doing this to promote the channel, not
for my own personal gain..after is free access for all, no

Throughout all of this I have offered to maintain the site specifically for
mtv, but again they said "we're not interested". Of course, I have no problem
whatsoever removing all references to MTV Networks and it's projects from, no that I don't work there anymore gives me even more reason to want
to do this, but the kicker is they are moving for an injunction to make me
stop using the internet address!

This is of course totally unacceptable: I registered the domain name, and I
don't plan on giving it up. Sure MTV and their parent company Viacom have a
vast legal team, but david also nailed goliath, so I have faith. In the long
run, everyone knows that the only *true* winners will be the lawyers.

There are many different viewpoints on this situation, but I feel that the use
of mtv in an addressing scheme can't be seen as an infringement of
intellectual property laws, and a search of the InterNIC database shows at
least 15 domain names registered with mtv in the address. Irony is that I
incorporated a company called ON RAMP, Inc (tm) and was already
registered to someone else, but I'm not suing them :)

It appears to me that MTV has their mind set on the address, maybe not
for now, but possibly for future use, and I feel extremely used, in that I
built up quite an audience for that address, and they are basically saying
"thank you very much, you may go".

A pre-motion hearing is scheduled for this thursday morning at 11am, wit the
honourable Judge McKenna presiding, in an attempt to get an injunction to make
me stop using the address I will update the situation as it unfolds.

Adam Curry,

China Airlines A300 Crash

Wed, 11 May 1994 09:02:33 +0800
The L.A. Times today (May 11) published a story on the A300 crash last month
at Japan's Nagoya airport. I'll quote the first paragraph and then summarize
the remainder of the story.

"A terrifying battle between an inexperienced co-pilot and his airplane's
super-sophisticated computer system preceded last month's crash of a Taiwanese
jetliner that killed 264 people..."

The events described in the rest of the article are as follows:
1. The plane was being hand-flown on approach to landing by
   its 26-year-old copilot.
2. About 2 minutes prior to landing, the A300 went into
   "go-around" mode for reasons unknown.

3. Even though the pilot warned the co-pilot 3 times in 30 seconds, as
   recorded by the voice recorder, the co-pilot continued to attempt to land
   the plane. The effect was that the auto-pilot was trying to pitch the
   nose up using the "horizontal stabilizer flaps" while the co-pilot was
   trying to pitch the nose down using the "elevator flaps" (the Times
   author might have this a bit confused).
4. The crew then switched the "go-around" mode off. However, the "stabilizer
   flaps remained set at a sharp angle."
5. The crew realized the plane was too high to land, so they set the
   "go-around" mode back on.
6. This caused the plane to climb sharply and approach a stall.  The A300
   stall-prevention system automatically increased the engine thrust but
   this INCREASED the climb angle to 53degs.
7. The airplane stalled.
8. The nose dropped and the airspeed increased to 150mph at an altitude of
   260 yards.
9. At this point, the entire electrical system stopped functioning
   for reasons unknown, including the flight data and voice recorders.
10. The plane crashed, killing 264 people. There were 7 survivors.

The root cause of this crash seems to be a confused co-pilot. However, the
A300's automatic systems contributed in two ways.  First, it continued to
attempt the go-around even though the plane was still being flown by hand. Had
the auto-pilot disengaged (with a suitable warning!) this whole disaster may
have been adverted.  I think a human supplying control inputs is the "final
authority" and the automatic systems should "back off".  Second, the
stall-prevention system's actions (increasing thrust) contributed to the
stall. This is a serious kind of failure, if a automatic system designed to
prevent a problem makes it worse, it should do nothing at all!

  — Mark Stalzer (

Re: Elevators, Car bumpers and Cryptography...

Peter Wayner <>
Tue, 10 May 1994 15:37:05 -0400
I once talked to a major elevator company about doing just what the Schindler
Elevator Corp. is accused of doing by the Toronto government. (RISKS-16.04).
The company told me that they were in the habit of selling the elevators at a
loss so they could make up the money in service contracts. Then they found
themselves battling independent service companies who undercut their prices.
They hoped to use cryptography to lock out any other service provider without
the right key.

Of course, this loss-lead approach is common in many businesses. Car companies
often sell their cars at a low price and hope to make it up selling spare
parts later. That is why I discovered that a spare bumper for my car cost over

The difference is that other companies are now making duplicate parts.  The
major automakers can try and discourage them, but they can't lock them out of
the business.

Cryptographic locks, though, are a different story. They probably can't be
broken in a reasonable amount of time. (See also 16-04) I'm not sure of the
case law on this, but I would suspect that it might fall under questionable or
illegal trade practices. At least in the US.

Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04)

Fredrick B. Cohen <fc@Jupiter.SAIC.Com>
Tue, 10 May 94 19:33:36 PDT
I think a lot of people are missing the real point about the RSA.  On my
pocket PC, I can create a code that requires 5,000 MIP years to break in a
matter of seconds.  If I am willing to use several more seconds, I can make a
code that takes 10^25 MIPS years to break.  Compare this to any other
encryption scheme, and you will find that the workload amplification of the
RSA is quite good.

And Shannon told us in 1949 that any non-perfect information transform can be
broken with enough cyphertext - and developed the concept of workload for
evaluating cryptosystems.  If we want perfect cryptosystems we know how to get
them, but it requires secure distribution.  On the other hand, the RSA
provides any degree of complexity we wish to generate (finite) and a fantastic
complexity amplification factor, and the advantages of a dual public key
system that can be used for both encryption and authentication.

The point is that the RSA has not been broken, rather it has shown just how
much of a David is required to defeat a given Goliath.  After all, in terms of
that story, David would have been a MIP second and Goliath 5,000 MIP years in
relative sizes for a break-even fight.  I'll take that David any day.  FC

Re: Bellcore cracks 129-digit RSA encryption code (RISKS-16.04)

Amos Shapir <amos@CS.HUJI.AC.IL>
11 May 1994 15:19:01 GMT
> So where does the 40 quadrillion figure come from?

It comes from this very table. 10^9 is a billion, not a trillion, in the US
system, and 40 quadrillion is 4 x 10^16, which is even less than what I get by
interpolating to 425 bits (can anyone who has access to the original RSA
article verify this?).

There seems to be an interesting risk here: most encryption methods rely on
"hard" problems, i.e. problems whose "brute force" solutions require
computation resources which are an exponential function of the key length.
But in a world in which computing power grows exponentially, such problems can
be solved in polynomial (or even linear) time!

Amos Shapir, The Hebrew Univ. of Jerusalem, Dept. of Comp. Science.
Givat-Ram, Jerusalem 91904, Israel  +972 2 585706,586950

Re: ACM Nightline (Kabay, RISKS-16.03)

Robert Morris <>
Wed, 11 May 1994 10:09:00 -0400
>...they have _no right_ to use the product without that contractual agreement.

This confuses several issues--that of theft, that of use and that of
licensing, and in an important case Kabay's implied position is wrong.
Certainly---and this is his main point---theft of intellectual property is
theft. However, property protected by U.S. intellectual property laws, notably
copyright and patent protection (especially the latter)---can not simply be
withheld from use at the whim of the owner. For example, patent holders MUST
license equally to all who meet reasonable terms. Indeed, the _purpose_ of
copyright and patent protection is to promote the widest possible access to
the new ideas by insuring that their creators have economic motivation to do
develop them. The owners of intellectual property who want to restrict its
distribution are expected to look to the trade secret laws to protect them.

I'm not sure what requirements are imposed on copyright holders (and as an
aside, I sure would like The National Computer Security Assn. to argue that
copyright, not patent, is the only appropriate form of protestation for
software! heh, heh, heh.), but I suspect they can not capriciously and
arbitrarily withhold copy permission from some but not others, and it will
even surprise me if they can put irrelevant terms in the copy permission. None
of this speaks to licensing, but (I speculate) the only legal culprit in a
licensing violation is the licensee who allowed the copy. And presumably that
contract violation is a civil, not a criminal matter in American law.

Bob, not an attorney, Morris

Don't always believe those E-Mail addresses

A. Padgett Peterson, Information Security <>
Wed, 11 May 94 08:17:46 -0400
One of the more subtle RISKS of E-Mail is in believing what you see.  Recently
a good friend of mine was repeatedly accused of posting not-so-nice messages
on various news-groups. Not so blatant as to be unbelievable but morally
damaging. This irritates me.

A few months ago I was flamed in RISKS for talking about the use of Ethernet
card firmware addresses as for tracking. Two weeks ago it enabled me to
quickly and positively identify the source of repeated failed attempts to log
into an Ethernet server as supervisor. When I asked the administrator for the
data in the log, he told me that he had never known that the six hex bytes had
a meaning.

Similarly, forged E-Mail is possible only because many E-Mail packages throw
away the Ethernet wrapper that made the communication possible in the first
place, a wrapper that *must* contain the return address or "the mail won't go

Here I have FTP Software's (plug) PCTCP which provides an MSDOS machine with
more built-in features than many UNIX implementations (won't go into them all
else it would be an adv't but will just say that it allows me to identify not
only the source, but the path used to get here).

For example what most people see in an E-Mail posting is this (lines have been
wrapped to 80 characters & true returns masked) - Judge and Goat are two PCs
in my office.

 From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34
 To: padgett@goat.ppp.qqq.rrr
 Return-Path: <Crusader_Rabbit@Jay.Ward.Cartoons>

 Demonstration of message headers.

What was actually received from the SMTP server was this but most
newsgroups & many mailers strip the "Received: from..." as above:

 From Crusader_Rabbit@Jay.Ward.Cartoons Wed 11 May 1994 07:34
 X-Envelope-To: padgett@goat.ppp.qqq.rrr
 Return-Path: <Crusader_Rabbit@Jay.Ward.Cartoons>
 Received: from judge.ppp.qqq.rrr ([123.456.789.000])
           by Goat.ppp.qqq.rrr (SMTPSRV); Wed 11 May 1994 07:34

 Demonstration of message headers.

Note that not only the originating name is sent but also the true IP
address [123.456.789.000]. Again this *must* be there.

Not to say that this is not a valuable capability since I prefer that
all incoming E-Mail come to a common point, just don't rely on them
since they can be *anything* the sender wishes.

Don't just toss those wrappers, dispose of them properly.


EFF's Kapor announces new cyberspace tv show

Stanton McCandlish <>
Tue, 10 May 1994 20:47:23 -0400 (EDT)
Stanton McCandlish * * Electronic Frontier Found. OnlineActivist

Forwarded message:
Date: Tue, 10 May 1994 09:13:23 -0400
From: (Mitchell Kapor)
Subject: My tv show

(I thought you might be interested in this.)

New Cyberspace TV Program

I am developing a new program on cyberspace in conjunction with WGBH-TV, PBS'
Boston affiliate.  The show is intended to be a window onto the world of
computer networks for the television viewer, whose point of view is that the
world of on-line communications is interesting because of what people do
there, not because of the digital plumbing which enables it.  We will be
focusing on the human aspects of networking and the individual and social
aspects of being on-line.  Cyberspace will be portrayed as a not-so-really
strange territory after all, where all of us will increasingly come to live
and work.  My role is to guide people through this new territory, introducing
the audience to its native culture, its scenic attraction, and its sights and

We assume our audience is motivated by curiosity to learn more about what goes
on in cyberspace, but we do not assume they are knowledgeable or, in general
experienced with it.  On the other hand, we will not trivialize the subject
matter by reducing it to a least common denominator.

We will give the show a look and feel which is approachable and down-to-earth.
Interview guests and roundtable participants will be drawn from the net
community itself.  There will be plenty of demos of cool net stuff from
Mosaic, CU See Me, and other cutting-edge applications and services.

We are taping two test shows in mid-June which will be shown in Boston and
other cities and hope to have some sort of national distribution (to be
determined) in the fall for a regularly scheduled program.  We are also going
to create a WWW server for the show, the segments of which will be
downloadable.  The server will be have on it additional material which won't
fit into the show format.

An Invitation:

We would like to include some video clips of net citizens expressing their
greatest hope and worst fear about the future of the net which we will edit
into an on-air piece for our regular feedback session.

It's important to me to have the voices heard (and faces seen) of people
already on the net.  This is an opportunity for those of us who enjoy
appreciate the decentralized and democratic character to express that
sentiment to a mass audience.  I hope you'll take advantage of the


Since an individual on-air clip will run at most 20-30 seconds, please keep
your statement succinct.

In shooting the clip, please feel free to pick a location which says something
about yourself, whether it's your computer, your pet, or the great outdoors.

We can accept Quicktime movies, VHS cassettes, or 8mm tapes.  If you enclose a
mailer, we will return your tape.  We can also pick up digital submissions
from any FTP site, etc.

Contact Information:


Postal: CyberTV
c/o Kapor Enterprises, Inc.
238 Main St., Suite 400
Cambridge MA 02142

Automation: request for input

Ken Funk <funkk@ENGR.ORST.EDU>
Thu, 28 Apr 94 06:59:08 PDT
Oregon State University, America West Airlines, and Honeywell are conducting a
study of flightdeck automation for the Federal Aviation Administration which
requires input from the scientific community.

The increasing use of automation on the flightdecks of commercial transport
aircraft has raised concerns about the overall safety effects of this
equipment.  While several studies have attempted to address some of these
automation issues, until now no one has tried to systematically identify all
issues that exist about flightdeck automation.  The objectives of this study
are to collect and compile a comprehensive list of all flightdeck automation
problems and concerns and to address them in order to identify or generate
recommendations and guidelines for the FAA, manufacturers, and operators.

To achieve these objectives we are soliciting information on automation
problems and concerns from individuals in a variety of disciplines.  When we
have compiled these problems and concerns we will prioritize them, study the
highest priority items using analytic methods and simulator studies, and
identify and develop recommendations based on our findings.

Although we are primarily targeting the aviation community for sources of
automation problems and concerns, we recognize that individuals in other
disciplines have knowledge of other kinds of system automation and know of
automation problems or have concerns about automation that would be very
relevant to our study.  Experts in computer science, human factors
engineering, psychology, and other fields often deal with the automation of
industrial systems, office equipment, and even consumer devices, so we welcome
information from them.

If you have direct knowledge about system automation and you know of problems
with or have concerns about the safety of such automation, you can help us by
filling out a copy of our Automation Problems and Concerns Questionnaire. This
is an opportunity for you to contribute to flight safety and, if you wish, we
will put you on our distribution list to receive copies of reports on the
results of our study.

If you would like to fill out a questionnaire, send a message to (don't post your request to this newsgroup!).  Request a
copy of the Automation Questionnaire, and I will send you a copy via e-mail.
When you have completed it (which should take between 15 and 30 minutes), just
e-mail the completed version back to me.  The problems and concerns you
identify will be added to our database and used in our study.

Ken Funk, Assistant Professor of Ind. and Mfg. Engineering, Oregon State Univ.,  (503) 737-2357  FAX: (503) 737-5241

Please report problems with the web pages to the maintainer