1999-10-29
Antti Karanta
Faculty of Technical Physics
Helsinki University of Technology
akaranta@cc.hut.fi
Jesse Lahtinen
Department of Computer Science
Helsinki University of Technology
jalahtin@cc.hut.fi
Java applets have taken the world wide web by storm. They introduce interactivity and the power of real programs to the otherwise static web pages. This gives immense possibilities, but could also introduce threats that have to be taken into account. The key factors in applets' popularity are their multi-platform nature and their safety as executable contents.
2.1 Animation and sound applets
2.2 Interactive applets
2.3 Protocol handlers
2.4 Applet usage limits
3.1 Portability
3.2 Making an applet
3.3 Performance
4.1 Sandbox
4.2 Signatures
An applet is basically a small java program that can be run in a Java-enabled web browser or a special applet viewer. They can greatly enhance the otherwise static structure of www-pages in a functional, visual and audible fashion [9]. They can be used to add interactivity to pages and to play sound or animation. The possibilities are endless, as most things that can be done with normal applications can be done with applets. The only absolute barrier are the security restrictions that applets have to adhere to.
Applets were introduced by Sun Microsystems as part of the Java language and were first taken into use by Netscape in January 1996, when they released the first ever Java-compatible browser, Netscape 2.0.
Nowadays both major browsers and some of the minor ones support Java and Java applets are used extensively on www-pages.
The applets are embedded in the web page in a similar fashion as pictures; they have a special <APPLET> html-tag that points to the bytecode of the applet and indicates the size, location and other information required by the browser. The applet is automatically executed by the browser's virtual machine after it is loaded [3]. Therefore applets are often loaded and executed without the user necessarily being aware of it.
At first when applets were introduced, they were almost exclusively used just for enhacing web pages. Even though more "serious" use of applets has become more common, the decorative functionality has not lost its significance. With applets the page designer can, without the need for external viewers or plug-ins, add (possibly interactive) animations, background music and sound effects thus making the page much more human and alive.
Applets are not just amusing but useless toys. Applets can have a modern graphical user interface (GUI) and all the functionality of an application that is not prevented by security measures. Thus many real world applications can, and have been, implemented as applets. The web is full of these; drawing applets, scientific calculation and data visualization applets, spreadsheet calculator applets etc.
One of the greatest advantages here is that a company or an organization can put on their web page an applet with very specific functionality to serve theirs and the user's needs. For example, an interactive and help providing on-line tax report filling applet is entirely possible to implement.
Content handlers or
protocol handlers are special purpose Java applets which
enable the browser to deal with new data
formats dynamically. The applets that understand the new format can be
loaded on the client "on the fly", with no installation of plug-ins
necessary [3,9].
This is very useful when experimenting with or introducing a new
information format. Documents containing information in the new format
can be published immediately alongside with the applet that can
interpret them. It also enables companies and organizations to define
their own data-formats and protocols (e.g. for secure commerce) if
desired.
At the moment the protocol handlers are in use only in HotJava, which is a purely Java based browser.
The greatest matter affecting how and what for applets can be used are the security restrictions imposed on applets. Even though limiting in some aspects, they can many times be worked around to achieve the desired result. For example, writing on the client's hard drive is prohibited, but the necessary information can be transferred to the server and saved there.
With the speed of the present day's network, another serious consideration
is the size of the applet. Downloading a large applet can take a lot of
time. This puts some limits on how much functionality is sensible to put into an
applet.
In the near future, large applets that are used often can be saved to the
local file system in a special
applet cache so they
don't need to be downloaded again every time they are used[6].
Also a new technology called
AppStream
promises to bring a significant improvement to download delays by
partitioning the applet and downloading only the essential parts at first
[7].
Applets, as Java in general, are meant to be platform
independent. However, the virtual machines of different browsers have
different bugs and otherwise behave differently in some
circumstances. Thus the Java slogan "write once/run anywhere"
translates into "write once/debug everywhere" [2]. It is still, however, a lot smaller task than
porting a program from one platform to another, and only one code
version needs to be maintained.
Significant progress in this field has been achieved since the initial
release of Java. It still remains to be seen if the browser
manufacturers will ever get their virtual machines compatible with
each other.
Making an applet is almost like making any other Java program. Java is an object oriented language and what are normally called applets are really instances of a base class called Applet, which all applets have to inherit from. Also a few special methods have to be implemented to tell the applet how to react to certain events in an applet's life cycle, such as starting the applet [1].
It is a common misbelief that as Java is an interpreted language, it
is painfully slow and completely unsuitable for any real purposes. This is
true only in some special cases, which are highly complex and computationally
intensive.
Java applets share the same performance statistics with normal Java
applications. There are numerous inventions in use in the Java virtual machines
to boost the performance, like HotSpot and the JIT-compiler. Besides that,
normal everyday applications are rarely computationally very intensive. That
combined with processors becoming ever more efficient brings us to conclude
that the performance is almost never an issue with applets.
Loading and executing code from an untrusted source is normally an immense security risk. The code can include virtually anything: viruses, trojan horses etc. These can have very nasty effects, like formating the user's hard disc or sending out classified information. Basically anything the user has rights to can be done by getting him to execute a program.
Java applets are often downloaded without the user even noticing and are executed without his prior consent. Thus one can clearly see that if the security issues had not been taken well into account, Java applets would be totally useless as downloading them would always be a considerable risk. Therefore the security of applets has been taken care of in many different ways. One should still always remember there is no silver bullet or a 100% secure computer system; there can always be bugs and mistakes clever hackers may find and take advantage of.
The security restrictions on an applet are different based on whether the applet is loaded from the web or the local filesystem and whether it is running in a browser or an applet viewer[4]. The user can also grant the applet some extra privileges, if the applet explicitly asks for them and the user so desires.
The goal of the applet security is that the (dumb) user would not need to worry or become a security expert just to be able to browse the web safely. The security is taken care of by default. In Sun's own words, untrusted applets can be run in a trusted environment [8].
To enforce the security, the applets are said to run in a private "sandbox", in which they are bound to dwell. They can not access information outside it, so they can not alter the user's system or spy on it. More precicely, an applet running in a browser can by default never
The applet security manager is the Java mechanism for enforcing the security restrictions described above. In addition to that, there are two more lines of defence to keep an applet in its sandbox. The byte code verifier takes care that an applet does not try to access memory outside the allowed bounds or use any other "dirty tricks" like stack overflow. The class loader makes sure that a malicious programmer cannot invade the system by replacing some of Java's base classes with one of his own [4].
In order for the user to be able to verify an applet's origin, authenticity and integrity the applets can be digitally signed. The signing is done using asymmetric keys, i.e. the maker of the applet signs the applet with his secret key and the validity of the signature and the integrity of the applet can be verified with his public key.
Besides knowing where the applet you execute comes from and that it has not been changed on the way, signing is really important when an applet wants some extra permissions, for example to write to a file in the client system. This kind of rights can be given to specific applets in a very detailed manner with an applet Policy Tool [5]. So, if the user trusts the signer of the applet, it can be given more privileges thus further extending the capabilities of applets.
Applets are gaining more and more popularity on web pages. Executable contents is certainly an area that is going to be increasingly important in the future. It has even been speculated that the model of buying and installing programs locally may be replaced by a model where people download the applets they need from www-pages as needed [9]. The users could even be charged on a by-use basis instead of purchasing a single licence.
Another area of growing importance is e-commerce. The e-commerce is just taking off and is going to grow enormously in scale. Before it can do so, it needs means to provide secure trade and interactive helpers. Both of these needs can be satisfied with the use of applets.
One thing is for certain: applets are here to stay.
[1] Campione M., Walrath K.: Overview of Applets, 29-Mar-96
<
http://www1.informatik.uni-halle.de/java/java-tut/applet/overview/>
[2] Elliotte R.: comp.lang.java FAQ: Programming applets,
06-Oct-97
<http://metalab.unc.edu/javafaq/javafaq.html#xtocid2672634
>
[3] Horstmann C, Cornell S: Core Java Volume I - Fundamentals, Sun Microsystems press, 1997
[4] Javasoft: Frequently Asked Questions - Java Security;Applet Security, 22-Jul-98
<
http://www.javasoft.com/sfaq/index.html#applets
>
[5] Sun Microsystems: The Java Tutorial: API and Tools Use for Secure Code and File Exchanges, Oct-99
<http://java.sun.com/products/plugin/appletcaching.html>
[6] Sun Microsystems: Applet Caching in Java Plug-in 1.3
beta, Aug-99
<http://java.sun.com/products/plugin/appletcaching.html>
[7] Sun Microsystems: AppStream Makes Java Applet Download Delays
a Thing of the Past, June 14, 1999
<http://industry.java.sun.com/javanews/stories/story2/0,1072,16025,00.html>
[8] Sun Microsystems: Frequently Asked Questions - Applet
Security, 26-Sep-98
<
http://java.sun.com/sfaq/>
[9] Tanenbaum, Andrew: Computer networks, 3rd ed., Prentice-Hall 1996