Issue doc: http://www.sandrasf.com/other/sandra/files/sec.rtf
How can we address best to solve it?
this is a great post from Sun about Java.
Even if you guys don't succeed, it's good that your try now, this is new from lets ignore them.
The main issue is for our end users what their Java experience is. (We the developers know about security and installation, but PLEASE lets understand that our end users do not have a CS degree and mainly, that they should not have to). Webstart is great, but it's 90% there for last 4 years.
#1 Main issue is wordsmithing the words in the applications that are signed by vendors that are approved. Some native english speakers should read the "warrning" screen, and say something like: "This autheticated Vendor has signed this application to be safe, PLEASE install the Java app". That should encourage the user to deploy the Java application.
This wordsmithing is not an API change, just a text change, that MUST make it to Java 1.5.x; We can't wait to develop applications after Mustang is widley distributed in 2008.
I do not see nothing but middle managment red tape to stop this, someone has to care.
Other minor issues:
- make it more like Flash install.
- make sure there are no other java versions on machine (some users have 10 jvm's there)
- in order to reduce the # of JVM's, get a list of top ten java deployed apps( Limewire, Azarus, etc.) and work w/ vendors to use WebStart and not install a JRE w/ each application. Current best practice is to ship a native JRE exe w/ your app.
- make it easy to deploy Java to a corporate Windows users (in a corp, the end user does not have domain admin rights to install software. Flash isntalls but not JRE).
In Summary, it's great that Sun now has a usability person that has a job of caring about how end users experience Java apps. That makes it good to be a Java developer.
I completely agree with you, that the implementation and experience of Flash should be the 'thing to beat'.
IMO, Flash is pretty amazing, in all respects of the end-user experience:
* Font handling
* Attractively-designed components
* Speed of applet launching
And, IMO, these are areas that Java (either Applet/Swing or JWS is relatively weaker. Cumulatively, I believe these issues dissuade developers from implementing in Java.
> Please also do something about the "Java Application
> Window" message that is placed at the bottom of every
FYI they have provided a workaround in Java 5 where you can enable/disable the message. F.E. this screenshot shows an application running in the sandbox using Java 5 but it does not show the message:
> FYI they have provided a workaround in Java 5 where
> you can enable/disable the message. F.E. this
> screenshot shows an application running in the
> sandbox using Java 5 but it does not show the
Any idea what the workaround is? How do we make use of it?
Sure, fire up javaws, then:
Edit->Preferences->Advanced (Show sandbox warning banner)
Signed applications are far more dangerous than unsigned. Shouldn't it be those signed windows with the uglification?
> Signed applications are far more dangerous than
> unsigned. Shouldn't it be those signed windows with
> the uglification?
The current rationale seems to be: "We place the warning there so a hacker can't fake OS security dialogs.".
I feel this isn't correct but at the moment I seem unable to word a counter properly. I challenge the Java community to find the problem with the logic. With a successful counter argument I suspect the offending uglification would be removed.
Any and all stabs at this are most welcome.
I whole-heartedly agree. There is enormous potential in Java Web Start but sadly it was 90% finished 4 years ago and only a small amount of polish has been done to it since. Features critical to the success of JWS have been put off indefinately as Sun continues to completely misunderstand and ignore the requirements of real-world developers who are trying to make a living by creating Java desktop clients.
IMHO Sun will continue on this path indefinately until the feedback cycle is fixed. Comments from developers enter a one-way communication channel and we never know if Sun thinks an idea is good, bad, or even read or even understood. The feedback cycle is absolutely critical but Sun needs to learn that feedback is a form of communication and communication only works when it is 2-way.
A great example of how the feedback cycle should work is the Sun JDNC project. Java Web Start development (and all Sun development) should follow this model.
Applets once ran in the sandbox without ugly/frightening warnings, except versioning was a nightmare because it was the browser's cacheing decision, and it was never clear which VM version was out there. Webstart is a great alternative to applets, but it should show users nothing more than a nice progress bar while downloading things, instead of enumerating all the jar names and popping up several times.
Unsigned webstart apps are just like applets in that they're sandboxed, but the phishing issue is that they appear to be native windows (that's sort of what we wanted with Swing, right?). Perhaps the unsigned webstart apps should contain text that indicates the URL where they came from instead of "Java application window" (cause for concern??) or "Untrusted window" (read: undesired popup) or something like that. To the user it would be obvious that the window wasn't native.
As far as I can tell, THIS IS NOW FIXED in 6.0.
Only... please lets fix it in 1.5.x, it's just a string.
I'm Mike, the User Experience Lead for J2SE.
As Stanley mentioned, we have aggressive schedules to improve the user experience for JNLP-powered applications. The two biggest problems are the splash screen and the security dialog boxes. We have changed the way the default splash screens work to be more professional (although I would HIGHLY encourage you to provide your own custom splash screen graphic). We have a whole new visual architecture for the security dialog boxes. The goals for this redesign are to reduce the number of dialogs, help the end user focus of the important security issues, and make the whole experience less alarming.
As all of you know, the overall issue of "how do we get the JRE installed on end user's machines" is a vastly complicated problem. From Java Web Start to Java Plug-in to the installers to Java Update to the Java Control Panel, there is a lot of technology here. Our goal is to coordinate the user experience for all of these technologies. End users should be focused on the solutions your applications provide and not on the plumbing we provide. The feedback you give us (like this thread) help us (individual engineers, designers, and management) understand your pain points and help drive solutions into J2SE.
I don't keep track of individual build #s but some of these enhancements are rolling into Mustang now. I'd encourage you to download a new build every couple weeks or every month and try your JNLP app against it. See how the new experience is. Take screen shots. Send us more feedback. Investigate the custom things you can add to your JNLP app to make it more polished and professional (like custom splash screens).
Thanks. There are people who, like you, care about the Java desktop technologies. Keep making noise.
wrt dialog boxes, I think an important one is missing: notify the user the program is asking for 'read' permission when code asks to open a file for reading.
often I just want to read some user specified file, it's bad to ask the user to grant read and write access when only read is required. The user thinks, "I don't want the app to modify my file, just read it. Why am I granting write access?".
Can you at least do the textsmithing?
You should not isntall this vendors application"
This vendors is autheticated "
Do you want me to write it up?
Any news on fixing the bug in 1.5 (and 1.4)?
That should be the priority.
What is Sun doing about this in the last few years?
Is desktop Java a step child? How about it UI people.
I have asked Mike Albers (J2SE UI expert) to comment on the dialog.
Stanley may have more thoughts on the webstart security implications.
I have alerted him to your post as well.
Hi Bino :)
+1 for focusing on Java Webstart issues before all others. Desktop user experience is the #1 concern for my company/product.
I am confident you guys can do it. After seeing all the great stuff in JDK 1.5 I am confident you can do the same for Webstart within the next couple of months. Please understand that there are a lot of fixes that you can (and should) include before Mustang that do not require any API changes.
Please also do something about the "Java Application Window" message that is placed at the bottom of every window. This is very ugly, especially in dialogs and popup windows. It is even worse on Unix/Linux because the window appears near the top of the window - very very very very ugly.
This problem really makes it impossible to use webstart applications with the sandbox security model (does not have "all security" rights), because granting the application "all security" is the only way to get rid of the ugly message. This in many cases drives people to having to grant all security rights to the application and in turn people get the "scarry screens" in situations where they would not have to.
I understand the reason for the "Java Application WIndow" message (so user is'nt spoofed) but why can't you do like browsers and append the "Java Application" message in the title bar. And if the window is borderless only then place it at the bottom of the window or something of the kind.
Please address this issue.
IMHO, there should be in the middle of unrestricted and restricted a "declarative" level.
This mode should require the JAR to be signed with valid certificate (self-signing should not be allowed) not grant any of the unrestricted access and limit by default to the restricted (sandbox) permissions as define by the JNLP spec. IF you need a specific Permission in this mode, you will define this in your JNLP xml file giving all the details of the permission : class name, parameters... (for instance if you need an HTTP access to the network, then the URL you will access).
At the end the JNLP file will hold a declarative list of all the required extra permission and with the parameters.
This is also the same for the extension files.
In the JNLP manager (the webstart launcher for instance) , there should be a list of known pattern (permission and expected parameters) with an associated threat level in each categories (.
For instance accessing to a local file is a bigger threat than accessing to the machine in the user perspective.
When launching an application the launcher will sum up all the threat in each category and present a clear mitigation to the user.
If the user agrees, then the security Manager should grant all the required Permission (and prevent non-required permission) !
Doing so, you will never be constraint to request a unrestricted access just for opening a HTTP GET to a server that is not your source server, for instance.
Please tell me what you think of this idea : "declarative permission granting" ?
There have been so many detailed explanations of severe problems with Java Web Start. It is bewildering why Sun doesn't understand how important this issue is, for the reason that are stated in the above mentioned request.
If we want to do well on the desktop, then there is no other way but than to provide a reliable and usable means for installing software. It is so elementary, that it boggles the mind why this is not being addressed.
It is sooooo much more important than many of the exotic improvements in 1.5 / 5.0. The very survival of Java as a desktop platform is at stake. I would conclude that Sun doesn't care about the desktop, except that at Java One, many senior keynoters went on and on about how strategically important this is to Sun's future.
www.salas.com / www.blogbridge.com
Thanks for the feedbacks.
User experience in Java Web Start has been one of the hot areas that we have received many feedbacks over the last year or so. Currently, we plan to work with UE to simplify the user experience (reduce # of screens/dialogs, remove scary wordings, etc.) in Java Web Start in Mustang, and hopefully the concerns you brought up would be addressed.
J2SE Deployment Team
Any chance that it be in 1.5.2 or 1.4.3 or similar?
> Any chance that it be in 1.5.2 or 1.4.3 or similar?
Since it probably will involve a lot of changes, it will be in Mustang (6.0) first. Backporting to 5.0 update or 1.4.2 update releases are still possible, but it is too early in the development cycle for us to commit at this point. We should have a better picture to determine if backporting is possible, once we finish the changes in Mustang.
I want to keep this thread updated with all information, hopefully people find it helpful.
There appears to be a activity at Sun to address this issue. (THANKS Stanley!!!!!!!!!!)
I hope it continues to a successful solution. We are all very pleased and wait for a solution. Please keep us up to date.
1. In order to work the proper channels, I opened a bug issue:
(It will take a few days for it to activate online but by end of week). We will be able to vote for the bug and track the bug.
2. Someone stated that this issue is a about a year old. I agree w/ people that say that is’s several years old (http://lopica.sourceforge.net/faq.html )
3. I agree w/ people in this thread that JDNC is a big success (with a an enormous potential that just won’t be derailed) . The reason I underline that is that top management at Sun say that Client Side Java on Desktop is key strategy to implement at Java One. And the users are clamoring for it.
But the execution of low level management and engineers appears to make it a low priority up to this thread, in their day to day tasks. So my suggested solution is an organizational one. I suggest that JNLP resources be moved under JDNC project and management. That would increase communication for all IMO, and better leverage resources and accelerate a satisfactory execution.
4. I agree that the solution appears to not involve changes to Api or spec. One example solution is the NetX JNLP.
Ex: java -jar netx.jar -jnlp http://host/webappfolder/my.jnlp
This does not display the security box at all. While not ideal, it does show that it can be done within current Api.
5. In general, I agree that it takes about 2 years for a JRE version to be come widely distributed. So a solution that ONLY addresses 1.6 (Mustag) and beyond is not acceptable. By my estimates, if Mustang gets released in ’06, that means our end users can will have a good distribution by ’08 and we the Client/Dekstop Java application developers can start deploying it in ’09. Clearly a problem of executing the direction of top management at Sun and what users want, for an additional few years. The solution has to address with at least hacked workaround or a partial fix for at least “1.5.2” (and maybe even for “1.4.4”). Something has to be done to at least in 1.5.x to display a less scary or redundant message or even possibly consolidate the dual splash screens. This is only for people that have registered to have a commercially signed and approved certificate. See, no Api; only JRE changes. Telling somone “it’s a technical issue” that they can’t grasp is not good IMO. Top management at Sun is smart and so are Java application developers and even most end users.
6. Lets look at competing Run Time that is not scary to deploy, to learn from them. I think it’s the only cross platform Run Time competing. We application developers have to follow the end users platforms.
a. http://www.macromedia.com/software/player_census/flashplayer - flash Run time has almost 100%, and Java is 2nd. **
b. Flash Run Time version 8 (code name Malestorm) will be much faster. (A big advantage of Java now is that is’ much faster). http://www.moock.org/blog/archives/000146.html
c. MacroMedia is able to execute on goals of easing deployment to maintain market share. http://www.macromedia.com/devnet/logged_in/fsharples_detectionkit.html or http://www.macromedia.com/devnet/logged_in/fsharples_detectionkit.html
d. Because of c, they have many, many products for developers.
** Java deployment should ideally match it’s ease of deployment or come close to it.
OT: There may be other things preventing client/Desktop Java deployment. That is why I think JNLP under JDNC would help. For example http://lopica.sourceforge.net/faq.html#winadmininstall. Our applications run in corporations. Which makes a lot our end users have a PC given to them by a Windows admin, that gave them no privilege to deploy an application. W/ a Flex/Laszlo application, they can install it. JDNC would be harder. Sun has to be able to reproduce this expensive environment (Windows Network Server + end user station). Compare user experience of launching a Flex application on a “clean” station. Then do the same with JDNC. If it requires that the IT department has to approve the application, that takes months to get to happen and is expensive. This is “sales prevention”.
We need the patch in at least 1.5.x regardless of the effort required. We agree w/ top management that it’s a priority. We hope that the rest of the organization understands that it’s a priority in their day to day tasks. It’s critical to survival vs growth IMO.
From the application developers, we thank Sun for the attention. I know we can build better applications in Java then Flex/Laslzo!
The sooner it gets solved, the sooner we can start displacing Flash on the Client/Desktop and taking their revenue.... we have a better product!
Please joins to lobby:
Is anyone from usability going to be there?
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.