|
Employ Secure Applets in Browsers
Applets may have fallen out of favor, but now that they run inside Sun's VM, we can use the Java 2 security model to manage the applet
by Kevin Jones
Posted February 4, 2004
Editor's Note: This is the first of two installments on creating and using secure applets. In the first part, author Kevin Jones discusses why applets are back in vogue after falling out of favor for a while and using applets in browsers, including managing their security. In the conclusion, Jones covers the process of creating and using a security certificate and changing the policy file.
A long time ago, in a galaxy far, far away, a company started working on a new programming language and run-time system. That company wanted a system that would enable devices to communicate with each other, so it designed the system to enable applets, mobile code that could be downloaded to a device. That company of course was Sun, and the language/system became Java. When I first started programming Java about seven years ago, applets were the thing, but they've fallen out of favor. Recently, however, I've seen a rise in interest in applets again. Let's see why this renewed interest seems to be happening, and how to use applets securely within a browser.
At one time, everything was centered on building applets. We taught people how to write basic applets and how to get applets to interact with the browser. The Java security model was couched in terms of applets, as was the Java thread model. Applets were considered the most important aspect about Java. So what happened?
Several reasons led to applets falling into disrepute. Initially the problem lay in the differences between browsers. Different browser's Java Virtual Machines (JVMs) offered different capabilities and in particular different security models. Then the browsers war heated up and Sun and Microsoft fell. Now the problem lay in the fact that the evolution of Web browsers didn't match the evolution of Java. As Java evolved from Java 1 to Java 2, Netscape's market share plunged and Microsoft made sure it shipped only Microsoft's virtual machine (VM) while Internet Explorer was off doing its own thing This situation meant that even if Netscape did ship a JVM, nobody cared, and as mainstream Java developers moved toward Java 2, writing applets for what seemed like Microsoft's dead-end Java implementation seemed pointless. All in all, applets became less and less important to developers.
However, the rift between Sun and Microsoft has now led to a situation where applets can be considered seriously again. As part of the settlement, Microsoft is phasing out its own JVM and now supports Sun's JVM within Internet Explorer. Mozilla also does not ship its own VM and also supports Sun's, which means that finally we have a scenario where both major browsers support the same version of Java.
Using Applets in Browsers
To solve the problems of having multiple Java implementations in different browsers, Sun introduced the Java plug-in (see Resources). In the past when developers used the <applet> tag on a page, the browser used its own JVM to execute the applet. The idea behind the plug-in was that the plug-in would define the version of Java for the applet to use. In fact, the plug-in has two versions: one for Internet Explorer and one for Netscape/Mozilla. The Explorer version is an ActiveX control and the Mozilla version is a Netscape plug-in. Using an ActiveX control to execute Java code with Internet Explorer always struck me as being highly ironic—Sun eating Microsoft's dog-food, as it were.
Compared to using an <applet> tag, using the plug-in was tedious; although, part of the plug-in download is a tool to convert <applet> to the appropriate plug-in syntax. Most developers are accustomed to using <applet>, and they would therefore usually write the <applet> tag and then run the converter—a wearisome task at best, an error-prone one at worst. Check out a comparison of <applet> tags and the corresponding plug-in conversion in Listing 1.
Back to top
|