The problem is that what should be the case simply isn’t. LWJGL and stuff built on top of it use native libraries for OpenGL, and that’s the way most people go for game development. I don’t blame them, LWJGL is awesome, and I personally love libGDX. It might be overkill for a lot of games here, but I don’t blame people for wanting to learn how “real” games are made.
But that’s a bit of a moot point anyway. Even unsigned, completely sandboxed applets will be disabled by this change. Applets and webstarts are essentially being killed off for everybody who can’t afford a certificate.
Since I didn’t see it specifically mentioned in the source article, let me pose this question, does anyone know if these same restrictions will apply to JavaFX based applications? Looking at the JavaFX deployment page, there is no mention of the type of restrictions that JavaSE based deployments will face. It seems to me that JavaFX is more in the spirit of a “Flash like” solution for the web, and JavaSE is geared more towards enterprise development.
If both versions will face the same restrictions, then feel free to disregard my hypothesis. :persecutioncomplex:
I was wondering the same thing. I thought I saw that JavaFX program are packaged up into jars, which I assume will have the same kinds of restrictions. I’ve never worked with JavaFX though, so I’m not really sure.
This is not new, it was already announced several months ago. OpenJDK + Icedtea-web uses its own implementation of Java Web Start which has a less paranoid security policy. For example, the publisher is not systematically shown as “UNKNOWN” when using self-signed certificates but there is still a different color for the warning so that you can make a distinction with “trusted” certificates. If Oracle really wants to annoy us, some of us will have to port Icedtea-web to Windows and Mac which is planned in the project Ji-Gong (alias JogAmp Runtime Environment).
There are some other solutions. We can use a single certificate for several developers so that it becomes more affordable.
We can use native installers or IzPack. I plan to use RPM and DEB packages under GNU Linux anyway.
I still think Oracle’s decision is really silly but I’m not surprised because I don’t trust corporations.
Yeah I was pretty sure it wasn’t new, it just hadn’t really hit me how much this is going to affect me until now.
[quote=“gouessej,post:27,topic:44642”]
That sounds really interesting, but sadly I’m not sure how it can get very far because it puts the responsibility on the end user, who knows nothing about Java. Similarly, even if there was a setting somewhere to not disable self-signed or unsigned jars, 90% of end users would still complain that “it doesn’t work”.
[quote=“gouessej,post:27,topic:44642”]
I’ve thought about this option, buying a certificate myself and offering it for free to anybody who uploads to my website. The problem is that what happens if one person gets ahold of the certificate and does something sinister (or accidentally sinister that gets flagged)? Would the certificates for everybody be viewed as suspicious? Doesn’t seem worth the risk.
[quote=“gouessej,post:27,topic:44642”]
This is a really interesting option, thanks for pointing it out. I’m also looking at Launch4J and JarBundler. I definitely need to do more research on packaging executables.
[quote=“gouessej,post:27,topic:44642”]
I understand why they’re doing this. It just sucks that there wasn’t a third option, or maybe a more standard way to package executables. Everything feels like a bit of a hack at this point, after working with standard jnlp for so long.
It’s already very far. I remind you that OpenJDK 1.7 is the reference implementation of Java 1.7. OpenJDK is installed by default under GNU Linux and the Icedtea-web maintainers can go on enabling self-signed applications by default. Moreover, the project Ji-Gong targets Android too but we need some more contributors.
[quote=“KevinWorkman,post:28,topic:44642”]
Personally, I agree with sharing my certificates with a few developers of free (or vaguely open source) softwares. If it isn’t enough, they will have to use my build system to benefit of my certificate so that I don’t take a big risk. It’s doable but I would prefer to push back Oracle.
[quote=“KevinWorkman,post:28,topic:44642”]
You can use Launch4J with IzPack.
[quote=“KevinWorkman,post:28,topic:44642”]
They want to get much money from everybody, the end users, the developers, … On my view, the biggest marketplace should be Internet itself. I know that the next steps will consist in forcing all end users (especially Mac and Windows users) to get their applications only from those dedicated marketplaces. Even Mozilla is helping them by claiming that all plugins are evil, Firefox OS has a dedicated marketplace too. We have to fight to free Internet, in order to prevent a few corporations from deciding its future alone.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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”.
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.
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.
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”.
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.
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:
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.
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”.
