If I was a blackhat malware developer, I would be drooling at the scale of Oracle's incorporation of third party affiliate software into a typical Java install. It massively expands the threat surface available for attackers.
Rather than targeting the JRE itself, I would be looking for vulnerabilities in the shovelware -- which is subject to less scrutiny by developers than the language runtime itself, and which is only installed by users whose security practices are less than perfect.
It's not impossible there'd be something interesting there... but Java is a more likely attack vector simply because part of its normal functionality is to execute code downloaded from the internet.
Before this recent patch, that code would be executed without even prompting the user.
Sure, there's a sandbox, but (as we know) sometimes a sandbox has cracks, particularly when the runtime is designed to let code to only enforce the sandbox for some code it runs, not all. (Compare to JavaScript execution, which also runs downloaded code without prompting, but JS in the browser is always in the sandbox -- there are things it simply can't do, vs. Java's "this is do-able but not for you".
Ah, Oracle - it was only a matter of time before Oracle was seen as so untrustworthy that people now won't even install Java. Oracle are still strong, but reputation does matter. You kill off your reputation, you weaken your company.
There are a lot of companies who would love to take out Oracle.
"People". Oracle software (DB, Java, etc, behind a firewall(s)) runs in every big company. The people reading this probably are still using Java (Clojure, Scala etc) from Oracle (as OpenJDK sucks), so what 'people' are you referring to? A consumer? Nope; doesn't care. Who is 'people'?
I'm not a fan of Oracle or anything, but I have worked for enough big companies (Oracle's paying clients) to see that this won't matter at all to Oracle's bottomline. And probably not much to their reputation either; I used to run OpenJDK on my smaller devices like my pandora; Oracle made an ARM version of the closed source JDK. Now I really want to use open source, but that binary brought tears to my eyes; it's blazingly fast, seems to use less memory than the other versions, is stable compared to openjdk and it showed that Java indeed is in the hands of Larry fully. There is no other option for Java and JVM languages.
I guess there're also a lot of people in the tech industry who would like to see Oracle going out of business. Really, everything they touch seems to instantly get worse. See Java.
I've pretty much always used the offline installer with Windows (I'd stick it on a flash drive and keep it in my bag with other useful installs like editors, SSH, etc.). But it's worth pointing out that this is a Java-on-Windows problem exclusively. It doesn't happen on OS X or Linux. I can't imagine the day when "apt-get install default-jdk" prompts me to install a toolbar...
I would have said that I can't imagine the day when searching my Ubuntu machine would return Amazon.com results, but that day has come, too. So yes, for now, it's a Java-on-Windows problem exclusively.
True, but remember that you can't apt-get the JVM anymore since Oracle changed the license for the newer versions, so I could very well imagine this happening to me on my Linux box unless my company switches over to OpenJDK.
I've found https://github.com/flexiondotorg/oab-java6 really useful. It's a shell script that downloads the Java binaries from Oracle, builds Debian packages for them, stashes them at /var/local/oab/deb, and adds this directory as a local apt repo for your system. The net effect is 'apt-get install sun-java6-jre' works again like it used to.
The article mentions to install the 32-bit offline installer but what if you are 64? I know 32-bit will work but are there disadvantages to using it over 64-bit? Or can you just download the 64-bit and uncheck the shovelware?
See the note on the consumer-facing Java website regarding 64-bit vs 32-bit versions of the JRE:
> 64-bit Windows operating systems (which may be Windows 7, Vista or XP) come with a 32-bit Internet Explorer (IE) browser as the standard (default) for viewing web pages. These operating systems also include a 64-bit Internet Explorer browser, however using it is optional and it must be explicitly selected to view web pages. Note that because some web content may not work properly in a 64-bit browser, we recommend using the default 32-bit browser and downloading 32-bit Java.
Unless you're one of those that need to run Java applets, I don't see the issue. I used to have issues with the Android SDK and 64-bit Java on Windows, but those seem to be resolved lately.
The advice in the ZDNet article is for non-technical folks. The greatest likelihood is that they'll need a JRE for running Java in a web browser, not doing development. In which case they should use the 32-bit version, even on 64-bit Windows.
If you're doing development, well then shame on you for not already knowing what you need. You also probably won't want the JRE, you'll want the JDK, which doesn't come with the shovelware anyway.
If you're a developer and you just need to run some Java utilities, then you'll probably be fine with the 32-bit JRE.
Basically, if you really need the 64-bit version, you probably already know it.
Can someone explain to me why they even bundle this extra shovelware in with their JRE installer? Surely the revenue gained from this is a minuscule fraction compared to their total revenue. Plus, this can't be good for their brand. So, it raises the question - why?
How will it work? Candidate applications will be submitted via a simple web site, evaluated by Sun for safety and content, then presented under free or fee terms to the broad Java audience via our update mechanism. Over time, developers will bid for position on our storefront, and the relationships won't be exclusive (as they have been for search). As with other app stores, Sun will charge for distribution - but unlike other app stores, whose audiences are tiny, measured in the millions or tens of millions, ours will have what we estimate to be approximately a billion users. That's clearly a lot of traffic, and will position the Java App Store as having just about the world's largest audience.
I vaguely remember the Google Toolbar and OpenOffice being shovelware'd with the Java installer pre-Oracle; the choice of bundles has changed but the practice hasn't.
I'm very distant from Java-land right now and equally distant from desktop development so I know next to nothing about the matter, but one of my co-workers is using PyCharm and is praising it every single day (as a former vim user, at that). So I can't help but wonder - how did Java fail, in your opinion, and what other framework "won", if any?
I agree somewhat with btip. The UI features of Java were not only ugly, but, until 6.0, slow. This is one of the reasons Eclipse uses SWT rather than native Swing.
6 brought with it a much faster UI experience. Unfortunately that happened after the transition of apps from the desktop to the web. So you had slow applet downloads vs Flash on the client. You also had compatibility issues that were more involved than Flash.
Finally, other cross platform frame works like Qt came along. Now you'd get closer native appearance with languages other than Java.
As a result of the confluence of events and changes Java became relegated to server or phone side.
Note the comment you are replying to qualified it to 'desktop' framework. Obviously Java is very popular on mobile, servers and in enterprise. On the desktop, beyond Minecraft, Eclipse, Azure and OpenOffice there aren't a lot of other popular desktop Java apps.
Java on the desktop failed because of .Net, because the UI widgets on Java looks horrible and nothing like the OS, and because Sun wasn't a consumer focused company and neither is Oracle.
Exactly what I meant, yes. There are a lot of places Java has succeeded, but being a framework to write and run desktop applications for the mass-market end-user consumer (a task which it was once positioned to excel at) was not one of them.
And all it took was a little user-focus and design work. Never happened. Very shortsighted IMHO, but I also believe it was not possible at Sun or Oracle. Just not in their nature.
Does anyone find it ironic that the background in the zdnet website is one huge clickable ad designed to capture accidental clicks? I tend to keep my hand over the trackball while reading for quick scrolling. I move the cursor off to the side so as to not cover the text. Yup, accidentally clicked on the zdnet background add twice while reading these articles. Funny that they are taking Oracle to task for their practices yet take an equally slime-o approach to monetizing their site.
If their justification is "the one that developers use," then you want the 64-bit installer. No one is intentionally confining themselves to 32-bit these days, except under very specific circumstances (usually non-x86, or embedded, but that's 99% irrelevant to a Java discussion).
Browser plugin issues not-withstanding, of course. But who uses Java in a browser anymore?
A decent number of game educational sites, including mine: http://eMusicTheory.com -- in a small Java applet, I can process MIDI and audio input, assemble digital audio on-the-fly for output (or use MIDI, but they stopped bundling the sounds), animations, etc. within pretty much any browser starting with IE5 or 6.
There's nothing else as powerful AFAIK.
Java's security problems seem like they'll kill this off, unfortunately.
How viable is OpenJDK JRE as an alternative for the average user? i.e. if I install it instead of the Oracle JRE next time I'm reformatting, is the Java software I use likely to stop working or develop bugs? I don't understand why Oracle would be driving people away from their platform like this.
Try it, as it depends on the applications you use. Some members of the jetbrains family didn't run on OpenJDK for a long time. The ones I use do now.
That said, if your platform lacks an installer and -more importantly- an updater, OpenJDK is not a good alternative. There's no reason to assume it is any more secure than the Oracle package except for the lack of additional toolbars.
Great, thanks for the tip! I just switched over to Mint a few days ago, and so far loving it. I install and reinstall Linux so frequently, that anything I can do to make the process less painful is useful.
For what it's worth I'm always installing Java on Linux servers without using root rights (so no rpm, no .deb: rpms but good old tarballs).
Certainly no "apt-get install whatever-jdk" for me. No, thank you very much. I want to be in control.
So I install the JRE (or JDK) in a user account and, once the .tar.gz file is decompressed/dearchived I do remove the unnecessary crap (examples, applets, etc.).
That's one big advantage right there about not needing to have admin rights to install: you know where all the files have been installed (in the user account, it's not possible to write anywhere else without being root) and you have more control on the crap.
That's not really possible to do as conveniently on Windows seen that you must have admin rights to install Java on Windows.
If stuff isn't running as root, but still running as you, that still gives it access to a fair amount of private data. So, to keep really suspicious code from reading your banking details, etc., you need to run it under a different uid than the one that runs, say, your web browser.
Yes we do that as well. All java processes are given a single local user account. They have their own JDK installation as well.
We even go as far as creating a new user account, deploying a JVM to it and wiping down during our build process so we get a consistent environment every time.
Rather than targeting the JRE itself, I would be looking for vulnerabilities in the shovelware -- which is subject to less scrutiny by developers than the language runtime itself, and which is only installed by users whose security practices are less than perfect.