JDK-6504236 : Implement IE Broker process for File I/O on Vista
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 6,6u1
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_xp,windows_vista
  • CPU: x86
  • Submitted: 2006-12-13
  • Updated: 2010-05-10
  • Resolved: 2007-11-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6u10Resolved
Related Reports
Duplicate :  
JDK-6622332 - Initial integration of new Java Plug-In
Duplicate :  
JDK-6559445 - Java applets do not work with IE7 "Protect mode ON" on windows Vista.
Relates :  
JDK-6548078 - The Java Security Model is broken on Windows Vista with IE7 Protected Mode
Description
FULL PRODUCT VERSION :
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.0.6000]
i.e. Vista

A DESCRIPTION OF THE PROBLEM :
The current Mustang release note (http://java.sun.com/javase/6/webnotes/index.html) claims that:

"On a Windows OS other than Windows Vista, when running a signed applet, a user is prompted with a security warning dialog box and must respond. If "Yes" is clicked, the applet will have AllPermissions to run on the user's machine. This includes permission to write/delete a file from the local disk.

On a Windows Vista OS, this is no longer true. Instead, AllPermissions is limited to Java Applet scope, not Windows scope. Because a process running in IE has a low integrity level, it will not be able to write/delete a file from a medium/high integrity level directory. "

This is true, but there is a well documented design to allow IE add-ins access the file system from the user's normal (Medium) Integrity level, rather the IE's Low Integrity level: implement an Internet Explorer Broker Process. E.g. Adobe Flash do this (http://blogs.msdn.com/ie/archive/2006/11/17/flash-player-9-update.aspx). Sun need to implement such a process for the IE Java plugin. Without it, Sun's implementation of file access (particularly via the AWT FileDialog) is unusable for ordinary users.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a signed Java applet that accesses the file system outside IE's virtualized file system (e.g. access a file in c:\users\<user name>). Either load, or save a file to this directory. The broker process should be used to access the file, so that the file access works - the current Java plugin lacks this, so the file access is constrained to the IE Low Integrity, which does not have write access to this directory.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Signed Java applets should be able to access all files that a Medium Integrity process can access, rather than just files that IE's Low Integrity process can. Note that this also applies to the AWT FileDialog and Swing file chooser dialogs.

REPRODUCIBILITY :
This bug can be reproduced always.
Comments
EVALUATION Once the latest JRE 6u10 binary is installed (from http://www.java.net/download/jdk6/6u10/) - the new "plugin2" architecture has to be enabled via the Java Control Panel. This is done by: * Launching the java control panel from the windows control panel * Clicking on the advanced tab * Expanding the "Java Plug-in" tree * And enabling the "next Generation Java Plugin" checkbox A browser restart is also then required. I've just verified that a new separate java process is started outside the IE process when an applet is launched and others have reported that this new plugin does solve the issues of signed applets not being able to write locally on vista systems.
09-01-2008
EVALUATION A new implementation of the Java Plug-In has been developed which changes the execution model of applets. Instead of running the applets in a JVM embedded in the web browser's process, they are now run in a separate JVM process which communicates back to the web browser. This work was checked in under 6622332. We have received confirmation from outside customers that the new plug-in solves the fundamental problems of running signed applets on Windows Vista. There are certainly still bugs to be fixed in the new plug-in to attain close to 100% compatibility with existing content, but the main problem has been solved. As of this writing the new Java Plug-In is not yet the default, but will at least ship side-by-side with the current one in the forthcoming "6uN" release, for which early access builds can be found at https://jdk6.dev.java.net/6uNea.html . The new plug-in will be initially available in the forthcoming build 08 barring unforseen circumstances. Closing this bug as a duplicate of 6622332. Once the new plug-in is available, please try it and file any issues against it under product java, category java_plugin, subcategory plugin2.
08-11-2007
WORK AROUND To workaround this on Vista, applet can write to the locallow directory instead: user.home + \appdata\locallow This should work for both Firefox and IE 7 on Vista. But then if Microsoft decides to change the locallow folder location later, then this will break. Or you can use java.io.tmpdir, which will return the user's temp\low directory. But this is a temporary directory of windows, and we have no control over when will the files get clean up.
16-02-2007