The television news program News 4 New York, this morning, reported the death of a man because EMS (emergency medical service) technicians could not locate his apartment building. It was reported that the man lived at a building with a five digit address but the system used to dispatch EMS technicians only allows a four digit address. I will report more on this risk story if it appears in the New York Times today and no-one else on the network has further details, but I'd remark that most programming languages encourage the apparent error responsible for this tragedy. To my knowledge, only REXX and certain Basic interpreters allow completely variable length strings, which would have perhaps avoided the problem (barring screen design considerations, of course.) In C, you must either malloc or decide in advance the maximum length of a field, and in practice this decision is usually made in secret by the programmer rather than reviewed by the end user. Since truncation of fields usually affects "the real end user" (that is, the general public in the form of customers, students, victims, and in this case patients) I believe that there is not enough commercial motivation to provide programming languages and systems that avoid the preconditions for this problem. How about legislation concerning responsible display and capture of COMPLETE information? Or, at the level of civil lawsuits, the fact that a defendant's system truncates data should always weigh against the defendant.
>From the pages of Popular Science, April 1991: "...Spectators at the first flight of Northrop's [YF-23] prototype noticed its huge all-moving tails--each larger than a small fighter's wing--quivering like butterfly wings as the airplane taxied out to the runway. Test pilot [Paul] Metz says this occurred because the early generation flight-control software didn't include instructions to ignore motions in the airframe caused by pavement bumps. The answer, he adds, is inserting lines of computer code that tell the system not to try to correct for conditions sensed when the fighter's full weight is on its nose gear." I'll grant that in the 1990s we can analyze wind-tunnel tests in a few hours (or less) and can even simulate untested airframes with some success. In the 1950s pilots frequently flew prototypes before the final results of early wind-tunnel tests were completely analyzed--a process that sometimes took weeks or months. But am I alone in thinking that in some respects it takes more chutzpah to test-fly one of these modern fly-by-wire wonders? <shudder> Joseph Hall, Student, sometimes Applications Programmer, NC State University
The article is in Computerworld April 29th, 1991, page 1. The leadin is a battle over whether an agency should release its data in the original machine readable tape format or on "more than 1 million sheets of paper". The article touches on some real issues of representation -- how much work should be done to transform representations to what the requestor wants and the costs of paper-intensive approaches. In the case of the initial example, part of the rationale for not releasing the information in machine readable format is that "it wanted to discourage commercial enterprises from making big profits off of the city's data-gathering efforts". This does acknowledge that information in machine readable form is very different from paper. Did the authors of the Freedom Of Information Act foresee the differences between paper and machine-readable data? What does the mean to privacy? The census bureau works hard to protect privacy when it releases its data. Does the FOI mean that raw, less guarded, data will become readily available? Can I search real-estate databases to find out where someone has lived for the last 20 years? To search arrest (not conviction, simply arrest) records? The article ends with "In the long run, it would be best for FOI requesters and agency FOI officers if government information systems were designed from the outset to allow for ad hoc queries and public access, according to several experts. Ideally, that would be just good IS management practice, but Podesta said that agencies need the prodding of a legislative mandate to consider the [technical??] issues of public access at the start of systems design.". While this is true, they should also consider the implications of such access.
Some people have asked how a "pirate" receiving cable channels illegally could be dumb enough to turn themselves in when the service stops? Pirates who know what they're doing WOULDN'T be turning themselves in. But most of these folks in question are otherwise legitimate cable subscribers who have been "sold" a modification to their cable boxes, MOST OFTEN BY A CROOKED CABLE COMPANY INSTALLER or other "legitimate" sounding entity who tells them that it is perfectly legit--that it's just another way of paying for the service. OK, so these people are gullible--but look at all the other scams people fall for every day. Their box goes out-- they call the cable company. These are most often ordinary folks, not "sophisticated" pirates. Similar scenaries have occurred with satellite TV, where crooked dealers tell their customers that instead of paying a monthly fee for services they can pay a lump sum and that it's all legit. Of course it's not. And just like in the cable case, if the service is cutoff these folks will usually call up the service wondering what went wrong. The news stories on the "cable bullet" are making a big deal acting as if this technique could be easily applied to all systems. The incident in question involved one PARTICULAR BRAND of cable box, which was being subverted by a particular technique. There is no "broad spectrum" method for doing the same thing on a wide variety of boxes (of which there are many types), and many existing designs would make such a "bullet" approach impossible. Also, even for the affected boxes, the odds are that the folks making the modifications will find an alternate method for illicit enabling of the boxes, and so the war of the countermeasures escalates into the future...
More on Docklands Light Railway (DLR), that was reported in RISKS-11.52 as having had two of its unmanned trains collide. This was reported in UK newspapers, together with a picture which looked like nothing so much as two model trains having collided on a set of points. This hasn't been the first incident; during testing, a train over-ran its buffers. Since a large part of the DLR is elevated, the train in question ended up hanging off the end of the track some thirty feet above the ground. I got an indication of the state of the routing software when I travelled on the DLR about three years ago (during that time, I worked in Docklands). The train drew to a halt on an empty bit of elevated track, waited for a couple of minutes, and then carried on. On checking with a DLR official, it transpired that there was due to be a development there at the time the routing software was written; due to various financial factors the building had been delayed but DLR had already included it in the software which, having been tested, they were unwilling or unable to modify. There is now a building at that site (the infamous Canary Wharf), but I haven't been back on the DLR subsequently. Rupert Goodwins, East Ham, London.
Below is a Call For Votes to create a newsgroup on testability/reliability issues. Please send your Yes/No vote to the address indicated below. Frances (email@example.com) - - 8< - - - - - - - cut here - - - - - - - - cut here - - - - - - - - - >8 - - Date: 26 Apr 91 18:19:48 GMT From: firstname.lastname@example.org (Nikolaus Gouders) Newsgroups: comp.lang.vhdl Subject: 1st CFV: comp.lsi.testing (was: comp.lsi.cat) Summary: call for votes Keywords: comp.lsi.testing Organization: Rechenzentrum Uni-Duisburg CALL FOR VOTES for comp.lsi.testing (was: comp.lsi.cat) ======================================================= SUMMARY: Newsgroup: comp.lsi.testing Yes votes to: email@example.com No votes to: firstname.lastname@example.org Voting period: April 29th, 1991 to May 20th, 1991 (inclusive) NAME/GROUP: comp.lsi.testing STATUS: unmoderated CHARTER: This newsgroup is intended to cover all aspects of the testing of electronic circuits such as (but not restricted to) * Testing of Digital and Analog Devices * Automatic Test Pattern Generation * Fault Modeling and Fault Simulation * Design for Testability * Scan Design and Built-in Self Test * PCB-Test and Boundary Scan * Design Verification Important topics are (again not restricted to) * Announcements (conferences, workshops, special issues) * Books on testing * Standards * Tools * Benchmarks * Questions and answers * Discussions concerning technical or algorithmic problems WHY A NEW GROUP: The ever increasing number of publications on testing shows a vivid and growing interest in that subject. A newsgroup on testing will stimulate and accelerate the exchange of related information among interested network users. It makes it easier to recognize current trends in testing, especially for novices. The discussion period showed a general agreement on the theme. Our first proposal for the name of the group was comp.lsi.cat, which is similiar to comp.lsi.cad. A number of contributors remarked that this name is not generally understandable or misleading. Among the proposed alternatives were: comp.lsi.test, comp.lsi.testing, comp.lsi.ate, comp.lsi.ft (fault tolerance). Taking into account that ".test" may sound like "alt.test", "news.test" which have a specific function within the USENET hierarchy, the proposed name "comp.lsi.testing" should be the most understandable and general one. Some authors commented that there are existing groups like comp.lsi which do not have an extreme news flow to date. Splitting therefore should not be necessary. We have never intended to split any group due to "net bandwidth", comp.lsi.testing is a new thread. A closer look at comp.lsi[.cad] shows that these groups are mostly design oriented, and this probably raises the level for participation of non-designers. Shortly: there was and is no forum for testing yet. SCHEDULE OF THE VOTE The voting period begins on monday, april 29th and ends at (including) sunday, 20th. Everybody is allowed to send one and only one vote for (YES) or against (NO) comp.lsi.testing. All votes reaching the addresses described below during the voting period will be counted. Votes arriving not during the period, duplicate votes, votes containing additional comments ("I vote YES, but...") are VOID. HOW TO VOTE Please send your vote to one of the following addresses: YES votes to: email@example.com NO votes to: firstname.lastname@example.org Please put your vote in the subject of the mail-header. Format: subject: YES comp.lsi.testing or subject: NO comp.lsi.testing Your mail MUST contain an e-mail adress to contact you (e.g. a .signature) to allow verification of the results. DO NOT SEND ANY VOTE TO A NEWSGROUP (for instance the group where you read this call for votes). RESULTS After the end of the voting period, the voting results will be published in the newsgroups "news.groups" and "news.announce.newgroups" including names, e-mail addresses and votes of the voters. To create the newsgroup "comp.lsi.testing" it is necessary that there are at least 100 more YES than NO votes, and there must be a 2/3 majority of YES voters. PUBLICATION This call for votes will be sent to news.announce.newgroups news.groups comp.lsi comp.lsi.cad comp.simulation comp.lang.vhdl and some e-mail addresses. You may freely distribute, translate, republish, crosspost etc. this article as long as the parts SCHEDULE OF THE VOTE and HOW TO VOTE remain unchanged and the names of the authors are included. Please send us your vote soon! The authors: Nikolaus Gouders (email@example.com) Holger Veit (firstname.lastname@example.org) -- | Nikolaus Gouders | |**********************************************| | University of Duisburg | | INTERNET: email@example.com | | Fac. of Electr. Eng. | | BITNET: gouders%du9ds3.uni-duisburg.de@UNIDO | | Dept. f. Dataprocessing | |**********************************************| - - 8< - - - - - - - cut here - - - - - - - - cut here - - - - - - - - - >8 - -
Please report problems with the web pages to the maintainer