The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 10 Issue 24

Thursday 23 August 1990

Contents

o E-mail lawsuit
Sean
o Re: Electronic house arrest units
D. King
o Proposed ban on critical computerized systems
Cameron
PGN
o Object Code Copyright Implications
Robert Biddle
o Discover Card
Brian M. Clapper
o Total Knowledge about all individuals
Clifford Johnson
Alan J Rosenthal
o Re: Useful credit-related addresses
Henry Mensch
o "Rogue Programs: Viruses, Worms, and Trojan Horses"
Gene Spafford
o Info on RISKS (comp.risks)

E-mail lawsuit

<seanf@scocan.UUCP>
Thu, 23 Aug 90 06:15:15 EDT
>From the August 13 issue of ComputerWorld (page 7)

E-mail lawsuit cranks open privacy rights can of worms, By Jim Nash

_Privacy vs Property_ might be a better case name for the
invasion-of-privacy suit filed last week against Epson America, Inc.

The suit, born out of a personal dispute last January at Epson's Torrence,
Calif., headquarters, pits those who hold electronic mail to be as inviolate
as U.S. mail against those who consider E-mail company property.

Attorney Noel Shipman filed the class-action suit in Los Angeles Superior
Court on behalf of ALana Shoars, Dick Flanagan, Lee Cheaney, Glen Mosby --
all former Epson employees -- and hundreds of other Epson employees who have
used the company's E-mail since Auguest 1989.  Shipman claimed that it was
about that time that Robert Hillseth, manager of Epson's Hewlett-Packard Co.
computer system, illegally tapped messages between the HP system and its
external MCI Communications Corp. E-mail service.

Shipman seeks damages of $3,000 per person for each alleged violation of a
California statute barring the interception of an electronic communication
without consent of all parties in the communication.
--- end excerpt ---

That's about all of real interest; the rest consists mostly of quotes from
both sides ("we deny it," "they did it," etc.).

No risks, per se, but more the result of issues previously discussed in
risks (namely, "network security," of various sorts).
                                                            Sean.


Re: Electronic house arrest units (Gong, RISKS-10.22)

<king@kestrel.edu>
Wed, 22 Aug 90 13:34:44 PDT
Let me take a "hack" at a design for a house arrest unit.

0> The unit is physically attached to the detainee, looking something
   like a bracelet.  This is in common with one of the products "out
   there", although not to the voice recognition unit that was the
   original subject of the thread.

1> The unit has, stored on a volatile memory chip, a supply of bit
   strings long enough to last the sentence.  These strings need not
   be particularly long -- a single bit for each "string" might well
   suffice -- but they are set at the dispensing organization, not
   determined by any algorithm.

   The device is built in such a manner that it can't be opened
   without destroying it, at least within the resources the detainee
   is likely to bring to bear.

2> At random but appropriate intervals, perhaps Poisson with
   lambda=ten minutes, a polling station, physically inaccessable to
   the detainee, broadcasts a poll signal; the bracelet broadcasts
   it's next bit string as stored per 1>.

3> The reply is received by several stations, and time delays are
   measured to put the detainee at the intersection of the surfaces of
   several ellipsoids with the polling station and each receiving
   station as foci, and several hyperbolae, with each pair of
   receiving stations as foci.

   There can be perhaps a half dozen polling stations and a half dozen
   receiving stations.  Any attempt by the detainee to build his own
   repeater to simulate being where he is supposed to be is doomed to
   failure, because if the repeater's transmitter is at any place
   other than the detainee's house the intersection of the hyperbolae
   will turn out wrong, and if the repeater's receiver is in the wrong
   place the speed-of-light delay between the halves of the repeater
   will swell those ellipsoids whose major axes do not run along the
   path from the halves of the repeater.

4> There is a box at the detainee's house that listens for polls and
   the detainee's bracelet's response and beeps a horn if there is a
   failure [no response, as opposed to the wrong response].  Detainee
   is responsible for notifying his probation officer in case of a
   failure -- "Come and inspect me and bring me a new bracelet."

Can someone poke a hole in this?  Seems cheap enough; 2K bytes of static RAM is
a about a month's supply at one bit per poll, the detainee can't leave any
device at his house to respond to polls for him because he can't open his
bracelet safely, it shouldn't be all THAT expensive [and a per-bracelet cost of
a few hundred or a thousand dollars does not sink the application], and yet it
looks like spoofing the system involves defeating well-known physics [assuming
you accept my stipulation that the detainee can't read out his RAM].
                                                                        -dk
     [Interesting?  Overkill?  Four choices among the following:
     A right/wrong solution to the right/wrong problem?  PGN]


Proposed ban on critical computerized systems

<cameron@argosy.UUCP>
Wed, 22 Aug 90 12:56:27 PDT
On page 63 of the August 1990 _World_Press_Review_:

"Unreliable Computers", by Nick Nuttall, "The Times," London

Two Australian scientists are calling for a world-wide ban on the use of
computers in sensitive areas, such as hospital intensive-care wards, the
nuclear-power industry, air-traffic control stations, and early-warning defense
systems.

Computers are inherently flawed and too unreliable for critical tasks, say Tom
Forester of Griffith University and Perry Morrison of the University of New
England, both in New South Wales.  In the British academic journal _Futures_,
they write that computer systems cannot be designed without the threat of
life-endangering malfunctions, because their very complexity makes thorough
testing for errors and bugs impossible.  Forester and Morrison have documented
instances of death, destruction, financial loss, and mayhem caused by
computers.  These include patients being given fatal drug doses by
malfunctioning computers; 22 fatal crashes of the Black Hawk helicopter --
which flies by computer -- used by the U. S. Air Force; and 104 failures in a
single day of the Los Angeles air-traffic-control computer in July, 1989.

I'd appreciate it if someone would dig up this issue of _Futures_ and post or
summarize this paper.


Re: proposed ban on critical computerized systems

<ISKS Forum <risks@csl.sri.com> [PGN]>
Wed, 22 Aug 1990 14:49:34 PDT
Oddly, RISKS-10.23 contained a note on the Ethics book by Forester and Morrison,
pointing back to the Contents and Preface in RISKS-9.15.

As they acknowledge in their preface (RISKS-9.15), they drew heavily on RISKS,
but they did not check all their sources.  They do have a disclaimer in the
book that not all of their information is guaranteed.  The 22 FATAL Blackhawk
crashes sounds BOGUS to me, and certainly not from RISKS.  PGN


Object Code Copyright Implications

&obert.Biddle@comp.vuw.ac.nz>
Thu, 23 Aug 90 14:48:54 +1200
Here in New Zealand the government is reviewing the "intellectual property"
laws, and several open meetings are being held to discuss the issues.  I went
to a recent such meeting about copyright, interested mainly in the user
interface question already widely discussed on Usenet and elsewhere.

At the meeting, however, what concerned me more was the subject of "reverse
engineering". Lawyers there agreed and insisted that object code be subject to
copyright, and that making any "disassembled" or "uncompiled" version of the
object code was making a derivative copy - and not allowed as "fair use". They
argued that the only people who would wish to do this would be people wanting
to get around copyright protection in creating competing programs.

I discussed this question with several of the lawyers afterward, and they
explained that if you obtained a copyright protected object program, then
object code was all you legally had.  One lawyer suggested that would mean you
could print out "ones and zeros", but nothing derived from them - they shrugged
when I pointed out that "ones and zeros" notation was not inherent in object
code, and so would also be a derivation. I asked how people could determine how
a program might behave unless they could look at it.  The lawyer suggested that
it was their view that the *behaviour* of the program was sufficient for people
to see how it would work.

Now there are some interesting points here.
1) If object code is copyrightable, what *exactly* is it that is subject
   to the copyright? Magnetic patterns? Ones and Zeros? Source code?
2) Of course, program behaviour in the past is *not* sufficient to
    determine how a program will behave in the future.

Most importantly, these people seem to be arguing that if you have (legally) an
object-code program protected by copyright, and even though you *do* have the
"fair use" right to execute the program, you may *not* have the right to
inspect the program itself by disassembling or reverse compilation, to
determine how it may work in future circumstances.  This seems to me a great
Risk.

Two final points:

  Firstly, of course programs may be protected by other legal mechanisms which
are not addressed here. But copyright is usually the minimum.

  Secondly, in the meetings addressing the issues here, there was little
attention paid to the rights and viewpoints of the *users* of computer programs
- most discussion centred on the rights of developers.  This too seems a Risk.

Robert Biddle, Computer Science, Victoria University, Wellington NEW ZEALAND


Discover Card

Brian M. Clapper <clapper@chekov>
Thu, 23 Aug 90 11:15:19 -0400
I recently received a Discover credit card and found that it boasts a
24-hour toll-free hot-line.  A colleague informed me that one can call this
hotline to retrieve account information from an automated system.  She noted
that it didn't request any identity verification, just the account number.

I called the number, and when prompted with the voice menu, selected the
option that would allow me to get my account balance.  I was connected with
a person, not a computer.  This operator requested such account verification
information as my address and SSN.  I figured either my colleague must have
been mistaken or the Discover folks had changed their policy.

After requesting some information from the representative, I asked him
whether one could obtain the same data on-line without talking to a person.
He assured me that all I needed was a touch-tone phone and my account number.
I asked him whether I had to verify my identify in any way -- there is no
PIN associated with this card, to my knowledge -- and was told, "No."

I was a little puzzled, since I'd called from a touch tone phone, so I called
back.  I turns out I had made a mistake when I called the first time -- I
forgot to end my request with a '#' -- and the computer assumed I was on a
rotary phone and connected me to an operator.  This time I pressed the '#',
and the system prompted me to enter my account number.  I did, and was
immediately informed of my balance, available credit, previous statement
balance, and current statement due date.  My colleague was right: I didn't
have to verify my identity in any way.

I find this odd, and more than a little irritating.  First, most
bank-by-phone systems I have used require a PIN before divulging personal
account data.  Second, the human representative required my name, address,
account number, and SSN before he would allow me to solicit information,
implying that Discover has a policy of verifying an account holder's
identity, but did not apply that policy to their automated system.

I don't particularly like the idea of someone being able to get that
information on me merely by calling a freely advertised number and punching
in my account number.  Any clerk at a store where I use my card can make the
call.  Anyone who finds or steals my card can, as well; Discover even makes
it easy by printing the number on the back of the card.

A letter complaint is in the mail...

Brian Clapper, Naval Air Development Center


Total Knowledge about all individuals

"Clifford Johnson" <A.CJJ@Forsythe.Stanford.EDU>
Wed, 22 Aug 90 13:53:40 PDT
> CANBERRA: Debt collectors believe that in the not too distant
> future there will be "total knowledge" about all individuals . . .

No need to look down under or into the future for this sort of thing.  Readers
of misc.legal may recall a recent submission reciting a bill already passed by
the Oklahoma state legislature, to take effect next January, requiring every
individual to list every possession (yes, even books) and its value for tax
purposes -- and requiring a physical inspection of every persons' property at
least once every four years to verify the accuracy of the list.


Re: Debt collector proposes "total knowlege" credit database

Alan J Rosenthal <flaps@dgp.toronto.edu>
Thu, 23 Aug 90 17:07:55 EDT
In comp.risks ph@wyvern.cs.uow.edu.au quotes a newspaper article:
>they believe banks and other lenders will have so much information that debt
>collectors will be made redundant.
...
>"Tomorrow's credit grantor will be extending credit in a perfect market with
>total knowledge of the debtor," Mr Owens asserted.

I can't believe how stupid people are sometimes when talking about the
allegedly glorious future.  Does he think that tomorrow's creditor's knowledge
will include seeing into the future to see the debtor's circumstances at the
time at which payment is required?

Sigh, it seems that only a minority of people realize that the application of
technology does not automatically solve any problem.


useful credit-related addresses

Henry Mensch <henry@GARP.MIT.EDU>
Wed, 22 Aug 90 17:36:20 -0400
the "medical information file" that simson referred to in his article
is the file that health insurers use (along with other information) to
determine if an individual is insurable.  if you test positive for HIV
antibodies (and weren't bright enough to get tested at an anonymous
test site) then your result will likely show up here...

Henry Mensch   E40-379 MIT,  Cambridge, MA


"Rogue Programs: Viruses, Worms, and Trojan Horses"

Gene Spafford <spaf@cs.purdue.edu>
Wed, 22 Aug 90 16:17:11 EST
I just received a copy of the book "Rogue Programs: Viruses, Worms, and Trojan
Horses," edited by Lance J. Hoffman.  The book is published by Van Nostrand
Reinhold, copyright 1990, ISBN 0-442-00454-0.  The publisher's suggested list
price is $32.95, in softcover.

This book is a collection of 27 articles and book excerpts about "vandalware"
on computer systems.  Contributors include Len Adleman, Anne Branscomb, David
Chess, Fred Cohen, George Davida, David Ferbrache, Michael Gemignani, Harold
Joseph Highland, me (!), Ken Thompson, Steve White, and many others.  The table
of contents lists the following parts: Overview of Rogue Programs, Social and
Legal Issues and Effects, Rogue Programs and Personal Computers, Rogue Programs
and Networks, and Emerging Theory of Computer Viruses.

Perhaps I'm somewhat biased because I'm the author or co-author of 3 of the 27
contributions.  However, I believe this is the most comprehensive collection on
the topic currently available.  It contains case studies, theoretical analyses,
legal opinions, and step-by-step technical information.  The book is valuable
as both a technical reference and as a textbook around which a course can be
organized.  I'm sure it is going to become one of the 2 or 3 standard
references in the field (the forthcoming book from ACM Press edited by Peter
Denning will probably be the other biggie).

If you are interested in some of the issues involving viruses, worms and
vandalware, you really should get a copy of this book and check it out.
                                                                       --spaf

Please report problems with the web pages to the maintainer

Top