If an application uses JAR files signed with different certificates, a solution is to sepa-
rate them in one JNLP application-descriptor file, and the rest of JAR files are in
another JNLP component-descriptor file, so that each JNLP file contains all the JAR
files signed with the same certificate.
When our application is not signed, and the JNLP file doesn't specify a security element, the
application is run in an untrusted environment, also known as the JNLP Client sandbox.
In such an environment, the following actions are allowed only after explicit user authoriza-
•Attempt to access the local file system using the standard JNLP services, both in read
•Use of the JNLP Clipboard service for both reading and writing.
•Attempt to send a job to the printer using that JNLP service.
Using the nativelib element, installing a SecurityManager , accessing other remote servers
different from the one from where the application was downloaded, or silently accessing the
file system or the system Clipboard is always denied.
Therefore, accessing the system Clipboard, printer, or local file system for untrusted applica-
tions is possible only via JNLP runtime services that will cause the JNLP Client to ask for per-
mission from the user.
The JNLP Client sandbox is slightly more relaxed than the applet sandbox, in that it
allows the calling of System.exit() and the access to ThreadGroup objects because
any JNLP-launched application runs in its own exclusive JVM.
A complete list of all the (unconditionally) allowed permissions follows.
Exit the JVM
Connect, accept from the download host