Ideally, the solution to the problem of securing intellectual property over the World Wide Web will use those standards and procedures of the web. To achieve integration with existing web technology, the process by which developers may secure their content and information should offer a virtually effortless alternative to the aforementioned techniques.
The development of security for intellectual property on the World Wide Web should account for existing technologies and standards. The procedure for securing intellectual property over the web will integrate the current standards for PICS with Netscape's Secure Sockets Layer. Of key importance in the procedure, digital certificates offer the means for the secure transmission of intellectual property from server to client.
Originally designed to provide parents and teachers control over the content children access over the Internet, the World Wide Web Consortium's Platform for Internet Content Selection (PICS) is a method by which developers may associate labels with content (W3C, PICS 1). The Recreational Software Advisory Council (RSAC) suggests PICS as a means for content developers to rate their own web sites with regard to sex, nudity, violence and offensive language. In utilizing PICS, RSAC aims "to provide a simple, yet effective rating system for web sites which both protected children and protected the rights of free speech of everyone who publishes on the World Wide Web" (RSAC 1). RSAC indicates, as well, that current client software such as Microsoft Internet Explorer already provides the means to filter content using the PICS labels.
While initially used for filtering, the labels of PICS may also provide the ability for other facilities to apply their own functionality. Because of the flexibility inherent in the PICS label format, developers can associate such labels with copyright and usage information. Such information, while offering the means by which content developers can protect the products they create, client software--web browsers, search engines, proxy servers and agents--can benefit from the increased instruction over what to do with particular information.
The primary difficulty in the implementation of PICS security of web-based content is the lack of support in current browsers. Using any current user agent, from direct socket access to the latest versions of Netscape Navigator or Microsoft Internet Explorer, a party may obtain via Hypertext Transfer Protocol, or HTTP, the full source of a given document and subsequently do anything with the content. A proper method for the dissemination of rights information should integrate the identity information of PICS rights labels with the associated content, in order to secure both distribution information and content.
In its simplest case, HyperText Transfer Protocol, or HTTP, is a request/response protocol (Berners-Lee 1) by which a client may contact a server in request for information. Because HTTP simply passes information along a communication path that may contain any number of intermediaries, the request/response communication does not provide the capacity for securely transmitting sensitive content. To secure the dissemination of rights-encoded content, therefore, the method of distribution should avoid use of HTTP.
A protocol that "provides communication privacy over the Internet" (Netscape 1), the Secure Sockets Layer (SSL) offers the opportunity to transmit intellectual property rights information securely. SSL consists of two separate layers--the SSL Record Protocol and the SSL Handshake Protocol. The SSL Record Protocol is used to encapsulate higher level protocols. The SSL Handshake Protocol provides the means for server and client to negotiate the details of communication with one another prior to actual content transmission.
The most important element of SSL security in light of intellectual property rights encoding, however, the Handshake Protocol also allows both client and server to authenticate the other. According to Simson Garfinkel and Gene Spafford, authors of Web Security and Commerce, SSL "allows for connections that are not encrypted but are authenticated and protected against deliberate tampering by a sophisticated attacker" (Garfinkel 235). Within this context, this capability offers servers the means to determine a given client or user agent's ability to process the PICS label.
Digital certificates present the method by which two parties may authenticate one another for communication. "Perhaps the widest used security protocol on the Internet today" (Gerck 1), SSL utilizes digital certificates to provide authentication of the parties in a transaction. The X.509 ITU-T Recommendation (RFC1422 1), the definition of digital certificates for use with SSL, describes the architecture for authentication services under a central authority as well as the data required for remote certification between two parties.
X.509 Digital Certificates, as envisioned in Netscape's SSL implementation, provide the security for transactions over the World Wide Web. A given user, armed with an SSL-capable web client, may provide sensitive or critical information, such as personal information or credit card numbers, to a web site without fear of theft. When utilized in the SSL implementation, certificates provide the authentication of a given server by client or authentication of a client by server. While client authentication is primarily utilized on a user-by-user basis, the application of this facility to the authentication of client software, then, offers a means to the securing of intellectual property.
To achieve intellectual property security, protocols can utilize all elements, from PICS to SSL, in transmitting content from server to user agent. For secure transmission, however, the protocols must integrate these elements to avoid misappropriation or tampering.
The primary concern in securing content over the World Wide Web would be the HTML file, the most used format for Web-based documents. To augment the HTML file, Andrew Daviel proposes the encoding of rights details into the HTTP document header. Daviel suggests the following encoding for the actions a given user can take with a document. Printing entails the generation of a hard copy of a document, or the generation of a printer-ready version. Saving, on the other hand, refers to the retrieval of the source document to non-volatile media. Quoting, finally, indicates the inclusion of a portion of the source document in a new document. In considering the associated numeric levels, Daviel suggests that for a given action, a "0" refers to no rights to the client, a "1" offers a conditional allowance of right, and "2" reports unconditional acceptance for client actions. In addition, Daviel suggests that a document can offer a URL for further information regarding the intellectual property status of protected documents.
Joseph M. Reagle of the World Wide Web Consortium suggests that developers should encode such information through PICS. One obvious benefit of utilizing PICS for copyright information and control is its wide application in other domains. For increased security, the PICS format allows for the inclusion of digital signatures, and the PICS system provides the opportunity for multiple documents to be protected with a single label set. Such functionality, while envisioned for HTML documents, can provide copyright status and control information for other "web referenceable [sic] resource including audio and visual content" (Reagle 1).
Utilizing the META tag located in the HTML HEAD section, content developers could stipulate control over printing, saving and quoting. Following Daviel and Reagle's suggestions for encoding rights information, web authors could code document rights information as seen in Figure 3-1. As noted previously, a web author could provide further information about the rights of a given document through the URL labeled "full," http://www.domain.com/IP-notice.html.
| |
| Figure 3-2. Linking a Rights Sheet to an HTML Document |
Alternately to Reagle and Daviel's suggestions, this research proposes that such information could be contained within separate files--web developers could link their various documents to these rights files in a manner similar to the application of Cascading Style Sheets to HTML. According to the World Wide Web Consortium's HTML 4.0 Recommendation, authors and web developers may use "style sheets across a number of documents (and sites)" and "change the style sheet without requiring modifications to the document" (W3C, Style 1). The Web Design Group suggests that "an external style sheet is ideal when the style is applied to numerous pages . . . As well, most browsers will cache an external style sheet, thus avoiding a delay in page presentation once the style sheet is cached" (Pozadzides 1). As such, web developers could achieve the same advantages with copyright information in referencing such information in a manner similar to the linking of external style sheets.
| |
| Figure 3-2. Linking a Rights Sheet to an HTML Document |
To link an HTML document to external copyright information, authors and developers could use the following proposed HTML. The section of HTML code offered in Figure 3-2, analogous to linking style sheets to the document, provides a linking method that offers the aforementioned benefits. The ability to apply and change property rights information for a large number of documents allows content developers a high degree of control over those documents as well as the possible elimination of excess bandwidth usage for identical rights data through document caching.
When considering the transmission of pages with intellectual property rights, user agents must offer the means to handle such data with accuracy. To achieve this goal, user agents would require various modifications. The primary modification that would be required of most user agents would be the addition of PICS functionality. While Microsoft Internet Explorer has such a facility, the software's current ability to process PICS labels is limited to RSAC ratings. To apply intellectual property rights information with little concern for security, all browsers--both Netscape and Microsoft offerings, as well as many other browsers--should provide the means for understanding and processing PICS-encoded rights labels. Appropriately, should such labels be encoded in stylesheet-like documents, the user agents should properly process the additional request for the separate rights information.
Once a given user agent can understand the details of the rights labels, it should correctly associate the rights levels with appropriate levels of functionality. As such, when restricted from quoting content, the browser should eliminate the user's ability to select and copy arbitrary objects on the page--specifically text. Many browsers, for example, include a menu for quoting functions: Cut, Copy, and Paste. To comply with the intellectual property restriction, a given browser should disable the facilities for selection, cut, and copy of text. With print-restricted content, user agents should disable printing functions. For many graphical user interfaces, such functions could be disabled on the appropriate menus.
Likewise, when receiving save-restricted content, the browser should restrict the ability of the browser to save a page or its contents. More importantly, however, when modifying the user agent to provide intellectual property functionality, browser developers should scrutinize the method by which the browser caches the page to speed up the user interface. Specifically, when browsing files over the World Wide Web, should a user agent cache pages on disk or in memory? The provision for caching allows quicker reloading over a single session--to ensure security, the user agent should delete the content following the browsing session. Would eliminating the cache for rights-encoded pages be a viable option?
While caching information may provide some benefits to speed and bandwidth, sophisticated attackers may utilize the temporary cache information to misappropriate protected content. Such attackers could misappropriate information through the capture of the memory image of transmitted data, as well. Developers could use the possible solution of caching encrypted copies of secured data--a measure that may introduce a large degree of slowdown to page loading and rendering. To protect information from nefarious parties, users may need to sacrifice the speed browsing for data security.
Of all client modifications, the addition of a digital certificate is of primary importance. This digital certificate, identical for all copies of the software, establishes the identity of the user agent requesting data, and allows servers transmitting rights-encoded documents to authenticate the user agent. Through such authentication, the server knows that the receiving software will understand and will abide by the details of the rights encoded onto the document.
In conjunction with the digital certificate, another important modification required of current user agents for proper handling of intellectual property rights is a modified SSL functionality. In accordance with the SSL v3 specification, the transmission of protected pages would entail transmission following negotiation between user agent and server. This negotiation, known as the SSL Handshake Protocol, consists of a ten-step exchange as follows (optional items are indicated in [brackets]):
As mentioned previously, connections between client and server can be authenticated without encryption. To recognize that a given user agent has rights-aware capabilities, the server must authenticate the client. Unlike most SSL applications, however, the aspect of the client the server must authenticate is the client agent. Specific user agent certificates offer the means by which those user agents could validate their own rights-aware functionality to servers. Because the user agent certificates are applied to all copies of the given browser, however, the transmission of the certificate should be encrypted to prevent a misappropriation of the identity of the browser.
In utilizing an additional digital certificate for user agent verification, the protocol would appear as follows:
For the security of content, the steps 10 through 13 are not optional--this exchange is required for the maintenance of the intellectual property rights. Steps 1 through 9 are virtually identical to the messages exchanged in the original SSL Handshake. Unlike step 9 in the original SSL Handshake, however, the exchange of ChangeCipherSpec messages in this handshake requires the exchange of a valid encryption method.
The UserAgentStart messages are identical in structure to the Finished messages--messages that verify that both client and server are properly synchronized for secure exchange of information. Should the message exchange fail to provide a valid agreement, the link between client and server should be severed. If client and server properly synchronize, however, the UserAgentCertificateRequest is transmitted to the client. Following the encrypted transmission of the user agent certificate to the server, the client and server can optionally change the details of encryption again. With a second exchange of ChangeCipherSpec messages, for example, client and server can opt to forego encryption for subsequent transmissions.
Following the exchange of the SSL Finished messages, the server and client can transport the rights-enabled content. While most SSL transmitted content is commonly encrypted, the protocol does not require encryption--only the proper authentication of user agent. Such authentication should attest to the user agent's ability to process the rights-enabled content.