EVALUATION

Suggested release note blurb:

Optional applet parameter 'jnlp_embedded' provide option to cache JNLP content on the HTML page and shortens applet launch time by skipping an network access.  The parameter  'embedded_jnlp' has as value the base64 encoded content of the applet JNLP file. For example:

       <applet  width="710" height="540" >
           <param name="jnlp_href" value="launch.jnlp"/>
           <param name="jnlp_embedded" value="PD94bWwgdmVyc2lvbj0iMS4wIiB . . . dC1kZXNjPg0KPC9qbmxwPg0K"/>
           <param name="draggable" value="true"/>
       </applet>

When present, parameter 'jnlp_embedded' value replaces content of JNLP pointed to by param 'jnlp_href'.  The value of 'jnlp_ref' is then optional and only used as backup when content of 'jnlp_embedded' is invalid.  There are a few restrictions on the embedded JNLP content:

(1) attribute href from element jnlp should be relative.
(2) attribute codebase from element jnlp should be empty (which means the codebase value will be derived from document base URL).
                                     

EVALUATION

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"/>
       </applet>

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.
                                     

EVALUATION

Proposed approach:

1) Support optional jnlp_content param to the applet tag.
   The value is base64-encoded content of JNLP descriptor.

2) If value is present then client VM should use this descriptor instead of loading it from the network.

Potential implementation issues:
  1) base64 version of JNLP can be potentially long - need to understand what is the limit here.
  2) client VM may need to be restarted - value should not be lost? or be in cache?
  3) Deployment code may try to get main JNLP from URL more than once. 
    Need to make sure these request do not cause network lookups. (this could depend on value of update tag)
  4) Subsequent launch of the app should not require new network lookups.
    Even if app is launched not from origibal web page. E.g. from desktop shortcut it created
  5) If we will cache given content in the cache. What URL we will use?
    Hopefully docbase & filename (need to make sure filename is always relative) =>
     it should not be possible to use this way to add arbitrary content to the cache for arbitrary URL.