Forum on Risks to the Public in Computers and Related Systems
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Volume 7: Issue 32
Tuesday 9 July 1988
Contents
Privacy in computer age (no place to hide)- Sayed Banawan
- Follow-up to legal hypothetical
- CEReuben
- Preliminary A320 Inquiry Results
- Martin Harriman
- Computer terminals and dermatology
- Steve Philipson
- Info on RISKS (comp.risks)
Privacy in computer age (no place to hide)
Sayed Banawan <banawan@sun1.cs.uh.edu>
Wed, 3 Aug 88 11:26:44 CDT
From Houston Chronicle (August 2,1988) without any permission: No Place To Hide Your Privacy In Computer Age by Albert E. Denny (Denny is a free-lance writer in Baltimore. MD) IN case you haven't noticed, your privacy is being invaded and eroded at an unprecedented pace nowadays, thanks to advances in communications technology growing out of proliferation of computers. No matter who are you or where you live, information concerning your personal life and lives of family members is being pumped into databases at a scary rate. Even your own computer may be watching you. The congressional Office of Technology Assessment reported that computers are being used to keep tabs on as many as 6 million workers, from government employees to bank tellers. In some cases, employers monitor the productivity by programming the machines to record how many keystrokes users make per hour. Computerized phone systems track how many calls workers make or operators handle. They can also be rigged to listen in on conversations. "It's Big Brother at its worst." says U.S Rep. Don Edwards, D-Calif. "Just because you get a job doesn't mean you lose your constitutional rights." No clear legal definition of privacy exists, but experts agree on a few basics: It means the right to keep personal affairs to yourself and to know how information about you is being used. The issue has big implications on information companies. "I think the industry feels that individuals must sacrifice a certain amount of privacy in the information age," says Peter A. Marx, an attorney specialized in computer law. The public disagrees. A 1984 Harris Poll found 75 percent or respondents "very" or "somewhat" concerned about threats to privacy. There is no place to hide. If you are a living, breathing person moving about in society. making purchases and paying bills, a growing file of information exists on your personal life and habits that is little short of mind-boggling. Such information is compiled in diverse ways. If I buy a toaster made by a major appliance company, what right does it have to include with warranty (to be filled by me) a battery of questions relating to my age, sex, occupation, hobbies, marital status, etc.? The obvious reason such information is is being compiled is so it can be fed into a computer and the resulting data used for misleading (and unauthorized) purposes such as the sale of mailing lists to specialized companies for money. When I buy common stock or subscribe to a financial publication, the subsequent barrage of solicitations from financially related companies interested in selling me a product or service can only be traced to the sale of such confidential information to those seeking to profit from it. That is a gross misuse to privileged information and I resent ti. We are all at the mercy of computers which spew out massive amounts of information on individuals that can be collected, cross-matched and manipulated to generate much more detailed profiles of U.S. citizens than ever before - sometimes in a matter of seconds. This information can affect everything from credit ratings to welfare eligibility to your chances of renting an apartment or landing a job. consider the following major sources of data that feed into computers, giving the most intimate details of your personal life: The Internal Revenue Service exchanges data with state and local tax authorities to check the accuracy of tax returns. Your Social Security number, the code that third parties need to tap into computerized information on you, is available to at least 125 government and private agencies. About 40 states sell direct-mail companies the information you provide when registering a vehicle or applying for a license. That reveals you age, sex, Social Security number - even, through deduction, your income range. The FBI's National Crime Information Center has more than 10 million centrally stored recoreds of criminal histories - all available to state and local authorities. The five largest credit reporting companies control records on more than 150 million individuals. Some states are computerizing their court documents, making it easier to monitor everything from eviction to criminal proceedings. Most banks are allowed by law to give out information on customers' accounts and credit histories to state government investigators. Life insurance companies, by tapping a central data base run by a company called the Medical Information Bureau, can find out details about your medical history from claims information provided by insurers. Direct-mail companies, hungry fro your business, comb through some of the above records and other information, churning out lists of specific individuals whom salesmen or political campaign may want to contact. Get used to those increasingly more personal letters and the chummy phone calls from salespeople who want to sell you something. They know everything about you, and the best defense may be to sign up for a course in sales resistance.
Follow-up to legal hypothetical (RISKS-6.42)
<CEREUBEN%AMHERST.BITNET@MITVMA.MIT.EDU>
Mon, 8 Aug 88 08:26 EDT
In March of this year I posted a hypothetical in RISKS Digest,
volume 6 issue 42, concerning the proper allocation of rights in
software between programmers and their employers. At the time, I was
writing a law school paper on this issue, and was curious to see how well
the legal standards I was uncovering lined up with your perceptions of
the basic equities. Here is the promised follow-up on that posting.
I. THUMBNAIL LEGAL ANALYSIS OF THE HYPOTHETICAL **
** What follows is not practical legal advice, but merely a brief
theoretical analysis.
Briefly, The hypothetical dealt with a programmer named John Allan, who is
hired to design and implement a touch-sensitive help utility for use in his
employer Medicomp's medical database, MEDSTORE. Allan later uses this same
utility in the development of a tax expert system, TAXELF, and is sued by his
former employer Medicomp. The posting asked for your thoughts on the extent to
which Medicomp, by contract or law, should be able to limit Allan's later use
of code and ideas developed during his employment with them.
The current law's treatment of such a situation is at best complex and at
worst completely unsettled. Principles of copyright, patent, trade secret,
unfair competition and contract law all potentially apply. In each of these
areas, there are relatively few statutes and written judicial opinions which
deal directly with computer software. New cases are constantly being brought;
however, most of these are settled out of court.
Therefore, I can't possibly provide you with a definitive "answer" to the
John Allan problem. What follows is merely the OPINION of a recent law school
graduate as to how this particular hypothetical MIGHT be approached by a court
today. Bear in mind that the law is in a state of flux. Also note that I have
NOT yet been admitted to the bar, and that in any event, this should NOT be
taken as practical legal advice.
As many of you correctly noted, Allan would most likely be covered by a
carefully drafted employment ageement, assigning to Medicomp the ownership of
any copyright or patent in the original program. Even if the contract did not
speak to ownership issues (which would be unusual these days), Medicomp would
probably by seen by a court as owning the copyright. The program was written
by "an employee" and "within the scope of his employment," and would therefore
qualify as a "work for hire" under the Federal Copyright Act.
As owner of the copyright, Medicomp could prevent Allan from using the
actual code in his tax system, both through direct copying or rewriting from
memory. While de minimus copying of insignificant or nonunique modules would
probably be allowed, Allan's wholesale appropriation of the entire help utility
would likely be seen as a copyright violation.
Less settled is the extent to which Allan could use the non-code elements
of the program. A number of courts would extend Medicomp's copyright
protection to the program's structure and organization. Few, however, would
bar Allan from the use of touch sensitive help in general.
The important thing to note is that, for the purposes of copyright law,
Allan's status as creator does not give him any greater right to use the
software than members of the general public.
As an ex-employee, however, Allan is bound by a duty not to use or disclose
the "trade secrets" or "confidential information" of his employer. This duty is
inferred at common law, but would likely be specifically stated in Allan's
employment contract as well. The precise definition of "trade secret" and
"confidential information" varies greatly from state to state. Moreover, as
Medicomp would likely be seeking equitable relief, i.e., to enjoin Allan from
further use of the software, the court would be free to engage in a more
open-ended balancing of the equities than would be permissible if purely
monetary relief were sought.
Given the flexible nature of current trade secret doctrine, a court could
really go either way on this issue. The touch sensitive utility at issue here
does seem to fall within the generally accepted range of protected information:
Allan's solution to implementing touch sensitive help would probably be
considered sufficiently "novel" by a court, the utility was likely "held out as
secret" by Medicomp, and the product has obvious commercial "value." On the
other hand, a court would also consider the extent to which the program was
developed prior to employment, the fact that the TAXELF and MEDSTORE do not
compete, and, in a minority of jurisdictions, the extent to which Medicomp
contributed in the development process apart from salary.
More generally, though the court may undertake the analysis from a number
of different angles (trade secret, copyright, contract, etc.) the following
general factors would likely emerge as relevant:
1) The nature of the employment relationship and the language
of the employment agreement.
2) Protection of employee's interests in intellectual property
predating the employment relationship, and in job mobility
3) Protection of employer incentives to invest
4) The nature of what was taken - intangible ideas vs. tangible
code. Unfortunately, this arguably reduces to the question
of whether Allan can change the code enough to make the
second utility seem like an independent creation.
II. SURVEY RESULTS
I received close to 200 responses from programmers, employers, students and
professors involved in various aspects of computer technology. Unfortunately,
despite my specific instructions to the contrary, many of the responses seemed
to be an account of what the writer felt the law was, rather than how she would
like it to be. Therefore, it would be misleading to draw any conclusions along
the lines of "90% of those surveyed thought Allan should not be able to reuse
specific code."
However, I can draw some general conclusions. The responses seemed to line
up surprisingly well with the treatment under the current law as summarized
above. Again, it is not clear whether this is an indication that the law
tracks what is considered reasonable in the industry, or that RISKS readers are
well-informed of their legal rights. The responses also reflected the highly
controversial nature of the allocation question and the range of issues
considered relevant. Issues discussed included:
1) The importance of information-sharing to program
development. Many of the responses mentioned that
programmers are most efficient in an environment where
information is freely shared. None of the cases or
statutes I read seemed to even contemplate the importance
of information-sharing in the development of an appropriate
software protection scheme.
2) The importance of protecting the employer's investment
through ownership rights. There was almost universal
agreement that the employer investor should own the
software. The responses differed, however, on how broadly
ownership rights should be defined.
3) An employee's right to her general programming skill. There
was, however, substantial disagreement as to exactly what
constitutes "general skill". There was general agreement that
it does not include actual code, but the responses diverged greatly
as to whether general skill includes code written from memory,
program structure and functionality.
4) The importance of competitive harm. Lack of competitive
harm was often seen as a factor in favor of allowing a
departing employee to make use of software owned by his
employer.
5) The nature of the software in question. A few of the
responses suggested that some kinds of programs should be
singled out as being more worthy of protection than others.
(For example, an employer arguably should not be able to sue
an employee who recycles a standard sort program.)
6) The affect of pre-employment assignment agreements on
inventive behavior. While most people seemed to feel such
agreements are valid and enforceable, many noted that
incentives to invent, and in particular, to reveal those
inventions to one's employer, would be greatly reduced.
7) Problems in policing ownership rights in software. Many
of the responses noted the difficulties inherent in proving
misappropriation, particularly where the defendant
originally wrote the code.
8) The team-programming problem. Some of the responses opted
for employer ownership simply because it would be next to
impossible to determine which employees were primarily responsible
for the develpment of a product, and impractical to give
ownership rights to low-level programmers only marginally involved.
9) Software Tools. A minority of the responses suggested that
denying an employee access to actual code she wrote for a prior
employer could greatly undermine her effectiveness and marketability.
Thank you all for your responses. They were a great help
to me in analyzing and critiquing the current law's allocation scheme.
Again, I'm not in a position to give practical advice, but I would
like to say this much: the law in this area is extremely muddled. There are
no clear cut answers, and the few emerging standards are subject to change. So,
don't take anything for granted. Also, after reading hundreds of cases,
statutes, articles, etc., I am convinced that there is a GREAT need for more
input from the technical community. Many judges, laywers, legislators and
commentators, even those of us with some background in computer science, do not
have a firm grasp of all the intricacies and unique needs of the software
develpment industry. If the law is to serve its function of promoting the
development and accessibility of software products, the legal and technical
community must work hand in hand.
Preliminary A320 Inquiry Results
martin@bashful <@RELAY.CS.NET:martin@bashful>
Mon, 8 Aug 88 20:01:59 PDT
Aviation Week and Space Technology, August 8, 1988 has a paraphrase of the
preliminary report; if you want more details than my paraphrase of a
paraphrase contains, I refer you there (I'm too lazy to type in any
substantial extract).
The major points of interest to RISKS readers would seem to be:
* The CFM56 engines and the engine controls responded properly to control
inputs; the throttles were advanced 5 seconds before impact, and the
engines had spooled up to 83% N1 speed by impact. This was not enough
to produce any useful change in aircraft attitude or speed (indeed, the
aircraft's airspeed would seem to have continued to decrease during
this time).
* The pilot and copilot (apparently informally) planned to fly at 100 ft.
AGL for the flyby, with no planned airspeed (oops). They ignored
three radar altimeter callouts below this altitude (the radar altimeter
gave six callouts in the 25 seconds between 100 ft. and impact, three
after the throttles were advanced).
* The pilot intentionally disabled the alpha floor protection mode in the
autothrust system; this mode is intended to provide protection against
windshear accidents. Alpha floor refers to the symbol used for angle of
attack--alpha floor would normally apply takeoff/go-around thrust if
the angle of attack were to exceed 15 degrees. As you can see from
following the altitude/speed profile of this flight, large aircraft
don't accelerate and climb very well (that is to say, at all) at low
speeds and high angles of attack. It takes a long time to spool up
large high-bypass engines, and it takes even longer before that energy
input has any effect on the aircraft.
At any rate, Aviation Week says the investigation is now trying to
determine why the pilot and copilot were unaware of their situation (that
is, why they were apparently unaware that they were lower than they
intended, and presumably why they were unaware that they were in deep
trouble with energy (= airspeed) management: airspeed dropped from
151 kt. at 25 seconds before impact to 112 kt. one second before impact).
In unrelated French (un)safety news, SNCF is investigating two changes to
brakes on its trains, following the second major accident in Paris: they
are considering replacing the conventional vent-all-the-air-and-eeeeeek
emergency brakes with an intercom to the driver, and they are considering
removing the disconnect valves which enable train crews to disable the
brakes on an individual carriage. (The source for this fine item is
New Scientist; the British railway-isms may give that away.)
--Martin Harriman
martin@cadev4.sc.intel.com
Computer terminals and dermatology (Re: RISKS-7.31)
Steve Philipson <steve@aurora.arc.nasa.gov>
Mon, 8 Aug 88 21:18:54 PDT
I found the article posted by steinmetz!welty@uunet.UU.NET (richard welty) on "Computer terminals and dermatology" very interesting. There were several statements in the article that directly contradict several studies I've read. For example: VDTs produce several types of electromagnetic radiation. The cathode ray tube emits low-energy x-rays. The phosphor material of the screen emits ultraviolet, visible, and infrared radiation. The electronic circuits produce radiofrequency and very-low-frequency radiation. Most electrical and electronic equipment can generate ``electrical noise,'' a low-level, broad-spectrum electromagnetic radiation. To date, no adverse biological effects in humans have been documented from these electromagnetic fields and the level of radiation emitted is far below the occupational standards set by federal authorities (references 2-4). Current design VDT's (within the last 10 years) emit essentially no detectable x-rays. Light, from the u/v through i/r range, is of low intensity, less than from typical office incandescent and flourescent bulbs. RF intensities are generally lower than the ambient intensities from local radio and TV stations. The article does point out that no known adverse effects have been linked to these sources at these levels, so the earlier statements aren't really significant. The article notes onset of dermatitis during conditions of "low ambient relative humidity at the time of the exposure", and that "The electro- static fields, however, are more likely to be the causitive agent of VDT dermatitis." These observations are consistent, as low humidity increases the tendency of electrostatic devices to precipitate out charged airborne particles. However, causality is not observed: " Whether this is a direct effect of the field itself or an irritant dermatitis from airborne particles is unknown." About three or four years ago, a panel at the ACM SIGCHI conference discused the issue of VDT hazards to health. Dermatitis was observed in several case studies. It was discovered that the effected operators had the habit of touching the screen and later touching their faces. This action served to transfer particulates that had precipitated out of the air from the screen onto the faces of the operators. The industrial "fix" to the problem was to institute a procedure of cleaning the screens of all VDT's at the beginning and end of each work shift. Blocking agents would be expected to help as they would not only reduce skin contact with the precipitated material, but also reduce the incidence of operators touching the screen, as this action would coat the screen with blocking agents transferred by the fingers. The conclusion of the SIGCHI panel was that the greatest danger to VDT users was through poorly designed workstations that contribute to poor posture, increased back and muscle strain, and visual problems causing eye strain, headaches, and even seizures. Straighten up out there, and clean those screens regularly!
Report problems with the web pages to the maintainer