The following topics are covered:
The JDK 7u45 release includes the following enhancements:
JAR file manifest attributes are available to enhance the security of running Java applets and applications in a browser. The Application-Name attribute provides a secure title for your RIA. The Application-Library-Allowable-Codebase identifies the locations from which your RIA can be started if the JNLP file or HTML page is in a different location than the JAR file. The Caller-Allowable-Codebase attribute identifies the locations from which JavaScript code can call methods in your RIA. See JAR File Manifest Attributes for Security for more information.
The Java Control Panel has an option for restoring the security prompts that were hidden when the option to not show the prompt again was selected. See the documentation for the Security tab of the Java Control Panel for more information.
The JDK 7u40 release includes the following enhancements:
For enterprises that provide a common execution environment and manage the applications that employees access, the Deployment Rule Set feature enables the creation of rules that allow some applications to be run without security prompts while automatically blocking other applications. This feature is intended to be used internally in an organization. See Deployment Rule Set for more information.
When a RIA is started, the JRE is checked to see if it is expired or below the security baseline. If so, the user is warned and given the opportunity to upgrade the JRE. For enterprises that manage the update process of user's systems, the deployment.expiration.check.enabled property can be set to suppress this check. See Deployment Configuration File and Properties for more information.
In addition, the Rich Internet Application Deployment Process section in this guide provides a look at how the deployment of RIAs is handled.
The JDK 7u25 release includes the following security enhancements:
Before Java applets and Java Web Start applications are run, the signing certificates are checked to ensure that one hasn't been revoked. Advanced options in the Java Control Panel can be set to manage if the checking is done and what services are used for making the checks. The default is now to check all certificates using both OCSP and CRLs. See the Perform Certificate Checks and Check for Certificate Revocation Using sections of the Java Control Panel documentation for more information.
Permissions and Codebase are new attributes for the JAR file manifest that are used to defend RIAs against unauthorized code repurposing. These attributes are used with signed JAR files for applets and Java Web Start applications. See Preventing a RIA from Being Repurposed for more information on these attributes. Steps 2 and 3 in the Deploying an Applet and Deploying a Java Web Start Application lessons in the Java Tutorial describe how to include these attributes in the manifest. In addition, the Security Dialogs section provides information on the prompts that are shown when a RIA is started, and Deployment Best Practices in the Java Tutorial provide suggestions for deploying your RIA.
This release includes the following security enhancements for running rich internet applications (RIAs), which are Java applets and Java Web Start applications:
RIAs prompt the user for permission to run the first time the RIA is launched. The prompt includes information on the certificate used to sign the application, the location of the application, and the level of access that the application requests. In most cases, users can turn off the prompts for future launches of the same application. See What should I do when I see a security prompt from Java? for a description of the prompts.
RIAs that are signed with a certificate issued by a recognized certificate authority require a single click by the user to run the application. Self-signed and unsigned applications require additional steps by the user before the application is launched. Therefore, for the best user experience, sign your RIAs with a trusted certificate before deploying to the end user. For information on signing JAR files, see Signing and Verifying JAR Files.
Depending on the security level set in the Java Control Panel and the user's version of the JRE, self-signed or unsigned applications might not be allowed to run. The default setting of High permits all but local applets to run on a secure JRE. If the user is running an insecure JRE, only applications that are signed with a certificate issued by a recognized certificate authority are allowed to run.
The Low and Custom settings are no longer available.
For more information, see the Security section of the Java Control Panel.
Sandbox applications (previously called "unsigned" or "untrusted" applications) are restricted to the security sandbox. Privileged applications (previously called "signed" applications) are provided unrestricted access to a user's system.
For Java Web Start applications, including applets that are launched using JNLP, the security element in the .jnlp file is used to set the level of access. If the element is not present, access is restricted to the sandbox. See Security in Rich Internet Applications for more information.
For applets that are not launched using JNLP, the permissions element is added to the applet or object element to set the level of access to either sandbox or all-permissions. See Deploying With the Applet Tag for more information.
Trusted-Library attribute. See Mixing Privileged Code and Sandbox Code for more information. The JDK 7u10 release includes the following enhancements:
For more information, see Setting the Level of Security for the Java Client and Java Control Panel.
This release includes Oracle's release of the JRE and JDK for the Mac. Here is related information:
This release introduces the following improvements for web-deployed applications:
Java SE includes JavaFX: JDK 7 Update 2 and later includes the JavaFX SDK. See JavaFX 2.0.2 Release Notes for more information.
Non-blocking installation of JRE and JavaFX using Deployment Toolkit: The web page continues to accept user input while Deployment Toolkit downloads and installs the required components. See 7052499 for details.
Reduced footprint of signed JAR files: This release provides a new signing method that enables you to sign a JAR file as one large object instead of signing every JAR entry individually. This saves up to 10% of the total JAR size. Note: Users must run JRE 7 Update 2 or later to be able to use these JARs. See 7049193 and the section Sign the JAR Files in Packaging (the information in this section also applies to Java SE).
Caching certificate details in the JNLP file for signed applications: For an application that uses security, a security dialog will present the cached certificates immediately for user approval while downloading the application in the background. An older JRE will ignore this functionality; it will present the certificate information after the application is downloaded. See 7049169 and the section Embed Signing Certificate into Deployment Descriptor in Packaging (the information in this section also applies to Java SE).
Caching enabled by default: Caching of network
content for application code running in Web Start mode is now
enabled by default. This allows application improved performance
and consistency with applet execution mode. To ensure the latest
copy of content is used, the application can use
URLConnection.setUseCaches(false) or request header
Cache-Control values
no-cache/no-store.
Embedded JNLP support for Web Start: The Deployment Toolkit can use a copy of a JNLP file embedded into a web page to launch an application. This helps to reduce number of network connections needed for the first start of a Web Start application from the browser. See 7052492 and the section Embed Deployment Descriptor into Web Page in Packaging (the information in this section also applies to Java SE).
Ability to pass secure JVM arguments to the Web Start application from inside the web page using Deployment Toolkit: This helps to avoid JVM relaunch due to JVM configuration mismatch and also helps to pass dynamic parameters from the web page. See 7072364 and the section Platform in Deployment in the Browser (the information in this section also applies to Java SE).
Improvements for handling content with gzip encoding: The deployment cache will keep application content in compressed form and return it to the application as-is with gzip content-encoding in the HTTP header. This makes behavior more consistent across different execution modes (first launch versus subsequent launch, cache enabled versus cache disabled). See 6575586 for more details.
Improved support for JNLP applications: JavaFX applications are more cleanly uninstalled; see 7085171 and 7053087. Recognition of JNLP install hints is improved; see 7046670.
Startup improvements: Startup has been improved for specific scenarios; see 7099086 and 7098160 for details.
New setting, Insecure JRE versions, in Java Control
Panel: If users have a version of Java on their system
that is below the security baseline, a warning message is displayed
before an application or an applet can be run using that version.
You can control this warning message with the Java Control Panel
Advanced tab setting, Insecure JRE versions, which
will set the property deployment.insecure.jres in the
deployment.properties file to one of the following
values:
Value of
deployment.insecure.jres property |
Value of Insecure JRE versions setting | Description |
|---|---|---|
NEVER |
Do not use insecure JRE versions | Untrusted content will always run with the default JRE. |
PROMPT |
Prompt user before using insecure JRE versions | Users will see warning dialogs; this is the default value. |
ALWAYS |
Allow using insecure JRE versions (not recommended) | Untrusted content will run with the requested JRE without any prompting. |
See Deployment
Configuration File and Properties for more information about
the deployment.properties file.
os attribute in the information
and resources elements can now contain specific
versions of Windows, such as Windows Vista or Windows 7.install attribute in the
shortcut element to specify their their desire to be
installed. Installed applications are not removed when the Java Web
Start cache is cleared, but can be explicitly removed using the
Java Control Panel.codebase attribute; see
Deploying Without CodebaseIn addition, the following enhancements are introduced:
Area: Deployment
Standard/Platform: JDK 7
Synopsis: Previously, the pack200 tool segmented
its output by default. As of this release, the pack200
tool will create one large segment per jar file. Therefore, if
deployers have jar files larger than the virtual memory available
on the end-user's systems, it is recommended that either the input
jar file be split, or suitably segmented by using the command-line
flag "--segment-limit=nnnnn" or the equivalent property
"SEGMENT_LIMIT".
RFE: 6575357
Area: Deployment
Standard/Platform: JDK 7
Synopsis: On Windows XP machines, the default cache
directory is now under $USER\Local Settings\Application
Data\Sun\Java\Deployment\cache. If needed, you may customize
it to point to a network share folder for a single application
cache across domain machines.
RFE: 7012538
Area: Deployment
Standard/Platform: JDK 7
Synopsis: The optional applet parameter,
jnlp_embedded, provides the option to cache JNLP content
on the HTML page and shortens applet launch time by skipping
network access. The jnlp_embedded parameter has as its
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, the jnlp_embedded parameter value replaces
the content of the JNLP value pointed to by the jn.p_href
parameter. The value of jnlp_ref is then optional and only
used as a backup when the content of jnlp_embedded is
invalid. There are a few restrictions on the embedded JNLP content:
Area: Deployment
Standard/Platform: JDK 7
Synopsis: As of JDK 7, clearing the cache works as
follows:
Area: JNLP Files
Standard/Platform: JDK 7
Synopsis: In order to support debugging of Java Web Start
applications, the -XX:HeapDumpOnOutOfMemoryError flag is
now supported in JNLP files for trusted applications.
RFE: 6664424
Area: JNLP Files
Standard/Platform: JDK 7
Synopsis: Previous versions of Java Web Start did not
correctly implement section 6.0.10 of the JNLP Specification. With
this fix, fine-grained values for the "os" attribute, such as
os="Windows\ XP", os="Windows\ Vista", and
os="Windows\ 7", will work as expected. Values such as
os="Win", and os="Windows" will continue to match
all Windows platforms. As of this release, os="Windows\ Vista
Windows\ 7" will only match Vista or Windows 7 and not Windows
XP.
RFE: 7014170
Area: Plugin
Standard/Platform: JDK 7
Synopsis: A message stating that the first generation of the
Java plugin is deprecated is now printed to the log file and to the
Java console whenever plugin 1 is used.
RFE: 7027792
Area: Plugin
Standard/Platform: JDK 7
Synopsis: On Windows, the tray icon is now disabled by
default. To enable the tray icon, use the Windows Start menu.
RFE: 6694710
Area: Plugin
Standard/Platform: JDK 7
Synopsis: The 64-bit toolkit is now supported on 64-bit
Windows platforms.
RFE: 6492139
Area: Plugin
Standard/Platform JDK 7
Synopsis: Previously, the persistence API provided only
temporary persistence for applets. When the VM exited, the data was
lost. Data can be persisted via any of the standard Java
mechanisms, through the use of LiveConnect to store data in the
page DOM, or using one of the JNLP services.
RFE: 6992419
Area: Plugin
Standard/Platform: JDK 7
Synopsis: Google Chrome is now supported by the DT
Plugin.
RFE: 6907245
