The requirement as per JNLP specification section 5.5, "Untrusted environment", that "Extensions requested from hosts other than the one that the JAR files were downloaded from must be signed and trusted as per section 5.4." is unnecessarily restrictive. Users should be able to write unsigned apps that run in the sandbox which pull in pure-Java extensions from other web sites which are unsigned and which also run in the sandbox. This would make it significantly easier to reuse libraries; no signing would be needed, and it would avoid a proliferation of security dialogs as the application launches, one for each of its signed extensions.
The current restriction is probably a holdover from the applet execution model, where all of the constituent jars must come from the same codebase. It is a basically arbitrary restriction and it is important to relax it. The JNLP specification should be revised and the Java Web Start client updated to allow unsigned applications to refer to unsigned extensions.
If this portion of the spec could be updated as a maintenance update rather than a major update, then this support could potentially be backported to an update release.
The current restriction is probably a holdover from the applet execution model, where all of the constituent jars must come from the same codebase. It is a basically arbitrary restriction and it is important to relax it. The JNLP specification should be revised and the Java Web Start client updated to allow unsigned applications to refer to unsigned extensions.
If this portion of the spec could be updated as a maintenance update rather than a major update, then this support could potentially be backported to an update release.
- relates to
-
JDK-6670678 Java Web Start must support a more flexible security model
-
- Closed
-
-
JDK-6670470 JNLP security model prevents redeployment of existing applet content
-
- Closed
-