There are some signed applets that overwrite deployment.properties to add JVM command-line arguments for various purposes, whether it is to increase the default heap size for applets or to turn on or off Java 2D acceleration properties. In the new plug-in, if there are any non-secure JVM arguments in this list, the JVM instance will not be allowed to run unsigned code.
There are some applets (see the Comments section for details) which are specifying invalid system properties. Because these aren't in the known good list of secure system properties, this basically causes the new plug-in to fail to launch any untrusted code, which is unacceptable.
We need to filter out insecure JVM arguments from the list specified via deployment.properties. With the new plug-in, developers now have a workaround for this, which is to specify these arguments via the new java_arguments applet parameter.
The other option we considered (under 6629341) was to treat all of the arguments specified in deployment.properties as trusted. This does not appear to be an acceptable solution on the Windows Vista platform, where deployment.properties is in a low-integrity location. Having different treatment of arguments specified in deployment.properties on different platforms would be confusing so we are not choosing this option.