The RISKS Digest
Volume 7 Issue 32

Tuesday, 12th July 1988

Forum on Risks to the Public in Computers and Related Systems

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

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

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!

Please report problems with the web pages to the maintainer

x
Top