SUGGESTED FIX

http://sa.sfbay.sun.com/projects/deployment_data/6u10/6670470.0
testcase: http://j2se.east.sun.com/deployment/www/tests/1.6.0_10/6670470
                                     

EVALUATION

The JNLP security model is badly broken in the context of applets. It
attempts to enforce arbitrary restrictions such as the following: if
the main JNLP uses sandbox security, it can not pull in extensions
from other hosts. This is a basic feature of old-style applets -- that
permissions are granted solely on the origin and trust status of the
code -- and it is unacceptable to impose this sort of restriction for
JNLP launched applets because it will prevent people from migrating
their existing applet deployments to use JNLP as the applet
description mechanism.

Removed the call to LaunchDownload.checkJNLPSecurity() in the
JNLP2Manager. Made AppPolicy.addPermissions() take a boolean argument
indicating whether to grant permissions to the class being loaded
based on the contents of the JNLP file. For the time being, Java Web
Start passes true for this argument and is unchanged. The Java
Plug-In's JNLP2ClassLoader passes false, and since it calls
super.getPermissions() (which grants permissions based on the origin
and trust status of the CodeSource), has the same semantics as old
applet deployments.

This change makes the Java Plug-In substantially more useful for
deployment than Java Web Start, which is also not an acceptable
situation. The two technologies must have parity. A very similar bug,
6518285, was filed against Java Web Start over a year ago. A follow-on
bug, 6670678, has been filed to make Java Web Start silently degrade
gracefully to a similar security model to this one if
checkJNLPSecurity() returns false. This bug will be fixed in 6u10 as
an implementation bug, while 6518285 is filed against the JNLP
specification and can only be fixed in 7.