Webstart Rant

General Discussions
#21

Seems to me the “scary message” makes Java quite impractical for distribution of my kind of game. Who, other than friends and relatives is going to click past that? Its kind of sad really, as there is an alternative. Back when I first started using Java, in 1997, one Java feature Sun was proclaiming was the “Sandbox Model”. This allowed users fairly fine grained control over what runs on their computer and how. Over the years, this feature has been quietly knocked on the head and buried, presumably at the insistence of the Enterprise market. In an alternate world, in which Sun was interested in the end user market, the Sandbox could have been marketed as a feature that makes running Java programs more secure than running other Windows programs. The default configuration for JWS could be to only read and write to its own folder. The “scary message” could be replaced by an upbeat one noting that, because you are running Java, your computer is much safer than if you were running a native Windows program. Can’t see that happening though.

I’ve been following the JWS discussion on this board for years. My conclusion is that if I want significant distribution for my game, I will have to get it rewritten in a language that is native to the Windows PC. I really like Java as a development environment. But as a distribution system for my kind of game, I think it very limited. I can see its usefulness in simple games that don’t require disk access. And in retail boxed games that carry their own Java install and just look like any other game to end users. But for my game, intended for net distribution but does need disk access, I don’t see Java as being practical. Sun is committed to the Enterprise market, not the end user one.

JWS, with its Enterprise orientation, is pretty much useless for mass market distribution. At best, it can help me reach a small “enthusiast” market for beta testing. And given the corporate orientation of Sun to Enterprise computing, I don’t really see that ever changing.

#22

Actually, JWS does exactly that, in the form of Muffins.

No, the problem here is that most of the people above want to change display modes, load native libraries etc, and no security model can keep a system safe if they’re allowed to do that. So it warns the user in no uncertain terms that they’re stumbling into dangerous territory.

#23

Which is all well and good and is great for us very very early adopters and Java developers who understand everything.

However for the average user the dialog is a disaster. They have not yet been educated in this matter yet, which is why Windows does not yet ask them to verify whether they want to install something or not yet (enforced code signing).

When in Rome, do as the Romans do. The whole security dialog should simply be removed if the code is properly signed and the OS ordinarily allows code to be installed.

Cas :slight_smile:

#24

Now there’s an interesting idea - only pose the question if the OS that WebStart is running on usually asks such questions.

But - alas! - users are stupid. They’ve only just learned not to run EXE files, so trying to get them to understand that JNLP needs care as well is taking things a bit far. And the fact that while running an EXE from the web requires confirmation, running a JNLP is just one convenient click makes them that much more dangerous.

As we used to say at an old workplace: “When determining the intelligence of your users, start at cabbage and work up”. Your average Internet Cabbage takes some time to get used to new things.

#25

As I tried to say before when the board kept complaining about message length, 1.5 changed the scary message from click yes to burn in hell and destroy your computer etc to do you want to trust this signed application distributed by Dan Kavanaugh

That’s probably too tame now, but what can I say, I’d much prefer this to the other.

Anyway, changing a display mode shouldn’t be regarded as being as dangerous as reading or writing to the disk (non-muffin) or of course, loading native libs. The malicious part of changing display modes is doing it rapidly for a long period of time which can cause damage to monitors (though presumably not any monitor sold in the last 10 years). Sun probably considers the idea that someone could mimic the entire screen of the computer it’s running on, and then ask for private information that looks like it’s coming from some trusted program (such as… maybe a prompt that looks like outlook express asking for username and password) and then send that information to some place else (the reason for the limitations on networking… not that I’ve ever found that limitation to be significant).

Muffins, while useful, are not gaurenteed to be in any way persistant, and the size of a muffin isn’t exactly gaurenteed either, you can request a larger size but jws or whatever the user has on their machine that handles jnlp files can arbitrarily deny a muffin be made larger than 1k for example. Also, working with muffins is pretty confusing, I don’t think the docs alone are enough, you pretty much have to find a working example, plus docs, plus a tutorial or two, and then you might get them working after a lot of time has been spent on it, but on the plus side, they can be used with a webstart app and not require a scary permission to make the information somewhat persistant. Another grip about muffins is of course, if you use them, you can’t run that application as anything but a muffin (because it includes classes that don’t exist for non-jws runs… unless you include dummy classes or something which still sucks).