Applets normally have few privileges and cannot connect to machines other
than the one which they came from.

Even if you sign your applet code to grant it privileges, it doesn't mean
that all operations should necessarily succeed.

1) Another applet, etc. could call your code or your library, etc. and make
use of you being signed to do malicious stuff.

There are a few exceptions (optimizations, perhaps), but generally, code
which is designed to run with a security manager must sort of declare that
it was designed to do so, knows what it's doing, and won't let itself be
abused to grant undue access to other (perhaps untrusted) code which calls
it.

What you're looking for is the AccessController.doPrivileged methods.  The
take either PrivilegedAction or PrivilegedExceptionAction, which are similar
to java.lang.Runnable, except that they have return values.  Invoking
AccessController.doPrivileged means I know what I'm doing, don't worry about
the privileges of my callers, only check the security access of my own code
and the code which I [in]directly call.

So, for example (and this is just writing as I go), you want to do something
like:

Socket s = (Socket) AccessController.doPrivileged(new PrivilegedAction() {
   public Object run() {
       try {
           return new Socket("some server", somePort);
       } catch (Exception e) {    return null;    }
   }
});

You mentioned AccessController.checkPermission.  This is how you force a
security check.  The Socket class constructor will (at least indirectly)
call checkPermission with a SocketPermission to _enforce_ these rules that
code which creates a socket must have permission to do so.

Rarely would one need to do such permission checks -- usually it's already
built in to the other stuff you call -- like opening sockets, or into your
superclass.  Even rarer would be the need to create new permissions to
protect some new type of resource which you provide.

Joel