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.
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.
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 email@example.com
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