Subject: RISKS DIGEST 12.55 REPLY-TO: risks@csl.sri.com RISKS-LIST: RISKS-FORUM Digest Wednesday 23 October 1991 Volume 12 : Issue 55 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Power outage downs New York Stock Exchange for 24 minutes (PGN) Near-sighted or far-sighted fibre-opticians? (PGN) MCI Friends & Family & anyone else with a touch-tone phone (Brian R. Krause) Risks of double standards (on PRODIGY)? (David HM Spector) Use of Prodigy on AMC Computers (Louise R. Silsby via Brinton Cooper) A note on RISKS contributions (PGN) Re: Videos and "Dumbing Down" (again) (Daniel J Yurman) Re: More ATM anecdotes (Mark Bartelt) Re: Oki Telephone Programming (Randal L. Schwartz) Re: Computer reads water meter (Lauren Weinstein, Sam Ho via John Sullivan, Lars Poulsen, Bjorn N. Freeman-Benson) Re: Have you tested your machine lately? (Neil Hunt) Re: Software Migration at the Johnson Space Center (Joe Bouchard) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Others may be ignored! Contributions will not be ACKed. The load is too great. REQUESTS please to RISKS-Request@CSL.SRI.COM. For vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 12, j always TWO digits). Vol i summaries in j=00; "dir risks-*.*" gives directory; "bye" logs out. The COLON in "CD RISKS:" is essential. "CRVAX.SRI.COM" = "128.18.10.1". =CarriageReturn; FTPs may differ; UNIX prompts for username, password. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise. ---------------------------------------------------------------------- Date: Wed, 23 Oct 91 10:17:15 PDT From: "Peter G. Neumann" Subject: Power outage downs New York Stock Exchange for 24 minutes The NYSE was down between 10:21am and 10:45am on Tuesday 22Oct91 because of a power outage that downed all of the computers (but not the lights!). ConEd suggested that the outage might have been related to a severe voltage dip at the local power station, resulting from problems with a disconnect switch on a 138,000-volt line. [Reuters, in SanFrancisco Chronicle, 23Oct91, p.C3] ------------------------------ Date: Wed, 23 Oct 91 9:21:23 PDT From: "Peter G. Neumann" Subject: Near-sighted or far-sighted fibre-opticians? U.S. spy masters prevent sale of optic fibre to Soviets' experts (by MARIE JOANIDDIS) PARIS, Oct 22 (AFP) - The United States, seeking to maintain its ability to spy on conventional telecommunications, is preventing western companies from selling much-needed optic fibre to the Soviet Union, several western experts say. Agreement on policy appeared unlikely before the next high-level meeting in Paris at the end of November or beginning of December of the western coordinating committee for export control (COCOM) which restricts the export of high technology to communist countries, they said. [This is the beginning of a longish article. The entire piece can be found in RISKS-12.55afp.] ------------------------------ Date: Wed, 23 Oct 91 19:11:07 EDT From: "Brian R. Krause" Subject: MCI Friends & Family & anyone else with a touch-tone phone I should have known better than to tell MCI who my friends and family are. Here's part of the brochure they sent to introduce me to their Friends & Family program: Q. "How can I leard the immediate status of my Calling Circle?" A. All you have to do is dial 1-800-FRIENDS from any touch tone phone, anytime. A recording will tell you who has been added, who is not eligible and who is in the process of being contacted. Anyone who knows your phone number and ZIP code can get a complete list of your Calling Circle. You don't need to know a number to check its status; the computer lists them all. I called MCI about this. The first representative I spoke with tried to convince me that nobody would try to get my numbers that way, and that, really, if someone was malicious, they could call him and cancel or change my service anyway. That made me feel good. I then spoke to the supervisor--she had never used the FRIENDS number, since "I work at MCI and can check my numbers all the time." She seemed surprised that you only needed a ZIP code, and has promised to get back to me. In the meantime, I'm not adding any more people to my list, and I'm considering switching to a company that doesn't make my monthly bill public information. Brian R. Krause, Software Developer, Milwaukee, WI 532XX ------------------------------ Date: Wed, 23 Oct 91 08:45:35 -0400 From: spector@acf5.NYU.EDU (David HM Spector) Subject: Risks of double standards (on PRODIGY)? There have been a number of very disturbing reports in the press (CNN, and WNYW tv in NYC) in the last several days that on one of PRODIGY's forums, which discusses the Holocaust, members have been posting anti-semitic messages. Some of the messages _advocate_ "another holocaust", etc, etc... The ADL (Anti-Defamation League) has protested to the PRODIGY management who responded that they "oppose anti-semitism", but they "encourage the free expression of ideas". Is this the same PRODIGY that makes decisions about what acceptable "free expression" is when it comes to use of electronic mail, and what are "acceptable" topics in their Health forums? Hmmm.. sees like a pretty scary double standard to me.... David HM Spector, 310 West 18th Street 5A, New York, N.Y. 10011 (212) 243-5548 Usenet: ..!{uunet,apple}!panix!spector ------------------------------ Date: Wed, 23 Oct 91 9:34:37 EDT From: Brinton Cooper Subject: Use of Prodigy on AMC Computers (from Louise R. Silsby) All of us on the Lab computer network (which is, in fact all of us) received this note this morning. What was the final judgement on Prodigy? I thought that the Prodigy flap was all a misunderstanding. _Brint |We have been directed by HQ AMC to suspend all subscriptions to the Prodigy |Services Company and remove all Prodigy software from AMC owned computers. |This includes all individuals that have installed personal copies of Prodigy |on their computers at work. This directive will remain in effect until |further notice. | |Employee owned computers used to access Prodigy Services may not be used to |access government owned computers so as to preclude the possibility of |unauthorized access to government data. | |If you have been using Prodigy as described above or if you have questions, |contact...[name and phone deleted]. ------------------------------ Date: Wed, 23 Oct 91 9:29:39 PDT From: "Peter G. Neumann" Subject: A note on RISKS contributions As I have remarked before, my moderatorship tends to run in cycles from permissiveness to wholesale rejections, depending on the topic, my mood, and how much time I can devote to interactive moderating. But the real problem, I fear, is epicylic rather than cyclic, because as RISKS gets more and more readers with greater intellectual, geographic, and other forms of diversity, more and more material gets submitted, and some of it is less generally relevant to everyone. After receiving a few complaints suggesting I get me back into a more-selective moderatorship, I think it may again be time to head back in that direction. I do not like to flood YOU with too much, but I am certainly flooded! In any event, keep the good incisive contributions coming! The following contributions represent what I hope is a final trickle on the earlier subjects. PGN ------------------------------ Date: Wed, 23 Oct 91 10:57:37 MDT From: djy@inel.gov (Daniel J Yurman) Subject: Re: Videos and "Dumbing Down" (again) Reference a series of reports in RISKS-12.52 and 12.53 on problems with returning videos, I am surprised that your readers have not linked the problem of closing rental return transactions with an earlier RISKs issue -- the "dumbing down" of the workforce. In most of the instances reported customers were eventually moved to rage over the stubborn insistence of employees and managers alike that the "computer had to be right." None of the video store staffs evidence the slightest inclination to question the information in their computer. This can be ascribed to a lack of training, education, or fear of getting yelled at by the manager for letting a late fee go by. The larger issue is what are these people [the video store employees] going to do when IRS screws up their taxes or when their Social Security benefits records are scrambled, etc? Are they going to believe that the government's computers are right or are they going to fight for accuracy of personal information which affects their lives? A case can be made for asking how well we are preparing people to put the question of computer accuracy in perspective. For instance, is the accuracy of the data a life and death matter. For medical diagnostic equipment the answer is yes, but for video rental transactions, the answer is no. Yet, in one RISKs report the writer reports he took the time to drive to the manager's home at 10 PM to resolve a $3 charge. Both the writer and the video store manager have lost it. They allowed themselves to be driven -- literally -- by a bogus record in a database maintained by people paid a minimum wage! There seems to be a problem of scale here. From an marketing point of view there are many video stores so customer service becomes a competitive edge to retain and grow sales. Enraging a patron over a $3 late charge seems penny wise and pound foolish. Obviously, a more astute video store manager would resolve a dispute over a late charge letting it slide to keep a good customer coming back. After all the computer would have a record of how good a customer was in terms of repeat business. Further, this example raises the issue that many businesses face which is how accurate do computer records have to be to keep making a profit and keep customers coming back? Many businesses let minor financial discrepancies slide in the interests of the overall commercial relationship with customers / clients. ATM transactions do not belong to this class of business activities, but late charges on video rentals probably do. Dan Yurman, Idaho National Engineering Lab., PO Box 1625 MS 3900 Idaho Falls, ID 83415 (208) 526-8591 ------------------------------ Date: Wed, 23 Oct 91 07:01:48 EDT From: Mark Bartelt Subject: Re: More ATM anecdotes (Moonen, RISKS-12.54) I continue to be amazed by the abysmal quality of the software that I encounter in ATMs. There are numerous situations where a bit of thought would have made them far less frustrating to deal with. Two examples: (1) I have several ATM cards (for accounts at various different banks), all with different withdrawal limits. Since most of my cards rarely get used, I have trouble remembering what the limits are. I recently stepped up to a machine, and asked it for $500. It insisted that I ask for a different amount, since that machine was capable of dispensing at most $400 in one transaction. Fine. I asked it for $400. This time it told me that it couldn't give me $400, since my withdrawal limit was $300. This incident was doubly frustrating: First, because it ought to be trivial to check the requested amount against both the card limit and the machine limit simultaneously, thus requiring only one retry rather than two. Secondly, each failed attempt required that the card be removed and reinserted, and the PIN re-entered. (Why?) (2) A few months ago I tried to make a deposit to an account which I hadn't used in quite some time. The machine refused to allow any access to the account, and displayed a message telling me to contact my branch. It turns out this bank has a policy of disabling all ATM access to an account that hasn't been used for more than six months. I was rather annoyed because (a) they don't tell customers this when an account is opened, and (b) nothing is mailed to a customer to whom this is about to happen, warning him/her that their ATM access will soon be disabled unless they take some sort of action. In order to get the account re-enabled, it was necessary to go into the branch in person. Not just any branch, either, but the branch where the account was originally opened! In my case, this was just a fifteen minute subway ride. What if I'd moved to a different city? To paraphrase H. L. Mencken, nobody ever went broke underestimating the intelligence of people who run banks. I'm just lucky that I was only trying to make a deposit. What if it had been an emergency situation, where I needed cash quickly? If an ATM is down, I can generally find another one that works. But if this were my only account, and all ATM access is denied, I'm out of luck. Furthermore, even if you agree with the concept that it's a good idea to disable withdrawals from a "stale" account (for security reasons, or whatever), what possible justification is there for not permitting someone to deposit money into an account? Mark Bartelt, Canadian Institute, for Theoretical Astrophysics 416/978-5619 ------------------------------ Date: Wed, 23 Oct 91 10:03:50 PDT From: merlyn@iwarp.intel.com (Randal L. Schwartz) Subject: Re: Oki Telephone Programming (Bell, RISKS-12.54) There's no risk to this. The phone number/serial number pair is validated on each call (which is why the phone wouldn't work in the first place). Programming your own number doesn't circumvent this; the methods for programming *any* cell phone are publicly available (I think the "universal" manual costs around $50, and I have the address somewhere). What you *cannot* change from any sequence of keypresses is the phone serial number. The serial number *can* be changed by replacing a chip, and this is what the other RISK articles have referenced. Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 [...unless you can change the "tamperproof" serial number. Also noted by Dave.Katz@um.cc.umich.edu and lars@cmc.com (Lars Poulsen). See also recent issues of the TELECOM DIGEST. ------------------------------ Date: Tue, 22 Oct 91 19:50:40 PDT From: lauren@vortex.com (Lauren Weinstein) Subject: Re: Computer reads water meter Greetings. The description given would indicate that the meters to be read do *not* make outgoing calls, but rather are interrogated by the central system. There are special features in various modern telephone exchanges for "ringless" connections to subscriber lines, specifically for such purposes as meter interrogation and line testing. Doesn't that give you a warm feeling? (It should be noted that some of these are not as "ringless" as they are supposed to be--some phones "ding" or "chirp"--usually at very late hours--when hit by some existing telco test routines.) Other clues also point in this direction, for example, the note that if *your* line is in use the system will get a "busy signal" (this would not be the case for outgoing calls *from* your line, but would be the case for incoming calls *to* your line). I assume that the exchange is programmed to ignore any call waiting features on the subscriber line in this sort of situation and just return busy for any subscriber use that conflicts with an interrogation request. The business about their only needing your phone number to set up the service, and that then they will delete it, is bogus. They need the number to program into the system. Once that's done, maybe the ordinary customer service rep. won't be able to see the number, but it'll be in there! Risks? The obvious ones, mostly, many of which have parallels with manual meter reading: accidental confusion between meters, undetected read errors resulting in false data, etc. Frankly, the most serious concern might be that an "electronic" meter that crashes or is disrupted in some manner might make it difficult to correct inaccurate billings. With mechanical meters, if there's an accidental over-read by the meter reader, they can go back and look at the meter again and verify what's going on--the mechanical system is fairly robust in that respect. But an electronic system could crash pretty badly. I wonder if electronic water meters would try to draw their power from the phone line--you can draw a very limited amount for that purpose. I also wonder how much hassle it will be to *get* to the phone line from many water meters! In many areas, water meters are currently mounted in the curb. This would imply installing a new meter somewhere closer to the house on the main water line. Actually, the biggest risk may be to the utilities themselves, if people start intercepting the interrogation calls and feeding back their own (presumably lower) data. Of course, this sort of thing has been going on with mechanical meters since the dawn of metering as well. For example, before the power companies started getting serious about really locking down power meters with steel collars and lead seals, there were people who used to flip their electric meters *upside-down* so that they would run *backwards* for some calculated period of time to reduce their bill appropriately (but not enough, presumably, to trigger computer-based flagging of their account for odd month-to-month variations). The rather amusing aspect of this was that people running such upside-down meters would need to turn *on* as many appliances as possible to try force the meter to run rapidly in the reverse direction. So while new technology often brings with it new risks, we see that sometimes it also acts to bring old risks into the 21st century in new forms! --Lauren-- [Many other folks commented on this one also, including Mark Bartelt. I gave up on trying to prune the following differentially. PGN] ------------------------------ Date: Wed, 23 Oct 91 15:01:14 CDT From: sullivan@geom.umn.edu Subject: Re: Computer reads water meter Sam Ho of UIUC was kind enough to point out that I jumped to a few unwarranted conclusions. He believes that the phone company is more directly involved in the scheme than I had guessed: -> From: ho@csrd.uiuc.edu (Samuel W. Ho) -> -> No, the meter does not call the water company. Rather, what happens -> is that the telephone central office sends a coded signal down the -> line to the water meter, while the line is still on-hook. The meter -> then responds with the reading. All this happens superimposed on the -> usual battery voltage, with the line on-hook. If your phone happens -> to go off-hook, or if there is an incoming call, the process is aborted, -> regular ringing or dial tone appears, and the water company tries again -> later. -> -> Normally, you tell the telephone company you want to use the telephone -> by drawing DC loop current. The meter is AC coupled so it doesn't draw -> current. -> -> They don't need your telephone number, since water meters are associated -> with buildings. If you move, you don't take your water meter reading -> with you. Instead, the meter is keyed to the telephone company's -> location information. This would also explain why they need your phone number to set up the service (to get the telco's location info), but don't store it. -John Sullivan ------------------------------ Date: Wed, 23 Oct 91 14:30:08 PDT From: lars@cmc.com (Lars Poulsen) Subject: Remote Meter Reading In RISKS-12.54, John Sullivan, Univ. of Minnesota (sullivan@geom.umn.edu) writes about the "Easy Reader" system to be introduced in Minneapolis over the next few years. The note reveals some uncertainty about the technology. The remote meter reading service is a feature of most electronic central office systems. It is being put into service in many parts of the country. The system requires special hardware and software on the telephone switch; the utility company subscribes to a specially equipped trunk. As I understand the system, the subscriber record contains a special flag to indicate that the line has a remote-readable meter on it. When it is time to read the meters, the utility company activates a special "modem" on their port, and the central office switch scans all the lines that are equipped for meter reading by that utility. Lines that are busy are bypassed (with some provision for scanning them later in a special pass). The switch connects the utility trunk to the subscriber line, and the meter is polled, and transmits its data. If the line goes off-hook during the transfer, the reading is abandoned and retried later. So, "your telephone will never ring" because there is not a conventional call placed. It does not interfere with service. And the utility company does not need to use your number, except as a record identifier to tell the local exchange carrier to set the proper flag bit. Since there is no dialer in the meter, it will not dial 911 in the night :-) :-) The polling protocol is designed to allow several meters to share the line. This is about all that I know. If you need more detail, I am sure there is a BellCoRe document describing both the meter side and the utility trunk interface. Lars Poulsen, SMTS Software Engineer, CMC Rockwell lars@CMC.COM ------------------------------ Date: Wed, 23 Oct 91 16:56:29 PDT From: bnfb@csr.UVic.CA (Bjorn Freeman-Benson) Subject: Re: Computer reads water meter The "Easy Reader" water meter also results in a hidden rate increase for certain customers---those who use metered local telephone service. If I still lived in area with mandatory metered phone service (e.g., most of Europe) and the water company was going to do this, I'd demand a rate reduction to match the (admittedly small) extra cost to me. Regards, Bjorn N. Freeman-Benson ------------------------------ Date: Wed, 23 Oct 1991 16:39:04 GMT From: nhunt@Csli.Stanford.EDU (Neil Hunt) Subject: Re: Have you tested your machine lately? Boyd Roberts reports on mysterious manifestations of FPU failure on his DecStation, and wonders about the risks of complex systems interacting to make diagnosis hard. We too had a similar failure, with similar symptoms: in particular, any X-windows buttons with curved edges would be scrambled across the whole screen. Meanwhile, most of the system seemed to run OK. Fortunately the DEC field service person immediately recognised the problem as I described it over the phone. We were skeptical, but let him swap CPU cards anyway, and the problem went away. Many systems have high complexity which complicates diagnosis of problems. Modern automobile engines come to mind, for example. However the physical complexity of a modern workstation has been much reduced from comparable machines of the past -- after all there are only about three parts inside the whole box. Once having diagnosed a hardware problem, even a novice service engineer could try swapping out all three in short order. (In our case we suspected a software problem and did a complete filesystem restore before calling in the field service!) Perhaps the RISK is in fault tolerant systems which mostly continue to work while not alerting the user to failure, except through weird seemingly unpredictable failure modes. Neil/. ------------------------------ Date: 22 Oct 91 18:39:18 CDT (Tue) From: bouchard@ioscc.neosoft.com (Joe Bouchard) Re: Software Migration at the Johnson Space Center First, some general replies addressed to comments about the original post. 1) Other vendors did have real time simulation software... none on a large enough box to support the proposed system. 2) Unisys A-Series (Burroughs) and 1100-Series (Univac/Sperry) equipement has the largest RANGE (i.e. ratio of fastest system to slowest system) of compatible computer systems available. In other words, these systems go from desktop processing to major mainframe class processing power with NO required changes to the software. Depending on how generically the ECL (Exec Control Language) was written, the change in disk drive types, etc. won't require changes either. Now, the RISK I was trying to point out was upper level managements lack of understanding of the many risks involved with moving mature software from one platform to another when there are major environmental differences between the platforms. The software we are talking about here is something like a million+ lines of fairly machine and environment specific flight simulator code (full instrument, vision, and cockpit motion included), mostly in FORTRAN and assembly language. Those languages allow a fair amount of connection to the specific details of the machine and the software environment. Simply transporting the code without doing a redesign gives mediocre results. It's something like taking a batch oriented application on a mainframe and turning it into a transaction oriented, relational database, desktop metaphor application on multiple PCs connected by LANs, expecting to keep the original design (code, too) and still get all the advantages claimed for the later environment. The management seems to be misled by all the talk about Ada and Unix turning computers into commodities that are VERY plug compatible. If SMS were written in something like Ada, it would be designed VERY differently, mostly because Ada implementations are required to support an environment (virtual machine, if you will) with certain givens that are true on ANY box it runs on. I don't believe that the Ada machine is very good at running real time simulation programs, but you get the point. Porting such a system from one box to another might require a bit of patching to manage specifics. The only catch is that you would end up with EXACTLY THE SAME SYSTEM you started with. It would utilize none of the advantages of the new hardware. The impression of the management around here seems to be that porting the software from one box to another automatically gives you all of the wonderful advantages of the new box without any programming effort (not to mention the effort to port that complex a system in the first place). And most of the desired changes are possible ON THE CURRENT BOX, given the effort to do the hardware and or software upgrades necessary (trivial when compared to simply[?] porting the code). A similar situation exists with the FADS (Flight Analysis and Design System) project. NASA has directed the migration of an existing system (also on Unisys 1100 series equipment) to multiple workstations, etc. The primary problem is that they are so concerned with avoiding change in the existing system (which works) that it is being force-fed onto boxes that were NOT designed to run that way. Changing the underlying hardware with no changes in design is only possible when the two environments are nearly identical. I do not dispute the advantages of the new environment. I DO dispute that moving to such an environment is free. I don't believe this RISK (system migration between environments) is limited to NASA or even just government sites. I've seen it happen at a public utility I used to work for (one of the reasons I left). That example was even simpler (changing mainframes) and was completed with ALMOST reasonable results. Even so, it took longer and cost more than initially estimated. This risk is magnified by being at a government site. Distrusting contractors is a way of life. The government pays the bills and, by definition, that means they know the best way to implement the task. While NASA used to have the technical know-how on the part of the government employees to come up with good designs (and still does in some areas), the above examples show this is no longer true with regard to these projects. Perhaps this is one of the reasons that the SSTO (Single Stage To Orbit) project is being managed by the SDI (Strategic Defense Initiative) branch of the Defense Department with limited paperwork. ------------------------------ End of RISKS-FORUM Digest 12.55 ************************