30-Nov-86 15:21:35-PST,13467;000000000001 Mail-From: NEUMANN created at 30-Nov-86 15:20:03 Date: Sun 30 Nov 86 15:20:03-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.20 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Sunday, 30 November 1986 Volume 4 : Issue 20 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Smart metals (Steven H. Gutfreund) Risks of having -- or not having -- records of telephone calls Audi and 60 Minutes (Mark S. Brader) Audi 5000/Micros in cars and the Mazda RX7 (Peter Stokes) Automated trading (Scott Dorsey) "Borrowed" Canadian tax records; Security of medical records (Mark S. Brader) 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) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) ---------------------------------------------------------------------- Date: Fri, 28 Nov 86 15:04 EDT From: "Steven H. Gutfreund" To: risks@CSL.SRI.COM Subject: Smart metals In Risks V4.19 Kim Collins calls for a discussions of passive versus dynamic control mechanism, and illustrates his definition with a skyscraper analogy: Passive Control: a building that flexes in the wind Dynamic Control: computer-controlled guy wires With the advent of cheap 'smart' metals, (metals that contract or perform other mechanical functions in response to temperature and other environmental stimuli), is the distinction very important anymore? I can use a metal with complex operational characteristics to control the windows and blowers in my greenhouse and provide environmental control. The proper application and installation of these metal control structures seems directly analogous the the proper declaration of the constraints that a software control system should carry out. Indeed I can conceive of a modeling system for a completely software based control system that uses a graphics environment that expresses these contraints visually in terms of their mechanical counterparts: (e.g. ThingLab or Maureen Stone's "Snap Dragging" in the SIGGRAPH '86 proceedings). Let me phrase this in terms of a RISKS administration dilemna: If an engineer designs a control system in such a graphic modeling environment and has no knowledge whether the final implementation will be in terms of hardware (relay-ladder control, smart metals, etc) or in software. If his system fails and is submitted to RISKS, would the editor of RISKS consider this material valid RISKS DIGEST material if the final implementation was completely free of software and computers? - Steven Gutfreund University of Massachusetts, Amherst [You bet. An algorithm is an algorithm is an algorithm. Although it is not stated explicitly in the masthead, I consider this forum to be devoted to something like RISKS TO THE PUBLIC IN COMPUTER-RELATED TECHNOLOGIES, although don't ask for a specific definition of scope. Nice example. Thanks. PGN] ------------------------------ Date: Sun 30 Nov 86 14:47:25-PST From: Peter G. Neumann Subject: Risks of billing information on all telephone calls To: RISKS@CSL.SRI.COM Sunnyvale CA (AP, 29 Nov 86) A telephone bill has vindicated a physically handicapped teenager jailed more than a month ago on charges he beat his mother to death. Charges were dismissed against Patrick Sparks, 17, when the bill found by his brother, Brad, 30, indicated their mother was still alive when the youth left home on the morning of the slaying, police said... Of course, it can work either way. The record of all of your telephone calls provides a remarkable chronicle of your activities... ------------------------------ From: mnetor!lsuc!dciem!msb@seismo.CSS.GOV Date: Thu, 27 Nov 86 17:20:43 est To: philabs!phri!roy@seismo.CSS.GOV Subject: Audi and 60 Minutes Cc: NEUMANN@csl.sri.com [ReSent-To: RISKS@CSL.SRI.COM] > I also saw the 60 Minutes episode. From the tone of the various messages in > RISKS 4.17, it sounds like everybody believes Audi is at fault. All I saw > was a lot of anecdotal evidence ... That's all you *saw* because anecdotes make good pictures. If you listened to the "text" of the article, you heard statistics on the number of runaway Audis -- if I remember rightly, something like 1 in 300 owners of the model in question had experienced this problem. While they didn't give the "control statistic", the same ratio for other cars, I can't believe it's anywhere near that high -- can you? Mark Brader, utzoo!dciem!msb ... being sysadmin of such a central node involves a lot less hassle and frustration when I can confidently say, "I don't know whose software is broken, but it definitely is not ours." Speaking of which... "I don't know whose software is broken, but it definitely is not ours!" -- Henry Spencer ------------------------------ Date: Thu, 27 Nov 86 08:58:31 pst From: Peter Stokes To: risks@CSL.SRI.COM Subject: Audi 5000/Micros in cars and the Mazda RX7. [...] I have heard that the new Mazda RX7's have microprocessor controlled steering or something of the like. I guess this is the beginning of "drive by wire". Peter Stokes, CMC ------------------------------ Date: Fri, 28 Nov 86 22:09:50 est From: Scott Dorsey To: RISKS@CSL.SRI.COM Subject: Automated trading In the last Risks Digest, RMann%pco@HI-MULTICS.ARPA says: "Now, I can't imagine these super-sophisticated arbitrageurs issuing MARKET orders -- it is too absurd to imagine. If the hedger issues limit orders, the trades do not occur and the stock price stays relatively stable." Presumably the problem is not that of sophisticated arbitrageurs making orders on enormous numbers of stock, but many thousands of not-so-sophisticated people using computers for small market orders. With the advent of modern services, practically anyone with a Commodore-64 can make predictions and issue remote buy and sell orders. It's a strange world. [And if they are all using the same program, the effects can be even stranger. PGN] ------------------------------ From: mnetor!lsuc!dciem!msb@seismo.CSS.GOV Date: Thu, 27 Nov 86 17:19:18 est To: RISKS@csl.sri.com Subject: "Borrowed" Canadian tax records; Security of medical records Discussion has been going on in can.general about the "Borrowed" Canadian income tax records, and the topic of security of medical records has arisen as a sideline. I thought these two articles contained material good for RISKS. Glossary for foreign readers: OHIP is the Ontario Health Insurance Plan. Essentially all Ontario residents have coverage, but unless our income is small, we (or our employers) have to pay a premium for it. Mark Brader ================== Begin 1st forwarded article ================== Path: dciem!utzoo!mnetor!spectrix!clewis From: clewis@spectrix.UUCP (Chris Lewis) Newsgroups: can.general Subject: Re: Borrowed records from Revenue Canada Date: 26 Nov 86 21:05:24 GMT In article <274@cognos.UUCP> glee@cognos.UUCP (Godfrey Lee) writes: >Did anyone see the news report that the suspect "has opened"/"wants to open" >an agency to track down people for a fee? [Interpolation by Mark Brader: Another report was that he wanted to use the records to reunite people with their forgotten bank accounts, for a fee. Of course, he could have been planning both things.] Oops, forgot about that one. Yes, indeedy, it would be good for "skip tracing". Interestingly enough, in Ontario, the OHIP enrollment file is even better - the dates are frequently far more up to date, because even tax avoiders (and others attempting to avoid payments) want to keep their OHIP coverage up-to-date. Until 1978/9 police were able to obtain such information - the general manager of OHIP didn't realize that the legislation enabling the existence of OHIP didn't allow it. Not any more. However, there were far more private investigators using pretext calls to OHIP for the same end. As an example of where things are compared to what they were like in 1978 (when the Health Records Commission started), OHIP didn't know how many copies of the OHIP enrollment fiche were made, where they went and never noticed any going missing (quite a few copies did - though, most likely they were simply misplaced or destroyed without being reported to the COM group). One of the more interesting (and sneaky) techniques we ran into for collection agencies acquiring info was: 1) Send letter saying "You have won....(something or other)" along with a cheque for $5 "Deposit Only" to debtor. 2) Find out the name of the debtor's bank from the cancelled cheque. I was asked to report a few other incidents that the Commission found: 1) Catastrophic OHIP data processing oversight: It is the practise of OHIP to collect several days worth of data entry at one of their district offices (there were 7 in 1978-79) and do an audit on them. Once every couple of months. This is done by taking the several days worth of claims (in the order of 100,000-400,000 claims) and running them through a program that would generate a letter of the form: Dear Our records indicate that you, or members of your family [remember OHIP numbers are for whole families, not individuals] saw the following doctors on the following dates: Dr A, Dr B, ... Could you please inform us if any of this information is incorrect? Note that there is no diagnostic code, service code or family member name. In one particular case, the account holder knew that one of the doctors was a OB/GYN, and reasoned out that it was his daughter (mid teens) who made the visit. To make it brief, his reaction had as end result his daughter committing suicide. When this occured, OHIP made some changes to their auditing program, such that when the diagnostic code or service code was a socially embarrassing thing (e.g.: abortions, D&C's, VD treatments - 20 codes in all, probably more now) the letters do *NOT* contain any reference to the associated visit. I was asked to personally inspect the OHIP code to ensure that this was being done properly. It was - sorta. When the senior analyst gave me the code, he said "it makes me want to cry" - if written in C (it was in a particularly grotty COBOL style), the code would have looked something like: int skipdiag[] = {100, 200, 202 ... }; /* 10 entries, sorted */ skipclaim(code) { if (binarysearch(skipdiag, code)) return(TRUE); else if (code == 400 || code == 501 || code == 722...) /* 10 clauses */ return(TRUE) else return(FALSE); } I gather that the analyst responsible for this piece of junk got thoroughly yelled at. Chris Lewis, Spectrix Microsystems Inc, Toronto, Ontario, Canada UUCP: {utzoo|utcs|yetti|genat|seismo}!mnetor!spectrix!clewis ARPA: mnetor!spectrix!clewis@seismo.css.gov Phone: (416)-474-1955 ================== Begin 2nd forwarded article ================== From: mberkley@watdcsu.UUCP Newsgroups: can.general Subject: Re: Borrowed records from Revenue Canada Date: 27 Nov 86 04:10:55 GMT In article <201@spectrix.UUCP> clewis@spectrix.UUCP (Chris Lewis) writes: >1) Catastrophic OHIP data processing oversight: > Dear > Our records indicate that you, or members of your family > [remember OHIP numbers are for whole families, not individuals] > saw the following doctors on the following dates: > Dr A, > Dr B, I used to work for the auditor of one of the provincial medical plans, and they had a similar program. Every month they would send out these auditing letters. They decided to expand the audit one year, but slightly change the letters. The new program printed out the subscriber's name, address, and medical claims on a standard form that would be heat sealed and mailed. The auditor was very picky (a good trait for auditors), so he had us check out the first batch, one more time, before it was mailed. We discovered that the programmer had somehow managed to print out the name and claims of one subscriber, and then the address for the next subscriber. Don't ask me how he managed to do it, but I'm sure glad that we checked! Mike Berkley, Department of Computing Services, University of Waterloo EAN: mberkley@dcsu.waterloo.cdn UUCP: {allegra,ihnp4,utcsri,utzoo}!watmath!watdcsu!mberkley ------------------------------ End of RISKS-FORUM Digest ************************ -------