Computer Underground Digest--Fri Aug 16, 1991 (Vol #3.30)
Moderators: Jim Thomas and Gordon Meyer (
[email protected])
CONTENTS, #3.30 (AUGUST 16, 1991)
Subject: File 1--Review: PRACTICAL UNIX SECURITY (Garfinkel and Spafford)
Subject: File 2--Review of "Practical Unix Security" (Garfinkel & Spafford).
Subject: File 3--Cyberspace and the Legal Matrix: Laws or Confusion? (Reprint)
Subject: File 4--Mystery Lurks In The Death of INSLAW Reporter
ARCHIVIST: BRENDAN KEHOE
RESIDENT CONVALESCENT: BOB KUSUMOTO
ULTRA-SCANMEISTER: BOB KRAUSE
CuD is available via electronic mail at no cost. Printed copies are
available by subscription. Single copies are available for the costs
of reproduction and mailing.
Issues of CuD can be found in the Usenet alt.society.cu-digest news
group, on CompuServe in DL0 and DL4 of the IBMBBS SIG, DL1 of LAWSIG,
and DL0 and DL12 of TELECOM, on Genie, on the PC-EXEC BBS at (414)
789-4210, and by anonymous ftp from ftp.cs.widener.edu,
chsun1.spc.uchicago.edu, and dagon.acc.stolaf.edu. To use the U. of
Chicago email server, send mail with the subject "help" (without the
quotes) to
[email protected].
COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing
information among computerists and to the presentation and debate of
diverse views. CuD material may be reprinted as long as the source
is cited. Some authors do copyright their material, and they should
be contacted for reprint permission. It is assumed that non-personal
mail to the moderators may be reprinted unless otherwise specified.
Readers are encouraged to submit reasoned articles relating to the
Computer Underground. Articles are preferred to short responses.
Please avoid quoting previous posts unless absolutely necessary.
DISCLAIMER: The views represented herein do not necessarily represent
the views of the moderators. Digest contributors assume all
responsibility for ensuring that articles submitted do not
violate copyright protections.
----------------------------------------------------------------------
Date: Wed, 14 Aug 1991 11:22:00 CDT
From: "Jim Thomas" <
[email protected]>
Subject: File 1--Review: PRACTICAL UNIX SECURITY (Garfinkel and Spafford)
Review of: _Practical UNIX Security_, by Simson Garfinkel and
Gene Spafford. Sebastopol, (Calif): O'Reilly & Associates, Inc.
481 pp. $29.95 pb.
Because I know virtually nothing about UNIX, I am eminently qualified
to comment on the Garfinkel/Spafford (G&S) volume. If I can understand
and learn from it, anybody can. I have no idea whether UNIX Whizzes
will find the tome worthwhile, but as a UNIX beginner, I judge the
book a first-rate primer for inquisitive, but uninformed, neophytes.
To label the G&S book a "security" manual is misleading. Their
introductory warning to would-be hackers who would interpret the book
as in invitation to break into the authors' systems is perhaps a bit
melodramatic (p. xxvii), but the book is about security as M*A*S*H is
about war. I suspect system administrators, such as the following
reviewer who is plagued by the screw-ups of folks like me who learn by
punching in commands to see what they do--would hope users read _UNIX
Security_ on the chance it would make them (the users, not the
sysads) better citizens and cause them (the sysads, not the users)
less hassle in answering obvious questions.
I'd guess that most users do not learn UNIX by taking classes, but
rather by trial and error, pestering the pros, and maybe even
purchasing a book or two. Unlike the detailed "how to" books, such as
_UNIX Made Easy_ (an oxymoronic title) that cover a wide range of UNIX
uses and commands from programming to learning the intricacies of vi,
_UNIX Security_ is more basic, focused, and appropriate for the UNIX
newnicks. Despite the focus on security, the book's emphasis is on
responsible system use by teaching, step-by-step, those aspects of use
at which security requisites arise. Such lessons obviously require an
overview of the basics, which the authors provide.
They begin with an overview of the history of UNIX dating from the
Mid-1960s with Multics to the rewriting and playful renaming of
Multics to UNIX derived from the fact that Multics tried to to
multiple things, and UNIX just one: Run programs (p. 7). But, the
openness and ease of UNIX also had a major drawback: The early
versions were not secure. Many of the original problems were the
result of holes in the software itself, but--and the authors stress
this throughout--the most serious security lapses are the result of
human error or indifference.
Cracking into any system in most cases requires access to an account
and then using that account to penetrate deeper by using various
tricks to obtain root privileges. As a consequence, the first line of
defense, argue the authors, is to assure that unauthorized logins are
prevented. There is little new for sysads in the book's first
substantive chapter, "Users, Groups, and the Superuser." But the new
user will find this explanation, along with the various charts
clarifying what all those symbols mean when we list the /etc/group
file, quite helpful. Subsequent chapters explaining files, defending
accounts, and securing data provide useful examples that can serve as
exercises for the beginner in ferreting out the complexity of UNIX as
well as for protecting one's own account against intruders. What for
experienced users might seem mundane serves newer users with ways to
develop and test knowledge of *one's own* account. The periodic
distinctions between legitimate curious use and inappropriate abuse
provide guidelines that encourage exploration while reminding the user
of the courtesies owed to the sysads and others.
For those active on the nets, a five chapter section on modems, UUCP,
Networks and Security, Sun's NFS, and other topics condenses much of
Quarterman's $50 _The Matrix_ into a few comprehensible chapters.
Although intended more for those setting up systems than using them,
the discussion illustrates what occurs when we dial into a UNIX system
and summarizes various operations of remote systems, including sending
mail and file transfer. I found that the general discussion helped
clarify the occasional error message and helps to use other systems
more efficiently, ranging from moving around within them to using ftp
and telnet.
Sysads may find little new in the discussion of what to do when a
breakin occurs, but the step-by step procedures might serve as a
mindful checklist. The cardinal rules--"don't panic" and "document"
are sound for all computer users when they suspect intrusion, and
inexperienced users should find the discussion helpful in reviewing
how systems track and identify other users.
Although most users do not encrypt files and know nothing about the
process, the early discussion of the process (pp 29-31) provides an
understandable overview of what encryption is and how it works. With
increasing emphasis on secure systems, discussions of encryption also
increase, and even for those of us who are functionally illiterate, it
helps to know what salt is and what it does to our password. Chapter
18 is devoted to a more detailed summary of encryption systems,
including ROT13 and crypt.
The chapter on "Computer Security and U.S. Law" is too brief. G&S
explain the legal options for prosecution and remind readers of the
hazards of criminal prosecution, which include law enforcement
illiteracy, the problems of search warrants, and the dangers of
equipment seized as evidence. Alluding to the experience of Steve
Jackson Games, where law enforcement seizure of equipment and a
pre-publication version of a new game had led to a suit against
Federal and private sector personnel, G&S warn employeers whose
employees--or they themselves--may have equipment taken by law
enforcement of their right to receipts and of the need to discuss the
conditions of return.
The section on law (p. 349) lists the laws likely to be used in
prosecuting computer intrustion along with a few word summary of the
violation each law represents. Because even the most recent laws tend
to be overly-broad and vague, the section on "Federal computer crime
laws" could have been expanded to include a discussion of the problems
of legal language and give a better summary of the relevant language
of each. It is also a bit disturbing that the chapters seems to
advocate (despite the caveats) prosecution in favor of other, less
punitive but equally effective, actions. My bias as an advocate of
decriminalization of many types of crimes and as a believer in
reducing, rather than increasing, the burden of the criminal justice
system led to me quibble, perhaps unduly, with what is otherwise a
well-summarized chapter. But, especially for students (who constitute
the bulk of the "hacker" population), there are numerous non-legal
options available, and to my mind there should have been greater
emphasis on elaborating the non-legal responses available and even
suggesting some new ones.
There is one irony in the G&S volume. Take the various chapters,
retitle them as "how to break into..." or "UNIX cryptography" and
rewrite the text in cyberese, then publish them in PHRACK or LoD/TJ,
and add at the end of each the caution "Don't get caught with this,"
and you might have law enforcement breathing down your neck. G&S have
written--albeit more articulately and with more detail and insight--on
the kinds of topics with similar examples to those found in some of
the better p/h newsletters. Proving, perhaps, that form can be more
important as content.
My goal here has been to suggest for the non-UNIX expert why they wold
find _Practical UNIX Security_ worth reading. Despite the title and
the authors' professed goal, is crammed with information on all phases
of UNIX use and with tips for utilizing the system's power. Those who
read and experiment with the volume are likely to become better system
and net citizens, both because of their knowledge and proficiency and
because of the socialization process entailed by practicing what the
authors teach us. It is well worth the price.
((Jim Thomas is CuD co-editor and trying to learn UNIX after
9 years on an IBM mainframe))
------------------------------
Date: Wed, 14 Aug 1991 11:22:00 CDT
From: Neil Rickert <
[email protected]>
Subject: File 2--Review of "Practical Unix Security" (Garfinkel & Spafford).
Following on the heals of the development of the microprocesor, the
last decade has seen an explosion of computers. However the expertise
to administer these computers has not grown at anything like the same
pace. The result is that there are large numbers of computers
administered by people who are seriously short of experience. Worse
still many of these computers are connected to Internet, readily
exposing them to would be electronic intruders.
Unix systems have particularly flexible networking facilities, but
while these provide great benefits to the Unix user, they also provide
portholes through which breakins can be attempted.
In the circumstances "Practical Unix Security" is a very timely
publication.
This is a book for all Unix admins, not just those concerned about
security. If you have a Unix work station on your desktop, and if you
are the sole user, and it not connected to any networks, you perhaps
have little to worry about in terms of security. But you can still
benefit greatly from reading "Practical Unix Security". For this is
not just a book about security. It also covers many aspects of
administering Unix systems. Indeed, it fills in many of the gaps left
by the system administration books that you will find in the Unix
section of your bookstore.
Doubtless the book will also be of interest to Unix detractors who
will welcome the opportunity to gloat at some of the security problems
in Unix. But while they are gloating, they should perhaps look more
closely at their own systems for problems which may be lurking just
below the surface, less well known perhaps, because their systems lack
the openness of Unix.
If you are looking for a specific list of steps to break into a Unix
system, this is not the book for you. The author's are quite careful
on this point. They do, however, give a guided tour through the
system indicating the points of weakness, and suggesting how to
configure your system to minimize the security problems. The book
covers passwords, file permissions and the use of umask, the risk of
trojan horses and selecting a PATH which reduces the risk, SUID and
SGID programs, logging activity, configuring UUCP to minimize security
problems, networking cautions including cautions on the use of NFS and
NIS services. It discusses Kerberos, SunOS secure rpc, and firewall
arrangements, as ways of enhancing security.
Some time is spent on discussing good system backup plans. A good
backup strategy can be important if your system security is broken,
for it allows you to recover any damaged files. But, more important,
it also provides recovery from the acts of incredible stupidity to
which even the most experienced computer administrators are
occasionally prone.
Security is not a technical problem, and the authors are careful to
point this out. It is a people problem. Technological fixes by
themselves don't work. If, for example, you impose a system of
machine generated passwords, this may create passwords that users can
not remember, causing them to write the passwords down on paper with a
net loss in security. There is always a tradeoff between security and
convenience. Some of the stricter security measures may generate
sufficient inconvenience that users will unthinkingly develop ways of
subverting the security mechanisms. Still, there is no excuse for
vendors favoring convenience to the extent that they sell systems with
virtually no security. Perhaps one of the most serious of these is
distribution of default configurations with a '+' in /etc/hosts.equiv
The authors do not mince words on page 238, where they state "This
is a major security hole" and on the next page "If you have a plus
sign in your host.equiv (sic) file, REMOVE IT."
Any book this length is bound to contain a few mistakes. "Practical
Unix Security" is no exception. Here are some examples:
p. 54 The su command only changes your process's effective UID; the real
UID remains the same.
That sounds to me like a badly broken implementation of su.
p. 92 Letting a user run the Berkeley mail(1) program without logging in is
dangerous, because the mail program allows the user to run any command
by preceding a line of the mail message with a tilde and an
exclamation mark.
While I agree with the authors that it would be unwise, the risk is
not as obvious as they assert. When a user attempts such a shell
escape, 'mail' implements it by invoking the user's login shell. If,
as in this example, the login shell is 'mail', then the tilde escape
to execute say 'csh' would result in 'mail' attempting to execute
'/usr/ucb/mail -c csh', and that would not get you very far.
p. 218 Your mail system should not allow mail to be sent directly to a file.
Mailers that deliver directly to files can be used to corrupt system
databases or application programs. You can test whether or not your
system allows mail to be sent to a file with the command sequence:
mail /tmp/mailbug
this is a mailbug file test
^D
If the file mailbug appears in the /tmp directory, then your mailer is
insecure.
This is not a good test to try. If 'mail /tmp/mailbug < message-file'
happens to work, it doesn't do anything more dangerous than say
'cat >> /tmp/mailbug < message-file'. There is only a problem if you can
persuade 'mail' to write to a file you would not otherwise be able to
write to, or to create a file with permissions and ownership you could
not normally use. If, for example, your 'mail' program were to
directly handle mail to files, and pass all other mail off to
'sendmail', this would not be a security problem at all unless your
mail program runs suid or sgid.
+++++
These examples are really only minor failings. But they do have the
effect of making the inexperienced reader believe that Unix security
is much weaker than in reality it is. This will tend to make
inexperienced admins unnecessarily paranoid, and perhaps afraid to do
anything useful with their system.
My major criticism of this book, in fact, is that it seems to present
an excessively paranoid view of the subject. The authors make an
attempt to avoid this very early, when they discuss risk assessment,
and point at that you need not go overboard, but should provide
sufficient security for the likely risk given the nature of the data
on your computer and the way it is used.
Unfortunately, the author's seem to lose sight of this later on when
they are busily pointing out the likely weaknesses, and how to protect
against them. Experienced administrators will have no trouble
deciding how much security they need, and balancing this with the
convenience they wish to provide to their users. But I worry that
novice administrators will not be able to make this judgement. They
may either overreact, and be so restrictive that their system is not
as useful as it should be, or they may decide that achieving
reasonable security is hopeless, and not even take the simplest steps
which are often the most important.
In summary, I recommend this book for every Unix administrator and
would-be administrator, not just for the security information, but for
the insight it gives into the workings of Unix. But I hope the reader
will keep in mind that the authors have made things sound scarier than
they really are.
((Neil Rickert, a professor of computer science, is the sysad of
the UNIX system at Northern Illinois University)).
------------------------------
Date: Mon, 28 Jul 1991 10:15:13 CDT
From:
[email protected]
Subject: File 3--Cyberspace and the Legal Matrix: Laws or Confusion? (Reprint)
((Moderator's note: The following first appeared in Boardwatch, and
later was sent across the nets by the author. We reprint it as part
of the on-going discussion about life in cyberspace)).
Cyberspace and the Legal Matrix: Laws or Confusion?
((By Lance Rose))
Cyberspace, the "digital world", is emerging as a global arena of
social, commercial and political relations. By "Cyberspace", I mean
the sum total of all electronic messaging and information systems,
including BBS's, commercial data services, research data networks,
electronic publishing, networks and network nodes, e-mail systems,
electronic data interchange systems, and electronic funds transfer
systems.
Many like to view life in the electronic networks as a "new frontier",
and in certain ways that remains true. Nonetheless, people remain
people, even behind the high tech shimmer. Not surprisingly, a vast
matrix of laws and regulations has trailed people right into
cyberspace.
Most of these laws are still under construction for the new electronic
environment. Nobody is quite sure of exactly how they actually apply
to electronic network situations. Nonetheless, the major subjects of
legal concern can now be mapped out fairly well, which we will do in
this section of the article. In the second section, we will look at
some of the ways in which the old laws have trouble fitting together
in cyberspace, and suggest general directions for improvement.
LAWS ON PARADE
- Privacy laws. These include the federal Electronic Communications
Privacy Act ("ECPA"), originally enacted in response to Watergate, and
which now prohibits many electronic variations on wiretapping by both
government and private parties. There are also many other federal and
state privacy laws and, of course, Constitutional protections against
unreasonable search and seizure.
- 1st Amendment. The Constitutional rights to freedom of speech and
freedom of the press apply fully to electronic messaging operations of
all kinds.
- Criminal laws. There are two major kinds of criminal laws. First,
the "substantive" laws that define and outlaw certain activities.
These include computer-specific laws, like the Computer Fraud and
Abuse Act and Counterfeit Access Device Act on the federal level, and
many computer crime laws on the state level. Many criminal laws not
specific to "computer crime" can also apply in a network context,
including laws against stealing credit card codes, laws against
obscenity, wire fraud laws, RICO, drug laws, gambling laws, etc.
The other major set of legal rules, "procedural" rules, puts limits on
law enforcement activities. These are found both in statutes, and in
rulings of the Supreme Court and other high courts on the permissible
conduct of government agents. Such rules include the ECPA, which
prohibits wiretapping without a proper warrant; and federal and state
rules and laws spelling out warrant requirements, arrest requirements,
and evidence seizure and retention requirements.
- Copyrights. Much of the material found in on-line systems and in
networks is copyrightable, including text files, image files, audio
files, and software.
- Moral Rights. Closely related to copyrights, they include the
rights of paternity (choosing to have your name associated or not
associated with your "work") and integrity (the right not to have your
"work" altered or mutilated). These rights are brand new in U.S. law
(they originated in Europe), and their shape in electronic networks
will not be settled for quite a while.
- Trademarks. Anything used as a "brand name" in a network context
can be a trademark. This includes all BBS names, and names for
on-line services of all kinds. Materials other than names might also
be protected under trademark law as "trade dress": distinctive sign-on
screen displays for BBS's, the recurring visual motifs used throughout
videotext services, etc.
- Right of Publicity. Similar to trademarks, it gives people the
right to stop others from using their name to make money. Someone
with a famous on-line name or handle has a property right in that
name.
- Confidential Information. Information that is held in secrecy by
the owner, transferred only under non-disclosure agreements, and
preferably handled only in encrypted form, can be owned as a trade
secret or other confidential property. This type of legal protection
is used as a means of asserting ownership in confidential databases,
from mailing lists to industrial research.
- Contracts. Contracts account for as much of the regulation of
network operations as all of the other laws put together.
The contract between an on-line service user and the service provider
is the basic source of rights between them. You can use contracts to
create new rights, and to alter or surrender your existing rights
under state and federal laws.
For example, if a bulletin board system operator "censors" a user by
removing a public posting, that user will have a hard time showing his
freedom of speech was violated. Private system operators are not
subject to the First Amendment (which is focused on government, not
private, action). However, the user may have rights to prevent
censorship under his direct contract with the BBS or system operators.
You can use contracts to create entire on-line legal regimes. For
example, banks use contracts to create private electronic funds
transfer networks, with sets of rules that apply only within those
networks. These rules specify on a global level which activities are
permitted and which are not, the terms of access to nearby systems and
(sometimes) to remote systems, and how to resolve problems between
network members.
Beyond the basic contract between system and user, there are many
other contracts made on-line. These include the services you find in
a CompuServe, GEnie or Prodigy, such as stock quote services, airline
reservation services, trademark search services, and on-line stores.
They also include user-to-user contracts formed through e-mail. In
fact, there is a billion-dollar "industry" referred to as "EDI" (for
Electronic Data Interchange), in which companies exchange purchase
orders for goods and services directly via computers and computer
networks.
- Peoples' Rights Not to be Injured. People have the right not to be
injured when they venture into cyberspace. These rights include the
right not to be libelled or defamed by others on-line, rights against
having your on-line materials stolen or damaged, rights against having
your computer damaged by intentionally harmful files that you have
downloaded (such as files containing computer "viruses"), and so on.
There is no question these rights exist and can be enforced against
other users who cause such injuries. Currently, it is uncertain
whether system operators who oversee the systems can also be held
responsible for such user injuries.
- Financial Laws. These include laws like Regulations E & Z of the
Federal Reserve Board, which are consumer protection laws that apply
to credit cards, cash cards, and all other forms of electronic
banking.
- Securities Laws. The federal and state securities laws apply to
various kinds of on-line investment related activities, such as
trading in securities and other investment vehicles, investment
advisory services, market information services and investment
management services.
- Education Laws. Some organizations are starting to offer on-line
degree programs. State education laws and regulations come into play
on all aspects of such services.
The list goes on, but we have to end it somewhere. As it stands, this
list should give the reader a good idea of just how regulated
cyberspace already is.
LAWS OR CONFUSION?
The legal picture in cyberspace is very confused, for several reasons.
First, the sheer number of laws in cyberspace, in itself, can create a
great deal of confusion. Second, there can be several different kinds
of laws relating to a single activity, with each law pointing to a
different result.
Third, conflicts can arise in networks between different laws on the
same subject. These include conflicts between federal and state laws,
as in the areas of criminal laws and the right to privacy; conflicts
between the laws of two or more states, which will inevitably arise
for networks whose user base crosses state lines; and even conflicts
between laws from the same governmental authority where two or more
different laws overlap. The last is very common, especially in laws
relating to networks and computer law.
Some examples of the interactions between conflicting laws are
considered below, from the viewpoint of an on-line system operator.
1. System operators Liability for "Criminal" Activities.
Many different activities can create criminal liabilities for service
providers, including:
- distributing viruses and other dangerous program code;
- publishing "obscene" materials;
- trafficking in stolen credit card numbers and other unauthorized
access data;
- trafficking in pirated software;
- and acting as an accomplice, accessory or conspirator in these and
other activities.
The acts comprising these different violations are separately defined
in statutes and court cases on both the state and federal levels.
For prosecutors and law enforcers, this is a vast array of options for
pursuing wrongdoers. For service providers, it's a roulette wheel of
risk.
Faced with such a huge diversity of criminal possibilities, few
service providers will carefully analyze the exact laws that may
apply, nor the latest case law developments for each type of criminal
activity. Who has the time? For system operators who just want to
"play it safe", there is a strong incentive to do something much
simpler: Figure out ways to restrict user conduct on their systems
that will minimize their risk under *any* criminal law.
The system operator that chooses this highly restrictive route may not
allow any e-mail, for fear that he might be liable for the activities
of some secret drug ring, kiddie porn ring or stolen credit card code
ring. The system operator may ban all sexually suggestive materials,
for fear that the extreme anti-obscenity laws of some user's home town
might apply to his system. The system operator may not permit
transfer of program files through his system, except for files he
personally checks out, for fear that he could be accused of assisting
in distributing viruses, trojans or pirated software; and so on.
In this way, the most restrictive criminal laws that might apply to a
given on-line service (which could emanate, for instance, from one
very conservative state within the system's service area) could end up
restricting the activities of system operators all over the nation, if
they happen to have a significant user base in that state. This
results in less freedom for everyone in the network environment.
2. Federal vs. State Rights of Privacy.
Few words have been spoken in the press about network privacy laws in
each of the fifty states (as opposed to federal laws). However, what
the privacy protection of the federal Electronic Communications
Privacy Act ("ECPA") does not give you, state laws may.
This was the theory of the recent Epson e-mail case. An ex-employee
claimed that Epson acted illegally in requiring her to monitor e-mail
conversations of other employees. She did not sue under the ECPA, but
under the California Penal Code section prohibiting employee
surveillance of employee conversations.
The trial judge denied her claim. In his view, the California law
only applied to interceptions of oral telephone discussions, and not
to visual communication on video display monitors. Essentially, he
held that the California law had not caught up to modern technology -
making this law apply to e-mail communications was a job for the state
legislature, not local judges.
Beyond acknowledging that the California law was archaic and not
applicable to e-mail, we should understand that the Epson case takes
place in a special legal context - the workplace. E-mail user rights
against workplace surveillance are undeniably important, but in our
legal and political system they always must be "balanced" (ie.,
weakened) against the right of the employer to run his shop his own
way. Employers' rights may end up weighing more heavily against
workers' rights for company e-mail systems than for voice telephone
conversations, at least for employers who use intra-company e-mail
systems as an essential backbone of their business. Fortunately, this
particular skewing factor does not apply to *public* communications
systems.
I believe that many more attempts to establish e-mail privacy under
state laws are possible, and will be made in the future. This is good
news for privacy advocates, a growing and increasingly vocal group
these days.
It is mixed news, however, for operators of BBS's and other on-line
services. Most on-line service providers operate on an interstate
basis - all it takes to gain this status is a few calls from other
states every now and then. If state privacy laws apply to on-line
systems, then every BBS operator will be subject to the privacy laws
of every state in which one or more of his users are located! This
can lead to confusion, and inability to set reasonable or predictable
system privacy standards.
It can also lead to the effect described above in the discussion of
criminal liability. On-line systems might be set up "defensively", to
cope with the most restrictive privacy laws that might apply to them.
This could result in declarations of *absolutely no privacy* on some
systems, and highly secure setups on others, depending on the
individual system operator's inclinations.
3. Pressure on Privacy Rights Created by Risks to Service Providers.
There are two main kinds of legal risks faced by a system operator.
First, the risk that the system operator himself will be found
criminally guilty or civilly liable for being involved in illegal
activities on his system, leading to fines, jail, money damages,
confiscation of system, criminal record, etc.
Second, the risk of having his system confiscated, not because he did
anything wrong, but because someone else did something suspicious on
his system. As discussed above, a lot of criminal activity can take
place on a system when the system operator isn't looking. In
addition, certain non-criminal activities on the system could lead to
system confiscation, such copyright or trade secret infringement.
This second kind of risk is very real. It is exactly what happened to
Steve Jackson Games last year. Law enforcement agents seized Steve's
computer (which ran a BBS), not because they thought he did anything
wrong, but because they were tracking an allegedly evil computer
hacker group called the "Legion of Doom". Apparently, they thought
the group "met" and conspired on his BBS. A year later, much of the
dust has cleared, and the Electronic Frontier Foundation is funding a
lawsuit against the federal agents who seized the system.
Unfortunately, even if he wins the case Steve can't get back the
business he lost. To this day, he still has not regained all of his
possessions that were seized by the authorities.
For now, system operators do not have a great deal of control over
government or legal interference with their systems. You can be a
solid citizen and report every crime you suspect may be happening
using your system. Yet the chance remains that tonight, the feds will
be knocking on *your* door looking for an "evil hacker group" hiding
in your BBS.
This Keystone Kops style of "law enforcement" can turn system
operators into surrogate law enforcement agents. System operators who
fear random system confiscation will be tempted to monitor private
activities on their systems, intruding on the privacy of their users.
Such intrusion can take different forms. Some system operators may
declare that there will be no private discussions, so they can review
and inspect everything. More hauntingly, system operators may indulge
in surreptitious sampling of private e-mail, just to make sure no
one's doing anything that will make the cops come in and haul away
their BBS computer systems (By the way, I personally don't advocate
either of these things).
This situation can be viewed as a way for law enforcement agents to do
an end run around the ECPA's bar on government interception of
electronic messages. What the agents can't intercept directly, they
might get through fearful system operators. Even if you don't go for
such conspiracy theories, the random risk of system confiscation puts
great pressure on the privacy rights of on-line system users.
4. Contracts Versus Other Rights.
Most, perhaps all, of the rights between system operators and system
users can be modified by the basic service contract between them. For
instance, the federal ECPA gives on-line service users certain privacy
rights. It conspicuously falls short, however, by not protecting
users from privacy intrusions by the system operator himself.
Through contract, the system operator and the user can in effect
override the ECPA exception, and agree that the system operator will
not read private e-mail. Some system operators may go the opposite
direction, and impose a contractual rule that users should not expect
any privacy in their e-mail.
Another example of the power of contracts in the on-line environment
occurred recently on the Well, a national system based in San
Francisco (and highly recommended to all those interested in
discussing on-line legal issues). A Well user complained that a
message he had posted in one Well conference area had been
cross-posted by other users to a different conference area without his
permission.
A lengthy, lively discussion among Well users followed, debating the
problem. One of the major benchmarks for this discussion was the
basic service agreement between the Well and its users. And a
proposed resolution of the issue was to clarify the wording of that
fundamental agreement. Although "copyrights" were discussed, the
agreement between the Well and its users was viewed as a more
important source of the legitimate rights and expectations of Well
users.
Your state and federal "rights" against other on-line players may not
be worth fighting over if you can get a contract giving you the rights
you want. In the long run, the contractual solution may be the best
way to set up a decent networked on-line system environment, except
for the old bogeyman of government intrusion (against whom we will all
still need our "rights", Constitutional and otherwise).
CONCLUSION
There are many different laws that system operators must heed in
running their on-line services. This can lead to restricting system
activities under the most oppressive legal standards, and to
unpredictable, system-wide interactions between the effects of the
different laws.
The "net" result of this problem can be undue restrictions on the
activities of system operators and users alike.
The answers to this problem are simple in concept, but not easy to
execute. First, enact (or re-enact) all laws regarding electronic
services on a national level only, overriding individual state control
of system operators activities in cyberspace. It's time to realize
that provincial state laws only hinder proper development of
interstate electronic systems.
As yet, there is little movement in enacting nationally effective
laws. Isolated instances include the Electronic Communications
Privacy Act and the Computer Fraud and Abuse Act, which place federal
"floors" beneath privacy protection and certain types of computer
crime, respectively. On the commercial side, the new Article 4A of
the Uniform Commercial Code, which normalizes on-line commercial
transactions, is ready for adoption by the fifty states.
Second, all laws regulating on-line systems must be carefully designed
to interact well with other such laws. The goal is to create a
well-defined, reasonable legal environment for system operators and
users.
The EFF is fighting hard on this front, especially in the areas of
freedom of the press, rights of privacy, and rights against search and
seizure for on-line systems. Reducing government intrusion in these
areas will help free up cyberspace for bigger and better things.
However, the fight is just beginning today.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Lance Rose is an attorney who works primarily in the fields of
computer and high technology law and intellectual property. His
clients include on-line publishers, electronic funds transfer
networks, data transmission services, individual system operators, and
shareware authors and vendors. He is currently revising SYSLAW, The
Sysop's Legal Manual. Lance is a partner in the New York City firm of
Greenspoon, Srager, Gaynin, Daichman & Marino, and can be reached by
voice at (212)888-6880, on the Well as "elrose", and on CompuServe at
72230,2044.
Copyright 1991 Lance Rose
The above article was originally published in Boardwatch, June, 1991
------------------------------
Date: Wed, 14 Aug 91 21:24 EDT
From:
[email protected]
Subject: File 4--Mystery Lurks In The Death of INSLAW Reporter
((Moderators' note: The death of INSLAW reporter J. Daniel Casolaro by
apparent suicide raises more questions about the entire affair.
Former U.S. Attorney General Elliot Richardson has called for a
Congressional investigation into the role of the Justice Department in
the affair. The Chicago Tribune (Aug.16, 1991, p. 14) reported that a
three hour autopsy this week found no evidence of anything other than
suicide, but that alternatives had not been ruled out, and no cause of
death has yet been given officially.))
Mystery Lurks In The Death Of Reporter
The Associated Press
Charleston, W. Va.- An investigative reporter found dead with his
wrists slashed in a hotel bathtub had warned others that he was on to
an explosive government scandal and might wind up dead in an
"accident".
The death of free-lance journalist Joseph D. Casolaro, 44, of Fairfax,
Va., initially was believed to be a suicide, but an autopsy was
ordered after the family members were contacted, police said Tuesday.
"He told us if he got killed in an accident not to believe it. That
was three months ago," said Casolaro's brother, Dr. M. Anthony
Casolaro of Alexandria, Va.
Casolaro had been working for a year on a book on allegations made in
1983 that the U.S. government stole software from INSLAW Inc., a
Washington company. The company has alleged in court that after it won
a $10 million contract with the Justice Department, the department
stole software designed to help law enforcement officials track cases.
Several of Casolaro's sources had warned him he would be in danger if
he continued his investigation, company owner Bill Hamilton said.
"I have some sources that Danny also had, and several of them told
him, 'These people will snuff you out without blinking an eye.' "
Hamilton said.
Dr. James Frost, an assistant state medical examiner, said a
preliminary report on the death would be completed today.
The body had been embalmed before the autopsy was held. Frost said
that was because early indications were that Casolaro had killed
himself.
Acquaintances said that they seen no indications of depression and
that Casolaro was in West Virginia to get more information.
In an outline of his book, Casolaro described his findings to Hamilton
as "an octopus, created in the 1950s and operating today with impunity
because it is intertwined with domestic and foreign intelligence
agencies...a criminal enterprise bent on making money.
------------------------------
End of Computer Underground Digest #3.30
************************************
