|
Risks Digest 10.24
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
/** comp.risks: 14.0 **/
** Topic: RISKS DIGEST 10.24 **
** Written 4:44 pm Aug 23, 1990 by risks in cdp:comp.risks **
RISKS-LIST: RISKS-FORUM Digest Thursday 23 August 1990 Volume 10
: Issue 24
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED
SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann,
moderator
Contents:
E-mail lawsuit (Sean)
Re: Electronic house arrest units (D. King)
Proposed ban on critical computerized systems (Cameron, PGN)
Object Code Copyright Implications (Robert Biddle)
Discover Card (Brian M. Clapper)
Total Knowledge about all individuals (Clifford Johnson, Alan J
Rosenthal)
Re: Useful credit-related addresses (Henry Mensch)
"Rogue Programs: Viruses, Worms, and Trojan Horses" (Gene
Spafford)
The RISKS Forum is moderated. Contributions should be relevant,
sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to [email protected], with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to [email protected].
TO FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>GET RISKS-i.j <CR>; j is TWO digits. Vol summaries in
risks-i.00 (j=0); "dir risks-*.*<CR>" gives directory listing of back issues.
ALL CONTRIBUTIONS ARE CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
THE MOST RELEVANT CONTRIBUTIONS MAY APPEAR IN THE RISKS SECTION OF REGULAR
ISSUES OF ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, UNLESS YOU STATE OTHERWISE.
----------------------------------------------------------------------
Date: Thu, 23 Aug 90 06:15:15 EDT
From: [email protected]
Subject: E-mail lawsuit
>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.
------------------------------
Date: Wed, 22 Aug 90 13:34:44 PDT
From: [email protected]
Subject: Re: Electronic house arrest units (Gong, RISKS-10.22)
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]
------------------------------
Date: Wed, 22 Aug 90 12:56:27 PDT
From: [email protected]
Subject: Proposed ban on critical computerized systems
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.
------------------------------
Date: Wed, 22 Aug 1990 14:49:34 PDT
From: RISKS Forum <[email protected]> [PGN]
Subject: Re: proposed ban on critical computerized systems
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
------------------------------
Date: Thu, 23 Aug 90 14:48:54 +1200
From: [email protected]
Subject: Object Code Copyright Implications
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
------------------------------
Date: Thu, 23 Aug 90 11:15:19 -0400
From: Brian M. Clapper <clapper@chekov>
Subject: Discover Card
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
------------------------------
Date: Wed, 22 Aug 90 13:53:40 PDT
From: "Clifford Johnson" <GA.CJJ@Forsythe.Stanford.EDU>
Subject: Total Knowledge about all individuals
> 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.
------------------------------
Date: Thu, 23 Aug 90 17:07:55 EDT
From: Alan J Rosenthal <[email protected]>
Subject: Re: Debt collector proposes "total knowlege" credit database
In comp.risks [email protected] 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.
------------------------------
Date: Wed, 22 Aug 90 17:36:20 -0400
From: [email protected] (Henry Mensch)
Subject: useful credit-related addresses
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
------------------------------
Date: Wed, 22 Aug 90 16:17:11 EST
From: Gene Spafford <[email protected].edu>
Subject: "Rogue Programs: Viruses, Worms, and Trojan Horses"
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
------------------------------
End of RISKS-FORUM Digest 10.24
************************
** End of text from cdp:comp.risks **
|
|
