Right now, many people are chasing the idea of applets; its neat, sexy, and everyone wants in. But, for many users, and many environments, certain capabilities may be inappropriate.
There has already been loud complaining in many forums about the lack of site configurable Certification authorities, lack of site control over Java features. A site needs to be able to decide who to trust, and who should be able to make these decisions, in a manner that a user can not easily override. The ease of configuration of trust parameters in Netscape is neat for personal use, but inappropriate for business. When Java gets its ability to check signatures, expect complaints about lack of site configuration of trust hierarchies. (Yes, as opposed to web of trust. As a bank, I want to be able to control what code can run with a very explicit hierarchy.)
However, for various reasons (notably compartmentalization, aka defense in depth), it is desirable to restrict disk (and possibly network) access to certain addresses. Something akin to chroot(), tagging of packets outside the applications control to make firewall filtering easy, filtering of available addresses to send to (only talk on local subnet). The ability to assign various levels of privilege to code that runs on a virtual machine will be essential. The ability to limit these privileges must be reserved in some way to those with site security responsibilities. The security people, in turn, will need the ability to delegate.
This can perhaps be provided based on a least trusted basis. Code starts out in a small, tight environment, with no access to anything other than the (protected) processor, and a promote() function which does authorization checking before granting new levels of privileges in certain areas.
Access to disk, access to local and remote network services, and the ability to pull the browser to a new URL are all privileges that should be orthogonally configurable, by site, by machine, or by applet.
A bank teller might need access to applets developed by the bank for various things, but not need access to anything over the internet. He would need to be able to access the local lan servers.
The need of users to get to different resources, and work under different levels of protection calls out for mandatory strong authentication in applets. In other words, a better design might be only execute applets with some (verified) signature attached to them.
The language in which the applet was written is important. More important is the ability of users and management to set policies, and see those policies enforced by applications. I could then set my browser only to run Livescripts signed by someone I know (or an agency that vets them for bugs), and only run Java with minimal trust in the absence of signatures.
I'll take as an example Anderson Consulting's demo BargainFinder (http://bf.cstar.ac.com/bf/). BargainFinder is a way to search 9 music stores on the web for an album, with one form. 3 of the stores are blocking the searches. In addition, a cypherpunk might wonder if the searches and their origins are being logged.
Thats not very useful for those of us who look forward to perfect marketplace information for consumer goods. Let me sketch BargainFinder2, as powered by Java. Instead of going to Anderson for the page, you download BF to your local machine. It does the searching, same as BF1 did, but with no blocking possible. You find your CD at the best price. Perhaps BF is rental-ware, perhaps its someone advertising their Java coding skills.
But its clear that this applet needs to be able to access the network freely. Its also plain that it won't be written for 6 platforms. It might be written for Windows, but the Java market might be larger still, and thus more attractive. (Not to mention that the network interface is mostly taken care of. no Winsock version worries.)
Other applets, say a Ecash wallet manager that interfaces with Quicken, needs access to your local disk, and needs to be able to respond to incoming network queries from shops.
Granular control of the access that applets have thus seems to be needed. Making Java 'secure' is not enough, because people will 'turn off' all the security to make one applet work.
It might also be interesting to consider automatically updating software, that can replace itself from time to time, after verifying that a signature is correct. Although, that does raise the value of stealing a key from some well known, trusted applet vendor.
To summarize, 'security' in the vauge sense that Java promises, while useful, needs granularity to allow it to fulfill its potential.
Comments are welcome. Adam