From risks-request@pica.army.mil Fri Sep 25 21:15:22 1992 Return-Path: Received: from csmes.ncsl.nist.gov (MACBETH.NCSL.NIST.GOV) by csrc.ncsl.nist.gov (4.1/NIST) id AA06376; Fri, 25 Sep 92 21:15:12 EDT Posted-Date: Fri, 25 Sep 92 17:49:23 PDT Received-Date: Fri, 25 Sep 92 21:15:12 EDT Received: from PICA.ARMY.MIL (fsac5.pica.army.mil) by csmes.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA02825; Fri, 25 Sep 92 21:10:11 EDT Received: from PICA.ARMY.MIL by Fsac5.pica.army.mil id aa06180; 25 Sep 92 20:59 EDT Received: from aed.pica.army.mil by Fsac5.pica.army.mil id aa06176; 25 Sep 92 20:58 EDT Received: from chiron.csl.sri.com by AED.PICA.ARMY.MIL id aa12944; 25 Sep 92 20:55 EDT Received: by chiron.csl.sri.com id AA20907 (5.65b/IDA-1.4.3.12 for risks-mil@pica.army.mil); Fri, 25 Sep 92 17:49:27 -0700 From: RISKS Forum Sender: RISKS Forum Date: Fri, 25 Sep 92 17:49:23 PDT Subject: RISKS DIGEST 13.82 Reply-To: risks@csl.sri.com To: ;@risks-list.ncsl.nist.gov Message-Id: Status: R RISKS-LIST: RISKS-FORUM Digest Friday 25 September 1992 Volume 13 : Issue 82 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: [CLEAN-UP OF SOME BACKLOG, A FEW MARGINAL. SLOWDOWN AHEAD.] Police files conference (Nigel Allen) Electronic mail confusion (Stewart T. Fleming) Duplicate Account Names (Martin Smith) Digitizing art (John Sullivan) Re: Airliners playing chicken (Rogier Wolff, Leslie J. Somos, Larry Seiler, Marc Horowitz) Re: Airplane chicken, scanning addresses, Sneakers (John Sullivan) Re: Postal service privacy RISK (Kraig R. Meyer, Gene LeDuc) Re: Bounced cheque libel (Peter J. Scott) Re: Computerized warrant systems & mobile data terminals (Michael G Kielsky) Re: Arrest warrants / Datamation (Lars Henrik Mathiesen, Bob Frankston, Cristobal Pedregal Martin, Geoff Kuenning) 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. **PLEASE** INCLUDE YOUR NAME & INTERNET FROM: ADDRESS, especially .UUCP folks. REQUESTS please to RISKS-Request@CSL.SRI.COM. Vol i issue j, type "FTP CRVAX.SRI.COMlogin anonymousAnyNonNullPW CD RISKS:GET RISKS-i.j" (where i=1 to 13, 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. For information regarding delivery of RISKS by FAX, phone 310-455-9300 (or send FAX to RISKS at 310-455-2364, or EMail to risks-fax@cv.vortex.com). 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: Tue, 22 Sep 1992 20:00:00 -0400 >From: Nigel Allen Subject: Police files conference Here is a press release from the U.S. Department of Justice. National Criminal Justice Information Conference in New Orleans To: City and Assignment desks Contact: Stu Smith of the Office of Justice Programs, U.S. Department of Justice, 202-307-0784 or 301-983-9354 (after hours) WASHINGTON, Sept. 23 -- A national conference on federal-state criminal justice information sharing will be held from Wednesday, Sept. 23, through Saturday, Sept. 26, in New Orleans, the Department of Justice announced today. Jointly sponsored by the Bureau of Justice Statistics (BJS) and the Justice Research and Statistics Association (JRSA), the conference participants will discuss "Federal and State Information Sharing to Effectively Combat Crime and Ensure Justice." Specific topics that will be aired include "New Measures in the Criminal Justice System," "'Weed and Seed' and New Drug and Crime Prevention Initiatives," "Challenges and Reforms to the Justice System in the 90s," "Uses of Incident-based Reporting Systems," "Recent Developments in Criminal History Improvements" and various research issues in corrections, prosecution and law enforcement. Among the approximately 250 people expected to attend will be officials from state and local government and various federal agencies as well as leading criminal justice researchers and scholars. Other participants will be the directors of State Statistical Analysis Centers (SACs) and other members, associate members and guests of JRSA. BJS has provided funding to state justice statistics and information systems through a network of SACs since 1972. There are currently SACs in 48 states, the District of Columbia, Puerto Rico, the Virgin Islands, and the Northern Mariana Islands. The SACs provide a wealth of data about crime and the operation of the criminal justice system to state and local governments, legislatures, and Attorneys General for policy analysis and planning purposes. This year is the 20th anniversary of the SAC program. It also marks the beginning of a new initiative to establish a truly national system of federal, state and local government information-sharing and readily accessible data bases. Additional information about BJS programs and publications may be obtained from the Bureau of Justice Statistics Clearinghouse, Box 6000, Rockville, Md. 20850. The telephone number is 800-732-3277. Canada Remote Systems - Toronto, Ontario World's Largest PCBOARD System - 416-629-7000/629-7044 ------------------------------ Date: Thu, 24 Sep 92 16:27:17 +0100 >From: "Stewart T. Fleming" Subject: Electronic mail confusion I wasn't going to contribute this until I read David Paschich's contribution (Wed, 16 Sep 1992) concerning potential confusion of users on electronic networks. Working within a computer-oriented university department, a lot of internal work (memos, reminders etc) gets distributed by e-mail. Such distribution lists exist for staff, postgraduate students and so on. This afternoon, a postgrad. student was surprised to receive complaints from postgraduates at a neighbouring institution about an e-mail message he had sent for internal distribution. What had happened was that an electronic mail address had become truncated and passed through the smart address matching path. None of the machines on that path flagged the address as invalid and the mail was sent on up the chain. When it reached the other institution, it was distributed to their postgraduates. This incident illustrates the potential for embarrassing disclosures, particularly in view of two results from a recent e-mail survey we carried out: Q: Have you sent or received confidential/sensitive information by electronic mail ? Yes: 75% Q: Was the material encrypted or protected in any way ? No: 91% Do you know where your e-mail messages are ? STF sfleming@uk.ac.hw.cs or sfleming@cs.hw.ac.uk or ...uknet!cs.hw.ac.uk!sfleming ------------------------------ Date: Thu, 24 Sep 1992 08:49:21 +0100 >From: msmith Subject: Duplicate Account Names (was Phone Numbers In Popular Entertainment) David Paschich writes in Risks 13.81 about one of the risks of getting account names mixed up, the fact that you could inherit someone's reputation (good or bad). While at University I came across another aspect of this problem. When people left their accounts were put on tape and deleted. I have a fairly common name (ask Douglas Adams) and there was someone in the year above me also called Martin Smith. Account names were normally first name and initial of surname but their account wasn't called MartinS, presumably because there'd been a name clash in the past. Thus I was known as MartinS. I came back from the summer holiday and guess which account had been deleted? Things then became even more confusing when I went to get my files back. There was *another* Martin S* (the surname escapes me) just arrived in the new intake who had already been given my old account name. My account had to be renamed to MartinSm. I can't help wondering who got deleted when I left. (not necessarily THE) Martin Smith ------------------------------ Date: Tue, 22 Sep 92 12:39:37 CDT >From: sullivan@geom.umn.edu Subject: Digitizing art The Economist (Aug 15) reports that the National Galleries in both Washington and London have plans to digitally record images of all their paintings, because digital images "last for ever". London hopes to scan their pictures "repeatedly over time ... to track how their colours change": "Since human colour memory is poor, and photographs change colour themselves, the only way to do this is by using a computer." I have trouble here dealing with image files I created a couple of years ago: we have new hardware, software, and file formats. I have all but given up hope that colors will look similar on the screen, when printed, and when scanned in. I hope the museums will give careful thought to such problems. -John Sullivan, The Geometry Center, University of Minnesota ------------------------------ Date: Thu, 24 Sep 1992 12:19:50 GMT >From: wolff@zen.et.tudelft.nl (Rogier Wolff) Subject: Re: Airliners playing chicken Last time I heard about this incident (Here on comp.risks I believe) it was told that _both_ "squats" had failed. I.e. there where considerations towards reliability and safety of the devices. An interesting question pops up now. Should these devices be wired in an "and" or in an "or" fashion? I guess that it would be safest to wire them in such a way that when they agree, they can override the pilot, but if they disagree, the pilot should be able to take responsibility. Roger EMail: wolff@duteca.et.tudelft.nl ** Tel +31-15-783644 or +31-15-142371 ------------------------------ Date: Thu, 24 Sep 92 10:27:48 -0400 >From: ah739@cleveland.freenet.edu (Leslie J. Somos) Subject: Re: Airliners playing chicken (RISKS-13.81) I know nothing about planes. I can understand preventing deployment of spoilers or thrust reversers while in the air, but I don't understand preventing brake application. Leslie J. Somos ah739@cleveland.Freenet.edu ------------------------------ Date: Fri, 25 Sep 92 09:09:53 -0700 >From: seiler@rgb.enet.dec.com (LARRY SEILER, DTN225-4077, HL2-1/J12) Subject: Safety interlocks that fail re "Airliners playing chicken" from RISKS digest 13.81: I agree that it is better to have an occasional accident due to a safety interlock system that fails than to have more accidents due to people accidentally doing fatal things like engaging the thrust reversers or deploying the spoilers while the plane is in the air. However, the better solution is to have an emergency override system that is simple enough to engage quickly, that cannot easily be engaged by accident and that warns that it is engaged. And, of course, there must be severe penalties for anyone who uses it except under emergency conditions. To use a computer analogy, there can be serious accidents if everyone has superuser privileges enabled all the time. But there are also problems if you cannot get privileges when you really need them -- like at 9pm when no one is around and you just have to read that protected file! Larry ------------------------------ Date: Wed, 23 Sep 92 22:54:47 EDT >From: Marc Horowitz Subject: Re: Airliners playing chicken Or, we can realize that failures and "impossible" circumstances do occur, and install overrides so the pilot can tell the system it's wrong. People deal with unforeseen circumstances better than computers. Marc ------------------------------ Date: Thu, 24 Sep 92 16:04:47 CDT >From: sullivan@geom.umn.edu Subject: Airplane chicken, scanning addresses, Sneakers A few quick comments on items in RISKS-13.81: David Wittenberg reports on airliners playing chicken, and suggests that we "not panic when a safety device does cause damage" even though switches "used in all sorts of safety devices ... will eventually fail". I'd like to see an overridable switch: if the pilot engages the brakes or thrust reversers, and the computer thinks the plane is in the air, it shouldn't just quietly fail to engage them, but should tell the pilot what is going on, and leave some way to override the ground/flight switch. Daniel Burstein is concerned about the post office's plans to send images of hand-written envelopes via computer to remote sorting sites, and the possibility that addresses could be stored in a database. Of course letters with typed addresses are already sorted by machines with OCR software, so these addresses are even easier to store. Overnight delivery services must enter each item sent into some kind of computerized tracking and billing system: who knows if any of them have thought to keep a database indexed by sender/recipient pairs? There has been much discussion of the real phone number used in 'Sneakers' for the NSA agent. The movie also shows phone numbers being typed in on a numeric keypad (when they first test the decoder), and at least one instance where touchtones are audible. I didn't try to identify any of these, but I'm sure someone will. -John Sullivan, The Geometry Center, Univ. of Minn. sullivan@geom.umn.edu ------------------------------ Date: Thu, 24 Sep 92 14:28:07 PDT >From: kmeyer@aero.org Subject: Re: postal service privacy RISK (RISKS-13.81) In RISKS-13.81, Daniel Burstein relays US Postal Service plans to use remote video technology to allow remote sorting of mail, and notes: "given OCR technology, it would be quite trivial to have EVERY piece of correspondence going through the USPS scanned, and a data list of who sent what to whom could be generated." I want to point out several issues related to this article: 1. The RISK of stored communication matrices--having a record of who communicates with whom--is perhaps simplified, but certainly not created by the use of computer sorting technologies. In small town days, the local postman and telephone operator knew exactly who communicated with whom. 2. OCR Technology is already very widely used by the USPS. If you place a letter in a mailbox that is designated "for envelopes with typed and printed addresses only," that envelope is read by an OCR and a bar code is put on to the envelope corresponding to the zip code. (Try sending yourself a letter in this manner!) 3. There was a front-page article in the LA Times (Sunday, 20 Sept?) that describes how firms in general are using remote technologies to move jobs to remote locations. It's generally a benefit to both the company and the workers. The company gets better workers and lower costs. The workers are happier because their wages go a lot further in the remote geographic location, allowing a better standard of living. Why not let workers in Vermont sort mail that is going through a plant in New York City? ------------------------------ Date: Fri, 25 Sep 92 07:33:53 PDT >From: leduc@nprdc.navy.mil (LCDR Gene LeDuc) Subject: Re: postal service privacy RISK (RISKS-13.81) In RISKS-13.81 Daniel Burstein wrote about Remote Video Encoding in use by the USPS, a procedure involving scanning a letter and sending the envelope's image to a remote site to be ZIP and barcode processed. [...] Those who fear this type of data collection are certainly under no obligation to include a return address on any envelope. In this case (for once!), the default in mailing a letter is "no return address" and one must override this default by putting one on the envelope. -gene- Gene LeDuc (leduc@nprdc.navy.mil), Navy Personnel R & D Center, San Diego, CA 92152-6800 ------------------------------ Date: Wed, 23 Sep 92 16:53:44 -0700 >From: Peter J. Scott Subject: Re: Bounced cheque libel Terry Gerritsen quotes The Lawyers Weekly as saying that the 9-year libel action, ultimately successful, of a company against Lloyd's bank for erroneously returning cheques marked "Refer to drawer", is believed to be the first of its kind to reach British courts this century. Actually I am aware of a case identical in all pertinent respects, and while I do not remember the date I am reasonably certain it was within this century. I remember finding it in a search of important libel decisions when I was in the UK and it stuck in my mind. Given such a clear precedent, it's appalling that it took nine years to come to a decision. Peter J. Scott, Member of Technical Staff | pjs@euclid.jpl.nasa.gov Jet Propulsion Laboratory, NASA/Caltech | SPAN: GROUCH::PJS ------------------------------ Date: Thu, 24 Sep 92 10:47:38 MST >From: MKIELSKY@apsc.com (MICHAEL G KIELSKY) Subject: Re: Computerized warrant systems & mobile data terminals Mobile data terminals (MDT's) in police cars are nothing new around here (Phoenix, AZ area), and have been in use for years. My experience has ranged from working for an organization which serviced these devices (and thus using them in testing), thoroughly studying the computer system that works in the background, to accompanying on-duty police officers from various departments on many ride-alongs, and viewing the system in action. These systems are in use with virtually every police agency in the Phoenix area, as well as the Department of Public Safety (Highway Patrol), but not with the sheriff's office. The systems are nothing more than data terminals on a radio network. Data traffic is NOT encrypted (risks obvious), and converting an installed base to handle encryption is not feasible for most departments. Log on practices vary, with identification information ranging from officer ID, to shift/beat code, with usually short (and few different) passwords. The "base computer" is connected to several databases, including the National Crime Information Computer (NCIC), the Arizona Crime Information Computer (ACIC), and motor vehicle records. Information retrievable includes driving license records (including traffic violation history), vehicle registration records (including vehicle description), arrest warrant information, stolen motor vehicle records, stolen firearm records, etc. Data retrieval is notoriously slow during busy times (Friday & Saturday night), sometimes taking as long as 30 minutes for a license plate check. Terminal to terminal messaging is possible. Communication with dispatchers is also possible. All transactions are recorded/printed. Accident Risks: A few years ago, the Phoenix Police Department, after experiencing numerous problems with officer's driving and operating the terminals at the same time, improved the ergonomics by mounting the terminal higher and closer to the driver. This way, the drivers eyes are not completely averted from the road while using the terminal. Privacy Risks: It is common practice for officers to "run" license plates on vehicles which they observe, for no reason whatsoever, or for any trivial reason. Information retrieved via the computer includes name, address, SSN, and driving license number of the current registered owner, vehicle identification number, lien holder (usually bank/loan institution), original lien amount, date vehicle first registered, date registration expires, vehicle description, and whether the vehicle is stolen. Registration violations are most commonly found this way. As newer officers (who often are less techno-phobe) take to the streets, use of the system is increasing. False Arrest Risks: Arrest warrant information obtained through the computer (term is "CAPRI Hit") will find the listed individual in handcuffs (i.e. existence of a computer arrest warrant record is sufficient probable cause for arrest). Again, we know how infallible information entered into computers is. These computer warrant records must then be verified against the actual warrant (on paper), before the arrestee can be arraigned (brought before a judge). These warrants are stored in filing cabinets at the sheriff's office of the warrant issuing jurisdiction (here it is the Maricopa County Sheriff's Office, and I have seen the actual filing cabinets stuffed with warrants). This process can be slow, since there are hundreds of thousands of outstanding warrants in these filing cabinets, some going back over half a century. Michael Kielsky, Arizona Public Service Company, P.O. Box 53999, Phoenix, AZ 85072-3999 602-250-2897 (W) 602-919-0182 (M) ...sunburn!overlord!mkielsky ------------------------------ Date: Fri, 25 Sep 1992 12:37:16 GMT >From: thorinn@diku.dk (Lars Henrik Mathiesen) Subject: Re: Arrest Warrants (Weinstein, RISKS-13.81) Lauren Weinstein writes about the classic treatment of the "computer- induced" nightmare through "minor" errors: > (A clue: at the end of the piece, the governor's order to stop the > execution is accidentally misrouted...) Actually, the order was to be sent by a special urgent-mail system --- but it was held back because the Governor didn't get it authorized by his supervisor ... (I think I read this short story in a science-fiction collection named _The Astounding-Analog Reader_.) Lars Mathiesen (U of Copenhagen CS Dep) (Humour NOT marked) ------------------------------ Date: Thu 24 Sep 1992 11:39 -0400 >From: Bob_Frankston@frankston.com Subject: Re: A simpler risk of computerized warrant systems (Karn, RISKS-13.80) Consumer car phones are already shipping with voice dialing. Extending that to replacing the keyboard by speaking letters as opposed to something as fancy as full word recognition would be straightforward. Given not only the safety risk but the awkwardness of using a keyboard in a car along with the compelling value of using the device while driving, I'd be surprised if voice is not added very soon. Let's start the timer going and see how long it takes to get the technology deployed. ------------------------------ Date: Thu, 24 Sep 92 20:34 CDT >From: steve@nuchat.sccsi.com (Steve Nuchia) Subject: Re: Arrest Warrants (Davis, RISKS-13.81) >Given the alleged facts here the amount in question must have been >on the order of $3; An incident with similar background but (so far) less outrageous conclusion happened to me. Early in my consultancy I had my business checking account at a small bank. Through a bookkeeping error on my part I bounced a check. The check was small, the account was small, the error was small and the overdraft was small. In what I hope and believe was a complete coincidence, the bank was closed by federal regulators between the time the check was bounced and the time I received notice of it. The check was not honored but the overdraft charge ate up the balance in the account plus a few dollars. Since I couldn't find anybody who had a clue what was going on I just abandoned the account. The bank was purchased by Texas Commerce Bank, one of the largest in the area. For several months they accrued overdraft charges to my old account because it now had a negative balance. The end result was that they wrote off the account with about $75 owing and sent me a nice registered letter to the effect that I had "caused a loss" of $whatever to the bank. The way I see it they made off with the $12 I had in there when they bought the old bank, but I suspect they could have one of those stealth arrest warrants issued for me by including my case on a list of other "losses" and mailing it to the district attorney. I also managed to spend a couple of hours in jail once due to a parking ticket that was over five years old. It was legitimate and once I was told about it I vaguely remembered having gotten it, but I had completely forgotten it. The arresting officer could not tell me what I was being charged with at the time of the arrest, which I found pretty offensive. All he knew was that a warrant existed. What I don't understand is why they can't send out letters to people instead of lying in wait for them and wasting everybody's time. It wasn't like I was going to flee the country over a parking ticket. Steve Nuchia South Coast Computing Services, Inc. (713) 661-3301 ------------------------------ Date: Thu, 24 Sep 92 9:43:17 EDT >From: pedregal%unreal@cs.umass.edu Subject: Re: A simpler risk of computerized warrant systems (Karn, 13.81) Phil Karn comments about a computer terminal mounted on San Diego police cars; these devices can be (and are) used by the driver while in motion. He points out the safety risks associated with that (typing/reading while driving). Karn also mentions that "[the police] like to drive around semi-continuously punching in license plate numbers", i.e., that they check plates in many situations that are not "only when they really suspect somebody (e.g., during a stop)". So there's a change with respect to the previous situation: now the checks on plates can be (they probably are) stored and can be manipulated much more easily; more such data is gathered; and, more relevant to RISKS, it can be easily matched with location, as police cars (will) have devices that continuously report their location. Of course, if the records exist, they will eventually be used against someone. This is yet another instance of a common risk: having more and richer data changes the possible uses of such data. Cristobal Pedregal Martin pedregal@cs.umass.edu (internet) Computer Science Department UMass / Amherst, MA 01003 ------------------------------ Date: Wed, 23 Sep 92 18:11:30 PDT >From: geoff@itcorp.com (Geoff Kuenning) Subject: Re: Datamation fiction (Weinstein, RISKS-13.81) Lauren Weinstein writes: > The classic treatment of the "computer-induced" nightmare through > "minor" errors must be the humorous (fictional) piece done by > "Datamation" in the early 70's. As I recall, the title of the story was "Computers Don't Argue," and it was not original with Datamation. I think it appeared first as a science-fiction short story in the late 60's. Geoff Kuenning geoff@ITcorp.com uunet!desint!geoff ------------------------------ End of RISKS-FORUM Digest 13.82 ************************ Downloaded From P-80 International Information Systems 304-744-2253