Text File

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)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. * RISKS MOVES SOON TO csl.sri.com. FTPable ARCHIVES WILL REMAIN ON KL.sri.com. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line (otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM. FOR VOL i ISSUE j / ftp KL.sri.com / login anonymous (ANY NONNULL PASSWORD) / get stripe:<risks>risks-i.j ... (OR TRY cd stripe:<risks> / get risks-i.j ... Volume summaries in (i.j)=(1.46),(2.57),(3.92),(4.97),(5.85),(6.95),(7.99).

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

Date: Fri, 3 Feb 1989 16:42:10 PST From: Peter G. Neumann <neumann@csl.sri.com> 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: Chalmers@DOCKMASTER.ARPA 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: sl@van-bc.UUCP (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.

Stuart.Lynne@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532

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

Date: Fri, 3 Feb 89 13:18:49 +0200 From: makela@tukki.jyu.fi 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: makela@tukki.jyu.fi, BitNet: MAKELA_OTTO_@FINJYU.BITNET BBS: +358 41 211 562 (V.22bis/V.22/V.21, 24h/d), Phone: +358 41 613 847 Mail: Kauppakatu 1 B 18, SF-40100 Jyvaskyla, Finland, EUROPE

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

Date: Thu, 2 Feb 89 14:05:09 gmt From: Jerome H Saltzer <jhs%computer-lab.cambridge.ac.uk@NSS.Cs.Ucl.AC.UK> Subject: Re: Massachusetts limits disclosure of driver's license database. (RISKS-8.19 ) [ From: <Saltzer@Athena.MIT.EDU> ]

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: ronni@juicy-juice.lcs.mit.edu (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 <Grant@DOCKMASTER.ARPA> 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 <AArsenault@DOCKMASTER.ARPA> 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: GORDON_A%CUBLDR%VAXF.COLORADO.EDU@CUNYVM.CUNY.EDU 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 <dan@WATSON.BBN.COM> 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 ************************