The Future of Trespass and Property in Cyberspace

An outsider who entered a company office and began reading files in a file cabinet would no doubt be arrested for trespass. Similarly, it would be improper and a violation of federal law for someone to open and read another person's mail, even if lax security, such as an unlocked mailbox, permitted the intrusion. It would be no defense, of course, that the trespasser was merely curious and had no sinister use for the information beyond finding out what the letters said. There is no basis to treat differently a trespasser who accesses information by computer. [Charney, Alexander 1996]

Introduction and Background

Human nature makes each of us create metaphors and models with which to understand and analyze new situations.  Case law, for example, uses metaphors drawn from one particular case to another in order to create justification for a certain judgment.  Computer trespass is the perfect example of how real space law is being extended by metaphor into cyberspace.  Unfortunately, it is also the perfect example of where metaphors can fall short.

Until now, computer trespass has been treated similarly by analogy to real space trespass, even in the face of imperfection and difficulty.  That is, an act in cyberspace which can be easily translated to a real space crime is therefore considered a crime.  In some cases, the application of real space trespass law to unauthorized cyberspace access has been done successfully.  In others, what seems like a crime has not been deemed so on the weakness of the connection between real space and cyberspace trespass [1].  Laws, such as the Computer Fraud and Abuse Act on the federal level as well as many state statutes, have also tried to translate trespass law into cyberspace, but have done so largely without success.  This is because they are fairly specific in their definition both of what a computer is and what unauthorized access is [2].

The retroactive modification of legislation, to include actions which society deems unacceptable, is futile.   If every computer trespass were the impetus for another rewording of the Computer Fraud and Abuse Act, then the Act probably is not doing its job [3].  The problem, however, is not to create exhaustive lists of currently conceivable actions, categorizing each as legal or illegal.  History has shown that such a list will likely be incomplete.  Rather, this whitepaper will explore how the use of broad concepts will allow the creation and modification of laws as necessary, and with greater flexibility with respect to changing technology.

Goals

How should the Internet operate in a world with perfect trespass laws?  How should those laws affect access itself?

First, we want the Internet to be, as it was intended, a place for the free exchange of ideas.  To this end, the Internet (and all related applications) should be easy to use.  Second, and in a perhaps conflicting light, the Internet at large should be a viable commercial marketplace.  To facilitate this, users should feel safe in the exchange of private information.

In light of these goals, what are the ideals for information access itself?  First, there should be a set of access rules and everyone on the Internet should know what they are.  Second, there should be publicly accessible space on the Internet, much as there are public parks and sidewalks in real space.  Third, private space should be allowed on the Internet.  That is, if a computer is connected to the Internet, the owner should be allowed to deem his private files unreadable to the world.  Fourth, privacy on the Internet includes the right to self-determination.  The same computer owner is allowed to determine which parts of his space are private and which are public. Fifth, finally and simply, the rules of access on the Internet should meet and withstand the changing state of technology.

Guiding Concepts

The first thought is to attempt to find an all-inclusive metaphor for cyberspace property and trespass.  Many metaphors are instinctive, as the terminology "trespass" is in itself a metaphor.  However, every real space metaphor has flaws in that it is fixed to real space.  Given the significant failure of any one metaphor, no matter how sophisticated, broader concepts can be used to explain how to view space when there may be no physical manifestation of it.

Property in cyberspace is defined, therefore, using containers, entities, and control. In general, a container is a barrier separating a collection of entities from the Internet and the outside world.  In real space, a container is a house, a file cabinet, or any other physical barrier between certain contained entities and the rest of the world.  An entity is something like a piece of paper or even another container.  Control, in real space, is a simple concept: an owner has ownership documentation and related property law, or is handcuffed to his briefcase to protect it.

In cyberspace, these concepts are much more difficult to define.  A container is something which may not even have an important physical manifestation, such as the protection encryption provides.  These are called virtual containers. An entity, in the same respect, may be a Microsoft Word document or that same document sent over a network.  Control in cyberspace is harder: there isn't necessarily only one briefcase to which someone should be handcuffed.  Overall, however, all entities are in some sort of container, some containers are located within parent containers, and all containers have some inherent permissions.  For example, all email documents are within either the sender mailbox, the recipient mailbox, or in transit, in which case the container is particularly weak.  This provides an excellent basis from which to begin designing an architecture.  Unfortunately, of course, not every trespass falls neatly into this idea, but we hope it to be a coherent overall scheme even if certain special-case adjustments need to be made.

Proposed Architecture

First, what exactly is a container?  We define a container by its properties.  These properties guide us through the discussion of our architecture for access.  Since trespass is the incorrect term as a metaphor, the more appropriate term is "unauthorized access."


Barriers and Points of Entry

A barrier is what stops users from exceeding their authorization of access into a container through the points of entry, but need not be physical barriers.  The points of entry into the container through the barrier are both its physical and network-based openings into the container.  One example of a container is an actual computer.  Some of its barriers are its physical location, as well as the ports on the computer which are open to network connection.

Due to the security inherent in certain encryption algorithms, an encrypted connection to a container would not be considered a point of entry into the container as much as an extension of the container to include the connection.  An unencrypted connection, however, is not only a point of entry into the system but also an unsafe one.  The proposed architecture relies heavily on the use of encryption because encryption is the very thing which enables virtual containers.  An encryption key defines two realms: data encrypted with the key, which can be considered the inside of a container, and data not encrypted with the key, which can be considered the outside. Different types of encryption (public versus secret key encryption) define different permissions, as the next section will show.  In addition, it seems that encryption will become more widespread and less controlled through law as time goes on.   There are many ways of providing secure barriers; encryption frequently provides a good solution, but in other cases the reasonable protection of points of entry through software means is also viable.

In order to encourage the use of the barrier concept, the architecture begins with the following combination of law, social norms, and market pressures.  In social terms, the use of strong encryption for email as well as other online communication is encouraged.  Criminal and civil law protect any point of entry secured by reasonable means, such as encryption containers or a widely-used software daemon.  The same law can specify that damage done through the unsafe entry into a container by an authorized user (such as the public reading of private files due to unencrypted telnet access into the parent container) does not receive protection under the law.  A second law defines that ignorance is not a viable point of defense in this arena.  With the increased use of encryption as outlined above, the market will make freely available many forms of easy-to-use encryption software.

Permissions

What are permissions?  What makes a container public or private or something else?  If a container is physically secured and only the owner can access it, the container is fully secure.  A container is fully public if the entire Internet community can access and modify its contents via any connection to it.

Most containers, it seems, fall somewhere in between fully private and fully public.  The owner will probably define a limited set of users who can modify the entities within the container and a larger set of users who can view them.  At the point of defining the permissions for the container in a traditional sense, the owner will also have the option to define what he wants from each user in order for the user to interact with the container.  Perhaps the owner doesn't want users to send anonymous email into his mailbox or wants only animated graphics but no Java applets accepted into his mailbox.

Law and code can be used to encourage the use of permissions as outlined above.  The code can provide three solutions, described below.  First, encryption can be used to prevent the reading of containers which exist only virtually such as email.  Second, container-controlled prevention of action based on user identification would operate in the same manner that operating system permissions do, for containers in which this is an option.  Third, owner filtering of which operations can be done on which containers can be implemented in code.  A first, important law makes illegal the falsification of information demanded by any of the technical solutions.  This does not suppress anonymous speech, in the case of required identification information, because no container is forced to require identification of its users.

The technical solutions operate as follows.  One or more can be implemented by the owner for any container, to his satisfaction.  First, encryption can be used, as outlined above, in the case when a container itself is not able to conduct negotiations with a user with regard to its permissions.  Second, in the traditional case of operating-system style permissions, some actions can be prevented explicitly by the container itself; such as "Person X does not have permission ever to modify any of the entities in this container."  In the third option, owners can filters all interactions to his container via labels required of the user; any interaction not bearing these necessary labels would be automatically rejected by the container.  One demonstration of the third situation is if a particular mailbox does not accept any spam, for example, while a sender wants to deposit his commercial email.  The owner of the mailbox can reject any email which does not contain a legally-valid return address and legally-binding non-commercial stamp, thus allowing him to receive only non-commercial mail from identified sources.

Ownership

Finally, what does it mean to own a container in the traditional sense, as one owns a house or a car, but without the existence of physical property?  A container is owned by someone if he purchases it or it is given to him.  In most cases, he can sell his container, as well.  An example of such a container is a computer which is wholly owned by one person or organization. It is conceivable that the ownership of some containers may be inalienable, such as a government-issued, digital identification key.

Most containers, however, can be rented, even without cost, to other people.  An example of this is any email service which currently allows users a specific mailbox on their server in which to store email.  The law should provide for renter's rights as much as an apartment renter has rights in that real space case.  Unauthorized access into a renter's container is no more acceptable than into an owner's, and the law should reflect that in a generic sense.  Contract law should assure renters that they are getting the level of security around their containers for which they pay.  Code, as well, should allow renters to protect their rented containers.

Finally, the persons identified as the owners of a container (along with the container renter, if there is one) are responsible for the maintenance of all of the above legal and technical mandates in order rightfully to claim unauthorized access, if such violation occurs.  This includes the careful inclusion of all signaling of privacy in code.  For without an obvious barrier to entry, a user should assume that a container is public in the relevant sense.

Conclusion

Property in cyberspace needs some type of protection from unauthorized access.  However, existing trespass metaphors, on which current legislation and case law are based, are flawed due to their reliance on characteristics unique to  real space.  Instead, the concept of containers can separate us from this problem.  The architecture proposed in this whitepaper, based on these more flexible concepts, more effectively addresses the changing issues of unauthorized access.

References

[Charney, Alexander 1996] Charney, Scott and Alexander, Kent, Computer Crime, EMORY LAW JOURNAL, Summer 1996.

[1] One reasonable example of this is American Computer Trust Leasing v. Jack Farrell Implement Co. (D. Minn 1991).

[2] 18 U.S.C. Section 1030.  See also Rasch, Mark,  Computer security: Legal Lessons in the Computer Age,SECURITY MANAGEMENT. April 1996.

[3] United States v. Robert Morris, Jr. 928 F. 2d 504 (2d. Cir. 1991) caused Congress to modify the text of the Computer Fraud and Abuse Act to cover penetration of not only a user, but also code written by his hand, into the definition of trespass.

Team

Benjamin Adida <ben@mit.edu>
Enoch Chang <echang@law.harvard.edu>
Lauren Fletcher <fletch@mit.edu>
Michelle Hong <mhong@law.harvard.edu>
Kristina Page <kpage@law.harvard.edu>
Lydia Sandon <lsandon@mit.edu>

Benjamin Adida, Presenter.
Lydia Sandon, Author.