In today’s world of mobile computing, common Internet services still provide severely limited support for the growing user community. Most services are networked, but their functionality is available from fixed access points only. Although services are potentially available in many places, users are often forced to manually initiate a connection with dedicated servers. Our vision is that users may roam between different sites outside their administrative control using only a smartcard, a PDA, or possibly a notebook. At remote sites, users will have access to their accustomed services without the need for manual configuration or software installation. The goal is to give users a single, consistent view on services as well as data from every remote site with the highest quality of service possible. In this sense, Internet roaming puts emphasis on the notion of mobility without compromising performance for the sake of transparency.
Internet roaming has a multitude of facets and it manifests itself in various ways. Being able to move the graphical user interface of a running application from one display to another, e.g. between several campus workstation pools, improves collaborative work of students. The same service is beneficial for system administrators as well as for home workers roaming between their office and home PC. Migrating whole applications instead of the graphical user interface only is the ultimate, but more visionary goal in this respect. To this end, single application protocols have to be enhanced for the provision of a sensible roaming support. For example, simple electronic mail services are far from perfect with respect to roaming. A first step to improve mobility is to forward mail to a WWW gateway. However, this approach bears the security problem of the messages being exposed in unencrypted form. Even worse, forwarding introduces a new problem comparable to a user having multiple mail accounts. Users are forced to manage forwarding, copies of replies etc. themselves. The burden of managing the data consistently and securely has to be placed on the service instead of the user. Internet roaming tackles the issues of accessibility and manageability to make services truly applicable in a global, insecure environment.
We consider three alternative hardware settings allowing roaming users to get access to services. An obvious approach relies upon desktops already available at the remote site: Internet kiosks, office PCs in an enterprise visited and workstation pools are popular examples. Despite of the heterogeneous hardware, all these computers are inherently insecure. Roaming users may protect their data using smartcards for encryption purposes. Making machines roaming-ready in the first place therefore requires equipping them with a smartcard reader, a trend already visible in the market. However, even if the user’s data may be processed on the smartcard, the untrustworthy desktop still has to be used to display the data, bearing the risk of eavesdropping.
Using PDAs is a different approach, solving the "last mile" problem just mentioned. Furthermore, convenience in a sense is even higher than in the desktop solution. Each roaming user has its own PDA, so no one has to search for an unused kiosk machine. The user has full control over his PDA, alleviating security concerns. Data may be processed, displayed and stored on the user’s own device. Only communication has to be secured. However, besides higher costs of PDAs in comparison with smartcards, processing power and display capabilities are worse than in the desktop solution.
Using notebooks is the third possibility. While the power of a notebook is comparable to that of a desktop, most other properties are similar to the PDA approach. But costs as well as weight are considerably higher than in the other two solutions.
Having the three alternative hardware settings and the heterogeneity of desktops in mind, a suitable implementation environment for Internet roaming has to be determined. Java with its platform independence and its built-in network capabilities is the language of our choice. Java virtual machines are available in one form or another for any relevant device. Even for smartcards, a standardized Java API does exist . Those JavaCards are multi-application cards, allowing multiple applets each implementing one roaming service to coexist. However, using Java as implementation language does not preclude legacy services to be made roaming-aware. Wrappers allow for code reuse, as is demonstrated in one of the projects described below.
The ability of installing new services onto an operative JavaCard is in favour of the dynamic nature of Internet roaming. Services are not forced to be known at every remote site in advance. Java’s ability to dynamically download code enables remote machines to be employed for services without the need for pre-installed code. However, higher availability in case of network failures is highly desirable for roaming services to be effective. Having the increasing memory sizes of JavaCards and PDAs in mind, it seems reasonable that the service’s code could be supplied to a certain extent directly by these devices, at least sometimes in the future.
When a roaming user wants to access a service at a remote site, he first has to get in contact with the remote environment and discover the services available. Because the services offered vary from site to site, a dynamic approach is needed. Bluetooth  or AirPort  are appropriate technologies to provide the physical connection on the lower network layers. Jini  is our choice for service discovery at the application layer. Jini’s explicit design in terms of spontaneous networking is best suited for roaming users temporarily accessing services.
Security is a central concern of Internet roaming, affecting remote machines as well as roaming users. While the Java security model provides a basis to shield remote machines from malicious code of services, the roaming user must be protected against malign service implementations using different methods. Many additional security related problems remain to be solved. Encryption of data while being transferred over insecure communications links is only one aspect. The Java applications’ security properties needed to effectively deploy roaming services are a different concern. Storage of encrypted data, e.g. forwarded messages, implies the need for accessing a remote host’s file system, possibly opening a security hole. Administration of roaming users and their data is yet another, but not the last problem domain. Should all roaming users share one guest account? When shall a user be considered to be roamed to a different site? How can tracking of roaming users be prevented to guarantee anonymity? These are only some of numerous questions still left open.
With respect to service providers, roaming is a known concept. The telecommunication industry, for example, allows mobile phones to roam between networks of different providers. Internet roaming is an analogue technology regarding Internet service providers (ISP), like GRIC , an alliance of over 300 ISPs. ROAMOPS  is a dedicated IETF working group dealing with the development of protocols and technologies in the field of roaming. However, this kind of roaming support is restricted to the network level, concentrating on issues like protocol interoperability and authentication, while our work addresses the application layer. Internet roaming is one aspect of Nomadic Computing . It shares some characteristics with Mobile Agents , Network Computers  and Ubiquitous Computing . However, there are some properties that make Internet roaming a distinct concept. In comparison with mobile agents, Internet roaming is a more static approach. Code shipping as well as execution on top of a virtual machine for reasons of security are properties shared with common mobile agent systems. However, there’s no notion of an autonomous agent acting on behalf of its originator while visiting multiple places on its way. A roaming user typically resides at exactly one place, possibly announcing its forthcoming arrival to future locations. While Network Computing is a server-centric approach, primarily focused to be employed enterprise-wide in a collaborative environment, Internet roaming does not rely on a centrally administered authority. Transforming the global network infrastructure into a big cluster of Network Computers certainly is unreasonable. It’s primarily the services that have to be focused upon. Ubiquitous computing "is a step towards moving computational power away from the desktop into the environment surrounding the user. ... Our general working definition [of ubiquitous computing] is any computing technology that permits human interaction away from a single workstation" . From the viewpoint of service availability, Internet roaming is one step to make ubiquitous computing become reality.
Access to Internet services becomes commonplace. However, most services in use today are designed to be used in exactly one place. On the contrary, user mobility increases, raising the need for services to become accessible from everywhere. Although in principle networked access is possible, e.g. via a notebook and a mobile phone connection, this approach has a couple of drawbacks. Besides being dependent on the equipment as such, wide area network communication—especially over a slow modem line—will always suffer from lower quality of service than a local setting. Services therefore have to be made roaming-aware in order to allow for high QoS. For example, if services require communication with a central "home" server, this communication may often happen out of the critical path. Security and anonymity both are central requirements in Internet roaming. JavaCards as well as PDAs are excellent devices to be employed in roaming scenarios. Cost as well as weight are low to moderate in comparison with notebooks. However, JavaCards and PDAs are relatively slow. Augmenting their Java virtual machines in a secure manner with the power of a host machine is the approach we follow.
1. Roaming X Windows
Is a project currently in the finishing stage, which is aimed at enabling users to move X11 interfaces—even after applications have been started—between different displays. It is primarily targeted for use in a collaborative environment. The implementation is based on xmove , which essentially implements an X proxy server with a simple command-line interface. The legacy xmove code is augmented with a Java wrapper adding the roaming specific functionality. An X11 application uses an xmove pseudo server as its display. The xmove pseudo server intercepts all X11 requests and routes them to a "real" X11 server, opening the ability to move the windows to a different display after transferring the X11 specific state to the new X server.
Our application suite provides dynamic, automated facilities for window movement. Every user logging onto a machine is equipped with a JavaCard. The card contains, amongst other things like the user’s authentication information, a description of the user’s X11 application windows—the user’s distributed desktop. After inserting the card, the distributed desktop is displayed in a graphical user interface. Windows may be moved via drag & drop from one display onto another. When opening a new secure shell on a machine, an xmove is started and registers itself as a Jini service, allowing its automatic discovery by the JavaCard. When the user roams to a different machine, he carries on his card all relevant information about his distributed desktop, allowing for its automatic restoration as desired.Our application suite provides dynamic, automated facilities for window movement. Every user logging onto a machine is equipped with a JavaCard. The card contains, amongst other things like the user’s authentication information, a description of the user’s X11 application windows—the user’s distributed desktop. After inserting the card, the distributed desktop is displayed in a graphical user interface. Windows may be moved via drag & drop from one display onto another. When opening a new secure shell on a machine, an xmove is started and registers itself as a Jini service, allowing its automatic discovery by the JavaCard. When the user roams to a different machine, he carries on his card all relevant information about his distributed desktop, allowing for its automatic restoration as desired.
2. Roaming email
Is another project currently under development. In the current situation, the user’s mail, possibly sent to different mail addresses, is routed to one mail server. Sometimes, copies are forwarded, e.g. to a mobile phone or to another mail account, for example on the home machine. Primarily, the intention of forwarding is to make the mail accessible easily from a different site. When answering mail, the situation regarding which copy resides where even worsens. The burden of managing the copies is left completely to the user.
Roaming em@il tackles these issues by allowing access to a user’s mail account in a secure manner from any roaming-ready machine, while managing the mail account consistently. Roaming-ready machines in this context are required to provide an Internet connection, a card terminal, and a Java virtual machine. Like in the roaming X windows application, JavaCards are employed. A standard mail reader such as Netscape Messenger is statically configured to contact a roaming-aware IMAP  server via the card, making manual configuration when arriving at a remote site obsolete. Any configuration as well as authentication and message encryption are responsibilities of the JavaCard. Among the additional capabilities of the roaming-aware mail service are for example its ability to automatically forward messages to a remote site. Roaming from one location to another may be done either with or without prior announcement, allowing for an even higher quality of service in the former case. Setting up a roaming mail account in advance as well as message forwarding to the destination remote site then become possible. The forwarded messages are handled transparently by the roaming-aware service as temporary copies and do not pollute the user’s mail account.
3. Twin JVM
A project scheduled for the near future, aims at providing a unified execution environment for Java applications on top of two Java virtual machines. This approach creates a single system image in the sense that a Java application is transparently executed by two modified, cooperating VMs. JavaCards and PDAs with its limited processing capabilities become enabled to make use of the power of a host machine without compromising security. The VM of the JavaCard/PDA is trusted while the host’s virtual machine is untrustworthy. Threads may be started under application control on either VM. Access to secure data stored in the trusted VM is granted only to trusted threads. All other access, in particular when crossing VMs, is handled transparently.
1. Sun Microsystems, Inc.: JavaCard 2.1 Application Programming Interface. http://java.sun.com/products/javacard/index.html, February 1999
2. Bluetooth Special Interest Group: Technology Overview. http://www.bluetooth.com, September 1999
3. Apple Computer Inc. & Lucent Technolgies Inc.: AirPort Fact Sheet. http://www.apple.com/airport/, August 1999
4. Sun Microsystems, Inc.: Jini Architecture Specification Revision 1.0. http://www.sun.com/jini, January 1999
5. Solomita, E., Kempf, J. and Duchamp, D.: Xmove: A Pseudo server for X Window Movement. The X Resource, Number 11, pp. 143-170, July 1994
6. Crispin, M.: Internet Message Access Protocol - Version 4rev1. RFC 2060. ftp://ftp.isi.edu/in-notes/rfc2060.txt
7. GRIC Communications, Inc. http://www.aimquest.com
8. Roaming operations (roamops). IETF Working Group, http://www.ietf.org/html.charters/roamops-charter.html
9. Kleinrock, L.: Nomadic Computing - An Opportunity, ACM SIGCOMM Computer Communication Review, Vol. 25, No. 1, pp.36-40, January 1995
10. General Magic Inc.: System and Method for Distributed Computation Based upon the Movement, Execution and Interaction of Processes in a Network. US patent no. 5603031
11 Ellison, L.: Internet Computing: Connect to the World.
12. Weiser, M.: The computer of the 21st century. Scientific American, 265(3): 66-75, September 1991
13. Abowd, Gregory D.: Ubiquitous Computing. Research Themes and Open Issues from an Applications Perspective. GVU Center & College of Computing, Georgia Institute of Technology, Atlanta, Technical Report GIT-GVU-96-24, December 1996