Talk:Java Web Start

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. —Preceding unsigned comment added by 212.179.92.170 (talk) 12:01, 26 October 2008 (UTC)

It's not even clear whether Sun currently supports it or not. On Sun's webpage they say you get javaws as part of JRE 5.0, but then if you actually install JRE 5.0 you'll see there is no javaws. —Preceding unsigned comment added by 72.196.244.178 (talk) 20:05, 8 April 2009 (UTC)

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)

True hacker never uses Internet banking of any kind, he just knows too much. Please stop flaming, seems already fully off topic Audriusa (talk) 08:57, 7 September 2011 (UTC).

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)

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)

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)

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)

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)

Who's Idea of a 'good suggestion' for permissions is in the article? Because its a very poor idea for anything more complicated than a text editor. The proposed solution is worse than self allowed permissions (Cancel or Allow, anyone?). My _opinion_ would be permission groups, perhaps intersecting with resource groups. Removed hearsay with bad system design. --ebola —Preceding unsigned comment added by 81.105.114.102 (talk) 21:57, 11 January 2010 (UTC)

If the application asks for additional (or even all) permissions in its JNLP file, it will not run unless signed or self-signed. If it is self-signed, a horrible warning will be shown. No warning should be shown if no permissions are requested but then the application cannot do much more than applet. Audriusa (talk) 09:01, 7 September 2011 (UTC)

External Links broken

A few of the external links are broken (could it have to do with sun being acquired by oracle?). I have no idea where the real pages are, but perhaps someone else does. If so please fix the links! 75.40.251.51 (talk) 18:49, 27 March 2011 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Java Web Start. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080705171823/http://today.java.net/pub/a/today/2005/08/11/webstart.html to http://today.java.net/pub/a/today/2005/08/11/webstart.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 23:16, 22 November 2017 (UTC)