At the recent cypherpunks meeting about Java, I was fairly skeptical of its power, especially its ability to do anything useful towards interesting cypherpunk projects. I've been thinking about it a bit more, and I believe I was overly pessimistic. My thinking problem was that I was envisioning Java as a replacement for ordinary HTTP server interaction (such as CGI scripts). I still believe that, absent HTTP server interaction, Java applets are quite limited. However, now that I've started thinking about systems that are built using a combination of Java and servers, the universe has expanded a lot. I'm still unclear about the exact security policy implemented by Java browsers, but this is my understanding: * No access to local files at all. * Can only access URLs on same server as applet came from. Actually, I'm pretty sure the latter is an oversimplification, that the applet can contact any socket as long as it is on the same IP host as the applet itself. However, since HTTP can do pretty much anything any other socket can, the only difference that makes is performance. Here's the "big insight" I had: the server can make up _both_ of these deficiencies, by acting as a file server and communications proxy. Essentially what this architecture does is shift the security burden from the client to the server. In this way, the applet can become "net complete," rather than merely Turing complete. I see one big drawback to this approach. Setting up a server like this is pretty expensive, and using it takes up precious resources. Not everyone has access to a fully scriptable server, which will limit a lot of people. One concern is the "parasitic" use of file system resources on the server. However, there may be a certain amount of security through obscurity that makes this ok. If all Java browsers enforce the policy of only allowing connections to the home host of the applet, then you won't be getting connections from other, parasitic applets. The remaining danger is rogue Java browsers, and non-Java applications that talk to the server, pretending to be Java applets. Some form of authentication could be used to reduce the impact of these attacks. I do see this kind of architecture used to supply services at, say, an organizational level. For example, the "scheduling" scenario could be implemented quite handily, including authentication of access to the schedules, and even distributed scheduling if the different servers are talking to each other. Another scenario which works is email, even including transparent encryption. This one is interesting to me, so I'll go into a little more detail. In this scenario, the server acts as a file server for keyrings (both public and secret) and mail spools. Here's a typical sequence of events for me getting my mail and replying to one message: 1. I call up the JavaMail web page, which is just a wrapper for the JavaMail applet. 2. The JavaMail applet starts with a forms-style login screen. I type my username. 3. The applet asks the server for my mail spool (given the username and perhaps also a password for authentication). 4. The applet displays my mail spool on the screen and lets me fiddle with it, scrolling through it, reading messages, etc. 5. Let's say one of those messages is encrypted with my public key. The applet, recognizing that fact, queries the server for my secret key, encrypted of course (with a symmetric cypher). 6. I type my password to the applet, which lets it decrypt the secret key. 7. Now, that it has my secret key, the applet can RSA-decrypt the encrypted mail and show it to me. 8. I want to reply to the message, so I hit 'r'. The applet gives me a window for typing my reply. When I'm done, I click "send". The applet queries the server for the recipient's public key. 9. When the applet gets the public key, it RSA-encrypts the message and sends it to the server for delivery. 10. When the mail has been delivered, the server notifies the applet of the fact. To me, this is an exciting scenario. Note that, as long as you trust the browser, this lets you read your mail from anywhere. I have no idea whether this scheme is practical. One temporary drawback is the speed of RSA operations. However, this will get fixed when there is native code generation or a bignum library, whichever comes first. Even before then, performance can still be good, using two techniques. First, implement a cache of decrypted session keys (also stored on the server in symmetrically encrypted form). Second, don't display a new email message until it's been decrypted. That way, the RSA operation affects only the latency of mail delivery, not the bandwidth of reading through messages. Of course, these techniques will also dramatically improve performance even for native code crypto. I can see people setting up servers like this for themselves. However, here's an idea on how to set these servers up "for profit." In return for providing file system and mail communications services, the server would expect clients to search keyspaces during idle cycles. When Java goes native code, the computing power thus tapped could be quite substantial. I'm interested to hear what people think about these proposals. Is this something that cypherpunks should be doing full steam ahead? Raph