Talk:Java Web Start

	This article is within the scope of WikiProject Apple Inc., a collaborative effort to improve the coverage of Apple, Mac, iOS and related topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Apple Inc.Wikipedia:WikiProject Apple Inc.Template:WikiProject Apple Inc.Apple Inc. articles
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the project's importance scale.

current status

I wondered what is the current status of Java web start and JNLP. Googling around I saw many few implementations beside Sun's reference implementation. Most of them are dead projects (e.g. openJNLP, netx).

I think there should be a section describing the current status, relevance and usage percentage of JWS/JNLP around the world vs. alternatives (in Java and in other languages/environments).

A section with current and previous/dead JNLP implementation projects would also be a good think to have.

riddled with security bugs

Using the security vulnerability search here: nvd.nist.gov by entering search term: java "web start" it finds over 20 holes from past 3 years. The article says Microsoft's "clickonce" is the equivalent technology, however there's 0 holes found for that technology.

In another comparison the whole Java package "JRE" has 50+ hits where the MS equivalent ".NET framework" had considerably less hits in the same 3 year search window.

I would not have bothered doing this comparison but certain large international banks are now mandating that all web bank users need to install JRE "in the name of security" (possibly also web start with it, I cancelled my bank account rather than find out). Given that the MS equivalent technology "clickonce" already comes installed and cannot be removed with the computer it's quite unreasonable to ask users to open even larger attack surface that's already known to be riddled with holes by the way of installing this.

Sorry for going off topic but imagine if your bank suddenly required you to switch to Windows Vista to use them. This is the equivalent thing if you happen to use say a smart/mobile phone to do internet banking and JRE isn't available to the mobile phone. —Preceding unsigned comment added by 88.115.113.221 (talk) 14:20, 7 March 2008 (UTC)[reply]

Access permissions

The article lists some advantages over applets, but I was wondering if there are any disadvantages. Is it true, for example, that Java Web Start programs cannot run without the user giving permission? In contrast, applets (like Clesh should run automatically. Stephen B Streater 21:08, 5 March 2006 (UTC)[reply]

well testing with a java web start app i wrote (http://www.p10link.net/~plugwash/picsim.jnlp) it seems in firefox i get the "open with" dialog and in IE (xp but not sp2) it just opens immediately. I don't have XP SP2 handy to try it in. Plugwash 22:57, 5 March 2006 (UTC)[reply]

I ran your example Web Start program on my Mac (OS X) and it starts running without a problem. But if I try "save", it pops up a permissions box, and if I refuse, it doesn't save or load eg "load is not possible due to security restrictions". In other words, untrusted code does not have access to the file system.

There is an option which says, effectively, "always trust this code", but if I don't select this and trust the code, it never saves. I think your code can save because you have said to trust it. So, unless you can save something on my Mac without me trusting you, I suggest we change the words in the Java applet entry "from untrusted code" to "from trusted code". Stephen B Streater 02:34, 6 March 2006 (UTC)[reply]

No the apps code is still running untrusted, allowing a java web start app access to a single file is like uploading a single file for a website. the website is still untrusted even though you let it have a specific file. Plugwash 13:24, 6 March 2006 (UTC)[reply]

There is a difference, though I can see that it may be more a difference in quantity than quality. I'll explain what I mean. If you go to the Clesh guest account, you run an applet where you can "save" data or "load" it (in fact it is stored on our server). In practice, no dialog box comes up asking for permission, and you don't have to trust me to load and save - or at all in fact.

With your example, following your explanation, I know enough about Web Start to know that I don't have to trust you very much to save a file - a malicious application could eventually fill my disc and stop my machine working though. Before your explanation, I just said "No" to the big scary box. So I can see that, technically, I don't have to trust you very much (if I have perfect knowledge about Java Web Start and how it works), but in practice, a normal web user who didn't trust you may not use this feature just in case it was dangerous.

I see the applet version is qualitatively similar because a user still in principle has to know that Java applets are safe, but it is quantitavely different because his machine will be configured by default to work in the applet case but not the the Web Start case. So if the Clesh guest account were to run in Java Web Start and save to the local disc, lots of people would refuse to use it (or not be allowed to by their company IT department guidelines).

So in conclusion: if the question is whether disc access requires trust, given that a Web Start program could fill the disc and break my computer, if I don't trust it at all, I shouldn't allow it disc access. However, not much trust is required, though typical users may not know this. The default configuration of popping up a scary box makes a lot of difference in practice. The applet requires no trust. I think this difference should be reflected in some way, though if the only thing a malicious program can do is write a big file, this should also be reflected. Stephen B Streater 14:34, 6 March 2006 (UTC)[reply]