Computing on the web introduces new risks, because web pages may contain programs that are executed on your computer when you visit the page with your browser. Web page authors use this executable content to perform a range of functions, from enlivening a web page to implementing a complete web based application. When you visit a page with embedded executable content, the program is downloaded to your computer and executed locally, to provide the effect intended by the web page author.
The best known example of executable content is Java, a programming language from Sun Microsystems Inc. With Java, you can create applets that provide special effects such as sound, animation and increased interactivity. Java is much more powerful and useful than implied by these uses; it can be used to construct powerful and compelling web based applications.
Another mechanism, ActiveX Controls from Microsoft, allows programs to be written in a language such as Visual C++, a dialect of C++. Java and C++ are general programming language: you can write any program you want in these languages, limited only by your imagination and originality. For examples of the immense creativity unleashed by these languages, visit Gamelan and The ActiveX Resource.
Many other mechanisms for executable content have been proposed. Safe Tcl, implemented in the Tcl plugin described here, provides a mechanism for executing Tcl scripts with portable user interfaces based on Tk, inside web pages. Contrary to Java and C++ which are compiler-based, Tcl is an interpreted language.
If there is such a wealth of mechanisms for providing executable content, why propose another one, based on Tcl and Tk? Asked another way: what's wrong with some of the proposed executable content mechanism that causes them to be used less than their inventors hoped for?
There are several answers to this question. Some of these executable content mechanisms are hard to use, their development tools are expensive, or they require special programming skills, as in the case of ActiveX and to a lesser degree Java. These are all valid reasons but they do not provide the complete picture. The major reason these mechanisms have received less adoption than expected is simple: security.
With the immense possibilities opened up by executable content comes the inevitable dark side. Just like any other software, executable content can perform useful functions and allow a visitor to your web page to experience the web in new ways. Just like any other program, executable content can also be used to mount each of the attacks described previously.
However, executable content embedded in web pages poses a special problem for the web user who is interested in protecting himself or herself against malicious programs. That is because the executable content is downloaded and executed on your computer, in some cases without asking for your approval, when you visit a page. If you visit the wrong page, your computer, its files and all valuable information stored on it could be compromised.
Responsible companies such as Microsoft and Sun are taking different approaches to addressing this potential danger. Microsoft is proposing its Authenticode technology as a mechanism to reassure end users that the executable content was created by reputable authors. Its approach is to impose an accountability framework on top of executable content.
As we saw before, this model works well if the authors are well known software companies. However, this model does not scale to the Internet, where anyone can publish and disseminate programs, information and executable content. Basing security only on accountability requires that one avoid using software and executable content from unknown sources. It means that you cannot visit web pages written by people you do not know, because they may have put some executable content into their pages, and a visit to their pages may be dangerous. This defeats the purpose and primary use of the web, which is distribution of information without centralized control.
There is another problem with the accountability based approach: the end user must make a decision whether to allow specific executable content to be executed every time a new piece of executable content is encountered. How many users will stay vigilant through the endless series of questions asked by the browser whether to allow this or that ActiveX control to be executed? Inevitably, you will make a wrong decision because your guard was down for a split-second, and then malicious code will be executed on your computer.
Some attacks, such as privacy attacks, are not recoverable, and for some attacks the damage is so severe that they should never be allowed to occur in the first place. The bottom line is that you cannot implement security solely based on accountability. You can only use accountability to relax security.
Here is an illustration of this important distinction: suppose you were tasked with implementing the protection of the President of the United States, and you decided to base this protection solely on accountability. You would let people meet with the President based on whether they worked for the government or a big corporation doing business with the government. Employment would be strictly verified, but no further checks would be performed; in particular, if one were approved to meet with the President, he or she would not be searched for weapons. Eventually someone would assasinate the President. When asked why you let this occur, in defense of yourself you would say that you had implemented a strict accountability mechanism and that you were now going to sue the company which employed the assasin.
Now let's compare this imaginary scenario with what really happens in reality: Everyone, when they want to meet with the President, must submit to a search of their personal effects, to ensure that they do not carry any weapons. The only people who are allowed to carry weapons when they are around the President are people that have been very carefully screened, trained and who are completely trusted. Thus, for most people, strict security is implemented by restricting their capabilities, while for some, who are held in trust and who are accountable, security is relaxed and they are allowed to have more capabilities.
The approach taken by Java and Safe Tcl is different: They provide a base environment that is safe, like Visual Basic Script, and then allow extension of the base with potentially unsafe features. Whether these potentially unsafe features are enabled is under the control of the end user. Instead of basing security on accountability, these systems use accountability strictly for the purpose of relaxing security. Because Java and Tcl are complete programming languages, any application that a programmer can imagine can be implemented in them, with the proper security allowances.