The RISKS Digest
Volume 19 Issue 10

Tuesday, 22nd April 1997

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…


Paperclip stopped trains in Finland
Jari M=E4kel=E4
2 jets in near-miss approaching LAX; pilot blames autopilot
Re: Air collision risk from increased accuracy
Mike Rogers
Privacy Legislation
Re: cyberstalker: house invasion a hoax
Ron Pfeifle
Re: cyberstalker: RISKS of assuming "high-tech"
Mich Kabay
Re: Hairiest Bug Stories
Steve Sapovits
Y2K and PARSLEY: Upgrade woes
Pete Mellor
Re: GMT and UTC
Martin Minow
Year-2000 Cost Estimates Rise
Re: RISKS screwups on time changes
Michael Bacon
Re: IVHS vehicles and safety assumptions
Alan M. Hoffman
Mich Kabay
Law Review Article on Spam
Martin Minow
Re: Risks of automatic spam blockers
Dimitri Vulis
Re: "Crack A Mac" contest
Martin Minow
Addendum to DES Challenge RISKS
Thomas Koenig
Re: 11-digit dialing
Lauren Weinstein
Reminder on Privacy Digests
Info on RISKS (comp.risks)

Paperclip stopped trains in Finland

Jari =?ISO-8859-1?Q?M=E4kel=E4?= <>
22 Apr 1997 12:53:41 +0300
The leading Finnish newspaper Helsingin Sanomat
<URL:> reported on 20 Apr 1997 that a
paperclip dropped into a traffic-control computer stopped all trains in
southern part of Finland for one hour Saturday 12 Apr between 22:30 and 23:30.

The paperclip had been in the traffic control spare machine under the space
bar approximately from Wednesday. It caused the machine to repeatedly
request login for three days, filling the hard drive.  After this, the spare
machine started to hinder the work of the main traffic-control computer,
which finally turned all the train control signs to "stop".

A SW expert from the company that had made the control program found that a
faulty keyboard was the reason for the incident and replaced the keyboard.
The paperclip was found later in next Monday.

VR Ltd Finnish Railways <URL:> claimed that the
computer failure did not create any danger to the travellers.

Jari M=E4kel=E4
  [They were going at quite a clip until the Finnish ...?  PGN]

2 jets in near-miss approaching LAX; pilot blames autopilot

"Peter G. Neumann" <>
Fri, 18 Apr 1997 11:56:32 PDT
There was a close call on approach to LAX on 16 Apr 1997, involving a KLM
747 inbound from Amsterdam and a Brazilian VASP MD-11 inbound from Osaka.
The MD-11 pilot apparently failed to follow the air-traffic controllers'
instructions for a tight turn on final approach, drifting across the
approach route of the 747.  The pilot of the MD-11 reportedly told
controllers that the autopilot ``didn't make the turn.''  But the pilot is
ultimately responsible, and an FAA spokesman said that the pilot could have
overridden the autopilot.  A National Air Traffic Controllers Association
spokesman said that tapes suggested problems with the autopilot gear,
although ``It could be the way they programmed it.  It could be a crew
oversight.  It could be lots of things.''  [Source: A *Los Angeles Times*
item, seen in the *San Francisco Chronicle*, 18 Apr 1997, A12]

Re: Air collision risk from increased accuracy (Brooks, RISKS-19.07)

Mike Rogers <>
Mon, 21 Apr 1997 19:17:30 -0400
In RISKS-19.07, John Brooks <> discusses the issue
of the accuracy of GPS and wonders if it increases the risk of collision
between 2 aircraft flying reciprocal courses, as the aircraft can now follow
that course more accurately than was possible with other navigation aids.

Unfortunately, a mid-air collision has occurred in Canada between 2
commercial aircraft that was, in part, caused by both aircraft following
reciprocal GPS courses.  In this case, the altitude separation between the
aircraft was lost as one aircraft was climbing away from the airport while
the other one was descending towards it.  This accident occurred near Soux
Lake, Ontario, where there isn't radar coverage that could have assisted in
ensuring that the planes were separated.

In the report from the Canadian Transportation Safety Board, (available
online at one of the conclusions
listed was:

  The probability of a collision between aircraft using GPS on established
  air routes is significantly higher than between aircraft using
  conventional navigation aids because of the greater accuracy of navigation
  using a GPS.

As a result of this, Transport Canada has suggested that pilots laterally
offset their navigation tracks.  However, I don't know if this has been
standardized to ensure that all pilots are doing this consistently.

Mike Rogers

Privacy Legislation

Edupage Editors <>
Thu, 17 Apr 1997 16:44:35 -0400 (EDT)
Senators Dianne Feinstein (D, California) and Charles Grassley (R, Iowa)
have introduced legislation that would bar commercial use of Social Security
numbers and make it illegal for credit bureaus to disseminate Social
Security numbers, unlisted phone numbers, birthdates, or individuals'
mothers' maiden names.  In the House of Representatives, Congressman Paul E.
Kanjorski (D, Pennsylvania.) submitted legislation that would create a
Commission on Privacy of Government Records and ban Social Security or
Internal Revenue Service records from being posted on the Internet without
an individual's written permission.  [Washington Post 17 Apr 1997; Edupage,
17 April 1997]

Re: cyberstalker: house invasion a hoax (Re: RISKS-19.08)

Ron Pfeifle <>
Mon, 21 Apr 1997 10:48:17 -0400 (EDT)
RISKS-19.08 (techno-harassment) outlines the report of the case of a
Windsor, Ontario family plagued by someone who, apparently, bugged their
home and was able to break in on telephone conversations at will, change TV
stations, etc...  all completely without detection, baffling security

This morning, CBC radio reported that the perpetrator ("Sommy") had been
caught — he was, apparently, the family's 15-year-old son.  The supposed
high-tech telephone tapping was simply him picking up on another line in the
middle of a conversation.

In light of this revelation, I reread the original RISKS article.  The
actions of a sinister stalker were transformed, on second reading, into the
very childish and inconsiderate running prank of an immature teenager.

With the sharpness of 20-20 hindsight, let me offer a few comments:

 o Occam's Razor:  The rather more exciting supposition that some nasty
   person with a lot of complicated hi-tech equipment, long term schemes (in
   order to have wired up the house for this kind of control) and sinister
   motives was chosen before ruling out the far, far simpler, but certainly
   less interesting possibility that someone within the home was doing the
   dirty work.

 o Square hole, round peg: Once you adopt that first assumption (hi-tech),
   explanations not involving hi-tech (round peg) can't be entertained
   because they just can't account for the bizarre behaviour.

 o To place this in a computer RISKS context, this sort of thing happens all
   the time in the software realm (a bug with mysterious magical symptoms
   appears in that defies your debugging efforts).  In order to understand
   and fix the bug, you often have to re-evaluate you basic assumptions
   about the nature and behaviour of the system in question (again, common
   fodder for RISKS postings).

Ron Pfeifle

Re: cyberstalker: RISKS of assuming "high-tech" (Re: RISKS-19.08)

"Mich Kabay [NCSA]" <>
Mon, 21 Apr 1997 18:41:34 -0400
"Emeryville Horror" due to victimized family's 15-year-old son

In what police apparently have suspected for some time, the "cyberstalker"
who made life miserable for Dwayne and Debbie Tamai at her new house in
Emeryville, ON, a small town near Windsor, was actually their 15-year-old
Son Billy.  [Stuff already reported in RISKS-19.08 omitted.]  The family, in
despair, put up their house for sale but had little hope of receiving a
decent price for a house under attack.  However, when police got permission
to question Billy, he immediately confessed that he was entirely responsible
for the mess.  It had started off as a prank and he had been unable to stop
it.  The child is likely to receive psychiatric help.

M. E. Kabay, PhD, CISSP (Kirkland, QC) / Director of Education, National
Computer Security Association (Carlisle, PA) /

Re: Hairiest Bug Stories (PGN, RISKS-19.09)

Steve Sapovits <>
Fri, 18 Apr 1997 12:24:33 -0400
A while back [RISKS-16.74] I posted a similar bug story to risks regarding a
program which failed in October, November, and December because the numeric
representations of these months have two digits instead of one.  One thing I
might not have mentioned in that post was that the solution mostly involved
"decoding" the interface.  "Decoding" is a term some co-workers and I coined
to describe the process of taking unnecessary complexity out of computer
code.  It's pretty amazing how some people can take a simple problem and
turn it into a complexity nightmare when code is involved.

In this particular case there was a whole big mess of C code using various
buffers, string copies, string concatenations, direct setting of characters
in strings, and numeric-to-string conversions to build a date string.  I
can't remember how many lines of code existed when I started decoding it,
but I do remember that the decoded version was a simple switch statement
with three cases, each of which had one sprintf() call.  The various buffers
used to hold all the intermediate pieces in the starting code resolved down
to one buffer.

I'm not the only one to notice that overly complex programming often
gets rewarded.  By overcomplicating things, a few things can happen:

1)  It takes more time to complete the task and usually requires
    lots of extra hours.  Hard work and long hours are often
    perceived to be a good thing even if they're being spent on
    something that wouldn't be necessary if the right solution
    had been applied to the problem.

2)  Overly complex code is usually very buggy requiring "heroic"
    bug fixes (more hard work and long hours).

3)  It's typically difficult for anyone except the person who
    created the mess to really understand how it all works.  This
    increases that person's value and often elevates them to guru
    status in the eyes of those who don't know any better.

I believe Rube Goldberg would have thrived as a programmer.

All the best programmers I've worked with have been good decoders.  Not
coincidentally, interfaces these people write tend to be clean and simple.
Maybe decoding should be part of every college Computer Science curriculum.

Steve Sapovits  N2K Telebase (  E-Mail:

Y2K and PARSLEY: Upgrade woes

Pete Mellor <>
Sun, 20 Apr 1997 19:21:12 +0100 (BST)
A friend of mine runs his own photographic processing business, and uses a
certain OTS package for accounting, etc.  The package in question has a name
like some kind of herb, so let's call it PARSLEY. :-)

My friend pays a maintenance charge which entitles him to receive
automatically all upgrades to PARSLEY.  He is aware of the Y2K bug, and
asked his friendly support person which release of PARSLEY would be
guaranteed "Millennium friendly".

Well, er, ... , none, to be precise.  There is something coming down the
line which will be Millennium proof, but that will be sold as a new product,
for which my friend must fork out a separate licence fee.

Anyone else out there had a similar experience with herb-like OTS software?

Peter Mellor, Centre for Software Reliability, City University, Northampton
Square, London EC1V 0HB, UK.  +44 (171) 477-8422,

  [My *sage* advice is that *thyme* is running out.  Although this kind of
  strongarm nonsense can really affect your *basil* metabolism, it seems to
  be an industry standard to force you to buy new versions.  The anti-virus
  folks certainly make a *mint* out of it!  PGN]

Re: GMT and UTC (RISKS-19.08)

Martin Minow <>
Tue, 15 Apr 1997 16:34:00 -0700
I wandered around the Royal Greenwich Observatory site for a few minutes,
but couldn't find an explanation of the difference, if any, between GMT and
UTC (on that site). The USNO clock, however, *does* show different times.
Poking around here and there, you'll discover that almost everyone (except
USNO) assumes that GMT is identical to UTC.  For example, consider the
Orlando Sentinel's timezone site at
<> where the
USNO clock, reading UTC, is labelled as "London (GMT)"

A site that appears to do PR for Greenwich, England,
<> reads, in part:
"In 1880, Greenwich Mean Time was made the legal time of Great Britain"

I'd really like to get an authoritative answer — it's starting
to be as interesting as the "Is 2000 a leap year" question.


  [Martin was not sure that this was RISKS-worthy.  However, I liked it.  PGN]

Year-2000 Cost Estimates Rise (Edupage)

Edupage Editors <>
Thu, 17 Apr 1997 16:44:35 -0400 (EDT)
Labor costs for Year-2000 projects have risen 30% since last year, when they
averaged $60 an hour, and they're still climbing, says an analyst at the
Gartner Group.  The revised labor cost works out to about $1.50 per line of
code, up from $1.10, causing Gartner to up its widely cited estimate of $300
billion to $600 billion for all corporate Year 2000 projects.  A study
released by Morgan Stanley & Co. last week suggests that companies could
save some money by replacing some code with packaged software and discarding
some of the 35 million lines of code that are typical for a large company's
computer system.  Meanwhile, a study of 24 federal agencies by Federal
Sources Inc. estimates that it will cost about $5.6 billion for the federal
government to rewrite all of its code to be Year-2000-compliant.  That's
about 2-1/2 times higher than an estimate submitted to Congress in February
by the Office of Management and Budget.  (*Information Week* 7 April 1997;
Edupage, 17 April 1997]

Re: RISKS screwups on time changes (RISKS-19.08)

"Michael Bacon" <>
Tue, 22 Apr 97 06:43:49 UT
Although maybe not reported in RISKS, I have it on good authority that
around 1988/89 a well-known financial institution experienced what could
have amounted to a very significant loss of funds, but was fortunately
confined (they believe) to test transactions, when their ATM system
overwrote the transactions performed in the hour 'lost' when the clocks were
put back.

Re: IVHS vehicles and safety assumptions (Mintz, RISKS-19.08)

"Alan M. Hoffman" <>
Wed, 16 Apr 97 15:40:01 -0400
>I see that type of "trusting" as qualitatively different ...

This brings to mind a discussion I once had with a McDonell-Douglas test
pilot about the risks of automated, "fly-by-wire" systems in modern
fighters.  It seems the newer jets (e.g., F-22) are NOT designed to be
aerodynamically stable; an major electronic failure could result in the
aircraft literally falling out of the sky.

He argues that the electronics are designed with a greater safety margin
than other critical components.  It is statistically more likely that a
control rod will break, for example, than the electronics and backup systems
will fail.  Meanwhile, he says, there is an advantage in "being able to
update the performance characteristics with the next software download."

Risks, as follows:
1) Trusting computers to be more powerful than physical laws.
   (aerodynamic stability vs. software control)
2) Trusting software engineers to deliver a "bug-free" product.
   (Ariane-5, anyone?)
3) The potential of building a "glitch" into military hardware which an
   enemy could reverse-engineer and exploit. ("The Death Star plans are NOT
   in the main computer!")

Alan Hoffman  Prepress consultant  digital INK

Re: IVHS vehicles and safety assumptions (Mintz, RISKS-19.08)

"Mich Kabay [NCSA]" <>
Thu, 17 Apr 1997 07:25:17 -0400
> ... "the laws of physics are irrelevant, ...

See the INFERNO series by Roger MacBride Allen (ACE Books, NY), where the
author explores precisely these consequences of Asimov's Laws of Robotics.

M.E. Kabay, PhD, CISSP (Kirkland, QC), Director of Education
National Computer Security Association (Carlisle, PA)

Law Review Article on Spam

Martin Minow <>
Sun, 20 Apr 1997 15:54:16 -0700
contains a long article on legal issues surrounding spam that might be
interesting to some afflicted readers.

Summary: "This article considers the recognized means to avoid the tragedy
of the commons--self-regulation, regulation by market forces, and government
regulation--and concludes that some government regulation of unsolicited
commercial solicitations in a unified medium is likely to be necessary and
will be permissible under the prevailing interpretation of the First


Re: Risks of automatic spam blockers (Curtin, RISKS-19.04)

Dr.Dimitri Vulis KOTM <>
Thu, 17 Apr 97 19:49:30 EDT
On the risks of issuing NoCeMs

I've been issuing NoCeMs for off-topic articles in several newsgroups (both
global Usenet and the nyc.* hierarchy) since the summer of '96.  I've
received two legalese threats of legal action from posters of material that
matched my criteria of being off-topic.

1. Michael Weir, a recruiter from Canada, insisted on posting job ads in
an unmoderated discussion newsgroup whose charter prohibits job ads and
resumes. He threatened to sue me for using his name in the NoCeM notices.
He also posted a series of abusive flames about me. A search of DejaNews
revealed several articles from him in Canadian newsgroups discussing
his litigations and asking for personal information about a judge.
Eventually he went away.

2. The "New York Theosophical Society" insists on posting in the local
newsgroup nyc.seminars (usually used to announce, what else, seminars).  One
Bart Lidofsky responded to the NoCeM articles by saying:

"I consider these messages to be a form of harassment, and will treat them
as such."

I have also seen several claims that the NoCeM notices themselves are
"spam".  Apparently, this term now applies to any traffic that the user
doesn't like for any reason.

I understand that other issuers of NoCeMs have also received threats, and at
least one poster has been forging old-fashioned cancels for the NoCeM
notices that mention his articles (another good reason to stop processing
all old-fashioned cancels).

Dimitri "co-proponent of news.lists.filters where NoCeM notices are posted"

Re: "Crack A Mac" contest (RISKS-19.07)

Martin Minow <>
Tue, 22 Apr 1997 07:51:33 -0700
In a note to the RISKS moderator, Jonathan Thornburg
<> asked several questions regarding the
Swedish "Crack-A-Mac" contest.  I forwarded those questions to Joakim
Jardenberg <>, who was responsible for the contest, and he
sent me some answers — which I have translated, changing Joakim's first
person to third person so I can editorialize without putting words in his

Jonathan asks: "Did the "around 30 minutes" installation time include the
time taken to" find two small shareware programs on the net, download them,
verify their digital signatures "to ensure the programs hadn't been tampered
with, and set them up?"

No, Joakim already had these products and had tested and evaluated them on
another computer before installing them in the contest machine.  The
shareware programs were not signed.

Jonathan: "Mac web servers may indeed offer excellent security and/or be
easier to administer than some of their competitors, but if they require
extra software add-ons to work reliably, then it's unfair not to count those
add-ons when assessing security, ease of administration, etc."

Joakim notes that installing add-on utilities is an ordinary and necessary
part of a webmaster's everyday functions. This is in no way unique for the
MacOS.  For example, no operating system had built-in protection against
"ping" attacks.  Several vendors posted fixes on the Internet.  Joakim
wonders how many system managers who used these fixes to patch their system
verified the patches using digital signatures?  "To be honest, I [Joakim]
think that these questions — attacks — are a bit silly as they don't have
anything to do with overall system usability.  I wanted to test a
narrowly-focussed security area, and the Mac fulfilled my expectations.
Look for some other tests in 'Crack-A-Mac, the Next Generation.'"

- -----

I would point out that Jonathan's concerns are quite real, and will become
more important as Internet-based software distribution becomes more
pervasive.  PowerTalk, a now discontinued variant of the Macintosh operating
system, supported RSA digital signatures, and they are supported by the
major Macintosh file archiving product.   Both Java and Microsoft's Active-X
support code signing which, ignoring the issues raised in several previous
Risks posts, is will be an essential part of a well thought-out Internet
distribution strategy.

Martin Minow

P.S.: PowerTalk, in addition to supporting digital signatures and secure
(encrypted and authenticated) networking, added considerable complexity to
the MacOS, proved quite difficult to program effectively, and was not
well-received in the marketplace.  I suspect that many of the PowerTalk ideas
will be re-invented and re-implemented over the next few years.

Addendum to DES Challenge RISKS (RISKS-19.09)

Thomas Koenig <>
Mon, 21 Apr 1997 14:37:04 +0200 (MET DST)
Apparently, the organizers of the Swedish effort have now come to the
conclusion that a source code release is beneficial.  According to their web
page, they are working on a release which includes other kinds of integrity

Thomas Koenig,, ig25@dkauni2.bitnet.

Re: 11-digit dialing (Seecof, RISKS-19.09)

Lauren Weinstein <>
Thu, 17 Apr 97 16:45 PDT
Mark Seecof reported on the availability of 11 digit local dialing in San
Diego.  Be warned that *counting* on this always working may be somewhat
premature.  Here in the (818) portion of L.A. over the last year or so, I've
noted exchanges where 11 digit dialing of local numbers worked and others in
the same area where it was impossible.  Even worse, in some cases it would
only work sporadically even in those exchanges where it had at one time been
observed to function.

The trend is definitely toward permitting 11-digit local dialing.  The
widespread introduction (delayed far too long, in my opinion) of area code
overlays depends upon this functionality.  But be careful about expecting
such dialing to work every time at this point.

--Lauren--  Moderator, PRIVACY Forum

Reminder on Privacy Digests

Peter G. Neumann <RISKS moderator>
17 Apr 1997
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.  It includes a digest (which
  he moderates quite selectively), archive, and other features, such as
  PRIVACY Forum Radio interviews.  It is somewhat akin to RISKS; it spans
  the full range of both technological and nontechnological privacy-related
  issues (with an emphasis on the former).  For information regarding the
  PRIVACY Forum, please send the exact line:
     information privacy
  as the BODY of a message to ""; you will receive
  a response from an automated listserv system.  To submit contributions,
  send to "".

  PRIVACY Forum materials, including archive access/searching, additional
  information, and all other facets, are available on the Web via:

* 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