Somewhat independent of the security/safety issues regarding Java applets, there are also questions about their suitability for crypto applications. Applets currently labor under several restrictions (at least when part of the Netscape browser) which make it hard to do crypto: Applets cannot accept net connections, and they can only make outgoing connections to the host which provided them to the browser. Applets cannot read or write local disk files. Applets cannot access other local hardware, such as smart cards, printers, or microphones. These restrictions make several things difficult. Finding good sources of entropy for random numbers is hard. Applets do have millisecond resolution event timers (provided that the implementation keeps times to that resolution, of which there is no guarantee), so they can get some entropy by keystroke timings or mouse movements. But they have little access to disk files or other sources of environmental noise. Retaining secure information between runs is also hard. Specifically, there is no place to store key data other than by sending it to the server and having it put it somewhere. It would not be hard to have an applet which created a public key, but the key would have to be stored in an insecure location. So the best it could do would be to encrypt the key with a user specified pass phrase and hope that was strong enough. The restriction on connections makes other applications difficult. To make an applet which can send PGP compatible email it needs to be able to look up keys on the key servers. This can only work if the host serving the applet can look up keys for it. It has to be either running a key server or able to forward requests to one. This requirement makes the applet not "self contained" in that to put it on your web pages you also have to have this other infrastructure in place. Another problem is in trusting applets. Imagine an applet to help you participate in electronic commerce. Just type in your ecash pass phrase and it will help you open your ecash account and then charge you tiny amounts as you surf the web. But of course if the applet is capable of withdrawing small amounts, it would also be able to withdraw big amounts as well. It could drain your bank account before you knew it. Some of these problems might be fixed by giving applets limited access to disk files. But even then it would be risky to let an applet see your PGP secret key ring or ecash wallet. Signed applets can probably help with some of these as well. If Phil Zimmermann has signed the PGP applet, maybe you'll trust it as much as you trust the PGP executable. Likewise if Chaum has signed the ecash applet you'll trust it as much as you trust the ecash software. The thing to keep in mind is that you are already trusting people when you use their code, or virtually any code for that matter. PGP is special because source is available. Of course most people don't have any guarantee that your particular binary was built from the source that you see. But all the other software you run makes you vulnerable. How do you know that DOOM, for example, doesn't check to see if there is a network connection and send out your PGP secret key ring? You even have a pointer to it in your PGPPATH environment variable. Maybe that's unlikely because you'd see your modem lights flash suspiciously, but how about networking applications? Suppose Microsoft's Internet Explorer rummaged through key rings and wallets, piggybacking packets on your output data as you browse? You'd probably never know. So there are limits to how much safety you can expect. Hopefully with signed applets it will be OK to authorize some overrides of the current restrictions so that these other kinds of applications can be provided. Hal