WORK AROUND

sign the applet code and add doPriviledged block to the entry point of the Javascript->Java call to allow Java code to run with all-permissions when calling from Javascript.

For more information on Java security model, sandbox applet and signed applets, and privileged block API.  Below are some documentation link that explain these:

http://download.oracle.com/javase/tutorial/deployment/applet/security.html
http://download.oracle.com/javase/7/docs/technotes/guides/security/doprivileged.html
http://www.oracle.com/technetwork/java/seccodeguide-139067.html#6-0

For the relationship between doPrivileged block, JavaScript and signed applet code:

Code is granted permissions:
   a) if all code on the stack is coming from trusted sources (and creation of the thread was initiated from trusted context)  (JavaScript is untrusted code; signed Java code is trusted)
   b) if code is trusted (signed) and explicitly calls doPrivileged to elevate permissions

All calls from JavaScript to Java are treated as calls from untrusted code (in the same way if you call signed code from unsigned java code).

That's why when calling from JavaScript to signed applet code, if you want the signed applet code to run with all-permissions, you need doPrivileged call in the applet code.   This is because JavaScript is in the context of the call.
                                     

EVALUATION

The problem is the call is triggered by JavaScript in the web page, calling into Java code in their signed applet JAR.   The call will trigger access to secure cookie.    With the secure cookie fix in 6u29 - we introduce a check to make sure SecureCookiePermission is satisfied before allowing access to the cookie.    In the 6u29 fix, we grant the SecureCookiePermission in our webstart/plugin classloader, and allow Java code to access secure cookie if it's originated from HTTPS and the same origin host.

Problem is in this scenario - the call is originated from the JavaScript, not Java code.  When we do a SecurityManager.checkPermission on it - it will eventually call into AccessControlContext.checkPermission, which will make sure all the ProtectionDomain in the current context has the permission.   In this case, there is JSProtectionDomain in the context, and SecureCookiePermission is not there (JavaScript is not loaded by our classloader).   That's why we throw the SecurityException and caused the problem.

For us, the right fix is to also grant SecureCookiePermission in the JSProtectionDomain, and allow it to access cookie if JS/applet is originated from the same HTTPS host.

For the customer, they can workaround it right now by adding doPrivileged block to the entry point of the js->java call.   This will elevate the Java code to be run with all-permissions - since their code is signed and trusted.