The following issues with deployment on Vista apply to JRE 1.6.0_05 and prior releases.
-
More Restrictive Sandbox for Signed Applets
If you run a signed applet on a Windows OS other than Vista,
you are prompted with a security warning dialog box and will need to
specify an action. If you click on "Yes", the applet will have AllPermission to run on your machine;
this includes permission to write/delete a file from local disk.
On Windows Vista OS, this is no longer true. Instead, AllPermission
is limited to Java Applet scope. Because the process running in IE has a low integrity level,
it won't be able to write/delete a file from a medium/high integrity level directory.
A signed applet running on Windows Vista has limited file access privileges compared to an applet
running on another Windows OS.
-
Signed JNLP Application Runs with Medium Integrity Level Only
Granting AllPermission in a Java Web Start application only permits the Security Manager to allow
operations that it would otherwise deny by throwing SecurityExceptions.
It does not in any way elevate the permissions the user or the process have on the system.
A normal (non-admin) user would typically only be able to read and write files within his own home directory
(unless other directories are specifically created to allow permissions to all users.)
-
User Experience Changes for HTTPS Connections on Windows Vista OS
On Windows Vista, several new behaviors were introduced in the areas of security and user experience for
HTTPS connections; they are:
-
HTTPS Certificate
IE7 blocks navigation to HTTPS sites that present a digital certificate that has any of the following problems:
-
Certificate was issued to a hostname other than the current URL's hostname.
-
Certificate was issued by an untrusted root.
-
Certificate is expired.
-
Certificate is revoked.
Upon encountering a certificate problem, IE7 presents an error page that explains the problem with the
digital certificate. You may choose to ignore the warning and proceed in spite of the certificate error
(unless the certificate was revoked). If you click through a certificate error page, the address bar
flood fills with red to serve as a persistent notification of the problem.
-
Mixed-Content Prompt
You will no longer see the so-called Mixed-Content prompt, which read:
This page contains both secure and nonsecure items. Do you want to see the nonsecure items?
Instead, IE7 renders only the secure content and offers the user the opportunity to unblock the nonsecure
content using the Information Bar.
-
New Default Protocol Mode
In IE7 on Windows Vista, the default HTTPS protocol setting is changed to disable the weaker
SSLv2 protocol and to enable the stronger TLSv1 protocol.
With the above changes in IE7 on Windows Vista, the user of our (Sun Microsystems Inc.)
Java Plug-in will see different behavior when running their applet.
-
Control Panel has Java Web Start AutoDownload of JREs Disabled
Since the posted autodl bundles cannot run on Vista (without being re-written, and re-staged for all releases),
the autodl feature is turned off by default, and the entry is disabled in the advanced tab of the Control Panel.
-
Control Panel has the Change Cache Location Dialog Disabled
Since the cache location must be set to a low-integrity directory,
changing it is disabled in the control panel.
-
Java Plug-in Extension Installer Mechanism May Fail for Non-Administrator Users Running in IE
The extension install mechanism added to Plug-in in 1.4.2 uses Runtime.exec() to run a java extension
installer (running "java -jar file"), or to run a native extension (running "file").
Normally these installers do things like write files to the lib/ext directory of the jre.
These processes will run with the same limited privileges the user has,
so may fail when (for example) writing a file where the user has no permission to write.
This problem would also apply to any Java Web Start application that attempts to install an extension
in lib/ext (though this is not a common practice).
