Design submitted for security review on 12/29/10:
As part of 7 performance improvement for cold start of JNLP applets, the deployment team plans to introduce an optional applet parameter called 'embedded_jnlp' which would have value of base64 encoded content of the applet JNLP file.
<applet width="710" height="540" >
<param name="jnlp_href" value="launch.jnlp"/>
<param name="embedded_jnlp" value="PD94bWwgdmVyc2lvbj0iMS4wIiB . . . dC1kZXNjPg0KPC9qbmxwPg0K"/>
<param name="draggable" value="true"/>
The applet param 'embedded_jnlp' provides an option to skip a network access for JNLP file content and shorten the applet launch time.
On cold starts, the base64 decoded value would be the initial JNLP content contributing to the final applet launch info. The embedded JNLP would be cache for subsequent warm starts of the applet, either from the web page or from the shortcut.
On warm starts, if needed, the embedded JNLP content will be used to update the cached JNLP.
In terms of security, since the JNLP client did not directly load the JNLP content from a location, it could not validate a codebase with absolute URL. To mitigate this we restrict embedded JNLP content to use only empty codebase, which would eventually resolves into the docbase URL. This would prevent malicious applet from faking codebase.
If the app jar is signed, launch info from embedded JNLP would go through the same signing validation as normal JNLP file content. Similarly, for unsigned applets, unrestricted accesses are prevented.
With the above design and consideration, we don't see that allowing embedded JNLP content on a web page, would create new security holes. We would appreciate if the security team review to make sure that it is indeed safe.