I’d like to thank everyone who helped spread the word on the new Code Signing requirements and guidelines starting with 7u21. In particular, Markus Eisele did a fantastic job with his blog, and also an article in Heise Developer (in German) – thanks @myfear!
We’ve just added two new FAQ questions to the OTN article on Code Signing in response to a two particularly frequent questions. The first is in response to questions around applet signing, and in particular the fact that prior to 7u21 signed apps were assumed to want full permissions, and unsigned were assumed to want to be sand-boxed. See the FAQ “How has this changed the underlying security model of Java applications in the browser?” for more information.
The second question relates to warnings when running applets in mixed (signed and unsigned) environments (particularly as it relates to JavaScript). 7u21 expanded the scope of when these warning would be presented, and we have addressed how developer can manage these situations in the FAQ “Does the code signing requirement impact “mixed code” environments?“.
Both questions contain links to the product documentation with additional information for developers and admins.
– Don
DonaldOJDK Blog 
Hi Donald,
I am looking for java upgrade from 1/6 to 1.7 for my client(vm leader) and trying to know what are the major performance improvements in 7? Can you point to the right information.
pls share your email as i cant see it here.
thank you
pradeep kamasani
The links from Henrik’s blog here, should help answer some of those questions: https://blogs.oracle.com/henrik/entry/migrating_from_java_se_6
Of course the best way to know for sure is to give it a try and see!
Any specific reasons why the switch to run signed applets in the sandbox is part of the (unsigned) applet parameters and not the (signed) Jar manifest? I cannot think of an easy way to abuse this, but it seems pretty risky to put such an important piece of information at a place where the signing company has no control over…
You should be able to set this in the jar as well. The support for applet parameters is for legacy reasons. There’s some corner cases I’d have to test out or ping engineering, but it should work either way. Also, proving the data under https should help minimize any concerns.
In what way does HTTPS prevent a rogue attacker from downloading my (signed) applet, upload it to his webserver and present it as his on his website and configures it to run outside the sandbox? If I tested my applet only to work fine inside the sandbox (much less testing required, as an exploit for a programming error will probably be still blocked by the sandbox!) and later my applet is abused by someone else who runs it outside the sandbox, it casts a danming light on me, the signer of the applet – which is a reason I’d rather not sign my applets if I cannot be sure it will not be used in such a context.
@mihi, sorry – I misunderstood. https is obviously a red herring if this is your core concern. Like you say, I’m not sure how that could be abused but definitely sounds like a case to be considered. I’ll have to do some digging on that one.
For the record, CERT/CC seems to have the exactly same concerns:
http://www.cert.org/blogs/certcc/2013/04/dont_sign_that_applet.html