1. Introduction

Peer-to-peer content sharing networks (e.g. [OpenNap,Clip2,Cl+00,Bay+02]) have traditionally focused on facilitating the sharing of static content and files. In this paper, we propose and describe a peer-to-peer (p2p) network that facilitates sharing of dynamic content generators, web services, and web applications in addition to static content. In contrast to existing web application development infrastructures, services published on our network are made available for other users to download and install. Much as popular files propagate across file sharing networks, the most useful services can propagate to many machines. This allows the multiple instances of a specific service to harness distributed resources and content that would not be available if the service were deployed in the traditional standalone fashion.

This work is implemented as an extension to the YouServ p2p web hosting system [Bay+02], which is currently deployed within the IBM intranet where it is in active use by almost 1500 unique users out of 5000 total. YouServ endows each peer with an easy to use webserver supporting basic HTTP commands for serving designated files. Atop this basic HTTP server engine, YouServ provides features that make webserving useful to a much wider community (ordinary web users) by (1) reducing site-availability problems due to limited machine uptime, (2) providing built-in dynamic DNS function that works with DHCP (3) working from behind firewalls or other impediments to inbound connections, and (4) offering an integrated single-signon authentication scheme for simplified and uniform access control across peers. (Recent extensions to the system additionally offer p2p content search [Baw+02] and immediate HTTPS/SSL support by way of an integrated certificate authority, providing strong security properties.)

This paper proposes an architecture that keeps with the philosophy of bringing web hosting to the masses by simplifying the creation of sites with dynamic content. In the past, setting up a webserver and website with dynamic content capabilities was a task for the skilled web developer. In addition, because code for dynamic websites is typically tailored for the specific system it is deployed on, rarely if ever does such code offer novel p2p functions by cooperating across a network of webserving peers.

Our architecture allows anyone to write modules (in Java) that intercept and respond to specific HTTP requests. Viewed as such, these plugins are on the surface quite similar to webserver scripts (JSP, ASP, CGI, PHP), and also bear a resemblance to SOAP web services. There are, however, several notable differences, including the following:

• Plugins are all in one, site-independent applications that require only simple web-based configuration (if any) in order to work on any YouServ installation. In contrast, almost all web applications built with, say, JSP or CGI, involve complex dependencies and configuration that can only be navigated by knowledgable web administrators.
• Plugins installed on one YouServ site are, by default, available for download and installation by other users. As such, instances of a popular plugin will propagate across the network, and can even cooperate to provide new p2p applications.
• Security (by way of digital signatures and sandboxing) is a first class function, since plugins are intended to be installed and run across multiple sites without the users being expected to understand the details of the code or even trust the site from which the plugin was obtained.
• Plugins have access to application state useful for developing end-user oriented, p2p web applications. This state includes the specific files being shared and their URLs, the installing site's domain and owner, identity information of the requestor, the site's default page template, and user group membership information.

In this paper, we describe the design of the YouServ plugin architecture and its implementation challenges, which include providing a simple yet sufficiently powerful API that encourages end users to develop interesting applications, ensuring security through sandboxing and/or signatures and reputations, and creating a web-based enviroment that allows simple installation, administration, and sharing of plugins using ordinary web browsers. We also provide a classification system for plugins, and describe specific application instances we anticipate would be immediately useful to the community.

2. Related Work

There are quite a few technologies already available for creating dynamic web content. Common Gateway Interface (CGI) [G96] is one of the standards for interfacing external applications with web servers. CGI scripts can be written in any of several languages and are supported by almost all major web servers implementations. Another construct for dynamic content is Server Side Includes (SSI) ([G96, chapter 5]), which are runtime-evaluated directives that can be included into HTML pages.

Newer schemes for dynamic site content provide closer integration with specific development environments and programming languages. For example, Active Server Pages (ASP) [A+99] integrate seamlessly with Microsoft technologies such as COM and DCOM objects. PHP: Hypertext preprocessor (PHP) [PHP] is another server-side scripting language that is easy to learn and offers wide database connectivity. A large collection of open source PHP code is also available for free. Java Server Pages (JSP) and servlets are the Java solution to dynamic content generation. They rely on the power of Java to be platform-independent and extensible.

The goal of the architecture described in this paper is not to develop yet another web scripting language. In fact, we expect to offer existing scripting methods such as JSP as components of our architecture. The focus of our work is instead on features that support p2p distribution, execution, and interaction of web scripts. That is, web scripts on one site should be able to be downloaded and used by another with little or no difficulty, and with confidence that the script will not damage the host machine. Further, these features should be available to users of ordinary skill.

In this regard, the closest related work of which we are aware is the Zope application server's facility for packaging web applications into what are known as products [L02, PL01]. Zope products facilitate the deployment of web applications to other Zope installations. Zope products, however, are still server-centric in that there is no support for p2p distribution, and once installed, they are not intended to cooperate across installations. Additionally, products offer no facilities to deal with the potential of malicious code that could be embedded within them.

There are several systems facilitating content sharing and distribution in a p2p environment [OpenNap,Clip2,Cl+00,Bay+02,BadBlue]. Of these, only BadBlue allows dynamic content content generation through its support of PHP. But as with Zope products, there are no facilities to support p2p distribution and interaction of deployed scripts.

The GRID [Globus] has some related goals to those of our plugin infrastructure. GRID, however, is aimed primarly at supporting distributed execution of compute-intenstive, server-side tasks, as opposed to the sharing and secure distribution of their code. Web services [CH+02] provide an infrastructure for uniformly invoking and querying server-side functions and applications across a heterogenous network. Like GRID, the focus of the architecture is on back-end infrastructure and integration instead of end-user sharing and propagation of useful web applications. We believe the web services infrastructure is complementary to our architecture, the idea being that plugins could expose themselves as web services for supporting interactions between peers.

3. A User-Oriented View

This section overviews the system from the perspective of a non-technical user who might want to use the features provided by plugins on some site, or enhance his or her own site with existing plugin-supported functionality. It gives a "user level" look at the system as currently deployed within the IBM intranet. A technical look at the system appears in the following sections.

3.1 Using Plugins

Users who wish to use some existing plugin need only visit what is called the plugin manager (Fig. 3.1) on any YouServ site running the plugin. Through the plugin manager, the site visitor can click any plugin name to invoke the home page of that plugin. Plugin writers are encouraged to create home pages with sufficient help links to enable users to easily navigate and exploit their functions. Since plugins are invoked through standard HTTP GET and POST requests, plugins can also be invoked through links and forms included within other pages available on the web.

The sign in link at the top of the plugin manager page is a standard feature of many YouServ pages. It simply indicates the user is not authenticated, and may not be able to access certain links without revealing his or her identity. For example, once the site owner is signed in (Fig. 3.2), additional configuration options are provided.

We expect that ultimately, most plugins will be located by users primarily by serendipity and word of mouth. We do, however, offer an authoritative location offering a collection of plugins along with documentation. YouServ also offers a p2p search function which can also be used to locate plugins.

3.2 Installing Plugins

Any plugin enabled by the site owner is by default available for (anonymous) download through the indicated plugin manager links. This behavior can be prohibited by the site owner to, for example, protect proprietary or otherwise sensitive code. A user who wishes to install a plugin on his/her own site can simply click the download link to obtain the plugin. The browser in response prompts the user to save the plugin, which should then be placed by the user in YouServ's plugin folder. While not implemented, we could associate the YouServ process with the plugin MIME type for proper handling of downloaded plugin. Implemented as such, the system as opposed to the user would copy the plugin to the proper plugin folder for a single-click install.

Once a plugin is installed within the plugin directory, the plugin manager displays the plugin name but does not enable it. Before the plugin's code can be invoked or its code downloaded off the site by others, the site owner must explicitly enable the plugin by clicking on the link provided within the Enable column. This gives the site-owner a chance to prohibit downloads or reconsider the plugin's installation based on the available digital signatures (we elaborate more on digital signatures in the following Security section).

In addition to a home page, plugin writers are encouraged to provide a primary configuration page which allows users to easily customize the plugin's behavior. This page is reachable through the "Configure" link provided alongside the plugin name within the site-owner's view of the plugin manager.

3.3 Example Plugins

The example plugins we have thus far made available were developed by our team primarily for the purpose of demonstrating the various API features in order to encourage development of novel functions by other technical members of the YouServ community. At the time of this writing, the plugin architecture has been deployed to the IBM YouServ community for only one week. To date, over 60 users have downloaded the plugin developers kit.

The MP3PlayList plugin is one such "proof of concept". It assembles URLs to all music (MP3) files shared on the site, and provides a convenient interface for generating tailored playlists (.m3u files) from them. Playlists, when served by a website, cause the browser to launch the default music player to stream the music listed within the playlist. Thus, by visiting the MP3PlayList home page (Fig. 3.3) and clicking the submit button, a user can quickly sample the music available on the site. Keywords can optionally be specified to customize the musical selection.

The configuration page of the MP3PlayList plugin is displayed in Fig. 3.4. Configuration pages are accessible only to the authenticated site owner. This plugin allows configuration of specific web-accessible folders that are to be mined for audio files. The page also allows designating who can access the (non-configuration) plugin pages by username and/or user group.

Another basic but useful plugin is the SimpleContentEditor, which allows the site owner to (remotely) edit site content using any web browser (Fig. 3.5). One could envision enhancing this plugin to offer additional Wiki-like [LC01] site-editing features.

3.4 Cooperative Plugins and Examples

Plugins such as MP3PlayList and the SimpleContentEditor are standalone in that their instances operate completely independently. Cooperative plugins are a much more interesting class which enable meta P2P applications. As an example, one could envision extending the MP3PlayList plugin so that its multiple instances cooperate to aggregate a global database of URLs, allowing the playlist generation function to assemble playlists of songs that span multiple (high bandwidth) sites.

A plugin that supports general p2p search over YouServ content would also be cooperative. For example, it would be relatively easy to take an open-source Gnutella client and repackage it as a YouServ plugin that makes the public YouServ content searchable on the Gnutella network. We had in fact intended to implement YouServ's p2p search function, YouSearch [Baw+02], as the first cooperative plugin example, but its development began before the plugin infrastructure was sufficiently mature.

Another example of a cooperative plugin would be one providing distributed content caching to allow low-bandwidth sites to increase their effective bandwidth. This would be similar to how today's heavily accessed sites contract with a service such as Akamai [Akamai], only without the expense. A site installing such a plugin would perform demand-based caching and redirecting for other YouServ sites, forming a dynamic content caching network coordinated by some central server and domain name system.

More concretely, to exploit the service, a (bandwidth-limited) site mysite.userv.ibm.com with a large but popular image myfile.jpg could increase the effective bandwidth available for serving that file by linking to it as follows:

http://cache.userv.ibm.com/_plugin_/CachePlugin/mysite.userv.ibm.com/myfile.jpg

The domain name cache.userv.ibm.com would point to the IP addresses of all high-bandwidth sites running the content-caching plugin so that requests for cached content are uniformly distributed across all participating machines via round robin DNS resolution.

When a YouServ site receives such a request, it is delegated to the CachePlugin, which extracts the source site name and the filename from the URL. The plugin then serves the requested file if it is located in its cache. Otherwise, the plugin could locate another YouServ site that is caching the file and issue a redirect. As a last resort, it could download it from the source, relay it to the requestor, and cache it locally for quickly satisfying future requests.

A final example of a cooperative plugin would be a web-logging ("blog") plugin that allows site owners to create and maintain web logs, with support of text search and cross-linking across other sites running the plugin. Such a plugin could provide the functionality of web log sites such as Radio Userland [Radio], but without the limitations (e.g. space quotas) and the extensive and costly centralized resources.

4. Security

Plugins, like other applications installed by a user, involve running code that has the potential of causing damage. Plugins in our implementation currently have the full power of the Java virtual machine at their disposal, thus malicious plugins could wreak havoc on the host machine by deleting files, installing back doors, and so on. This section overviews the features implemented to minimize risks due to malicious plugins: digital signatures and code sandboxing.

4.1 Digital Signatures

Recall that our architecture allows plugins to be downloaded from any of a number of participating sites that are not necessarily trusted by the downloader. This feature, key to successful propagation of the most useful applications, also raises the possibility of malicious plugins being offered for download, or reputable plugins being tampered with before distribution. To eliminate this possibility, YouServ supports plugin signing and verification. Typically code will be signed by the creator, but users who dissect the plugin implementations could also sign the plugin as an endorsement of the code.

When a plugin is first detected by YouServ, its signatures are verified, and those signatures corresponding to unrevoked, YouServ-issued certificates are displayed by the plugin manager alongside the plugin's name. Recall that before the plugin is loaded into memory and its code ever invoked by the system, the site owner must explicitly enable the plugin by clicking on the appropriate link in the plugin manager. YouServ warns the user before activating a plugin to ensure it is signed by a reputable user or was obtained directly from a trusted source.

Every YouServ installation is automatically assigned an X.509 security certificate by the YouServ certificate authority. The original purpose of the YouServ certificate authority was to provide each site with immediate support of HTTPS/SSL for secure site access. The plugin architecture reuses this certificate for the purpose of plugin signing and verification.

Plugins in YouServ are packaged in the Java JAR format. YouServ leverages the Java functions that allow JAR files to be signed by any number of X.509 certificates. While signing a JAR file can be a complex and intimidating process, the YouServ installation includes a utility program that allows an authenticated YouServ user to sign aribtrary JAR files with their YouServ certificate in a single step.

4.2 Sandboxing

Another security technique that is complementary to digital signatures is code sandboxing. Sandboxing permits specified code (such as an untrusted plugin) to use only a limited set of operations to prevent or limit any damage should the code turn out to be malicious.

We are in the process of implementing the YouServ plugin sandbox by leveraging the Java 2 sandbox features. The current plugin sandbox design involves multiple permissions that (untrusted) plugins can be granted by the user with reasonably easy to understand consequences. We detail these permissions here, beginning with the most restrictive policies and ending with the privileged (unsandboxed) policy. We motivate and explain the consequences of most permissions through some of the previous example plugins such as the MP3 playlist generator.

Before diving in to details, it is worth noting that a plugin could be coded to work gracefully at a variety of sandbox levels. As such, running a plugin within a highly restrictive sandbox would not necessarily prevent it from working entirely, but might limit some of its features. Users could quickly guage the trade-off between the functionality of and the freedom granted to the plugin.

No special permissions

Without any special permissions, untrusted plugins run within a sandbox that corresponds to the the untrusted applet sandbox used by most web browsers, but with access to a restricted set of PluginAPI methods.

The PluginAPI methods that are made available without any special permissions provide information to the plugin that could be obtained by any user who simply points his browser at the site and navigates the publically accessible links. For example, one such method allows the plugin to obtain a list of URLs to public, non-hidden (by index.html) content available on the site. Others allow access to the site's domain name, the username of the site owner, and even access to the contents of public, non-hidden files on the site.

Risk assessment: The strong security properties of the untrusted applet sandbox has been well-tested due to its wide deployment in most web browsers. At the worst, malicious plugins operating in such a sandbox can consume excessive CPU time.

Example application: The MP3 playlist generator plugin described earlier could be made to run at this sandbox level, albeit at a reduced level of functionality. The plugin would only need to maintain a list of all publically available, non-hidden MP3's on the site via the PluginAPI method described above. No Java methods outside the untrusted applet sandbox are be required, nor are any restricted PluginAPI methods.

User identity permision

Plugins might want to implement access control policies, which would require knowing the identity of any visitor. The user identity permission allows the plugin to request this information, which in YouServ is obtained through a single sign-on authentication scheme.

Risk assessment: Allowing plugins to know who is accessing what is a relatively low risk. A malicious plugin could use the information to compile a list of people who visited the plugin and expose this list to someone who might be interested in monitoring who visits these sites. At worst this seems a relatively minor privacy issue.

Example application: See below.

Cookie permission

Plugins are likely to require persistent state; however, the amount of state required will be small in many cases. A cookie permission is provided that allows plugins to read and write a length-limited state file. This permission is somewhat analagous to granting websites the ability to store cookies in one's browser, hence the designation of this permission as the cookie permission.

Risk assessment: Extrapolating from the fact that browsers allow cookie-enabled websites to write arbitrary data into a length-restricted state file, there appear to be no significant risks associated with such a permission

We would grant user identity and cookie permissions to imported plugins by default, though much as browsers allow users to disable cookies, the default sandboxing level could be user configurable.

Example application: Going back to our MP3 playlist example, the configuration operations that support access restrictions require knowing user identity, and the access and folder configuration information would require storing within a small persistent state file.

Hidden URL access permission

Because of index.html files which "hide" directory listings, some files, while publically accessible to anyone who knows the URL, may not be discoverable through browsing the site. Though it is a poor practice which we do not advocate, a common webserver idiom is to access-restrict content by hiding it in this manner. In some sense, the URL itself serves as a password.

The hidden URL access permission lets a plugin invoke the PluginAPI method for obtaining URLs to hidden (public) content.

Risk assessment: Note that this capability does not give the plugin access to the actual files themselves, only their locations. However, a malicious plugin could expose these URLs to the world by printing them in some output page available for anyone to download. The risk of this permission, then, is exposure of files a user assumed were "secure" because they are hidden behind index.html files.

Example application: Because access to the playlist generator can be restricted to designated users, it's possible that the site owner does not mind potentially exposing hidden URLs of his MP3's to those designated users. By granting the playlist generator the hidden URL access permission, MP3's could be put in a hidden directory and shared without directly exposing their URLs to non-designated users.

Private URL access permission

YouServ allows the site owner to restrict content access in some folders to only designated users (user groups). This permission would allow a plugin to obtain a list of URLs that are accessible to a designated user.

Risk assessment: As with hidden URL access permission, the plugin does not have access to the files themselves. However, a malicious plugin with this permission could expose the URLs of these files to the world. Though these files remain access restricted and hence inaccessible to those without the required permissions, there is some risk in that the names of the files are exposed, and filenames themselves may convey a good deal of information about the contents of those files.

Example application: A site-owner might be interested in generating playlists of copyrighted music that was legitimately purchased by him/her. To avoid copyright infringement, the site-owner would be advised to place any such content within a folder to which only he/she has access. For playlists to be generated over such content, the plugin would require the ability to obtain URLs to those files.

Credentials permission

Some plugins might want to provide URLs of private content to applications other than the web browser. Because YouServ uses primarily (secure) cookie information for determining the identity of the requestor, external applications would not be able to access URLs that point to private content unless the authorization credentials are instead encoded in the URL. The credentials permission allows a plugin to invoke a PluginAPI method that encodes the current user's authenthentication credentials within a given (local site) URL.

Risk assessment: Unlike the previous permissions, this permission can be a moderate to severe security risk. Even though the plugin does not have direct access to any private files, a malicious plugin could still collect the credentials it generates, and publish those credentials to a publically accessible page. Anyone who accesses the secret page could then impersonate those users and access those files. Since credentials would be specifically tied to the URL, this would not allow the user to be impersonated in general, but only in accessing those specific files whose URLs were intercepted.

Ignoring a malicious plugin, an ill-programmed plugin might fail to adequately protect the credentials by not requiring encrypted (HTTPS/SSL) connections. In such a case, credentials risk exposure to network sniffers.

Example application: The previous MP3 playlist generator assumes that the MP3 player is a browser-internal player which can provide appropriate browser cookies for authenticating the user. If instead the browser is configured to launch an external MP3 player such as WinAmp, then the playlist would fail since the external player would not have access to the browser cookies necessary for authenticating the user to YouServ.

By granting the MP3 playlist generator credentials permission, the plugin could have the PluginAPI encode the user's authorization credentials in the MP3 URL parameters. As long as the MP3 URLs within the playlist are HTTPS, and the playlist itself is served over an encrypted connection, these credentials remain secure.

Hidden file read access permission

A plugin might require access to hidden content. The hidden file access permission allows a plugin to obtain not only URLs to that content, but also the data within the files themselves.

Risk assessment: Similar to the hidden file url permission, except slightly more severe since the plugin itself (as opposed to an outside party) is able to expose the contents of the hidden files.

Private file read access permission

A plugin might require access to files within the access restricted zone.

Risk assessment: This could allow a malicious plugin to circumvent the YouServ access controls and expose private content to anyone.

File write access

A plugin might require updating files whose handles were obtained using any of the read access permissions.

Risk assessment: This allows a plugin to change public site content at will, giving a malicious plugin the ability to destroy content, remove index files to expose hidden content, and so on. It would not allow the plugin, however, to modify files other than those that can be fetched through allowed plugin API methods (implying system files would be safe).

Example application: The simple site editor plugin described earlier would require this permission. It would also require hidden and private content access permissions if hidden and private content editing was desired.

(Limited) network permission

A plugin might need to open up connections on the network, for example to contact a coordinating server, or to contact other peers running the same plugin. This permission gives the plugin ability to open up network connections (to designated sites).

Risk assessment: This permission makes it easy for the plugin to disclose any information it might be able to obtain to other servers. It also could allow the plugin to perform denial of service attacks, saturate the network connection, and so on.

Example application: A plugin implementing the Gnutella p2p search protocol, which requires connections be opened to arbitrary other machines, would require unrestricted network access permission.

Privileged permission

A plugin might need to perform complex file operations or other operations not permitted by the standard Java applet sandbox. This permission gives a plugin full access to the Java API (including file system I/O, etc).

Risk assessment: Severe. This permission should only be granted to trusted, signed plugins, since this permission would allow the plugin to perform arbitrary operations such as delete files, expose artibrary private files, and so on.

Example application: A plugin may need to maintain a complex database of information, which could require unrestricted access to the file system.

5. Creating a Plugin

YouServ plugins are Java programs and associated resources that are encapsulated in the standard Java JAR package format. While not required, plugin authors are encouraged to include source code along with the object code to faciliate extensions and enhancements by other users.

Along with the standard Java libraries, plugins have access to special APIs that provide access to application state useful for enabling site indepence, application security, and integration with other aspects of YouServ (for example, for maintaining a consistent look and feel). This section describes these APIs, how they are used in plugin implementation, and how they compare to related APIs such as Java's Servlet APIs and the Java JSP architecture.

5.1 The Plugin Interface

The first step in writing a plugin is to create a class that implements the YouServ Plugin interface. Conceptually, this interface is very similar to the Java servlet interface, with methods for initializing the plugin when it is loaded, performing cleanup when unloaded, and handling web requests. The interface differs in a few ways in order to make security a first-class feature and better support site independence.

Consider a plugin with the name "MyPlugin". Once installed, such a plugin will have a webpath (the portion of the URL following the domain name) as follows:

/_plugin_/MyPlugin/

This is called the plugin's root webpath. YouServ delegates requests from any URL whose webpath begins with a plugin's root webpath to the handleRequest() method of that plugin. This is a bit different than a Java servlet, which has a doGet() or doPost() method similar to the handleRequest() method of a YouServ plugin, though typically associated with only one specific webpath which is configured in the application server settings.

We elected to have plugins themselves handle sub-page delegation through a single method in order to minimize the need for complex configuration interfaces and files. A few exceptions to this delegation scheme allow for handling the most common types of sub-page delegations more elegantly. These exceptions involve three reserved subpaths of a plugin's root path which have special behavior. The first is the config webpath:

/_plugin_/MyPlugin/config/

Any webpath beginning with this string will result in a call to the handleConfigurationRequest() method of the plugin instead of the handleRequest() method. This webpath has been associated with a special method so that it can be automatically access controlled. That is, only the site owner will be able to access such methods, and this access control is enforced at a level higher than that of the plugin so it cannot be bypassed. This scheme simplifies implementation of plugin configuration since there is no need to explicitly implement or enforce access control. It also eliminates the possibility of inadvertently exposing critical configuration and administrative operations.

The second reserved subpath is the resource webpath:

/_plugin_/MyPlugin/resource/[resourcename]

The purpose of the resource webpath is to support serving of static content without the need for any explicit delegation through Java code. When a YouServ site is provided with a resource webpath, instead of calling handleRequest of the designated plugin, the system will search the resource section of the plugin JAR file for the named resource, and serve that resource directly.

An example will make this more clear. Consider the previously-described MP3PlayList plugin which displays a home page containing a form and an image. Instead of inserting code into handleRequest that explicitly serves the image, the plugin instead contains the image within the resource subdirectory of its JAR file. Say this image file is named icon.jpg. By placing it in the resource section of the JAR file, once the plugin is installed, it can be web-referenced with the following webpath:

/_plugin_/MP3PlayList/resource/icon.jpg

Ultimately we would like to support the full JSP specification so that JSP files (which are basically static HTML files with embedded Java code) could be included as plugin resources. As an approximation, the Plugin API currently supports fetching parameterized HTML resources in which strings can then be substituted for template variables at runtime.

The third reserved subpath of a plugin's root webpath is the web webpath:

/_plugin_/MyPlugin/web/[your plugin created filename]

This webpath is much like the resource webpath. However, instead of serving files from the JAR, it serves files from a special directory in which a plugin can write web-accessible content that may vary from installation to installation.

For example, a photo album plugin might want to generate some thumbnail images based on those images shared on the current site. Instead of polluting the YouServ shared folder with these thumbnails, the PluginAPI allows the plugin to obtain its own unique web directory in which it can write these thumbnails. These files can then be addressed through this reserved web webpath. Continuing with our example, if the plugin needs to generate a thumbnail called "mypic.jpg", it can write it in its web directory (obtained from the PluginAPI) so it can be web addressable with webpath:

5.2 The PluginAPI Interface

The PluginAPI interface provides useful application state to the plugin. It also provides functions important for coding web applications that we felt were lacking from the Java API. For example, it offers the ability to encode an arbitrary string for appropriate display within an HTML page, as suggested in [SS02] as an important application-level tool for avoiding cross-site scripting attacks.

One important feature of the PluginAPI is a suite of methods that allow the plugin code to query the set of all (private or public) files accessible on the current site, and to obtain a file handle and/or URL to the content. The plugin can also query the site owner's name, the site's domain, the location of the shared web folder, the name assigned to the plugin, and so on. This state allows plugins to be implemented so that they work properly on any YouServ site within which they are installed, without this sort of information having to be explicitly configured by the user.

YouServ sites also have a standard "look and feel" provided by a fixed header and side-bar style that plugin writer's may wish to preserve in their applications. The PluginAPI allows embedding of HTML snippets or resources within the default YouServ page template. This allows the template to evolve (or differ across YouServ deployments) without affecting plugin implementations.

Plugins also typically require that state be maintained. The PluginAPI provides a method which returns a directory in which a plugin may write such state without conflicting with other applications or plugins on the site. As described earlier, the API also provides a web accessible directory in which the plugin can write state or other content that needs to be web addressible.

Perhaps the most important class of functions provided by the plugin API allows the plugin to conveniently exploit YouServ's security features such as its single sign-on authentication scheme, group membership verification, and HTTPS/SSL enabled connections. Not all sites can offer HTTPS/SSL due to firewalls or other issues, which could complicate building a site-independent plugin. The PluginAPI offers methods for constructing URLs and also obtaining user identity as securely as possible given the capabilities of the hosting site. This keeps the plugin free from having to precisely specify when, where, and under what circumstances to use encrypted versus non-encrypted connections.

5.3 Wrapping it All Up

Once implemented, the plugin's class files, resources, and optionally its source code are wrapped up into the JAR file. Though optional, the creator should sign the JAR using the YouServ signing tool. Once in JAR format, the plugin can be deployed by simply copying it to the YouServ plugin folder and activating it through the plugin manager.

Most simple plugins require minimal coding. For example, the SimpleContentEditor consists of approximately 150 lines of straightforward code, and two HTML template files as resources. The MP3PlayList example is almost 500 lines of code, much due to its multiple configuration options and error handling. Code for a minimalist "hello world" example that prints the authenticated visitor's name with a comical image within a YouServ-style-preserving page appears in Appendix A.

More elaborate plugins will obviously require significantly more code. However, the plugin API frees the implementor from some of the most tedious, time consuming, and error-prone implementation issues, such as user authentication, application configuration, and ensuring security through appropriate use of encrypted connections (when available).

6. Conclusions

We have described the design and implementation of an architecture that allows for peer-to-peer sharing of web applications. The goal of the architecture is to bring dynamic content generation capabilities to the websites of non-technical users, and also to facilitate the development and deployment of meta p2p applications atop the YouServ network. Unique to this web application development architecture is the ability to develop and propagate site-independent applications which are easy to install and configure, and its security features offered as an integral part of the architecture to reduce the burden on developers and site owners. While the system is only in its initial deployment phase, we feel the potential applications of the system are numerous. As the infrastructure and its adoption matures, we expect it to be used in many unanticipated and interesting ways.

Appendix A. "Hello World" Code Sample and Screen Shot

package com.ibm.uServ.web.plugin.helloWorld;

import java.io.*;
import java.util.*;

import com.ibm.uServ.web.plugin.Plugin;
import com.ibm.uServ.web.plugin.PluginAPI;
import com.ibm.uServ.web.plugin.PluginIO;

/**
 * "Hello, World!" YouServ plugin
 *
 * @author Roberto Bayardo
 */

public class HelloWorld implements Plugin {
	
    // BEGIN Plugin API implementation
    public boolean initialize(PluginAPI api) {
        return true;
    }	
	
    public void cleanup(PluginAPI api) { }
    
    public int handleRequest(PluginIO response, PluginAPI api) {
        String method = response.getMethod();
        if (method.length() == 0) {
            // Handle the home page request
            return displayHelloWorldPage(response, api);
        } else {
            return Plugin.NOT_FOUND;
        }
    }

    public int handleConfigurationRequest(PluginIO response, PluginAPI api) {
        // There are no configuration options, so just show a pretty page
	// indicating this, while preserving the YouServ look and feel.

        String config_snippet = api.getStringResource("config.html", null);
        String page = api.createStandardPage(response, 
                                             "HelloWorld Configuration",
                                             config_snippet);
        response.setHTMLBody(page);
        return Plugin.RESPONSE_SET;
    }
    // END Plugin API Implementation
	
    protected int displayHelloWorldPage(PluginIO response, PluginAPI api) {
        String username = response.getInsecureIdentity();
	// Above we request only insecure identity information so that
	// the page works without requiring HTTPS redirect.

        if (username != null) {
            String[][] substitutions = new String[][] { 
                new String[] { "USERNAME", username }
            };
            String helloSnippet = 
                api.getStringResource("hello.html", substitutions);

	    // Note: The helloSnippet refers to the static resource named
	    // hello.jpg that must be included as a JAR resource.

            String page = api.createStandardPage(response, 
                                                 "HelloWorld Plugin",
                                                 helloSnippet);
            response.setHTMLBody(page);
            return Plugin.RESPONSE_SET;
        } else {
            return Plugin.AUTHORIZATION_FAILED;
	}
    }
}