The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 17 Issue 23

Thursday 3 Aug 1995


o Minneapolis homeless burn out US West Internet connection
Joyce K Scrivner
o A Monkey Wrench in Ford's Floppy Promotion
Padgett Peterson
o Total surveillance on the highway
Phil Agre
o Computerized prognoses for critically ill hospital patients
Lauren Wiener
o Watch-ing the detectives
Mark Eckenwiler
o Intel-Hacking Conviction
Mich Kabay
o Re: Tenth Anniversary Issue
Mark Seecof
Dave Parnas
o Re: Limits to Software Reliability
Pat Place
D. King
o Call for Papers - 1996 IEEE Security and Privacy Symposium
John McHugh
o SEI Symposium: 1995 Software Engineering Symposium
Purvis Jackson
o Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.

Minneapolis homeless burn out US West Internet connection

"Scrivner, Joyce K" <>
Wed, 02 Aug 95 16:15:00 CDT

Sometime during 28 July 1995, a chilly evening, a group of homeless located under one of the Minneapolis bridges started a fire. This fire melted three fiber-optic cables connecting some local systems to the Internet. The media (radio, television and print) reported all local access to the Internet was gone, but phone service (including long distance) was still available. I didn't see any correction(s) reporting some Internet access was through phone lines. Nor did I hear what happened to the `homeless'.

[Michael Ayers <> noted an article in the *Minneapolis StarTribune* on 30 July 1995, which added that a copper cable also went out, and that most voice calls were rerouted automatically, but data transmissions were not. PGN]

A Monkey Wrench in Ford's Floppy Promotion (Edupage, 1 Aug 1995)

Edupage <>
Tue, 1 Aug 1995 21:22:31 -0400

Ford Motor Co. decided its latest PR blitz would include a high-tech twist — a press kit on a floppy disk. The only problem is, the disk contained a "monkey virus," which, among other things, can make it appear as if all the data's been erased from the hard drive. "Just don't use it," says a Ford spokesman, who couldn't explain how the disks could have become contaminated. Ford followed up by sending all recipients apologetic letters via, you guessed it, snail mail. (Tampa Tribune 31 July 1995, B&F2)

A Monkey Wrench in Ford's Floppy Promotion (RISKS-17.23)

A. Padgett Peterson <>
Thu, 3 Aug 95 10:32:47 -0400

This would be funny if not so sad & is just the latest of a long line of manufacturers who have sent out infected disks. PB gave us the MusicBug early in this decade (still have some sealed floppies if there is any doubt). Intel gave us the Michelangelo.

The depressing fact is that the *easiest* thing to detect is a boot sector virus on a floppy disk since it is always changes one specific sector that should always be the same. Five years ago I wrote a generic freeware floppy boot sector virus detector/restorer (FixFbr). It still works.

IMNSHO though, anyone who sends out a floppy disk to unsuspecting people without knowing exactly what is on the disk (would be easy to do random sampling and compute/compare every byte with a certified master - take about five minutes per disk and would only require that one be checked from each batch) has not exhibited "due care". Said this in print in 1992 and have been saying ever since. Where is Ralph Nader when you need him ?

The RISK is not that there was a virus on the disk. The real RISK is of a manufacturer does not know *exactly* what IS on the disk, the virus is just a symptom of a much deeper problem.

CAVEAT: have not seen the disk (yet - would like one for my collection) but this note seemed to come from a reputable source. Tried calling Ford but no-one seemed to know what I was talking about. The fourth person did agree to try to find out & said they would call back. RSN. My opinion of any such incident still stands.


Total surveillance on the highway

Phil Agre <>
Tue, 1 Aug 1995 17:51:20 -0700

A controversy is growing around the failure of "Intelligent Transportation System" programs in the United States to exercise any leadership in the adoption of technologies for privacy protection. As deployment of these systems accelerates, some of the transportation authorities have begun to recognize the advantages of anonymous toll collection technologies. For example, if you don't have any individually identifiable records then you won't have to respond to a flood of subpoenas for them. Many, however, have not seen the point of protecting privacy, and some have expressed an active hostility to privacy concerns, claiming that only a few fanatics care so much about privacy that they will decline to participate in surveillance- oriented systems. That may in fact be true, for the same reason that only a few fanatics refuse to use credit cards. But that does not change the advantages to nearly everyone of using anonymous technologies wherever they exist.

Let me report two developments, one bright and one dark. On the bright side, at least one company is marketing anonymous systems for automatic toll collection in the United States: AT/Comm Incorporated, America's Cup Building, Little Harbor, Marblehead MA 01945; phone (617) 631-1721, fax -9721. Their pitch is that decentralized systems reduce both privacy invasions and the hassles associated with keeping sensitive records on individual travel patterns. Another company has conducted highway-speed trials of an automatic toll-collection mechanism based on David Chaums digital cash technology: Amtech Systems Corporation, 17304 Preston Road, Building E-100, Dallas TX 75252; phone: (214) 733-6600, fax -6699. Because of the total lack of leadership on this issue at the national level, though, individuals need to do what they can to encourage local transportation authorities to use technologies of anonymity. It's not that hard: call up your local state Department of Transportation or regional transportation authority, ask to talk to the expert on automatic toll collection, find out what their plans are in that area, and ask whether they are planning to use anonymous technologies. Then call up the local newspaper, ask to talk to the reporter who covers technology and privacy issues, and tell them what you've learned.

On the dark side, here is a quotation from a report prepared for the State of Washington's Department of Transportation by a nationally prominent consulting firm called JHK & Associates (page 6-9):

Cellular Phone Probes. Cellular phones can be part of the backbone of a region-wide surveillance system. By distributing sensors (receivers) at multiple sites (such as cellular telephone mast sites), IVHS technology can employ direction finding to locate phones and to identify vehicles where appropriate. Given the growing penetration of cellular phones (i.e., estimated 22% of all cars by 2000), further refinements will permit much wider area surveillance of vehicle speeds and origin-destination movements.

This is part of a larger discussion of technologies of surveillance that can be used to monitor traffic patterns and individual drivers for a wide variety of purposes, with and without individuals' consent and knowledge. The report speaks frankly of surveillance as one of three functionalities of the IVHS infrastructure. (The others are communications and data processing.) The means of surveillance are grouped into "static (roadway-based)", "mobile (vehicle-based)", and "visual (use of live video cameras)". The static devices include "in-pavement detectors", "overhead detectors", "video image processing systems", and "vehicle occupancy detectors". The mobile devices include various types of "automatic vehicle identification", "automatic vehicle location", "smart cards", and the just-mentioned "cellular phone probes". The visual devices are based on closed-circuit television (CCTV) cameras that can seve a wide range of purposes.

The underlying problem here, it seems to me, is an orientation toward centralized control: gather the data, pull it into regional management centers, and start manipulating traffic flows by every available means. Another approach, much more consonant with the times, would be to do things in a decentralized fashion: protecting privacy through total anonymity and making aggregate data available over the Internet and wireless networks so that people can make their own decisions. Total surveillance and centralized control has been the implicit philosophy of computer system design for a long time. But the technology exists now to change that, and I can scarcely imagine a more important test case than the public roads. People need to use roads to participate in the full range of associations (educational, political, social, religious, labor, charitable, etc etc) that make up a free society. If we turn the roads into a zone of total surveillance then we chill that fundamental right and undermine the very foundation of freedom.

Phil Agre, UCSD

Computerized prognoses for critically ill hospital patients

Lauren Wiener <>
Wed, 02 Aug 95 09:33:44 -0700

The 31 July 1995 issue of _Forbes_ includes an article (pp. 136-7) on the products of Apache Medical Systems, which predict patient outcomes based on a database of "400,000 hospital admittances covering 100-odd diseases. From these statistics Apache's software can predict patient survival with an accuracy that can *sometimes* beat that of doctors' hunches." [fake italics mine]

The software is intended to guide the doctor's choice of treatment. Several examples are given, include a rather chilling one in which the supposed objectivity of the computer is enlisted to coax a husband for permission to take his wife off a respirator and let her die. The doctor who founded the company (Dr. Knaus) is quoted as saying he created the system because "I wasn't smart enough to figure out what to do in each situation." Another highlight: "Many hospitals adopted the Apache system to cut costs and measure quality in intensive care units."

The article closes with a brief discussion of the ethical issues, in which Dr. Knaus says: "If I were [the patient], I would want to be judged on Apache. It knows only those facts that are relevant to my condition, not race or insurance coverage, which have been used to allocate care in the past."

In other words, the computerized system is good because it is an improvement over a deeply flawed, inequitable, and racist system?

Watch-ing the detectives

Mark Eckenwiler <>
Wed, 2 Aug 1995 18:26:06 -0400

*The New York Times* 2 Aug 1995 contains a story about the apprehension of a homeless man as a murder suspect in NYC. Apparently, a digital wristwatch not belonging to the victim was discovered near her body on the floor of her apartment. NYC police found a number stored in the watch's memory, which they identified as an account number at Banco Popular de Puerto Rico, a bank with several branches in NYC.

Having previously been evicted from his home (his mother's residence), the suspect was homeless and therefore not easily located. Police solved this problem by asking the bank to put a hold on the account, which showed a history of monthly veteran's benefit check deposits. The suspect showed up at various branches to withdraw money, was turned away on each occasion, and eventually appeared at one of the remaining branches (which was staked out by the police).

He is now in custody, and was scheduled to be arraigned today on charges of murder and attempted rape.

Mark Eckenwiler

Intel-Hacking Conviction

"Mich Kabay [NCSA Sys_Op]" <>
31 Jul 95 23:09:52 EDT

From the Reuters news wire via CompuServe's Executive News Service:

Computer expert convicted of hacking at Intel

PORTLAND, Ore., July 26 (Reuter, 26 Jul 1995) - A computer-programming expert has been convicted of hacking his way through an Intel Corp. computer network in what he claimed was an effort to point out security flaws. Randal Schwartz, 33, was convicted Tuesday on three counts of computer crimes after a 2 1/2 week jury trial in Washington County Superior Court. [He was convicted of stealing passwords, and making unauthorized changes in Intel network.]

Comments from MK: Another story confirming the old principle that you do NOT attempt to improve security by busting it without getting _written_ authorization from an appropriate officer of the organization. This is known as the CYA principle.

M.E.Kabay,Ph.D. / Dir. Education, Natl Computer Security Assn (Carlisle, PA)

Re: Tenth Anniversary Issue

Mark Seecof <>
Tue, 1 Aug 1995 13:53:01 -0700

Okay, now that I've seen RISKS-17.22 I can't contain my desire to offer up my opinion. I've followed RISKS closely for 6 years; I paid less complete attention before that. I've learned a heck of a lot from RISKS; it has a remarkable signal-to-noise ratio for which I thank PGN first (3 cheers for our leader; hip, hip...) and the many wise and thoughtful contributors immediately after. But you see, it's not enough. I mean, RISKS, like any other voluntary, self-selected-participation communication forum, isn't enough to counteract the problems in the industry.

Very many of the items and issues discussed in RISKS reveal that the perpetrators of the problems either missed or ignored the lessons of those who went before. Remember the SGI development memo in RISKS-15.80? Just about every problem identified in that memo had been discussed in Fred P. Brooks' _Mythical Man Month_ years before. And the SGI folks had NO CLUE. I could adduce hundreds of similar examples of people with "new" problems documented in RISKS that were really variations on OLD problems. Okay, so some problems come up over and over. But the shared experience of practitioners (shared through books, articles, RISKS, etc.) ought to help people (a) avoid, (b) mitigate or minimize, and (c) fix such problems, but it seems like many people walk right past the bridges and jump into the chasm. Now, I'll admit that when someone *avoids* a problem or class of problems successfully, that doesn't often get written up in RISKS. Perhaps RISKS suffers from the same "bad news sells" syndrome that politicians like to denounce in newspapers. But somehow (based on my personal experience in the industry plus what I pick up...) I don't think reality is that simple or that happy.

We need RISKS. We need the books by Brooks, and Don Norman, and all the others. We need the articles, the conferences, and even the water-cooler bull-sessions.

But what we really need is to figure out how to reach the practitioners who aren't curious about these issues. Perhaps we can try to influence the early training of programmers. Maybe every "Dumbkopf's Guide to C++" book ought to have some RISKS horror stories in it. Perhaps we could arrange out-of-band rewards (ACM prizes?) for developers who do-the-right-thing and encrypt their password files, use checksums to validate key entry of patient-record-ID's, apply systematic design principles to their projects, provide useful documentation, etc.

One factor that seems to promote a great many problems is schedule pressure. Under schedule pressure developers stop building tools before production parts, abandon formalized methods, choose not to implement RAS-critical or testability items on the theory that they'll take too long, postpone preparing documentation (often forever), and so forth. We fancy-pants RISKS readers know that these are often false economies. Whatever system may emerge from a panicked development will likely have many problems. Worse, we know that panic frequently will not shorten the delivery schedule, since every foolish economy will be offset (sometimes exceeded) by cost (time and money) to correct its effects. We have to come up with good methods to avoid problems that everyone believes will shorten schedules rather than stretching them. Most software developers use igh-level (level 3) languages now. Hardware developers use CAD/CAM systems. Tools like these help shorten schedules at the same time that they help developers avoid certain types of problems (for example, a well-realized CAD system provide simulation to make sure modules fit properly at interfaces). In this vein, we need to come up with tools and methods that minimize RISKS without appearing to bulge schedules. People will always blow off that NASA waterfall chart when their software project is behind the calendar. We need to replace it with stuff they'll reach out for like a drowning man for a life preserver. (I'm only moderately hopeful here, because entropy suggests that you can always deliver crap faster than quality... but we've gotta try.)

The other RISK, not of poorly realized systems but of systems that do hateful things (like, say, electronic payment systems that provide retailers with detailed personal information about customers without their (customers') knowledge or consent) we must approach in another way. We've got to distinguish between poor design (say, failure to use crypto to secure cell-phone ID's) for which people are tempted to compensate with stupid policy (e.g., private policy: restrict roaming; public policy: criminalize possession of radio receivers capable of tuning cell-phone freqs) and deliberately warped design (say, the Clipper chip) *caused* by bad policy (private: kissing DoD/FBI heinie; public: attempting to spy on everyone). Every scheme (of education, tool-building, whatever) we deploy against ineffective development applies to the poor-design problem. But I think we need a different approach to the evil design problem...

Social pressure affects people a lot. To avert evil system designs, our best tactic is to promote an ethos that despises people who participate in the design or construction of evil systems. We need to cultivate cultural pressure against such people. We want people to internalize that ethos (that is, we want them to find such work loathsome), and we want them to externalize it (that is, we want them to actively scorn and revile people who do such work). The second, external, form of pressure will ensure the adoption of the first, and help deter evil behaviour even from people who have not internalized our ethos but who wish to avoid offending those who have. I suggest that we've been far too nice recently. We practitioners haven't properly ostracized the (for example) Dorothy Dennings of the world.

We need RISKS to keep the people who give a damn in touch. We need RISKS so people like myself (your humble contributor) will have something to learn from. And--going into the future--we need to work toward disseminating methods and attitudes that will help avert and minimize risks. I don't read a single issue of RISKS without considering what (if any) lessons from it I can use or share with colleagues. I frequently excerpt (will full attribution and a back pointer to the complete record) RISKS Digest for my friends and coworkers. And I strive constantly to promote better design GOALS, better methods, and better implementation techniques for the projects I work on. (I don't claim consistent success, but I make my effort...).

The anniversary lesson is: since we keep seeing the same stuff come up with only minor variations in detail, we've got to work these problems at some more basic levels. Reading and/or contributing to RISKS is voluntary. We've got to *push* RISK awareness on other people. Subtly, I hope; by example, I hope. But somehow.

Re: Tenth Anniversary Issue

Dave Parnas <parnas@triose.crl.McMaster.CA>
Wed, 2 Aug 95 09:05:30 EDT

In RISKS' self-congratulatory TENTH ANNIVERSARY ISSUE Prof. Peter Denning wrote, "RISKS is vibrant, alive, and well after 10 years." I am not so sure.

The first step towards solving a problem is raising awareness. In the case of RISKS, it was important to make people aware of the risks of using computers. As people became aware of the immense power of our technology, we wanted them to understand that although computers were becoming larger, faster, and more pervasive, computer systems were far from infallible and one can not assume that they will function correctly.

Awareness is not an end in itself. After awareness should come understanding. We should be trying to understand why computers are so untrustworthy that some of our leading experts avoid computer controlled aircraft, oppose reliance on computers in nuclear plants, etc.

Even understanding should not be our final goal. After understanding should come a discussion of solutions. We should be looking for ways to make computers more trustworthy, to reduce the risks of using this highly beneficial technology.

I think that the first goal has been achieved. In addition to RISKS, which is widely read by professionals, reporters, and users, we have seen the publication of several very good consciousness raising books. More and more, we find that RISKS is simply distributing stories that have appeared in the press somewhere. Instead of getting direct reports from professionals describing their own professional experiences, we are getting reports of what they read in their local papers. Some regular contributors seem to do nothing but run a clipping service. Frankly, after a while, many these stories sound he same. They are superficial, provide few technical details, and no new insights. RISKS is often quite boring. There are a few detailed reports from someone with professional understanding of the problem but they are often buried among news clips. Some writers add their own professional analysis and occasionally we hear a new idea, but those are the exceptions.

It is time for RISKS to turn its attention to the next two phases. We need to try to understand why these errors keep happening and what we can do about them. We should leave the cute stories to the public press and move on. Only then, will I agree that RISKS is vibrant, alive and well.

Prof. David Lorge Parnas, Communications Research Laboratory, Department of Electrical and Computer Engineering, McMaster University, Hamilton, Ontario Canada L8S 4K1 905 525 9140 Ext. 27353

Re: Limits to Software Reliability (Mills, RISKS-17.22)

Pat Place <prp@SEI.CMU.EDU>
Tue Aug 01 14:21:36 1995

The example that Dick provides nicely illustrates the fallacy that software is inherently less reliable than hardware.

Consider the situation where a system in operation (or test) fails. We observe the failure and may, if we are bright enough, be able to track that failure down to some flaw. We can now use a very crude measure and categorize the flaw: design-time or run-time.

Dick's example shows, to a reasonable level of confidence, that it is possible to equate software and hardware systems at run-time. If his resistor simulation is sufficiently accurate, the software simulation will suffer from run-time failures in the same way as actual resistors fail. If not, we might have better run-time behavior in the software analog than we do in the hardware system.

Both of the systems will suffer from the same design-time flaws. They have to by the nature of the design of the experiment.

It is an interesting motherhood statement that software is inherently less reliable than hardware. There must be some reason that this statement is generally believed. The obvious reason is that our software systems have more design time flaws than our hardware systems. I have two plausible explanations for the greater number of design-time flaws in software.

  1. We are designing far more complicated software systems than hardware systems.
  2. We are less careful designing software than hardware because the perceived cost to change software is less than the perceived cost to change hardware.
I suspect that it is a combination of these factors that leads to more design-time flaws in software.
Pat Place

Re: Limits to Software Reliability (Mills, RISKS-17.22)

Tue, 01 Aug 95 16:58:00 BST

The software in my home thermostat works just fine. I would have expected a mechanical clock to have broken down by now.

Large software systems of the kind whose reliability we discuss over the net are seldom designed this way*. It is not the case that there are several hundred thousand copies of a few dozen basic modules that are connected through narrow interfaces, with all of the complexity being in the topology of the interconnections. Instead, the interfaces are relatively fat, and as the program grows in complexity it gets fatter and less well structured. Imagine if you will a world in which you could add wires to any point inside your 554 chips or resistors or transistors just by conceiving of a nice wire to add.

Furthermore, the reliability traps in software systems are mostly design faults, but the reliability traps in hardware systems are mostly component failures, with some design failures thrown in.

Hardware reliability is an issue in software systems as well as in hardware ones, of course, but the nature of software systems is such that you can gain confidence in the reliability of your hardware by using it in unrelated applications; this is only true at the component level in hardware systems.

The real reason why software appears to be not as reliable as hardware is twofold:

We should not say "software can't ever be as safe as hardware".

We should say instead "There is obviously a correlation between system complexity and presence of design flaws. Since the cost v. complexity curve is steeper for hardware than software, there is also likely to be a correlation between system complexity and system software content. Therefore, there will be a correlation between system software content and presence of design flaws, but this in itself does not show causation."


* object oriented designs come closer to this methodology, which is partially why they gain a following in some circles.

** If you double the complexity of a program, you need to use a bigger disk or add a SIMM or two — no big deal. If you double the complexity of a piece of hardware, you are likely to double the fielding cost.

Call for Papers - 1996 IEEE Security and Privacy Symposium

John McHugh <>
Thu, 27 Jul 1995 16:39:25 -0700

[Please contact John for the complete Call for Papers, submission details

May 6-8, 1996, Oakland, California, sponsored by IEEE Computer Society Technical Committee on Security and Privacy in coop with The International Association for Cryptologic Research (IACR).

Focus this year: re-emphasizing work on engineering and applications as well as theoretical advances, plus new topics, theoretical and practical.

Information about this conference will be also be available by anonymous ftp from in directory /pub/SP96, on the web at The program chairs can be reached by email at

John McHugh, Program Co-Chair, Computer Science Department
Portland State University, P.O. Box 751, Portland OR 97207-0751, USA
Tel: +1 (503) 725-5842 Fax: +1 (503) 725-3211

SEI Symposium: 1995 Software Engineering Symposium

Purvis Jackson <pmj@SEI.CMU.EDU>
Thu, 27 Jul 1995 17:53:41 EDT

Engineering the Future
11-14 September 1995
Pittsburgh, PA

[VERY LONG message truncated; would not even fit in a RISKS issue! Please contact Purvis Jackson for Preliminary Program info.]

Please report problems with the web pages to the maintainer