by Simon Dobson
There has recently been an increased interest in integrating executable code into the World Wide Web (WWW), extending the idea of moving data with the notion of mobile code. There are many possibile applications of this technology, including "active" documents, parts of which are executed at the client, dynamic extensions to browsers to support new interface widgets, off-loading complex search processing etc. Several technologies already exist to support active documents, but none has yet achieved overall acceptance. There are many important issues to be explored first, especially extensibility, portability, openness and (most of all) security.
The WWW Consortium (W3C) organised an open workshop in July in Boston to discuss these issues and attempt to arrive at a consensus on how to procede with integrating mobile code into WWW in an open and flexible fashion. It was attended by technology providers (including Sun, DEC, Microsoft, and IBM), network service providers, members of the W3C staff, and other interested parties including two staff from RAL.
The companies with mobile code technologies already available each gave a short presentation of their systems and the lessons learned. The systems ranged from scripting languages wush as IBM's Object REXX and Sun's Safe-Tcl through to full-blown compiled languages such as Sun's Java, Kaleida Labs' ScriptX and DEC's Obliq.
A major lesson from the systems was the need to address the GUI in a portable manner. Many content providers - especially for multimedia titles - want to provide their own distinctive display objects, which acts against any standardised widget set built-in to browsers. For example, Sun's HotJava browser allows Java code to be used to animate HTML pages, providing customised display capabilities - but anyone wanting a novel presentation must provide the code to implement it. If a page contains a novel widget, the browser could automatically download the necessary code to handle it.
Mobile code also needs access to the file system and network services (made substantially easier by the standardisation of URLs). There are several standard APIs which may be identified, including a "business card" API for acquiring user information direct from the browser.
The main issue is still security: how to ensure that downloaded code does not compromise the client system. Safe-Tcl adopts a "padded cell" model of security, where a piece of untrusted code is run in an environment which provides only very limited access to the outside world. Extra features may be added by introducing functions into the cell along with the code, allowing more trusted code to access more system functions. This may be contrasted with the "sea of objects" model in which code is given handles on to only some of the objects in the system. The risk here is of accidentally giving an untrusted routine a handle for a powerful object, which may then be used to damage the client. As a way forward, it was suggested that the community concentrates on enabling "microscripts" - small scripts embedded within HTML for tasks such as forms validation. These run well in extremely secure environments ("fully padded cells"), so do not endanger client machines. Browsers will need to provide a standard API to scripts, and this API may be expanded as new features are agreed. There is never likely to be any agreement on a single web scripting language, so open integration of scripts in different languages is also very important.
Hopefully the issues discussed at the workshop will lead to the wider availability of active documents and extensible web browsers in the future, and improve the overall usability of the web for us all.
inf.rl.ac.uk