meiner meinung nach verletzt es explizit keine regel:
* Read files on the client file system.
* Write files to the client file system.
* Delete files on the client file system, either by using the File.delete() method, or by calling system-level rm or del commands.
* Rename files on the client file system, either by using the File.renameTo() method, or by calling system-level mv or rename commands.
* Create a directory on the client file system, either by using the File.mkdirs() methods or by calling the system-level mkdir command.
* List the contents of a directory.
* Check to see whether a file exists.
* Obtain information about a file, including size, type, and modification timestamp.
* Create a network connection to any computer other than the host from which it originated.
* Listen for or accept network connections on any port on the client system.
* Create a top-level window without an untrusted window banner.
* Obtain the user's username or home directory name through any means, including trying to read the system properties: user.name, user.home, user.dir, java.home, and java.class.path.
* Define any system properties.
* Run any program on the client system using the Runtime.exec() methods.
* Make the Java interpreter exit, using either System.exit() or Runtime.exit().
* Load dynamic libraries on the client system using the load() or loadLibrary() methods of the Runtime or System classes.
* Create or manipulate any thread that is not part of the same ThreadGroup as the applet.
* Create a ClassLoader.
* Create a SecurityManager.
* Specify any network control functions, including ContentHandlerFactory, SocketImplFactory, or URLStreamHandlerFactory.
* Define classes that are part of packages on the client system.
und da beide applets ja keinen schaden anrichten können, warum sollten sie nicht theoretisch nicht miteinander kommunizieren können, sie laufen ja in einer vm, und damit auch in einer sandbox, oder? ist jedenfalls nur ne vermutung
