RISKS@CSL.SRI.COM (RISKS FORUM, Peter G. Neumann -- Coordinator) (12/01/86)
eRISKS-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>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" <GUTFREUND%cs.umass.edu@RELAY.CS.NET>
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 <Neumann@CSL.SRI.COM>
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 <stokes%cmc.cdn%ubc.csnet@RELAY.CS.NET>
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 <kludge%gitpyr%gatech.csnet@RELAY.CS.NET>
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 <account holder>
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, <date>
Dr B, <date>
...
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 <account holder>
> 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, <date>
> Dr B, <date>
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
************************
-------