RISKS-LIST: RISKS-FORUM Digest Monday 7 March 1988 Volume 6 : Issue 38 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: EPROM Risk (Brian Randell) Bigoted expert systems (Jack Campin) PC-LOCK -- BEWARE (J Greely) Yet another antiviral program -- BEWARE (Ted M.P. Lee) mac II virus (Robert Ward) Database Design and Misuse (James H. Coombs) Correlating databases; Disappearing skills; Copious warnings (Paul Smee) Re: Disappearing Skills (Henry Spencer, Jonathan I. Kamens, David Wittenberg, Mark Vonder Haar) Re: Police computer problem -- license-plate matches (Brint Cooper) Leap year madness (Alan J Rosenthal) More on Bank ATMs and checking your statements (Eric Herrmann) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM. For Vol i issue j, FTP SRI.COM, CD STRIPE:, GET RISKS-i.j. Volume summaries in (i, max j) = (1,46),(2,57),(3,92),(4,97),(5,85). ---------------------------------------------------------------------- From: Brian Randell Subject: EPROM Risk Date: Mon, 7 Mar 88 9:48:47 WET DST The amusing, but rather vague, article which is excerpted below, was in The Guardian of 7 March 1988. From further (non-excerpted details) I surmise that it comes from a press release from the makers of the Psion Organiser. PSION'S MEMORY IS MADE OF THIS, by Tony May As a drug smuggler, Paul Dye knew that a filofax was of no use to him, but since his highly entrepreneurial business demanded a portable diary, contact list, memory prompter, calculator and note-taking device, he opted instead for a Psion Organiser. At around (pounds)100 for the basic machine, he got a hand-held computer whose memory could hold details of his (pounds)200 million drug smuggling ring, and could be wiped clean if the law caught up with him. But since he has been fined (pounds)202,000 and is now doing 28 years in gaol partly on the strength of evidence obtained from the machine's "erased" memory we may conclude that he potentially has a case under the Trades Description Act. Our computer staff tell us that when he came to erase his file the details were no longer available to him but were retained in the EPROM chip-based storage system which does not actually erase. They also tell me that Psion may have had another walk-on part in the case as members of the ring used corsets bought from Marks & Spencers to carry heroin, and the stores use Organisers for till price checking and chargecard validation. Mr Dye may not have been entirely happy with his purchase, but Psion believes that 300,000 of them will have been sold by the end of year ...... Brian Randell, Computing Laboratory, University of Newcastle upon Tyne PHONE = +44 91 232 9233 JANET = Brian_Randell@uk.ac.newcastle UUCP = ...!ukc!newcastle.ac.uk!Brian_Randell [Ah, the old residue problem strikes again. The eraser's edge. Psion-ARA! PGN] ------------------------------ From: Mr Jack Campin Date: Mon, 7 Mar 88 18:48:47 GMT Subject: Bigoted expert systems Further to Brian Randall's posting about the St George's Hospital case: According to the Times Higher Education Supplement (26.2.88) St George's is actually one of the LEAST discriminatory teaching hospitals in London, with 12% nonwhite students; others, using human assessors whose procedures cannot be reviewed, get as low as 5%. In a warped way this is almost a success story. What other examples do readers have where "knowledge" elicited from "experts" has codified prejudice? There are proposals afoot to give expert systems total control of British social security benefits; the record suggests that any bigotry that can be built in, will be (refusals of benefit have been made in the past on racial grounds by clerks belonging to neo-Nazi organizations). Does any state anywhere have legislation requiring public access to source code of software performing tasks like that? (not that that would be a lot of help with a neural network that didn't like black faces). ARPA: jack%cs.glasgow.ac.uk@nss.cs.ucl.ac.uk USENET: jack@cs.glasgow.uucp JANET:jack@uk.ac.glasgow.cs useBANGnet: ...mcvax!ukc!cs.glasgow.ac.uk!jack Mail: Jack Campin, Computing Science Dept., Glasgow Univ., 17 Lilybank Gardens, Glasgow G12 8QQ, SCOTLAND work 041 339 8855 x 6045; home 041 556 1878 ------------------------------ Date: Mon, 7 Mar 88 03:21:13 EST From: jgreely@tut.cis.ohio-state.edu (J Greely) Subject: PC-LOCK (Re: James Ford, RISKS-6.34) -- BEWARE Organization: The Ohio State University >There is a program called PC-LOCK (*NOT* the PD version) which is made by >Johnson Computer Systems. We have installed it on some hard disks here and >have had no problems at all. A quick warning about PC-LOCK (shareware). If you are currently using version 1.0, REMOVE IT IMMEDIATELY. It will not hurt you if it already works, but you might be tempted to give a copy to someone else, and this could be fatal. Version 1.0 stores your password in an "unused" section of the partition table, and does not document this. Approximately 10% of all Western Digital hard disk controllers (PC/XT version) *also* use this section, for an advanced partition management feature (that never worked). If you have one of these controllers, installing PC-LOCK version 1.0 will lock your system, and make your hard disk completely inaccesible. The good news is that Western Digital will send you a replacement BIOS chip upon request (mine arrived within 3 days). PC-LOCK version 1.1 does not have this problem, and performs perfectly on every system I've seen it on. > You have to boot with drive "C" and enter the proper password to gain >access. There are 5 possible passwords you can set/use....1 administrator >password and 4 user passwords. Sounds like a newer version. >PC-LOCK, Johnson Computer Systems, 20 Dinwiddie Place, Newport News VA 23602 If you'd like to contact the author by phone (I had to, about the version 1.0 problem), there is no listing for JCS, just ask for a Johnson on Dinwiddie. He was very helpful, and has further information about who to contact at Western Digital. ------------------------------ Date: Thu, 3 Mar 88 11:54 EST From: TMPLee@DOCKMASTER.ARPA Subject: Yet another "antiviral" program -- BEWARE To: Risks@csl.sri.com The following is abridged from the March 3 Minneapolis Star & Tribune. Anyone willing to guess how many people are being suckered into buying this (or other similar products) and how long it will be before they discover that the protection being advertized is illusory and can't be anything but? Now if the vendor (Lasertrieve) in question also sold insurance and was willing to significantly lower the premium for insuring against loss of data if you used his program, then I'd listen. N.J. FIRM SAYS IT CAN 'INOCULATE' COMPUTERS AGAINST 'VIRUSES' Associated Press Seattle, Wash. A New Jersey company is offering to "inoculate" computers against "viruses," or rogue programs that are designed to spread from computer to computer and damage data the computers store. The Viralarm system was announced Tuesday by officials of Lasertrieve Inc., of Metuchen, N.J., during a Microsoft Corp. conference on [CD-ROMS]. A statement issued by Lasertrieve said that although the newer CD-ROM disks are impervious to corruption because information on them cannot be altered, many computer users are concerned about protecting programs on hard disks or on conventional floppy diskettes. Viruses are creating a growing fear among computer owners and users. Officials in Israel recently announced the detection of a virus that, if left to spread unchecked, could have wiped out memory banks and disabled computers throughout the country. Previous antiviral programs only drew attention to changes, noted the size of a program or monitored the dates of program changes, and all were "easily fooled by sophisticated viruses," the statement said. Viralarm consists of a special program to protect another program, creating a software barrier. The protection is available for individual personal computers and works for most of the operating systems now available, the Lasertrieve statement said. ------------------------------ Date: Mon, 7 Mar 88 12:56:21 -0500 (EST) From: Robert Ward Subject: mac II virus It was recently reported in this newsgroup that the editor of "MacMag," a Canadian monthly magazine, hired a programmer to create a Mac II virus which served more or less as an advertisement (or at least an attention-getting device). The virus was supposedly set to go off on March 2, the birthday of the Mac II. It was reported that the virus had been spotted on Compuserve and other commercial databases. Well, it's now well past March 2...any actual sightings of contamination? ------------------------------ Date: Sat, 5 Mar 1988 22:15:30 EST From: "James H. Coombs" Subject: Database Design and Misuse [RISKS-6.32 and -6.36] I have been thinking about design requirements. First, a database designer needs to understand thoroughly both the data that will be stored in the database and the ways that it will be used. Clearly, the designer must be a pessimist. One way to reduce problems caused by partial data would be to specify NULLS NOT ALLOWED for critical fields. This would prevent the entry, for example, of a record specifying a license number but not a make and model. Unfortunately, energetic organizations can easily subvert such integrity constraints by directing their operators to enter some value that will be treated as a NULL (e.g., "N/A" for make and model). Nonetheless, designers must make themselves aware of the consequences of NULL values in particular databases. Even though their efforts can be subverted, they can make such subversion relatively easy to spot; they can supplement their design efforts by specifying clearly in the documentation that pseudo-NULL values should not be entered. Should a database fall into misuse on entry, an ethical supervisor might still appear someday and correct the situation. If it is preferable to allow entry of partial records, one can still define views that allow only certain people to see those records. Once the record is filled out, it becomes available to others. Again, this sort of constraint can be subverted easily (e.g., assign the appropriate privileges to everyone). Alternatively, as PGN suggests, the front end can issue warnings when the results are likely to be misinterpreted. In all of these situations, however, we rely on the organization 1) to want to use the database properly and 2) to enforce the appropriate constraints. I do not believe that designers can prevent this sort of misuse. (In an extreme case, a pseudo-NULL could be chosen from the values of a closed set, e.g., all cars of color RED are understood to have an unknown color.) I hope that I'm missing something here. --Jim Dr. James H. Coombs, Software Engineer, Research Institute for Research in Information and Scholarship (IRIS), Brown University [Interesting choice of example, in that red cars are involved in accidents disproportionately many accidents! PGN ------------------------------ Date: Fri, 4 Mar 88 10:45 GMT From: Paul Smee Subject: Correlating databases; Disappearing skills; Copious warnings Several short comments on miscellaneous recent discussion. 'On the topic of correlating databases': Matt Fichtenbaum mentions a NY match of the driving licenses DB with the aid to the blind DB. Never lived in NY, but in many states, eligibility for aid to the blind is determined by the state of your *uncorrected* vision; while eligibility for a license is determined by the state of your *corrected* vision. The general principle involved is that while cross-correlation may, prima facie, seem reasonable, it might not really be meaningful. 'Disappearing skills': The biggest danger posed by people who can't do simple math 'the hard way' is that they tend to trust whatever their computer or calculator says. Knowing how to do it by hand, and well, increases a person's 'feel' for the right answer. For example, I recently objected to a sales assistant trying to charge me an amount I knew was wrong. 'The till [US cash register] says it's 12 pounds', she insisted. 'Why don't you believe it?' Well, I said, I've got 5 items, each under a pound, so can't be over a fiver. Indeed, she'd mis-keyed one of the prices. More frighteningly, I occasionally see the same sort of obviously wrong (but 'the computer said so, it MUST be right') answer being accepted by an engineering student. I would be much more comfortable if I felt that the bridge I'm driving over (or the airplane I'm on) had been designed by someone who had a 'feel' for the maths, so that he or she would be able to recognize if the 'computed solution' was actually believably near to the reasonably expected one -- or if not, why not. I think knowing the basics helps give this sort of feel. 'Copious warnings': (I've lost the original title of this chain). The principle of the 'boy who cried wolf' is often neglected -- dangerously, I think. For example, the micro I use at work always says, when you ask it to format a disk, 'Warning: formatting disk B will cause all data on the disk to be lost. Do you really want to do this?' Well, I know it's going to ask that, and I know I've just put a virgin disk in the drive, so I always anticipate it with a 'yes'. Some day I'm going to forget to set drive B (so it will go for A, or worse, C); or I'm going to mix up my disks in the shuffle, and regret it. It would be safer (in my environment at least) if it would first LOOK at the disk, and reserve the warning for those cases where the disk actually already has been formatted. (My controller can tell the difference, at least for it's own format disks. There would be the risk, of course, of accidentally formatting a disk which has already been done in some other machine's non-standard format, but for me that's not an issue.) There are a lot of examples of this in computing -- for example the system which *always* asks you to confirm deletions. Of course I want the thing deleted, I wouldn't have asked you to otherwise. For my own (mainframe) delete I've managed to wrap in a personal heuristic, so it asks only if (a) the file(s) are 'protected'; or (b) the file string contains a 'dangerous' wildcard spec -- like '**' (everything); or (c) I've requested multiple single files (because, the way I work, that usually means I've mistyped some filename like '*.fred' as '* fred' instead. Nevermind bugs, faults, and breakdowns in 'emergency warning' systems -- there's a lot of just plain poorly thought out design. ------------------------------ Date: Sun, 6 Mar 88 00:10:59 EST From: mnetor!utzoo!henry@uunet.UU.NET Subject: Re: Disappearing Skills [RISKS 6.35] > I never learned how to multiply by using a slide rule ... Ah, but what happens if it becomes necessary to find a logarithm or a square root and your calculator's battery is dead? If it were me, I'd either dust off my slide rule or dig out a book of tables -- I have, and can use, both -- but those options increasingly are not available. (The standard references like the Handbook of Chemistry and Physics are dropping things like log tables on the grounds that they are superfluous nowadays and the pages are better used for other material.) One can argue that logarithms and square roots are in some sense less fundamental than multiplication, but to what extent is this a lingering side effect of days when multiplication was easier? Certainly I use the square-root key on my calculator quite a lot. > ... The need for multiplication will probably exist as long as mankind ... The same can be said of the need for logarithms, square roots, trig functions, etc... and artificial aids have been the normal approach to them all along. Engineers have been completely dependent on artificial aids for doing multiplication -- in the sense that the slowness of doing it by hand would be considered utterly intolerable for practical purposes -- for many decades. (Here I am not talking about computers, but about mechanical calculators, slide rules, and log tables. Not to mention assistants! Grace Murray Hopper once commented that she could remember when "computer" was a job title, not a piece of machinery.) > Technological advances should save us time; they should not "save" us the > "bother" of being able to think. To what extent does a purely mechanical skill like multiplication constitute "thinking"? Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ From: jik@ATHENA.MIT.EDU Date: Sat, 5 Mar 88 22:30:47 EST Subject: Re: Disappearing Skills [RISKS 6.36] In RISKS 6.35, Ronald J. Bottomly says, I am not condoning technological stagnation, but I am condemning absolute technological reliance. The need for multiplication will probably exist as long as mankind exists; but it seems dangerous (RISKy?) to come to rely upon calculators (or whatever will succeed them) to perform this multiplication. A story by Isaac Asimov called "A Feeling of Power" illustrates this point beautifully, using the same example (dependence on calculators) that Mr. Bottomly uses. The story takes place at a time so far into the future that man has become completely dependent on calculators and has forgotten how to do calculations by hand. One man rediscovers hand calculation, and the results are quite surprising. I won't spoil the plot, but I definitely think it is worth reading. Jonathan I. Kamens ------------------------------ Date: Fri, 4 Mar 88 06:29:23 PST From: wittenberg%ultra.DEC@src.dec.com (David 'Witt' Wittenberg) Subject: RE: Disappearing skills [Also noted Issac Asimov ...] The thing that scares me more than people being unable to do arithmetic is the inability to recognize wildly erroneous calculations. A friend of mine (who works as a software engineer) quoted a value for the ability of a ski resort to move people up the mountain. It was off by 4 orders of magnitude. Even if we lose the ability to add accurately, we must retain the ability to recognize major errors. --David Wittenberg ------------------------------ From: allegra!cbcsta!mvh@EDDIE.MIT.EDU Date: Mon, 7 Mar 88 18:09:53 est Subject: Disappearing Skills (Re: RISKS-6.33) Organization: AT&T Bell Labs, Columbus OH We have long ago lost *THE* most fundamental basic skill for 95% of the people in western civiliation: farming. Unless you can feed yourself, please don't lament the loss of multiplication skills. By the way, technology is probably the primary cause of lost farming skills. Mark Vonder Haar ------------------------------ Date: Fri, 4 Mar 88 0:24:17 EST From: Brint Cooper Subject: Re: Police computer problem -- license-plate matches I'm all in favor of improving the matching algorithms used by the police, to avoid using defective database systems and cause serious problems for innocent people. But here's the other side of the story: Look how the police can use database systems to be more efficient in catching up with people running loose with outstanding arrest warrants. About 4 years ago, a young man whom I know neglected to pay a $25 Public Defender's fee for services in District (Traffic) Court. Subsequently, a bench warrant was issued for his arrest for violation of probation. Meanwhile, he had left this state and was working elsewhere. Six months ago, the man was vacationing within the state and locked his keys in his car. At 3:00 a.m. police found him trying to open his own car with a coat hanger. Being forthright, he showed his license and said, "This is my car. I've locked myself out." Here there are two databases: one for outstanding traffic violations and one for outstanding criminal warrants. Since this fellow was doing something possibly "criminal," the cops checked the latter database and got a hit. They detained him and the rest is sadder history than it need have been. Once in a while, we who worry about risks should review the countless routine uses of computers and databases without which ours might be a less desirable society in which to live. We're a large country, and this brings special problems that seem made to order for computers. _Brint ------------------------------ Date: Mon, 7 Mar 88 10:45:07 EST From: Alan J Rosenthal Subject: Leap years A program was discussed recently that caused accounts created on 29 feb this year to be listed as expiring on 29 feb next year, and access then to be denied due to the invalid expiry date. In risks 6-34 Michael Wagner identifies three design errors: > 1. Two different representations/algorithms for dates ... > 2. At least one representation allows illegal dates to be expressed ... > 3. The treatment of an illegal date *in the future* as an expired date... I think concluding #1 and #3 is not justified. Probably dates were simply represented as records containing entries for day, month, and year (like on many IBM computers). Since 29 was in the valid range for a day, it was representable. Then the simple approach of adding 1 to the year would produce an invalid date. I don't think that the original article said that the illegal date was treated as being in the past; it's probably just that as a security feature access is denied to accounts with invalid expiry dates. #2 is certainly correct. If the representation was the simpler "number of days since time x", then the calculation would have been simply to add 365, and in a leap year the user would be cheated out of one day, rather than an illegal date created. In the same issue, Mark Brader writes: >All right now -- how many people reading this *haven't yet realized* that >their watches have to be set back 1 day, ... This brings up another interesting issue. Many programs assume that time goes forward. For example, documentation for the Amiga says that this is guaranteed and that programs should not move the time backwards. At a place I work for we have networked microcomputers running a database program in which the central database is updated nightly, and the update program assumes it is run every day and that all un-updated entries were created today. Setting the date backwards between updates would have caused problems. Fortunately we realized that the problem existed. ajr ------------------------------ Date: Mon, 7 Mar 88 13:53:49 PST From: pixar!banzai@ucbvax.Berkeley.EDU (Eric Herrmann) Subject: More on Bank ATMs and checking your statements I would like to contribute yet another anecdote about the sometimes bizarre and arbitrary world of electronic banking, which happened maybe 3 months ago. After receiving my bank statement for the month, I took all the ATM receipts I had accumulated and proceeded to balance my checkbook. All was well except I saw a $60 withdrawal from a Gibraltar Savings branch (linked by the Star system to my bank) on the same day that I withdrew $40 from my Great Western machine (about two blocks distant). I had no receipt for this, and I couldn't remember withdrawing the money, nor could I conceive why I would withdraw $40 and then withdraw $60 the same day two blocks away, but it occurred to me that I couldn't prove anything, so I decided to eat the $60 loss. About a month later, I received a form from my branch bank explaining that a $60 withdrawal had been mistakenly posted to my account, and that the amount had been restored. The explanation was hand-written, but did not explain who posted the transaction, why it was posted, or how the mistake was discovered. I would agree with David Segal that good record-keeping is necessary as a check on technology. In this case, had the bank not confirmed and reversed the error, I would have had no recourse to recover the money. Thankfully, all I lost was a month's worth of interest. The problem was not compounded, I suppose. ------------------------------ End of RISKS-FORUM Digest ************************