Bingo! Certificates carry the price that they do in order to incentivize good behavior. The logic goes that someone isn't going to risk losing their investment by distributing malicious code under their certificate and having that certificate revoked/black listed. It's far from a perfect solution, but there is some logic behind it. Bottom line is that giving permission to unknown users to sign with your certificate is just asking for trouble down the road.

Ok but this isn't what I suggest. I wouldn't give them the trusted certificate, I would put it into our build system which would build the games, sign them and copy them into their definitive location(s). Each developer could trigger the build by using our web GUI. If I found something problematic in the code or in the library, I would be able to suspend the authorization. If each developer prefers buying her/his own certificate, Oracle and its friends will win, they frighten you and you behave exactly like they want whereas a collective solution would allow them to earn a lot less money and they could do nothing against us as long as it is legal. If they increase the price of a certificate for organizations, it will still be more affordable for us to work together than buying individual ones.

JGO is great. I'm sure we can make something great together. If OpenJDK was a lot more popular, we could simply use CACert.

I agree with you but several people here would like to go on using Java Web Start and/or applets. Of course, trust can be neither bought nor sold, that's why I speak about "trusted" certificates instead of trusted certificates. Trusted computing is a bad joke and something dangerous. I left Chrome Web Store several months ago despite the relative success of TUER on this website. Oracle doesn't solve the real problems, this security changes are mostly a diversion. nsigma will probably be able to help me to package my game as a DEB package, I'll use Red Line RPM for RPMs, I'll have to use something else for Mac and a native installer for Windows. I just hope I won't have to build those installers under each target platform.

Ok but this isn't what I suggest. I wouldn't give them the trusted certificate, I would put it into our build system which would build the games, sign them and copy them into their definitive location(s). Each developer could trigger the build by using our web GUI. If I found something problematic in the code or in the library, I would be able to suspend the authorization[/b].

That's a big "if". This scenario relies on you to be the gatekeeper. If we're talking about a few developers who know each other then it's probably not an issue. On the other hand, for a site that would take submissions from unknown devs, it becomes much more complex. Are you confident enough to say that you can just jump into a strangers code and understand every piece of logic in a short amount of time? Do you ever make errors or overlook something in your own code? Unless the answers are absolutely yes and absolutely no, then there is an inherent flaw in the proposition. I'm also not sure what legal difficulties this could lead to for the certificate holder if something malicious was released and caused a large amount of damage.

If each developer prefers buying her/his own certificate, Oracle and its friends will win, they frighten you and you behave exactly like they want whereas a collective solution would allow them to earn a lot less money and they could do nothing against us as long as it is legal. If they increase the price of a certificate for organizations, it will still be more affordable for us to work together than buying individual ones.

When it comes to large corporations, there are no such thing as friends, only "business partners" and strategic alliances. Call me naive, but I'm not exactly sure that Oracle really profits in this scenario. Do you have some reliable data that shows how much money they collect, if any, when a developer purchases a certificate from a CA? They also still give developers a gigantic "free pass" called packaged applications. If JavaFX is any indication, this is the direction that Java in general is heading. Considering the fate of Flash, and the fact that HTML5 seems to be the new perceived panacea of web development, it's probably the right move to make. Let's face it, nobody was really happy with applets or web start, so the hand wringing seems a bit perplexing.

In the case of certificate authorities, misbehaving certificate holders get blacklisted, their applications/domains start throwing up ugly warnings, and any investment of cash that they had put into their certificate is voided. What happens in the scenario where there are no public reviews or ratings?

The whole "certification" is just money digging, because, what else could it be? What trust can be put for an unknown person, who pays $50 to certificate an application to push it to the web? The $50 dollars worth of trust, what is nothing because trust cant be bought.

What trust can be put in a person who anonymously puts an application on the web for free? $50.00 seems like a mighty cheap price for a certificate from what I've seen. To be accurate this isn't a certification process in the same sense that an app store certifies things. Oracle is making no claims that the application being run has been reviewed by them. The trust comes from the fact that most malicious authors a)don't want any sort of trail leading back to them, and b)don't want to have to shell out a chunk of cash for a new certificate if their previous one is revoked. It also provides a centralized way to disable any applications that are found to be rogue. I'd argue that people do indeed give a certain level of trust to businesses and individuals who are associated with different paid and unpaid industry organizations.

And the most important, who has the right to decide for others? What is the right of Oracle to impose anything on the user? If the sofware is malicious and the user runs it, its sole responsibility of the user and the developer for every bad thing that happens.

I am not a lawyer, but I think Oracle is well within it's rights to put requirements on it's licensed software. The way law works at the moment, you are not the owner of the end product, merely the media it's on. Unfortunately, more often than not, people don't say "Oh no, a malicious software application. Curse you original developers!". They tend to blame the platform itself. Fun fact: BSODs are more often than not due to badly written 3rd party software. Who takes the blame for it though? This has happened quite a few times with Applets. Unfortunately people don't go "Oh what a horribly implemented feature, I'll just disable applets in my browser until the problems are worked out". They go "I heard Java is a horrible security risk, so I shouldn't install it on my PC". What good does that do Oracle, or any of the "good" Java developers?

It's very doubtful that Oracle will require security certificates for all levels of applications. Local applications are already unrestricted, and considering OS's impose their own set of security layers, it would make little sense to add yet another layer. Considering, again, that Java is moving towards allowing you to easily package a local JRE with your applications, I would assume that the OpenJDK group is moving along a parallel path. Where is this perceived "control grab" by Oracle? They're essentially "sunsetting" a feature in their product, not making themselves the sole distribution gateway for applications by any means. As a developer, this means that at worst, I am required to make a native package for each of my target platforms like the majority of other major languages out there while still retaining the ability to maintain a single code base built upon well tested and reliable libraries. As I see it, this still positions Java well ahead of other languages.

One last thought on this. When you have a packaged application, the average end user is less likely to be aware of what language it's written in. When something goes bad, it will more than likely get associated with the application and helps alleviate the misplaced blame problem mentioned earlier.

And one more thing: there are no excuses for this, because even if this was really only the security issue, Oracle had 16 years to create a reliable sandbox environment for the browsers for the applets.

That would be a fair criticism if technology had remained static for the past 16 years, and if Oracle had owned Java for that whole time as well. Let's not forget Sun owned and maintained Java until they were acquired by Oracle in 2009. Browser plugins have always been a bit of a headache which is why I think the big push is towards gearing web applications to be written in the native languages of browsers, JavaScript, HTML, and CSS.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

While I appreciate your well thought out response, the fact still remains that any sort of linking between the browser and a VM that's outside of the browser is a bad idea from a security standpoint. This problem isn't unique to Java, almost any of the popular browser plugins becomes a target for malicious attacks. At some point the hit to a brand isn't worth keeping an inherently dangerous feature in a product.

As I stated, Oracle would appear to be in the process of sunsetting applets, not making them some new revenue stream. They've even included a way for users to easily detach the JVM from the browsers via the Java Control Panel recently. For better or worse, HTML5 and JavaScript are the new preferred platforms for web application development. Even Adobe, who I would estimate have a far larger base of users of Flash than Oracle have applet users have started gearing their online tools for HTML and JS.

Technological shifts are seldom "painless" for all parties involved. We may disagree, but I see this change as a net benefit for Java in the long run. Security experts have advised people to either disable Java in their browser which wasn't that straightforward for the average user until recently, or uninstall Java completely. If the first scenario is followed, Applet writers are locked out, but application writers still have the ability to work. If the second scenario happens, then both application and applet devs are locked out leaving only server side devs fairly unscathed for the short term.

I'm perfectly happy to have any faults in the logic corrected. Considering the direction of Java and how it treats different deployment setups though, I don't feel that your logic supports this as a cash grab scenario. Indicators would seem to be that this, if anything, is a soft nudge to devs to move away from applets before they ultimately pull support for them completely in the future.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Again lukasz, feel free to correct me or point out the contradictions. I'm open to changing my stance based on sound reasoning; however, the equivalent of saying "you're wrong" without offering any form of evidence or logic to back it up does nothing to demonstrate the correctness of your assertions.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

First you are comparing Java applets to web technologies on the matter of security. Thats perfectly correct but the contradiction you make is that you try to separate those two while actually the technology demands in terms of security are almost 100% the same for each. Java could have solved its security issuess the same way that: Flash, Chrome plugins, Firefox plugins and every other.

I don't separate those two. My point still stands that plugin technologies that connect the local OS to a web browser are a security liability. I can't think of a single plugin provider who has "gotten it right". Even Flash, which has been around and upgraded for no small amount of time, still has exploits. Same with Adobe Reader and pretty much any other major plugin you can think of. I've not developed a chrome plugin, but when I did FireFox plugins, I remember using JavaScript and being restricted to the browsers sandbox. The browser didn't hand control over to a 3rd party VM capable of calling native code and libraries. Chrome also uses their own integrated version of Flash. It's better to secure your own house than rely on your neighbor to do it for you. I just don't expect perfection from the applets while pretending that security is better with any of the other semi-comparable technologies.

Next thing is that you separate those who paid for licensing from those who haven't and say that Oracle has right to ban applications that arent signed by a "reliable" authority. This is hard to stand because such a stance breaks up the freedom of development and forces the open technology - which Java is to hold many users, who aren't able to pay, but have good will to develop an useful application. There is completely no difference between a person who will pay $50 for certificate and the one who wont. Actually I could tell the oposite of what you say and speculate about who may have bad intentions on the web, and say that it could be rather a person who paid $50.

Security certificates are not a license nor are they in fact any sort of security on their own. They are a way to tie an application to a developer or organization. Having that link allows you to take security related actions such as blacklisting/blocking any apps signed by a developer who has been found to be causing harm to users. Java's security model, even with a signed certificate is still highly venerable to spoofing from what I've read, but it is a stumbling step in the right direction. As far as I know, Oracle is in within it's rights to make this move. I am of course speaking of legal rights. I'll leave "morally right" arguments to the philosophers. This in no way breaks up "freedom of development". The only ability you're losing is the ability to embed your application in a web page. The "good will" devs are perfectly free to develop those same ideas. The only thing that changes for those that can't pay is that they package up their code in a different manner. These "crippling" requirements don't seem to have had an limiting impact in development in any of the languages that don't offer a browser based plugin.

Unless hackers have changed, I don't see them wanting their application tied to any sort of accountability, much less reliant on something that could be used as an effective kill switch for the majority of targets infected by said application, even less so when having to pay for that "privileged".

And about the 16 years where the secure sandbox could have been done. The technology here is very not the issue, and the dynamics aren't important because the whole security job protection is done on software level and is abstracted from the hardware. Sun and Oracle had a lot of time but instead... I really dont know what they were doing.

So software is in no way a technological or dynamic issue? Security models on the OS and browser sides have been carved in stone for 16 years? There were no demands for improvements or changes in the JVM for that whole period. While I would never argue that Sun and Oracle are or were perfect in all of the decisions made in Java, but it's not like applets are the sole technology of Java. If your argument boils down to Java doesn't have a perfect security model, then I think your assertion is just as valid for any other technology out there.

If this is not for a cash, tell me why did Oracle decided to move "free" Java out of the web? For security reasons? Anybody who will pay some cash can create malicious application, and few days later grab a theft from intercepted bank account getting a multitude of return in cash, before the application was blacklisted. Thats certainly not for security reason, because if so - they would have to read source of every application that is going to be certified. Actually any other reason other than cash can be easily put down.

I think I've explained my thoughts on the reasons for security certificates more than once now. Perhaps you can explain how you believe there is any sort of windfall potential for Oracle by this move considering every other deployment option is free and would cause large losses to the supposed revenue stream. There is still a glaring lack of figures showing what, if anything, Oracle makes off of the purchase of a certificate. Your "ratings system" suggestion suffers from the same fault as the delay in blacklisting in your scenario. It really crumbles when you consider how long it would take for users to post/submit enough reviews for people to pay attention (if at all) while still allowing the malicious application to run amok on the machines of users who aren't paying attention. Again, you have to establish the "cash reason" before you can put down other reasons.

I may not agree with your view on a certain number of things, but I appreciate you taking the time to clarify your position. In the end I think applets, both signed and unsigned, are going to meet the same fate.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Just for the information of anyone thinking they're better off making executables to deploy instead to get around the problem... apart from linux with its paradoxically weak security (someone must have left their tinfoil hat off for too long), getting executables onto a Windows or Mac machine is no longer as easy as you'd hope. You more or less have to sign the executable's installer or you can expect it to be automatically deleted or flagged as a virus and then automatically deleted. If you're lucky the user will get a scary looking dialog which has a default option of "delete".

My argument is that - Java as other technologies like flash doesn't have to be unique on its own way by blocking jnlps and applets - the "security issuess" are just Oracle false excuses for, because as every web application written in almost every web technology that have the same security issuess - the same is Java with no exceptions. ...

Your assesment here is that Oracle is interested in the client side technology. Rather the thing is, Oracle is hugely serversided. The client side is a bonus, it's easier and more cost effective to close it down to spend resources to fix it. In that sense You are right but Oracle ain't wrong either: it's more secure to not use technology.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson

TCP/IP is just a delivery mechanism and URL's are exactly what their expanded acronym advertise. They have nothing whatsoever to do with security. Secure mechanisms are built on top of or utilizing them. As for file systems, I'm 100% positive that there have been changes there as well, but that's neither here nor there. The security issues are with the "sandbox" whose requirements don't remain static when the language they're supposed to contain changes. As new features are added to the language, you also introduce new ways to exploit the system.

I believe I stated that all of the major plugins have these issues, and that Java was far from the only plugin maker who was in the process of ditching that type of technology. The "security issues" are far from a false excuse no matter who the developer in question is.

I think you have the wrong view of what certified means in the context of this discussion. The certificates aren't a sign of code review, they're a sign of verifying who a publishing party is, no more, no less. Furthermore, there is no such thing as an Oracle/Java specific security certificate. The only requirement is that a certificate must be an RSA certificate. From Oracle's RSA signing page:

Quote

Getting RSA CertificatesRSA certificates may be purchased from a Certificate Authority (CA) that supports RSA, such as VeriSign and Thawte. Some CAs, such as VeriSign, implement different protocols for issuing certificates, depending on the particular signing tool you are using.

RSA may be making some money, but RSA != Oracle, making the rest of your statement moot.

I can't think of any function or computation that Java can do that can't be done in another language. The ways to do it may be easier or more difficult, but there is hardly anything that makes Java a unique snowflake when it comes to performing any task. Once you learn concepts, which is the important thing to grasp when studying programming, figuring out the syntax of a different language isn't that big of an issue. Devs are hardly indentured servants to the kingdom of Java.

As I said I'll leave the legally right vs morally right issues to the philosophers. This discussion has veered far afield of where it started, so I'll leave it at this. Any future plans that revolve around Java applets probably shouldn't. Setting the issue of the "path to there" aside, the destination is the same.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Just for the information of anyone thinking they're better off making executables to deploy instead to get around the problem... apart from linux with its paradoxically weak security (someone must have left their tinfoil hat off for too long), getting executables onto a Windows or Mac machine is no longer as easy as you'd hope. You more or less have to sign the executable's installer or you can expect it to be automatically deleted or flagged as a virus and then automatically deleted. If you're lucky the user will get a scary looking dialog which has a default option of "delete".

Cas

Linux forces you to set the "execute" flag on any sort of executable before you run it the first time. You also run as a restricted user account unless you're daft enough to stay logged in as root all the time. In the case of a bundled Java application on any platform, there shouldn't be a need to install anything unless you really want to make it look fancy and store it down in one of the system directories. Everything that your application needs, including the JRE, can be put into a compressed file, unzipped by the user, and run directly. Where are the security tripwires being tripped here?

Mea Culpa: I know nothing about MacOS, so if the scenario was more geared towards the Apple eco-system, then replace the "on any platform" with "on at least two of the platforms".

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Wouldn't that be a McAfee issue and not an OS issue? McAfee and Symantec, while popular, create some of the worst products in the virus scanning field. Do yourself a favor and give AVG, Avast, or any of the other scanners a look. Zip files aren't unique to Java or any specific application so everyone would face the same issue.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Wouldn't that be a McAfee issue and not an OS issue? McAfee and Symantec, while popular, create some of the worst products in the virus scanning field. Do yourself a favor and give AVG, Avast, or any of the other scanners a look. Zip files aren't unique to Java or any specific application so everyone would face the same issue.

Why not using Winclam? Symantec already did some false claims about an Android application allowing to display what the camera see in the background. "Trusted" computing isn't trustworthy. I'm fed up with all those gatekeepers (including the one under Mac OS X 10.8 ), those tolls, those inproductive companies (CA), the application stores, we should just burn them (please burn the banks too).

I'm fed up with all those gatekeepers (including the one under Mac OS X 10., those tolls, those inproductive companies (CA), the application stores, we should just burn them (please burn the banks too).

Don't forget the first rule of Fight Club, gouessej.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Linux forces you to set the "execute" flag on any sort of executable before you run it the first time. You also run as a restricted user account unless you're daft enough to stay logged in as root all the time. In the case of a bundled Java application on any platform, there shouldn't be a need to install anything unless you really want to make it look fancy and store it down in one of the system directories. Everything that your application needs, including the JRE, can be put into a compressed file, unzipped by the user, and run directly. Where are the security tripwires being tripped here?

Mea Culpa: I know nothing about MacOS, so if the scenario was more geared towards the Apple eco-system, then replace the "on any platform" with "on at least two of the platforms".

I think you misunderstood - by default most Linux distributions generally lets you install any old shite, and doesn't put any impediments in front of the user to doing so. There's no warnings about unsigned code.

Windows and MacOS no longer generally have people running as root either but it doesn't stop malware from doing what it does. Even when it does need root users are happy to put in the administrator password to get what they want...

I think you misunderstood - by default most Linux distributions generally lets you install any old shite, and doesn't put any impediments in front of the user to doing so. There's no warnings about unsigned code.

Really? If we're talking proper installation, as in packages, then I've been seeing warnings about unsigned code for years!

All that package stuff... that's for official distro stuff. For anything else, anything goes... just look at our games for example. They're just a .tar.gz. You just unzip and double click to run. They could do absolutely anything

Archives aren't installers. Packages can run scripts as root. In comparison your "can do anything" is quite limited, assuming you're not making your users run your game as root. Packages are not just for distros - they're also the way to achieve certain forms of OS integration if you need it.

I *thought* the solution to this problem would be to write an uploader that creates an executable out of compile jars and libraries, but now Cas has me paranoid that even that won't work. More research is required.

It looks like the only way to run jars is for the end user to mark the signed jar as trusted using the keytool command? This puts a lot of responsibility on end users, who have no idea how to do any of this stuff.

Is this seriously the case? And how does this impact executables, which are just running jars behind the scenes (I think)?

I *thought* the solution to this problem would be to write an uploader that creates an executable out of compile jars and libraries, but now Cas has me paranoid that even that won't work. More research is required.

Maybe I'm misunderstanding here, but why would you think that an executable jar won't work? If you're using WebStart, then yes, you'll fall under the new lock down procedures. If you're launching it locally, then there are no restrictions on your application by default. As a side note I've just noticed that NetBeans now has the option to package an application into a standalone MSI or EXE installer.

I could be mistaken, but if you go on to read the next part of that trail, it notes that in order to enforce security on an application you have to explicitly pass the "-Djava.security.manager" flag to the JVM at start up. Furthermore, if you jump to the article about controlling applications linked from that page, and go to the second page called "Observe Application Freedom", the very first line states "A security manager is not automatically installed when an application is running".

From what I gather, the article you linked to is explaining how an end user/organization can optionally lock down local applications since such restrictions are not present by default.

It looks like the only way to run jars is for the end user to mark the signed jar as trusted using the keytool command? This puts a lot of responsibility on end users, who have no idea how to do any of this stuff.

If the end user has gone through the steps needed to lock down local java applications, then using the keytool command probably isn't an issue for them. As this is an "above and beyond the defaults" feature, I'd wager that acceptance/rejection of a certificate in the case of a regular user launching an applet/WebStart application from their browser will still be handled by the standard security popup and its don't trust/trust/always trust mechanism.

Is this seriously the case? And how does this impact executables, which are just running jars behind the scenes (I think)?

I think this is the "exceptional" case, and not the default rule. Executables, which are just running jars that they extract from an internal resource bundle behind the scenes as you suspected, should work as normal with no extra intervention on the end users part.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

Ahh okay, I understand now. I thought the security manager would be enabled by default, but I should have read more before flipping over my desk. Thanks for clearing it up for me.

I get why they're adding the security manager, but I would guess that people who are technically savvy enough to enable it aren't the ones being exploited in the first place...

Anyway, looks like my project over winter break will be to write an uploader that takes jars and libraries as input and outputs an executable file. Sounds painful, but hopefully it'll help novices who just want a quick way to show off their programs.

I get why they're adding the security manager, but I would guess that people who are technically savvy enough to enable it aren't the ones being exploited in the first place...

I have the feeling that it's geared more towards paranoid corporate IT departments who need a way to allow Java to run, but still want to control what applications it can run by default. Without that ability, they are faced with an "all or nothing" scenario with Java.

Anyway, looks like my project over winter break will be to write an uploader that takes jars and libraries as input and outputs an executable file. Sounds painful, but hopefully it'll help novices who just want a quick way to show off their programs.

Considering both NetBeans and Eclipse are starting to offer the ability to create packaged applications, have you considered seeing if one of their platform API's could be leveraged to automate the compiling/packaging for you? It would probably save you a lot of blood, sweat, and tears that would come from developing a packaging tool chain from scratch.

Arthur: Are all men from the future loud-mouthed braggarts?Ash: Nope. Just me baby...Just me.

I have the feeling that it's geared more towards paranoid corporate IT departments who need a way to allow Java to run, but still want to control what applications it can run by default. Without that ability, they are faced with an "all or nothing" scenario with Java.

Haha that makes sense, considering my company's IT department's reaction to the first wave of Java exploits was to silently uninstall Java from all company machines overnight. Pretty funny day for the Java developers!

Considering both NetBeans and Eclipse are starting to offer the ability to create packaged applications, have you considered seeing if one of their platform API's could be leveraged to automate the compiling/packaging for you? It would probably save you a lot of blood, sweat, and tears that would come from developing a packaging tool chain from scratch.

That's an interesting idea. I'm still in the very early stages of thinking about how to solve this particular problem, but if I could just write a handy "here's how you create an executable from eclipse" and then allow users to upload executables, that would be awesome. I wonder if there are eclipse plugins for exporting to executable? To the google!

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