I wonder if there's any possibility we could have a programme where by Sun endorse specific libraries with a certificate that would allow said libraries to be used without having to sign code?

What I'm getting at is, it would be a great boon to LWJGL and JOGL developers to not have to sign their applets and therefore not introduce the (still-scary) security warning before running an applet that relies on such libraries.

What I'm getting at is, it would be a great boon to LWJGL and JOGL developers to not have to sign their applets and therefore not introduce the (still-scary) security warning before running an applet that relies on such libraries.

(sidenote: you don't have to sign JOGL applets, JOGL is available as an already signed extension)

Yes, that would be a improvement for java casual gaming. Nice loading screen and it would be leveled playing field with flash . Sun don't care too much about web games, but that is a great idea and won't cost sun any money, so it should be really easy to make a great improvement. I would say that slick2d would be nice to include as well.

sun signes the JOGL distribution with a certificate which is AFAIK on the whitelist of trusted certificates by default (I am not 100% sure but I can't remember that i added sun to the list).Just start one of the jogl demos or the gears applet (https://jogl-demos.dev.java.net/) you shouldn't get a certificate warning dialog.

Anything within the JRE is automatically OK. JOGL is not part of JRE.Despite JOGL being signed by Sun, it is still just a 3rd party application in the view of the JRE - and rightly so.

If Sun did have a certificate to sign jre-external applications with, that gets automatically signed, then that same certificate should be available to other providers than Sun - otherwise Sun gains an unfair advantage.This however implies that Sun guarantees that this 3rd party application does not contain malicious code. Something I don't think that Sun ever will unless they handle the entire code base.

Am I the only one who things this security warning is a good idea and boosts the trust in applets and the java platform as a whole? Actually I start to shiver thinking about what the various other browser plugins are allowed to without even asking for...

Well the security thing's a great idea but there's some rather common APIs that really don't need it. Like JOGL and LWJGL for example. They just do 3D rendering. Sun could take a release, pore of the source a little, and slap a cert over it to make it effectively another optional part of the JRE like Swing etc. in Update 10.

Am I the only one who things this security warning is a good idea and boosts the trust in applets and the java platform as a whole? Actually I start to shiver thinking about what the various other browser plugins are allowed to without even asking for...

Well, I certainly don't agree - in fact, seeing a certificate that is signed by "sun microsystems, inc." (yes, in freaking lowercase!!!) makes me all but certain that the thing is untrustworthy, because if Sun made Java, and Sun made this plugin, why the hell would it need to ask my permission to do something? Add to that the fact that the simple use of my graphics card is not the type of high risk operation that should require any sort of manual permission to be given. Which, of course, is irrelevant, since the security model in Java is such that there's no way to fine-grain any sort of permissions to services (compare to, say, the Flash plug-in, which lets you allocate an applet a customizable amount of disk space, and decide specifically whether you want to give it microphone and camera access; and which, btw, in version 10, adds accelerated 3d graphics support to the player with - you guessed it - no warning at all, which is totally 100% reasonable and right).

Nobody should trust applets, ever, unless they specifically trust the people that made them, which for games is not generally going to be the case. To me, the idea that people should need to give 100% pwnage access to their computer in order for the game to get access to accelerated graphics is ridiculous, and goes against the entire idea of computer security; even if they're just giving the OpenGL plugin access, they still should not be trained to click "Trust" whenever they play some random game. And as we know from what's happened with Vista, people do get into the habit of just allowing everything when they're forced to do it too often, to the point where if there's an option, they'll turn off the checks altogether.

In other words, I am fiercely in favor of Cas' suggestion, I think it would significantly improve the user experience of Java games, and would leave trust dialogues to what should be their original purpose - pop up something when an application needs some unusual level of access to your computer, not when it just needs to draw some polygons.

Well, I certainly don't agree - in fact, seeing a certificate that is signed by "sun microsystems, inc." (yes, in freaking lowercase!!!) makes me all but certain that the thing is untrustworthy, because if Sun made Java, and Sun made this plugin, why the hell would it need to ask my permission to do something? ..

Remember doing 3d still involves graphics drivers and it is still possible to get a blue screen on some OSes under certain conditions. This has nothing to do with the quality of the 3d lib which does the native binding and even can change over time. Putting signed 3d libs on the whitelist is like trusting all current and future driver implementations.

why not doing a little bit lobby work and sign all graphics libraries with the same certificate? (aka signed by 3d Graphics Community) This would reduce the number of certificates the user would have to sign in his lifespan but would also increase the probability that he has to sign two certificates in the first app he launches.

a) it doesn't solve the issue - it just decreases the issue, but it will happen at least once for a userb) the signing entity would have to guarantee the validity of all code bases ? - at least thats whats implied by a cert.c) a *company* needs to be the signing entity

Remember doing 3d still involves graphics drivers and it is still possible to get a blue screen on some OSes under certain conditions. This has nothing to do with the quality of the 3d lib which does the native binding and even can change over time. Putting signed 3d libs on the whitelist is like trusting all current and future driver implementations.

IMO, this is a risk you're signing on for any time you open a game. And if Flash is doing it anyways, Java can easily get away with it, since everyone will be assailed by sites and Flash ads that use their 3d drivers on a daily basis anyhow. Might as well follow along in Flash's wake is what I'm thinking... The upshot is that if people have drivers that are really so bad that they are BSOD-ing their computers, they'll need to be fixed ASAP or these people won't even be able to go to Youtube without a crash. But again, this is going to happen with or without Java deciding to do it, so we might as well reap some of the benefits, no?

Unless maybe there's something different about the way Flash is doing accelerated graphics that somehow makes it more safe? I don't see how that's possible, but...

I would like to also point out that this is not specifically in the realm of 3D drivers, which, btw, almost never ever bluescreen (in fact I haven't seen a BSOD for several years now). It's a way for Sun to extend Java's functionality with endorsed 3rd party extensions and allow developers to access these extensions to Java without having to grant all privileges just do to it.

In the time it takes Sun to come up with a great big new API for this and that, trundling as it does through the preposterous tedium of a JSR, companies like Adobe just say, hm, this is what we need to make Flash loads better, let's put it in the next release. Which is why Flash now dominates video delivery and shortly, 3D in the browser.

I have to admit I haven't yet took a look flash but something tells me that you won't have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.

BUT I never said hardware acceleration is not possible or risky in general (see Direct3d/OpenGL java2d pipeline or JavaFX with hw accel backend). If its an implementation detail everything is ok but libraries which bind-java-to-native-code-outside-the-control-of-the-java-community break still the sandbox and the user should be notified.

my 2c...

And don't forget, Sun is still a server && enterprise company possible security exploits in java would harm sun far more than security problems in adobe's flash.

I have to admit I haven't yet took a look flash but something tells me that you won't have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.

Ok, I looked into it a bit, and Flash's 3d support is, indeed, very limited; it sounds like it's just able to apply perspective correction to textured triangles, and this may be hardware accelerated, but they don't have a full 3d engine. So you're right, no direct OpenGL API or anything like that.

I still don't think I agree, though, that providing OpenGL access would open up a security hole. Is there something I don't know about JOGL's API that would permit system pwnage? I've never heard of an exploit like that before.

Quote

BUT I never said hardware acceleration is not possible or risky in general (see Direct3d/OpenGL java2d pipeline or JavaFX with hw accel backend). If its an implementation detail everything is ok but libraries which bind-java-to-native-code-outside-the-control-of-the-java-community break still the sandbox and the user should be notified.

I guess I'm not entirely sure what you mean here. To me, a Java wrapper around OpenGL does turn the underlying native code into an implementation detail. That's kind of the point of OpenGL, to expose a useful graphics API without forcing you to interface directly with the graphics card. I don't see any need to break out of the sandbox for that, especially if the native code at the interface is controlled by Sun (which it is, if we're talking about JOGL).

We may just be arguing different points here, I'm not sure. I agree with Cas, I don't see any conceivable security hole in exposing the OpenGL API, there's no route that I know of that allows an OpenGL call to do anything bad to your computer (modulo, of course, a real devious bug in the driver code that accesses the graphics card, which is a totally different issue that shouldn't be Sun's concern at all, since it would be someone else's bug).

At the risk of repeating myself: to force a complete break from the sandbox to achieve something that should be possible from within it is bad bad bad security practice. Without a finer grained security mechanism (which would be all but impossible to phase in at this point in Java's evolution), the best solution is to directly allow access, even if only in limited form, to the safe bits of functionality that are most commonly used.

You could look at the argument this way: if LWJGL isn't safe, is Java2D?

Cas

that boils down to "Did we or someone else build it"

Security is only a part of the picture of "does it work?" I'm sure you could find a pragmatic solution to keeping everyone happy. Like having the user select a level of paranoia(PR-department needs to come up with a better word ) High/Strict - as it is now or medium/Lose - that adds a default list of certificates to the trusted list.

Seems to work for most consumer targeted firewall software...

The advantage of going this route is that you don't get a split between JVM implementations/distributions between ones that do and do not endorse.

I still don't think I agree, though, that providing OpenGL access would open up a security hole. Is there something I don't know about JOGL's API that would permit system pwnage? I've never heard of an exploit like that before.

hum, I guess probably tens.... even being able to switch fullscreen without user agreement could be considered as a security hole. even if it is far to be perfect, browser security have been improved a lot year by year by learning what can annoy the user, in a normal security you should not be able to :- switch fullscreen- control mouse- use too much ressource memory/cpu- open multiple window- produce error by sending wrong instruction to device (can happen when enabling low level devide access)- disable browser close- produce fake screen/window => undecorated window- change target of a drop (ex : moving a window when mouse up after a drag)- etc... etc...

in short , most cool stuff can appear as security hole depending on how coder use it.

Quote

I have to admit I haven't yet took a look flash but something tells me that you won't have direct access to apis like OpenGL - if yes sorry but than Flash is the next ActiveX which was almost a synonym for maleware.

probably you will be able soon to get access to a secured interface to perform hardware accelerated stuff but this doesn't sound flash like to directly program opengl, but it will (it already..) use HW for 3D as for 2D in a secure (not direct) maner for sure.

Fullscreen is a privileged action currently but I notice that Flash doesn't ask permission to go fullscreen. But it's not part of the OpenGL bindings anyway.

All I'm saying is, if the source is submitted to Sun, they could give it a thorough security check and then endorse it by signing with a certificate which allows the JVM to load it without any security warnings popping up. As if they'd basically written the code themselves and made it part of the JRE. For something as simple as LWJGL it should be a doddle.

Fullscreen is a privileged action currently but I notice that Flash doesn't ask permission to go fullscreen. But it's not part of the OpenGL bindings anyway.

yup seems it dont, also severals plugins dont too, but IMHO it should be requiered because if no, you can produce some kind of "phishing" application : fake window/linux login, fake desktop, it is up to the coders imagination

Quote

All I'm saying is, if the source is submitted to Sun, they could give it a thorough security check and then endorse it by signing with a certificate which allows the JVM to load it without any security warnings popping up. As if they'd basically written the code themselves and made it part of the JRE. For something as simple as LWJGL it should be a doddle.

ok that would be ofsourse really great (but I would really prefer that they make it loadable as an extrnal library not included in the base JRE, this one is already ..... toooo big also xternal libraries will work with older JVM as it wont requiere lastest JRE, I dont understand why java dont work more that way => provide external libraries and not always increase the base jre)

That phishing stuff... is basically utterly paranoid. If you find yourself visiting the sorts of sites that have applications that can do that - you're already flirting with trouble anyway. I think the whole issue has gotten out of hand, a bit like the supposed threats of terrorism - that is, the paranoia is now actually far more of a bloody hassle than the actual threat.

That phishing stuff... is basically utterly paranoid. If you find yourself visiting the sorts of sites that have applications that can do that - you're already flirting with trouble anyway. I think the whole issue has gotten out of hand, a bit like the supposed threats of terrorism - that is, the paranoia is now actually far more of a bloody hassle than the actual threat.

not really you can fall on such website just by clicking on a result in google or by clicking on a link on a digg-like website, I am not paranoid but the money stolen using internet as bank account or credit card number and other is quite huge.... and probably a product that dont take care of that and can help doing such thing will get a very bad advertising/publicity for the futur if it happen only once and will be ofcourse forbidden in compagny..

EDIT:

Quote

the paranoia is now actually far more of a bloody hassle than the actual threat.

You could look at the argument this way: if LWJGL isn't safe, is Java2D?

Cas

No, but even Java2D is also not considered strictly safe by java's standards as well (switching full screen will require code signing).That said, I agree that OpenGL could be considered just as safe as Java2D: No code signing necessary as long as you don't switch to full screen.

But in principle I believe the security dialog is a Good Thing. It's good that there is some kind of user feedback that the application requests privileges outside of the sandbox. It has prevented java from becoming the tool of choice for malware and it got java the reputation of being safe, so considering exceptions should always be approached with the greatest care.

yup seems it dont, also severals plugins dont too, but IMHO it should be requiered because if no, you can produce some kind of "phishing" application : fake window/linux login, fake desktop, it is up to the coders imagination

The solution here is to do exactly what Flash does - show an overlay that says "Press ESC to exit full screen mode" and then hard code the escape key to do so, without the programmer having any choice in the matter. Also, IIRC the fullscreen mode can only be entered as a result of a user interface action, not a pure programmatic one. These are technical issues, not fundamental security ones.

Quote

ok that would be ofsourse really great (but I would really prefer that they make it loadable as an extrnal library not included in the base JRE, this one is already ..... toooo big also xternal libraries will work with older JVM as it wont requiere lastest JRE, I dont understand why java dont work more that way => provide external libraries and not always increase the base jre)

I think this problem is almost exactly what Cas is addressing - if there was a system in place for an optional second tier of official Sun libraries that didn't require full sandbox-breaking to run but also didn't need to be installed with the base JRE, it would allow a lot more modularity.

But in principle I believe the security dialog is a Good Thing. It's good that there is some kind of user feedback that the application requests privileges outside of the sandbox. It has prevented java from becoming the tool of choice for malware and it got java the reputation of being safe, so considering exceptions should always be approached with the greatest care.

Absolutely. But not considering exceptions at all is a big problem, too, because it means that things that should be considered sandbox safe now need to be out of the sandbox, which is a security flaw - people should never need to grant permission to their entire system just to allow something to use their graphics card, but under the current model they do.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org