A great deal of attention has recently been paid to the strategy of increasing Java security by having applets certified and digitally signed by some trusted authority. Current proposals for this argue for certification only as a method for establishing the identity of the code provider; it is expected but in no way guaranteed that code providers with reputations to protect will take appropriate care to verify the safety of the code they sign. Given that Microsoft, a company that has announced interest in Java code signing, has in the past released software containing hostile code [7], we believe that such certification is best used in conjunction with additional security strategies, such as the window personalization technique described in this paper, which is complementary to (and independent of) applet signing.
It may also be the case that we will see the further development of the code signing strategy beyond simple certification of provider identity to encompass at least limited verification of code safety and other attributes. In the event that this occurs, we once again note that even the most competent and conscientious certification authority is likely to occasionally err and certify a malicious applet as safe. Given the extremely sensitive nature of some of the information that such applets might attempt to steal, it clearly remains advisable to minimize that risk through additional strategies where possible.
Finally, we point out that there will be substantial pressure on many web users to allow some uncertified applets to run; the broad variety and large number of applets present on the Web today argues that applets are fulfilling a need -- and requiring and checking digitally signed certification for every applet is likely to be viewed as being a logistically complex problem.