RFC 3751

Omniscience Protocol Requirements

๐Ÿ“… published April 2004, from ietf

RFC 3751: Omniscience Protocol Requirements ๐Ÿ”ฎ

okay bestie, this one is RFC 3751, called Omniscience Protocol Requirements ๐Ÿ’…. S. Bradner from Harvard U. wrote it for the Network Working Group, it's in the Informational category, and it's dated 1 April 2004 ๐Ÿ™ˆ (the date is giving joke energy, ngl). There's no Obsoletes or Updates line on this one, so it doesn't replace or change any other RFC. ๐Ÿฆ‹

Status of This Memo

This memo is here to provide information for the Internet community โœจ. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited ๐Ÿ’–.

Copyright (C) The Internet Society (2004). All Rights Reserved. ๐ŸŒธ

Abstract

There have been a bunch of legislative initiatives in the U.S. and elsewhere over the past few years to use the Internet to actively interfere with allegedly illegal activities of Internet users ๐Ÿ‘€. This memo proposes a number of requirements for a new protocol, the Omniscience Protocol, that could be used to enable such efforts. ๐Ÿซ 

1. Introduction โœจ

Okay, so, in a June 17, 2003 U.S. Senate Judiciary Committee hearing called "The Dark Side of a Bright Idea: Could Personal and National Security Risks Compromise the Potential of Peer-to-Peer File-Sharing Networks?," U.S. Senator Orrin Hatch (R-Utah), the chair of the committee, said he was interested in the ability to destroy the computers of people who illegally download copyrighted material ๐Ÿ˜ญ. He said this "may be the only way you can teach somebody about copyrights." "If we can find some way to do this without destroying their machines, we'd be interested in hearing about that," Mr Hatch was quoted as saying during a Senate hearing. He went on to say "If that's the only way, then I'm all for destroying their machines." [Guardian] ๐Ÿ’€

Mr. Hatch was not the first U.S. elected official to float something along this line. A year earlier, representatives Howard Berman (D-Calif.) and Howard Coble (R-N.C.) introduced a bill that would have immunized groups such as the Motion Picture Association of America (MPAA) and the Recording Industry Association of America (RIAA) from all state and federal laws if they disable, block, or otherwise impair a "publicly accessible peer-to-peer file-trading network." Immunized from ALL the laws ๐Ÿ™ƒ

The attitude of some of the copyright holders may be that it's OK for a few honest people to have their computers or networks executed as long as the machines and networks of the dishonest are killed. But it is not likely that any measurable error rate would be acceptable to the public. Clearly, anyone implementing laws of this type needs some way to reduce the error rate and be sure that they are dealing with a real bad guy and not an innocent bystander ๐Ÿง.

Part of determining if someone is a "bad guy" is determining his or her intent ๐Ÿค”. Historically, western jurisprudence has required that prosecutors show that a person intended to commit a crime before that person could be convicted of committing that crime. [Holdsworth, Restatement, Prosser, United States v. Wise, Garratt v. Dailey] Because it can be quite difficult to establish a person's intent, lawmakers have, in some cases, reduced the requirement for prosecutors to establish intent, and mere possession is now proof enough of intent. that's not it, that's not how intent works ๐Ÿ˜ค

This memo proposes a set of requirements for a new protocol to be used by prosecutors to determine a person's intent. The goal is to reduce the need to dilute the historical legal requirement to show intent, and to help groups such as the MPAA and RIAA be sure they are dealing with lawbreakers and not 60 year old non computer users ๐Ÿ‘ต๐Ÿผ๐Ÿ’….

2. Omniscience Protocol Requirements ๐Ÿ”ฎ

For the purpose of these requirements, I will assume that the OP is implemented using a client-server model. The OP client is installed on the user's computer, and the server is installed on a computer run by a law or copyright enforcement organization. OP Clients would register with all OP Servers that pertain to the legal jurisdiction in which the client is located each time the computer is started. OP Servers would then, on whatever schedule they have been configured to use, send OP Queries to OP Clients to find out if the computer operator has engaged in an illegal act of interest to the operator of the OP Server ๐Ÿ‘๏ธ. Future versions of the OP might operate using a peer-to-peer model if the copyright enforcement people can ever get over their visceral disgust at the very concept of peer-to-peer networks ๐Ÿ™„.

For the purpose of this memo, I will use copyright infringement as an example of an illegal act that the OP protocol could be used to expose. The OP has numerous possible applications beyond ferreting out copyright infringement. For example, the OP would be of great assistance to instructors trying to determine if their students are producing original work or engaging in plagiarism. The same function would be invaluable to newspaper editors checking up on reporter's dispatches ๐Ÿ“ฐ.

Also for the purpose of this memo, I assume that an evil-doer (also referred to as a miscreant) is in full control of a computer, and that OP Servers will generally be operated by "Good guys." (See Functional Requirements FR5-7 for requirements to ensure that the latter is the case.) In the context of this memo, "evil-doer" and "miscreant" are defined as individuals or groups of individuals who perform acts that the operator of an OP Server has a legally recognized right to prevent. In the context of this memo, "good guys" refers to individuals or groups of individuals who have a legally recognized right to prevent certain acts that computer users may attempt to do with their computers. The use of this term is not meant to convey any value judgment of the morality, forward thinking nature, public spiritedness, or the monetary worth relative to most of humanity of such individuals or groups of individuals ๐Ÿ’…๐Ÿป.

2.1. Operational Requirements ๐Ÿ› ๏ธ

OR1: The OP client must be able to install itself into all types of computers over the objections of the computer user.

Discussion: The OP client would be installed by legal mandate in all new computers, but since there are hundreds of millions of existing computers, the OP client must be able to install itself in all of these existing computers in order to afford universal coverage of all possible miscreants. This installation must be accomplished even if the user, many of whom have full administrative control over their computers, tries to prevent it. not the consent vibes ๐Ÿšฉ

OR2: True OP clients must not be findable by the computer user by any means, including commercial virus detectors, but all hackers' programs that mimic OP clients must be easily findable by commercial virus detectors.

Discussion: Since anyone whose intent was to violate the law would not want the OP client to be watching their action, they would try to disable the OP client. Thus the OP Client, once installed, should be invisible to all methods a user might employ to discover it. Users must be able to find and remove any virus or worm that tries to masquerade as an OP client to escape detection. ๐Ÿ•ต๏ธโ€โ™€๏ธ

OR3: The OP must be able to communicate through uncooperative firewalls, NATs, and when the computer is disconnected from the Internet.

Discussion: Since the evil-doer may have control of a local firewall or NAT, the OP must be able to communicate with the OP server, even when the firewall or NAT has been configured to block all unused ports. Also, since the evil-doer might try to hide his or her evil-doing by disconnecting the computer from the network, the OP must be able to continue to communicate, even under these circumstances. Meeting this requirement may require that the OP client be able to reconfigure the user's machine into a cell phone or to implement GMPLS-WH [GMPLS-WH]. ๐Ÿ“ฑ๐Ÿ’€

OR4: Neither the operation of the OP client or the OP server must be able to be spoofed.

Discussion: The user must not be able to create their own version of an OP client that can fool the OP server. Nor can it be possible for someone to create their own OP server that can be used to query OP clients.

Discussion: Because of the potential for a user to hide their illicit activities by mimicking the operation of the OP client on their machine, it must not be possible to do so. In the same vein, because of the potential for violating the user's privacy, it must not be possible for a non-authorized OP server to be seen as authorized by OP clients. Since there will be an arbitrary, and changing, number of OP servers, at least one for each type of protected material, OP authentication and authorization must be able to be accomplished with no prior knowledge of a particular OP server by the OP client. ๐Ÿ”

OR5: The OP client must be able to be installed on any portable device that can be used to play protected material or execute protected software.

Discussion: Since small, portable devices, such as MP3 players, are becoming the preferred method of playing back prerecorded music and videos, they must all include OP clients. OP clients must be able to be automatically installed on all such existing devices. ๐ŸŽง๐ŸŽ€


2.2. Functional Requirements โœจ

okay bestie, this is where the OP gets its whole personality ๐Ÿ’… the functional requirements are basically the OP's wish list, and it's a lot ๐Ÿ˜ญ

FR1: The OP client must be able to determine the user's intent. ๐Ÿ”

Okay so, just knowing that someone has a copy of a protected work on their system doesn't automatically make it illegal ๐Ÿ™…โ€โ™€๏ธ it could totally be a copy they bought, like, legit. The OP must be able to tell if a copy is an illegal copy with complete reliability. It must be able to tell an original, legal copy apart from a bit-for-bit illegal reproduction. The OP client must be able to tell the difference between copies made for backup, which are generally legal, and copies made for illegal distribution. For some kinds of software, the OP client must be able to figure out what the user intends to do with it ๐Ÿค”

This matters for the DMCA (the U.S. Digital Millennium Copyright Act) and similar laws around the world. Those laws mostly outlaw having circumvention technology, like crypto analysis software ๐Ÿšซ There's an exemption for legit researchers, but without an OP it's super hard to tell if someone wants that tool for research or to break copyright protections and make illegal copies. With the OP, the DMCA and laws like it could be rewritten so circumvention technology is legal, and developers can find out if their security protocols are any good. Which, right now, might be illegal ๐Ÿ’€

FR2: The OP client must be able to remotely differentiate between illegal material and other material with the same file name. ๐Ÿ“

A user might make a file with the same name as a protected work. The OP must not be fooled into thinking the user's file is the protected one. Not on my watch ๐Ÿ™…โ€โ™€๏ธ

FR3: The OP client must be able to find illegal copies, even if the filename has been changed. ๐Ÿ•ต๏ธโ€โ™€๏ธ

The user must not be able to disguise a protected work by just changing its name. Nice try ๐Ÿ˜Œ

FR4: The OP client must be able to find illegal copies, even if the user has modified the work in some way. ๐Ÿงฉ

The user must not be able to disguise a protected work by modifying it, like by prepending, appending, or inserting extra material, or by changing some of the protected work. The OP must be able to make a legal determination that a modified work is no longer legally the same as the original if the amount and type of modification exceed a subjective threshold. Yes, "subjective" is doing a lot of work in that sentence ๐Ÿ™ƒ

FR5: The OP client must not be able to be run by a hacker, and the OP interface into a user's computer must not be able to be exploited by a hacker. ๐Ÿ›ก๏ธ

OP clients are going to be seriously attractive targets for hackers, because they'll have full access inside a user's computer ๐Ÿ‘€ The interface between the OP client and server must be secure against all possible hacking attacks. All of them. Every single one. ๐Ÿ˜ฐ

FR6: The OP client must be able to discern the motives of the operator of the OP server and not run if those motives are not pure. ๐Ÿ˜‡

It can't be assumed that the OP server operators will always have the best motives, so the OP client must be able to reject requests from the OP server if the server's operator has an evil (or illegal) intent. For example, the OP client must block any operation that might stem from a vendetta the OP server operator might have against the user. Iconic behavior from the client, honestly ๐Ÿ‘‘

FR7: The OP client must not be able to be used to extract information from a user's computer that is unrelated to illegal copies. ๐Ÿ”’

To keep the user's privacy safe, the OP client must not be able to pull information from the user's computer that isn't germane to figuring out whether the user has illegal copies of works or plans to use protected works in illegal ways. Privacy is giving main character energy ๐Ÿซถ

FR8: The OP client must be able to differentiate between protected material that was placed on the user's computer by the user and any material placed by others. ๐ŸŽ€

It must not be possible for a third party to put protected material on a user's computer to incriminate the user. The OP client must be able to know, with certainty, who placed material on each computer. That includes cases where a third party has physical access to an unprotected computer, or where the third party knows the user's logname and password. Not a single loophole, bestie ๐Ÿ™…โ€โ™€๏ธ

FR9: The OP client must only implement the laws that apply to the specific computer that it is running on. ๐ŸŒ

The Internet crosses tons of legal boundaries, so an OP client has to know exactly where, in geopolitical space, the computer it's running on is located. Otherwise it can't know which laws to apply when it scans the user's computer ๐Ÿ—บ๏ธ The OP client must also be able to be automatically updated if the laws change, or if the computer is moved somewhere the laws are different. This requirement also means the OP client has to know where its OP server is located, so it can tell whether the client and server are in the same legal jurisdiction. The OP client must know what to do, or not do, when they aren't in the same jurisdiction. Finally, the OP client must include a mechanism to automatically retrieve any applicable new laws or court decisions and properly interpret them. Ngl, that's a lot of homework for one little client ๐Ÿ“š


3. Security Considerations ๐Ÿ”

Okay, this part is seriously intense ๐Ÿ˜ญ The OP requires strong authentication of clients and servers so they can't be spoofed. It also requires strong integrity technology so messages between client and server can't be modified in flight. It also requires strong encryption so nobody can observe the communication between client and server. All of this is required in an environment where many users are in full control of their computers and will be actively hostile to the reliable operation of the protocol. Good luck ๐Ÿซ ๐Ÿ’€


4. Informative References ๐Ÿ“š

Here's the reading list, lowkey a whole vibe ๐Ÿงš

  • [Garratt v. Dailey] Supreme Court of Washington, 6 Wash. 2d 197; 279 P.2d 1091 (1955)
  • [GMPLS-WH] Generalized Multi-Protocol Label Switching (GMPLS) for Worm Holes, work to be in process
  • [Guardian] "Senator proposes destruction of file-swapping computers." The Guardian, June 19, 2003. (http://www.guardian.co.uk/usa/story/0,12271,980890,00.html)
  • [Holdsworth] Holdsworth, W., History of English Law 680-683 (1938)
  • [Processer] Prosser, W., et al., "Prosser and Keeton on Torts," Hornbook Series, 5th ed., 1984
  • [Restatement] 1. Restatement of the Law: sec 13 Torts (American Law Institute) (1934)
  • [United States v. Wise] 550 F.2d 1180, 1194 (9th Cir.)

5. Authors Address ๐Ÿ’Œ

Scott Bradner Harvard University 29 Oxford St. Cambridge MA, 02138

EMail: sob@harvard.edu Phone: +1 617 495 3864


Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ๐Ÿฆ‹

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement ๐ŸŒธ

Funding for the RFC Editor function is currently provided by the Internet Society. ๐Ÿซถ

๐Ÿ“ฆ where this page comes from