Black Box 4/BlackBox.cdr/textinfo/risks8a.arj/RISKS820.TXT

Text File | 1989-02-07 | 21.0 KB | 402 lines

RISKS-LIST: RISKS-FORUM Digest  Sunday 5 February 1989   Volume 8 : Issue 20

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

Contents:
  FAA and flying under pressure in Alaska (PGN)
  New use for Credit Cards (?) (Leslie Chalmers)
  Computer Chaos in Burnaby (Stuart Lynne)
  Swedish fighter plane crash (Otto J. Makela)
  Re: Massachusetts limits disclosure of driver's license database.
    (Jerome H Saltzer)
  "Computer Literacy Education" Report Available (Ronni Rosenberg)
  Engineering vs. Programming (Lynn R Grant)
  Re: Structured Programming (Al Arsenault, Allen Gordon, Dan Franklin)

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

Date: Fri, 3 Feb 1989 16:42:10 PST
From: Peter G. Neumann <[e-mail]>
Subject: FAA and flying under pressure in Alaska

Barometric pressure reached 31.85 inches at Northway, Alaska, on 1 Feb 89, the
highest ever recorded in North America, and the third highest in the world.
(This followed temperatures that unofficially reached -82 F; the official
weather bureau thermometer conked out at -80.)  Because most aircraft
altimeters could not provide accurate readings, the FAA grounded all air
traffic that would require requiring instrument approaches.  [Source:  San
Francisco Chronicle, 2 Feb 89, p. A2]

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

Date:  Sat, 4 Feb 89 15:47 EST
From: [e-mail]
Subject: New use for Credit Cards (?)

The following appeared in a newsletter from my company's travel
agency that came with an airline ticket I received recently.

  The phrase 'one card does it all' is taking on new meaning.  This month,
  Hyatt Hotels Corp. is testing a system that will allow a credit card to be
  used as a hotel room key.  When the guest checks in by presenting a credit
  card, the hotel's system will alert its in-house system to allow entry to the
  guest's assigned room when the guest's credit card is inserted.

  The new feature, to be tested at the Hyatt Regency in San Francisco, is just
  one element in the major hotel chains' efforts to increasingly cater to
  business travelers.

  Automated check-in and check-out systems - with 800 numbers and videos - are
  already in place in some hotels.  Watch for other chains to join the
  automation revolution.  Ramada Hotels is evaluating a similar program that
  allows check-in, room key use and check-out all using a cellular machine.
  Guests will be able to slip the card through a machine for automatic
  check-in, and the machine will assign the guest a room and encode that room
  to accept the guest's card.

  At check-out, a similar procedure is followed.  When more than one guest is
  staying in a room, the hotel can make a blank card that will allow room
  entry.

I would say their are many risks associated with this (but not obvious enough
for the hotels to notice), but the sentence that really stopped me was the last
one.  One interpretation of this is that the hotels will be equipped with
credit card duplicating machines, some of which won't even be restricted to
hotel employees! Granted, these duplicate cards won't *look* like real cards,
but they will probably be good enough to fake out any machine which reads the
mag stripe on cards.  (Telephones which take credit cards come to mind
immediately.)

An alternative interpretation is that the extra cards will be coded to contain
values that are recognized by the hotel security system but which are not
exact replications of the credit card mag stripe.  I sure hope this is right,
but somehow I doubt it.
                                             Leslie
(The usual disclaimers apply.)

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

Date: 4 Feb 89 08:01:59 GMT
From: [e-mail] (pri=-10 Stuart Lynne)
Subject: Computer Chaos in Burnaby
Organization: Public Access Network, Vancouver, BC.

Yet another example of a very poorly executed computer system!

From the Vancouver Sun, Thursday, February 2, 1989
  Burnaby's computer chaos started with obsolete system
  Jeff Lee - Sun Regional Affairs Reporter

A computer system Burnaby bought three years ago for $200,000 that ended up
costing more than $1.2 million to make operational was obsolete when it was
chosen, a report on the purchase indicates.  The report released this week,
also cited in-fighting among the muncipal departments, a flawed tendering
process and lack of detailed plan as key reasons why the project "ran out of
control."

Burnaby Mayor Bill Copeland said the report also shows council was not kept
informed of the problems encountered in trying to make a prepared database
system work effectively.  "It was not flagged for council. Even though some of
us (on council) were questioning the high cost of the system, at no time until
it was too late did our staff come forward and say the had problems," he said.
Copeland called the computer system "a money-eating monstrosity" and promised
to find out why staff never told council, and why they never caught on to the
fact the system was designed in 1965.  He said it is too early to tell if staff
will be disciplined, but council "is disappointed in our manager and director
of administration. It appears our staff did not advise us when they should have.

Rumours circulated

Copeland said rumors had been circulating for some time about the systems's
cost overruns, but no formal report was prepared until manager Mel Shelley
ordered an independant audit in mid-1988.  The report, prepared by consultant
Brian Mullen, not only showed the system was obsolete, but said the decision to
make "enhancements" to it to make it fit Burnaby's needs was unwise.  The
system failed an average of twice a week in 1988. It "is unreliable," Mullen
said.

The municipality chose New York-based Information Associates Ltd. to provide
the software after it received only two other bids, one of which was
disqualified at an early stage.  A staff report at the time said the system
would cost $118, plus an additional $70,000 to modify the software to Burnaby's
needs,.  Mullen said many computer companies would have bid on the project had
the system of tendering been relaxed. He said the terms of the bidding process
were so retrictive that companies would have had to spend up to $10,000
preparing for a $100,000 bid.  He also pointed the finger at infighting between
the information services department and other agencies over the choice of the
system.  Nearly $450,000 was spent on a computer consultancy firm that worked
for 2 1/2 years trying to make the system work.

Municipal manager Shelley said he is preparing a report for council for Monday,
and did not want to comment publicly before then.  A spokesman for Information
Associates' Canadian offices in Toronto could not be reached.

--- end of article ---

Comments:
    - note politician trying to CYA by claiming that he wasn't informed.
    - no overall plan
    - over restrictive tendering policies limited competitive bidding
    - office politics

Not noted in this article but mentioned in a smaller article last week was
the fact that the requirements where changed frequently.

I'm going to try and track down some more info next week. But it seems that
this is a clear case of incompentence on the part of the people in charge of
the project. They don't seem to have handled *anything* correctly.

[e-mail] {ubc-cs,uunet}!van-bc!sl    Vancouver,BC,604-937-7532

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

Date: Fri, 3 Feb 89 13:18:49 +0200
From: [e-mail]
Subject:  Swedish fighter plane crash

  The only existing prototype of the Swedish fighter plane JAS was destroyed
in a crash at Linkoping on Thursday.  The plane was making a landing after it's
7th test flight, when for reasons unknown the plane rolled sharply to it's
left, causing the left wingtip to hit the ground.  The plane then rolled wildly
to the left side of the runway, losing it's wings and landing gear.
Suprisingly enough, the main airframe was left relatively intact, and the
pilot escaped with a broken arm.
  According to specialists, the most probable cause of the accident was a
technical failure.  As the plane in question is designed for supersonic speeds,
it is non-stable at subsonics.  This would probably mean computer failure.
  The whole accident happened before the cameras of the TV-Aktuellt crew.
The fighter project has already been criticized severely, since is already 7
billion Swedish kronor (the American usage, ie 7000 million; around one billion
US$) over budget and 1 1/2 years late.  The Saab-Scania military airplane
section has contract for 30 JAS fighters at a fixed price, with an option for
150 planes more if there is an agreement on pricing.  The Swedish air force
has an estimated need for 300-400 planes after the year 2000.  Also the Finnish
air force has been interested in the plane.

Otto J. Makela (with poetic license to kill), University of Jyvaskyla

InterNet: [e-mail], BitNet: [e-mail]
BBS: [phone] (V.22bis/V.22/V.21, 24h/d), Phone: [phone]
Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE

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

Date: Thu, 2 Feb 89 14:05:09 gmt
From: Jerome H Saltzer <[e-mail]>
Subject: Re: Massachusetts limits disclosure of driver's license database.
         (RISKS-8.19 )
[ From:  <[e-mail]> ]

Jon Jacky comments,

  What I find notable about this story is the linkage between selling
  personal information in government databases to anyone who asks and
  legitimate law enforcement activities.  It seems in this case it is
  felt you cannot limit the first without hampering the other.  I can't
  tell from this account whether that is a technical consequence of the
  way the database works, follows from the legalities somehow, or is
  just a misconception.

The answer lies somewhere in between; it has little to do with computers or
online databases, and civil libertarians in Massachusetts have fought a running
battle on the subject for many years.  The Registrar of Motor Vehicles has
taken a position from time immemorial that your driver's license and your
vehicle registration are matters of public record, and it has always made all
the information in its files available to anyone who requests.  With the
automation of the Registry databases, the Registrar balanced the possibility of
increased invasion of privacy against the possibility of increased revenue to
the Registry (from selling the entire database on tape) and sprang for the
revenue.  Those of us who register their new car in Massachusetts are
accustomed to receiving computer-generated letters from rustproofing companies
that start out "Dear Mr. Smith: I'll bet you want to protect your investment in
your new Toyota. . ."

Occasionally someone makes some progress against this particular problem; a few
years ago the Registry grudgingly began to allow people to request that their
social security number not be used as their driver's license identification
number.  But this flexibility is not publicized, and only those with enough
interest in privacy to ask discover it.  As a result you can construct a list
of what some people would consider Massachusetts "troublemakers" by purchasing
the Registry database and going through it to look for identification numbers
that don't pass social security number validity tests.

The legal maneuvering that Jacky reported should be viewed in the light of the
traditional Registry position.  The first bid was to simply cut off all access
to the information; I doubt that anyone expected that position to hold, but it
had the entirely reasonable effect of forcing the Registry to make explicit
arguments about who really needed to share the information and why.  From a
strategic point of view, the procedure may have been close to optimum--it took
only two steps, and the result is certainly a big improvement.  It remains to
be seen whether or not the Registry finds some way to wriggle around the new
rulings.
                      Jerry Saltzer

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

Date: Thu, 2 Feb 89 00:28:59 EST
From: [e-mail] (Ronni Rosenberg)
Subject: "Computer Literacy Education" Report Available

Many thanks to all who sent me messages about computer literacy. In about
three weeks, my Ph.D. thesis will be available as a technical report from
MIT's Laboratory for Computer Science (LCS-TR-433, January 1989).  If you
would like a copy, you can request it from the lab or from me.

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

Date:  Wed, 1 Feb 89 16:00 EST
From: Lynn R Grant <[e-mail]>
Subject:  Engineering vs. Programming

Over the years I have heard many arguments about why engineering is a
science and programming is not, and I have even believed some of them,
since I went to engineering school before I got into the computer
business.  It has finally occurred to me what the real difference is.

Engineers do a better job of design, not because they are more professional
than programmers, but because they must.  When you design a radio or an
automobile, there are hundreds of people wo must get involved in order to build
it.  You can't sit down and discuss it with every one of them, so you must
clearly document what you want in order to give them half a chance of building
it right.

When you design a program, the design and the program can be one and the
same, so a lower level of design documentation is possible.

As evidence of the fact that engineers design better because they must, not
because they are by nature more professional, I submit the fact that
microprocessors are being put into all sorts of formerly hardware driven
devices, and hardware is being microprogrammed, for the most part, I believe,
to get around the great overhead of engineering documentation.  And we are now
getting hardware that has the same sort of failures caused by insufficient
design that we have always experienced in programming projects.

Lynn R. Grant,    Consultant,    Computer Associates International, Inc.
                  The opinions here are, of course, my own.

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

Date:  Thu, 2 Feb 89 13:02 EST
From: Al Arsenault <[e-mail]>
Subject:  Re: Structured Programming

I learned a couple of years ago that one can teach students some very valuable
lessons about what 'structured programming' really is and why it's useful while
they're at a relatively impressionable stage of their careers (I moonlight as
an instructor of computer science at a local university.)

I noticed that many students had as an overriding goal getting the programs
they write for class to work right - "style" and "structure" took a back seat
to generating the right output.  So, I assigned two projects, which were
identical except that a particular data structure had to be implemented one way
in the first assignment and a different way in the second one.  Then, I gave
the students approximately three weeks to complete the first assignment, but
only about one week to do the second.  (This was a second programming class for
most students, and the assignment took about 1,000 lines of Pascal code, so it
was a major undertaking for most student.)

The result was that those who had written the first program "properly" (i.e.,
lots of modularity, information hiding, and other buzzwords) had to make only a
few modifications to complete the second assignment, while those who had
programmed without any sense of structure got to write the entire thing over
from scratch.

Several former students have since told me that it taught them a very valuable
lesson, which they have carried with them into their professional careers.

It's something like spilling a drink on your keyboard:  once you've been burned
by something once, you usually learn not to do it again.
                                                             Al Arsenault

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

Date: Thu, 2 Feb 89 11:52 MST
From: [e-mail]
Subject: RE: Structured Programming (RISKS-8.19)

I would like to add an example to the discussion of structured code etc.
Several years ago I worked for a couple of years for a software house that
produced a turn-key accounting system.  It ran on a POINT 4 mini (DG NOVA
clone) under IRIS.  This is not a favorable environment for development! Worse
the entire system consisting of over 1000 modules was written in Business
Basic!.  To make the matters worse the system was written for the Leasing
Industry, which has perhaps one of most nightmarish accounting schemes
imaginable since there are lots of ways to structure leases.  Anyway, the
design of the database was, in principle, masterful.  There were master files
which contained the names and locations of virtually every file, field and
program, inaddition to the records and files which contained data.  On the
other hand the programs were written in a "spaghetti code", using 2-character
variable names (the limit for business basic).  No attempt was ever implemented
to use some of the tools available and precompilers.  Needless to say
maintenance was literally a nightmare.  Implementing changes were worse.  If a
field in a control or data file or record were changed, there was no way to
track which of the 1000 modules were affected until after the modified software
was put into use by the client and they screamed back at us.

The masterful design of the database was also one of its weaknesses.  Everytime
during data entry operations, a record was written to the database, a couple of
hundred disk reads had to be performed in order to get all of the locations,
etc., of the files, programs, etc.  Since this was a time share system,
multiplying that by 30 or 40 data entry operators in addition to other
personnel doing various system operations, brought the system to its knees.
The disk drives were simply overwhelmed with swapping and the necessary file
read and write operations.  Fixes were implemented but it was like installing
after-market items on a '56 chevy to make it go fast.  Of course even if the
programs were structured, the performance problem would not have been fixed.
The catch-22 was that because of the problems with maintenance we had no time
to implement real fixes.
                                  Allen Gordon

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

Date:     Fri, 3 Feb 89 13:39:12 EST
From: Dan Franklin <[e-mail]>
Subject:  Re: Structured Programming

A recent message on this topic asked if anyone was still carrying out
studies of what programming practices contribute to errors.  The
answer is emphatically yes!

"Delocalized plans" are one example of a programming practice that's
been demonstrated to cause errors.  This phrase refers to a procedure
for performing some action -- a "plan" -- whose steps are spread
through the actual code -- "delocalized".  Delocalized plans are a
fruitful source of maintenance errors, because maintenance programmers
generally don't (and often can't) read through an entire program
before they start making what appears to be a small, localized change.

One recent article on delocalized plans appears in CACM, Vol 31 No 11 (November
1988): "Designing Documentation to Compensate for Delocalized Plans" (Soloway
et al).  The article is a bit more general than the title implies; the general
problem of delocalized plans is discussed as well as documentation issues.
(This article is a follow-on to discussions of delocalized plans in the book
"Empirical Studies of Programmers", Soloway and Iyengar, Eds, Ablex, N.J.,
1986, as well as an article in IEEE Software, May 1986, "Delocalized Plans and
Program Comprehension".)

The authors discuss an experiment using a 14-module, 250-line Fortran program
that performs simple database operations.  Different programmers were asked to
modify the program to add an "undelete" feature, which would restore deleted
records in the database.  It looks like a simple task, because deleted records
are not actually removed, merely marked "deleted".  The trick is that the
obvious method of calling the search routine to find the record, then clearing
the deletion mark, doesn't work because the search routine skips over deleted
records.  In other words, deletion itself is done by a "delocalized plan" that
affects both the delete routine itself and the search routine.  Many
programmers asked to make the change didn't realize that.

This simple experiment shows a language-independent source of maintenance
errors and (to me, at least) indicates that to the extent practical, you should
try to group together all the steps that perform some operation, rather than
scattering them throughout the code.  Obvious?  Perhaps; but in a world where
some people think indenting code is a bad idea, even obvious conclusions
apparently need to be demonstrated.
                                                   Dan Franklin

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

End of RISKS-FORUM Digest 8.20
************************
-------