Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Java Oracle

Will New Red-Text Warnings Kill Casual Use of Java? 282

New submitter ddyer writes "Java 1.7.0_40 [Note: released earlier this month] introduces a new 'red text' warning when running unsigned Java applets. 'Running unsigned applications like this will be blocked in a future release...' Or, for self-signed applets,'Running applications by UNKNOWN publishers will be blocked in a future release...' I think I see the point — this will give the powers that be the capability to shut off any malware java applet that is discovered by revoking its certificate. The unfortunate cost of this is that any casual use of Java is going to be killed. It currently costs a minimum of $100/year and a lot of hoop-jumping to maintain a trusted certificate.'"
This discussion has been archived. No new comments can be posted.

Will New Red-Text Warnings Kill Casual Use of Java?

Comments Filter:
  • red spots (Score:3, Funny)

    by Anonymous Coward on Thursday September 26, 2013 @01:36PM (#44962205)

    red spot warnings have not killed off casual sex.

    So-- probably not?

    • Re: (Score:2, Insightful)

      by TWX ( 665546 )
      Yeah, but generally that kind of screwing has a strongly anticipated immediate short-term benefit, even with the long-term ramifications. I don't see such euphoria in the original case...
  • by Anonymous Coward

    While I would hope for the day that Java dies the pathetic death it is due, I doubt that will happen. Much more likely is that "unauthorized" Java VMs will start to crop up that let the user whitelist applets rather than relying on Oracle's certificate system.

    • by Gerzel ( 240421 )

      Or people will just move to the OSS version.

    • I doubt Java as a programming language is going to die any time soon since Android, which has been the fastest-growing platform for a while now, is pretty much a JRE running on top of a Linux-based kernel.

      Oracle's own walled-garden Java on the other hand might not fare so well.

    • Much more likely is that "unauthorized" Java VMs will start to crop up that let the user whitelist applets rather than relying on Oracle's certificate system.

      Doesn't OpenJDK already do this? I haven't done Java in years so I'm a bit behind the times.

  • by DavidHumus ( 725117 ) on Thursday September 26, 2013 @01:42PM (#44962305)

    But don't get your hopes too high.

  • by SirGarlon ( 845873 ) on Thursday September 26, 2013 @01:44PM (#44962331)
    TFA says this is for "Rich Internet Applications," that is, Java applets embedded in Web pages. It doesn't seem this would affect Java programs that you execute locally, such as (for example) Eclipse.
    • by snookerdoodle ( 123851 ) on Thursday September 26, 2013 @01:50PM (#44962449)

      Exactly.

      OP doesn't seem to know anything about Java.

      This will not affect standalone Java programs, only applets.

      It could be argued that they should have done this a long time ago.

      Mark

      • by i kan reed ( 749298 ) on Thursday September 26, 2013 @01:54PM (#44962511) Homepage Journal

        It could also be argued that java has no place in browsers given the modern flexibility of javascript. The UI features are worse, the performance differences are negligible, legit code is sandboxed either way. All you're left with as an advantage for true java is threading.

        • Performance differences negligible?
          The most advanced thing I've run in javascript was Wolf3D. I remember javascript doom was not playable (it's not available anymore, because of unauthorized use of the game assets). Java has smooth Minecraft and whatever stuff, for example Text Express from Zylom which is a little game that runs very smooth ; you can barely run a Tetris in javascript and it will look like a Windows 3.1 freeware, use shit ton of CPU, make the whole web browser slow.

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          >the performance differences are negligible
          In javascript you can run multi-threaded computation, you have access to native network buffers (for no copy transfers of large amount of data), ... I was told no.

          >given the modern flexibility of javascript
          So, you are saying: if there is a Java library to do it, there is _always_ a javascript library to do it. Access to any file format, implementation of any network communication protocol, ...

          I am _really_ skeptical. Javascript may be great for accessing web

        • Spoken like someone with very little knowledge of one or the other. Yeah, you'll get modded up on Slashdot, but any "java is slow" post is.

      • However applets could be what it means for "casual use of Java".

      • by Anonymous Brave Guy ( 457657 ) on Thursday September 26, 2013 @04:56PM (#44964617)

        It could be argued that they should have done this a long time ago.

        But it wouldn't be argued by anyone who actually knew what they were talking about.

        For one thing, signing a Java applet proves exactly nothing about how trustworthy it is. You can easily get a signing certificate by spending a small amount of money and waiting a small amount of time. The whole concept of granting increased permissions to untrusted software just because it's been signed is absurd.

        Secondly, blocking unsigned applets will break numerous existing web-enabled devices, which has been one of the significant remaining use cases for applets in recent years. These are effectively running embedded web servers and serving up the applets from there, so you can't just go in and upgrade them later when your certificate expires (and the longest cert periods you can get from major CAs are only about 2-3 years, a fraction of the normal lifetime of some of these devices).

        The craziest thing is that the kinds of device I'm thinking of are typically used by the IT guys in large organisations. Some of them are going to go through months of approval process before they get installed, and when they do it will be in server rooms or data centres, accessed electronically via a separate management network with no connection to the outside world, and accessed physically via biometric security that would make James Bond cry. But in order to keep those applets safe, now they need to be signed too, just in case? Seriously?

        Not everyone using applets accesses them from a public web site. They can't necessarily upgrade or replace them on a whim. The kinds of environments still using them are more likely to be exactly the kind of long-running projects where whipping up a quick replacement in JavaScript isn't a sensible option and where backward compatibility really matters.

        Also, to anyone who thinks alternative technologies like JavaScript and HTML5 canvas/SVG offer the same flexibility and speed as Java applets, I know a prince in Nigeria who'd like to sell you a classic car from his collection for a great price.

    • by jonabbey ( 2498 ) <jonabbey@ganymeta.org> on Thursday September 26, 2013 @01:55PM (#44962547) Homepage

      This would not affect Eclipse, no, but it does affect locally produced applications that are distributed from an intranet web server with Java Web Start / Java Network Launch Protocol.

      Previously, we could just self-sign our app and users could choose to accept the app once and for all and not be bothered so long as the signing cert didn't change. Now, all of our users running Java 1.7.0_40 are given the threatening dialog each and every time they run our internal app, and they can't get rid of it.

      We're going to pony up for a code signing cert from a (Java-recognized) certificate authority to make the dialog go away. It's a hassle, but probably still the right thing for Oracle to do at this point.

      • Re: (Score:2, Interesting)

        by Anonymous Coward

        Can't you make your own CA cert, shove that into the JRE/JVM keystore, and chug along "for free"? Or did you decide that it was worth $100/year to not deal with having to automate running keytool on all your desktops?

    • by bigpat ( 158134 )

      Also of note that it appears that the applet will accept any certificate that the browser recognizes from any trusted authority. So there are a variety of SSL certificate options at various yearly prices. Right now I see one offering certificates for $60 per year.

      So, yes it will increase the cost of publishing a java applet on a website, but no this doesn't create a central authority out of Oracle for revoking certificates like the OP says. It just ensures that people can verify the identity of web sites

  • by Ksevio ( 865461 ) on Thursday September 26, 2013 @01:46PM (#44962351) Homepage
    "Casual" use of Java is fairly rare - if there's an applet on a website, I'm probably going there to find it and won't be worried about it being unsigned. Most sites use Flash or Javascript rather than fire up the JVM.

    The typical user will just click "Run" no matter what it says anyways, that's why Google's malware blocking doesn't even give the option to proceed to the website on its warning page.
    • "Casual" use of Java is fairly rare - if there's an applet on a website, I'm probably going there to find it and won't be worried about it being unsigned. Most sites use Flash or Javascript rather than fire up the JVM.

      The typical user will just click "Run" no matter what it says anyways, that's why Google's malware blocking doesn't even give the option to proceed to the website on its warning page.

      That's exactly what this is, but worse. They're saying that in some future release there will be no 'just run it anyway' button. Google's malware page *does* give an option to continue, it just takes a couple extra clicks to get there. This will have no such option. Also, appealing Google's block is quick, easy, and free. There's no appeal here, just extortion.

      Essentially what Oracle is doing here is saying to all the applet developers: "It'd be a real shame if something were to happen to that app of yours.

      • by Ksevio ( 865461 )

        Google's malware page *does* give an option to continue

        Last I saw, the only way was to copy the URL and paste it in the address bar, but it may have changed.

        • Last time I encountered it (earlier this week) there was a 'take me back' button, and beside that was a small 'advanced options' link. Click the advanced options link and it'll give you a 'continue anyway' button. Been that way for quite a while.

  • by TheCarp ( 96830 )

    The noitice is good, and in the general case this is good. I see some serious problems for system admins who have to use systems with older ILOs. Just about every ILO or remote console I have used in the past few years has been java based and used self-signed certs.

    It would be nice if you could whitelist trusted networks. I would like this when going to random google pages, this will be a serious pain when it comes to administering systems.

    • Time to start archiving versions of portable Java so they will be available for use with a standalone Firefox Portable to run all those legacy apps. Or something similar.
    • by ADRA ( 37398 )

      You used to be able to install self-signed certs into a keychain, and I'd be surprised if they took away the ability to do so in the future.

      • by TheCarp ( 96830 )

        I don't actually deal with ILOs in my current position (often anyway). However the last environment I was in was utterly pathological. the ILO would generate its own self-signed cert, meaning you would litterally need to install a new cert for every single ILO.

        Maybe that is fine in a small environment, I have been working in ones where we are talking about something on the order of 2000 systems.

    • by Junta ( 36770 )

      Does it do plugin or java web start? In the latter case, this doesn't factor in. Most things that I deal with that once were java plugin centric are now java webstart if they can't manage to pull it off in http/javascript/html

  • by Anonymous Coward on Thursday September 26, 2013 @01:48PM (#44962395)

    > The unfortunate cost of this is that any casual use of Java is going to be killed.

    You may think you're just a casual user of Java. You may think you just use Java for recreational purposes. Everybody knows Java is just a gateway language for other languages like C#. And we all know what happens to C# programmers.

  • by FryingLizard ( 512858 ) on Thursday September 26, 2013 @01:49PM (#44962419)

    Java? Casual? That's like saying the US Tax code is good bed-time reading.
    After realizing I was spending half my frickin' life compiling, reloading, and waiting... waiting... (I'm looking at _you_ Tomcat) I switched to Python and never looked back.

  • by stewsters ( 1406737 ) on Thursday September 26, 2013 @01:49PM (#44962433)
    I really don't think that there is a casual use of Java applets anymore. Banks and large corporations use it, but when was the last time you ran someone's java app that wasn't your own or a major corporation's? Large players can pay $100 a year for their app without thinking about it. Personal projects you trust and can push continue on. You shouldn't be running java apps from random other sources if you value security.
    • Personal projects you trust and can push continue on.

      RTFS:

      Running applications by UNKNOWN publishers will be blocked in a future release...

      There is a 'continue on' button right now, but this is stage one of phasing that out entirely.

      • by bws111 ( 1216812 )

        Unknown means unknown by the system running the app, not unknown by the world in general. Make your own cert, put it in the truststore, and now you are known.

    • NOAA aviation weather tools are done in java - used extensively by pilots.

    • There's a really cool open source SSL VPN called Adito that allows you to do port forwarding over SSL via a browser-launched Java applet.

    • by suutar ( 1860506 )
      last week. GUI client for one of my favorite chat programs uses Java Web Start and is written/maintained by one guy in Denver.
    • I really don't think that there is a casual use of Java applets anymore.

      Minecraft is hugely popular and the only reason for many of us to temporarily enable browser applets.

      You can choose to buy Minecraft without testing its browser demo... but if you want to preview whether your old machine can handle the 3D decently *before* plunking the ~20+ to license the full applet-less version, there's no alternative.

  • Java applets? (Score:3, Insightful)

    by bigtech ( 722116 ) on Thursday September 26, 2013 @01:50PM (#44962439)
    Did I just step out of a time machine?
  • by l2718 ( 514756 ) on Thursday September 26, 2013 @01:54PM (#44962527)

    Java applets are an essential tool for science education -- as simulators [colorado.edu], calculators [hws.edu] etc. Are all these research groups supposed to get some authority to digitally sign their applets?

    Fundametally, a major aspect of Java security is that, since it runs on a VM, an applet it is inherently encapsulated. Yes, VM bugs can cause problems, but the value of all the free educational applets online far exceeds any possibly security benefits of unptached VM bugs.

    • by ADRA ( 37398 )

      I agree in general, but I'd say any apps that want system access (legitimately breaks out of sandbox protections) should be disabled for self-signed apps that haven't been manually white-listed. The number of Java apps needing system access should be low in general.

    • I imagine there will be an option in the deployment settings (which were also added with this release, I believe) to allow unsigned applets to run. As for Java running in a VM providing sufficient security, I'm going to have to disagree. Java security exploits have been responsible for a whole lot of malware over the years; in fact, it's one of the most common ways for malware to propagate. I think it's pretty clear by now that whatever security benefits the JVM might have once held are no longer a factor.
    • I'm sure that's great software - but does it really need to run inside a browser? The first link you gave involves downloadable apps and/or Java Web Start - not an embedded JVM. The latter link I'm not sure about.

      It's worse than Flash - the sandbox has access to your printer and a whole lot more. It can still be a nuisance even if it's not escalating access.

  • Does it show the warning in any of the linked articles?

  • WAAAAT (Score:4, Insightful)

    by GameboyRMH ( 1153867 ) <`gameboyrmh' `at' `gmail.com'> on Thursday September 26, 2013 @01:58PM (#44962593) Journal

    Most of the Java apps I use are unsigned.

    Here's what I see happening: Lots of people hanging onto old Java versions, creating an even bigger security disaster.

  • by BitterOak ( 537666 ) on Thursday September 26, 2013 @02:02PM (#44962641)
    I thought the whole point of Java is that it runs in a sandbox so applets don't NEED to be trusted. Are they admitting failure here?
    • Re: (Score:3, Insightful)

      by dbc ( 135354 )

      Yes. Exactly. They just plead guilt to selling snake oil, as we knew they were doing all along.

      And my mod points ran out yesterday :-/

      • They didn't need to "plead guilty", the department of homeland security issued a public press release a year ago telling everyone to uninstall Java. A year later Oracle has basically agreed.

    • > I thought the whole point of Java is that it runs in a sandbox so applets don't NEED to be trusted.

      Yes, and then later Applets are allowed to interact with JavaScript code in the surrounding browser, and vice versa JavaScript can interact with methods of the Applet. That would never open up such complex interactions that nobody could foresee the security problems. Nope, nosiree. (sarcasm)
    • How is this post insightful? It posits an incorrect assumption. Java wasn't created for applets. Maybe that's what you've mostly seen. Second, there are unsigned applets that are sandboxed and signed applets that can have expanded access to your system. The whole point of the Java exploit scare was websites hosting an unsigned applet that behave like a signed applet.

  • This will be unfortunate.

    We've had problems with our university issuing certificates for domains and for code, which is not intended for public use.

    Making it not run will mean we will have to dump Java and use one of our other OPEN SOURCE coding methods.

    Buh bye!

    Not that we're the fifth best world university or in the top ten list of US research universities or anything.

  • The last reason left to have Java installed?
    • Perhaps, but not an excuse to let Java applets run freely in your browser. TFS says that this only applies to applets; programs run out-of-browser will probably function normally. Even if that's not the case, I'm sure they'll have an option to allow unsigned code to run.
  • Retards (Score:4, Insightful)

    by 0123456 ( 636235 ) on Thursday September 26, 2013 @02:11PM (#44962769)

    As others have mentioned, there are a ton of embedded systems which use Java as the control interface and load unsigned or self-signed applets to do so. Block them, and we'll be forced to stick with an old version of Java.

  • by nurb432 ( 527695 ) on Thursday September 26, 2013 @02:16PM (#44962835) Homepage Journal

    No, i didn't RTFA... Are they going to refuse to run self-signed at all, or can you opt out of the blockage as the end user?

    I'm OK with a warning;"hey do you trust this?" and a choice to say yes, but complete blockage is uncool.

  • by Sarusa ( 104047 ) on Thursday September 26, 2013 @02:23PM (#44962935)

    Nobody should be running Java in browser. It's a blinking, gaping 'zero day me here!' for any drive-by malware and Oracle can't keep up with the exploits (though they still keep trying to re-enable their plugin on install, along with trying to install junkware, the evil bastards).

    I do use Java for standalone apps, this is not an anti-Java thing - it's the browser plugin that is the problem.

    Big slow institutions that are stuck using Java can pay the $100 and still get the extra drive-by protection. Everyone wins. Of course the baddies could still get a cert... but then we're back to 'don't run it in browser.'

    • Nobody should be running any fully functional, system aware, computer program in a browser...
      A java applet is a java computer program written by "someone" coming from "somewhere" running in a browser on your computer.

      Replace "java computer program" with "c++ computer program" (or any other "real" language) in the previous sentence, and it describes a situation no less dangerous, arguably more-so.

      It has nothing whatsoever to do with the language, its the paradigm.
  • by WaffleMonster ( 969671 ) on Thursday September 26, 2013 @02:29PM (#44963023)

    Is it more difficult to give up on making the sandbox mechanism secure or to review all code for all applets to make sure they are "trustworthy"

    I would think money making conspiracies aside the first approach is a solvable problem while the second is a hopeless fools errand... perhaps I'm wrong given there are just 3 remaining people in the world still using java applets on their websites.

    • Why isn't sandboxing applets the responsibility of the browser?

      • Why isn't sandboxing applets the responsibility of the browser?

        I have not made or even hinted at the above claim. OS jailing of browser and browser jailing of extensions are important yet insufficient.

        Java runtime is closer to the application space and therefore best positioned to make contextual access decisions regarding resources it controls or arbitrates in applet mode.

        Consider the case where java is running in a sandbox and an application is able to escape the java applet runtime into the execution environment of java runtime. While this does not pose a threat t

  • It currently costs a minimum of $100/year

    Wow, I'm a malicious java programmer and this is really going to stop me!

    Scarlett: Rhett, Rhett... Rhett, if you go, where shall I go? What shall I do?

    --
    BMO

  • Legacy (Score:4, Insightful)

    by mwvdlee ( 775178 ) on Thursday September 26, 2013 @03:56PM (#44963981) Homepage

    Does this mean the new Java will start bitching about legacy Java applications I've been running for years?
    What will this do to companies that run their own Java applications? They can no longer apply security patches for Java in the near future without the massive cost of repackaging their self-made Java code?
    This has "money grab" written all over it.

  • Honestly, while having users authenticate a self-signed cert in a browser did help with security, etc it also broke a lot of devices. I still cannot use my WRT54G with any modern browser aside from the default browser on Android 2.3.6; same with my newer model router with latest firmware.

    And honestly the problem IS NOT the hardware I'm accessing - its the stupid browsers.

    They're only going to cause the same kinds of headaches for everyone.

    P.S. I'm not in favor of Java or Java Appletes, but it still
  • So that pretty much means that they are admitting that they never managed to get sandboxing to work properly for Java.

  • by hobarrera ( 2008506 ) on Thursday September 26, 2013 @11:17PM (#44967317) Homepage

    So Java applets will become less common on the internet? OMG, I can't belive this!

"If it ain't broke, don't fix it." - Bert Lantz

Working...