Hacker News Reader

I need java support in the Browser. Have you ever tried to use it? You have to do no less then 10 clicks with lots of warnings and restart the browser in order to activate it, and that's only for one site. And you have to repeat that for every website that uses java-applets.

It's a way easier to download a binary and execute that.

It's dead for the end-user for every meaningful definition of "dead".

Also ActiveX was the MS answer to Java, not the other way round.

> It's dead for the end-user for every meaningful definition of "dead".

Unfortunately not, there are MANY institutions that still rely on Java Applets.

That's why this might be a noble thing for Oracle to do. Institutions around the world are harming their users using this tool, and it's possible Oracle could encourage them to stop doing that. (Although frankly just mentioning the possibility that an action might be the right thing to do, seems to make it less likely that Oracle would do it.)

Practically nobody is exploitable! Only signed Java applets on a whitelist can be run: https://www.java.com/en/download/help/jcp_security.xml

You must be either exaggerating or not up to date (not aware that not every applet is automatically run). I don't think anybody is getting harmed. What do you think a realistic attack scenario using Java applets looks like? You'll have to break RSA, or how are you going to fool the browser plugin to run your exploit?

GGP comment observed that many people can't avoid using Java applets. Others have observed that the Java people have to use for applets is often quite old, so it is perhaps as old as the Java I used the last time I had to use Java applets. I'm sure that very few of us are "up to date"; that's kind of the point. Perhaps there are strange applet fetishists who keep their Java package installs at the bleeding edge of postmodern Java applet specialness. Even so, forcing normal people to use Java applets is harming your users, because normal people turn it off.

As recently as last year I've seen browser apps that require Java 1.3. As in they won't work with Java 1.4+. Until browsers kick Java out, Java applets aren't going anywhere.

"I can't think of any applications that couldn't be made with JS and html5, so institutions must have no reason to use Java besides wanting to harm their users"

https://developer.chrome.com/apps/usb

The thesis says nothing about access to the underlying hardware. Incidentally, Java has it and Javascript does not have it.

Have you ever programmed in java or javascript.

don't worry, its just a freshman that learned about the church-turing thesis a few weeks ago and wants to sound smart.

k from now on write all your web apps in assembly.

Wait are you trying to say that java has less boilerplate than javascript?

Yes, that's way I said "end-user". If you don't know what java is, this does not affect you.

The only way to file a (mandatory under penalty of huge fines) monthly tax report for a business here where I live is a web service that requires Java (or ActiveX) to do a digital signature for filed documents. There is currently no alternative (JavaScript APIs for that do not exist). Same goes for all other digital banking - requests have to be cryptographically signed and Java is pretty much the only widely portable way to do it.

Is that "end-user" enough for you? All busness owners in the country and all other general population doing eGovernment?

These governments and institutions should be called to task, PMs/ministers/MPs impeached if need be. Their negligence or refusal to act on this matter is a threat to national security. Literally.

PMs impeeched over java applets? get real.

I don't understand - there are end-users in those institutions using java applets. They have to use java applets because their institutions mandate their use for anything from bug tracking software (yes really, I've seen it with my own eyes) to expenses software.

But almost all of these end-users have admins. People that activated java in the browser form them. And these can take care of the updates.

I'm still not sure what you're getting at here. It's a zero-day exploit. Updates won't help with that.

Java-applets in the internet are not used anymore as i explained. And if quite a few poeple use it in their intranets they don't care particular for a 0day. If their intranet is used to deploy these, everything is already lost.

Even if the webbrowser that displays the intranet applets is used to surf the internet it's not a attac surface as you have to whitelist every site that's able to use applets.

If you live in Denmark, you are all but guaranteed to be an "end-user": https://en.wikipedia.org/wiki/NemID

Since the Javascript NemID client was introduced last year, most users don't need Java anymore.

That's for OTP though, users with tokens or keyfile have to use the OpenSign applet still. Haven't seen any stats, but OpenSign usage is probably pretty small compared to standard NemID/OTP.

> Also ActiveX was the MS answer to Java, not the other way round.

Except ActiveX goes back to Windows 3.1 and OLE 2.0.

Yea, this is exactly because of the security problems.

One of those crufty little shops is ADP, one of the biggest payroll processors around. I hate that I have to use their applet crapstack, but it's not so simple to just turn it off.

Very true, but Step #1 is to declare it deprecated.

Look, Microsoft is still struggling to retire Windows XP, a 14-year old operating system that was end-of-life'd over six years ago. However, at least they've been TRYING... and sending clear signals that support won't extend indefinitely.

Oracle, however, hasn't even begun the official process of winding down applet support. So why should ADP, or any other "captive-audience", "bare-minimum" crapshop even consider putting migration plans on their long-term timeline?

Just say it's deprecated. You don't even have to commit to a fixed end-of-life date yet. Just start the ball rolling with a signal that remaining on applets into the 2030's won't be a viable long-term vision. It might well take a decade or more to fully wind it down, but the first step is simply signaling your intention to eventually do so.

At this point, it's hard to argue that benefit of perpetual applet support isn't outweighed by the harm that it inflicts on public mindshare for the rest of your platform. At least start signalling that this cruft is going away eventually, to change the narrative about Java overall being cruft in general.

Why would Oracle voluntarily cut into their support revenue?

As I just indicated above, they should do so because the support revenue stemming from applets is surely outweighed by the damage to their brand overall.

However, given that Oracle still pushes the Ask.com toolbar in their consumer-facing installer, it does seem clear that they are not yet concerned about that calculus.

Perhaps if Microsoft's open-source, cross-platform changes to .NET makes them a more significant threat in a few years... or if maybe some newer emerging non-JVM language starts to gain traction in the enterprise... then Oracle will be pressed to drop its complacency. That is indeed a very slow-moving world, but Oracle practically radiates a "We Couldn't Care Less" vibe, and that would seem to make it vulnerable to disruption at some point.

>they should do so because the support revenue stemming from applets is surely outweighed by the damage to their brand overall.

'Surely'?

If that were the case, why wouldn't Oracle have already done so?

Why don't you assume that Oracle has already run the numbers on how much they collect from enterprise contracts to support all manner of legacy technologies (including applets) and choose to exploit it? A good portion of Oracle exists just to service that revenue stream.

You want them to also drop another revenue stream (Ask/Yahoo co-branding) because of the "damage to their brand overall" from a co-branded installer? Sounds like a good way to give Larry a chuckle.

I doubt many who care about the terrible JRE installer would suddenly start sending cash Oracle's way because they removed the Ask/Yahoo bundle.

> However, given that Oracle still pushes the Ask.com toolbar

They don't do that anymore. http://www.pcworld.com/article/2940688/java-installer-ditche...

And have replaced Ask with with Yahoo.

Because of the shame and brand damage of making such a terrible product? And because people who want to call themselves professional engineers have a moral obligation not to knowingly fuck things up for their users too badly?

A car company shouldn't sell a car with defective brakes, even if the defect was great for replacement airbag sales.

> Because of the shame and brand damage of making such a terrible product?

From the article: this is the first Java zero day in two years.

Now how many other products we use all the time have had no zero days found for two years? Chrome? Windows? No.

What's more, it's not totally clear that this is even a problem in Java itself, seeing as it apparently relies on a Windows-specific common controls library exploit? There aren't enough details in the report to say, but it seems likely that this is somehow (ab)using AWT to trigger a bug in Microsoft's code.

>Oracle

>the shame and brand damage of making such a terrible product

I agree. If anything, owning Java is a brand improvement, based on my (admittedly limited) experience with other Oracle products. But that's just my personal opinion.

Look at Microsoft receiving multi million dollar payments for continued XP support, there's the potential for more support revenue by announcing the intention to EOL.

One of the companies I worked for used an applet to load data from a webapp and insert it into an Access 1.0 DB file in the users hard drive.

After exporting the data, the user would have to run a really old gov't program (to which the Access DB file belonged) to upload the data to a legacy server, over X.25 (click an icon on the desktop).

The most important requirement is to use the DB file installed in the user's hard drive (always same directory, no way to change it): can't generate new ones because the gov't program stores some cryptic arcane data in it, and even though we could reverse engineer it, we wouldn't be legally covered if we sent the wrong cryptic data.

Second requirement is: users are ignorant, don't know how to save files and how to navigate directory trees, 'computers = magic' to them.

How would you address this situation?

Have them download and run a desktop program. You could even write it in Java and also bundle a jre within an exe for actually better overall experience for windows users.

The Web only goes so far.

> Have them download and run a desktop program. You could even write it in Java and also bundle a jre within an exe for actually better overall experience for windows users.

Yeah, it would work. Could even have used Java Web Start.

The webapp would have to be developed as a web service with a desktop client (and maybe a web client as well), as the data created by different users, with different roles, and in different office buildings, had to be shared.

Is it OK to bundle the JRE in a closed-source program, though?

It is not only OK but expected to distribute the JRE with your apps.

Yeap. It's preferred to vendor a JRE (non-system JRE) inside your app (which is basically just extracting it to some dir you always control), which doesn't conflict with whatever else is on the box (no registry settings, /etc/profile or common locations like /usr/some/unix/path/to/system/jre ), and auto-update your app which includes updating the JRE. This is how to deploy a supportable app, which reduce support tickets about "you broke our apps, our IT department is going to call our VPs and is going to call your VPs" and pre-sales issues like "we can't buy this because we can't change JRE versions."

https://www.java.com/en/download/faq/distribution.xml#eula

>One of the companies I worked for used an applet to load data from a webapp and insert it into an Access 1.0 DB file in the users hard drive...After exporting the data, the user would have to run a really old gov't program (to which the Access DB file belonged) to upload the data to a legacy server, over X.25 (click an icon on the desktop)....

> How would you address this situation?

Well, first I would sign up for a github account. You know steps two and three.

I just noticed this got downvoted. What I meant is that in a situation like that it's really time to polish your github and linkedin, so you can quickly get a different job. If it's a fragile legacy system with Access 1.0 (!) and a bunch of external requirements you aren't allowed to touch, how much of a change can you make?

I wish to God that Oracle would simply deprecate and discontinue browser-side Java applet support.

Oracle's flagship ERP product is Applet-based, so I doubt that's going to happen anytime soon.

Killing it might be hard as long as companies like Cisco base their products on it. We tried a dozen of teleconferencing programs and none was able to beat Cisco Webex Java applet. Ugly? Maybe. Slow to start up? Indeed. But just works on anything (Windows/Max/Linux/Android etc.) and doesn't spin up the fans in my laptop to 100% like Google Hangout does.

Nope, Webex it doesn't work on: * Android (tested 4.4.4, app opens chrome on a page that asks to install the same app, when opening with firefox it says that it is not supported) - why app would open a browser is beyond me * Linux 64bit - screen shared by others is not visible

My company just transitioned to a Java applet-based time clocking/PTO/etc. management application.

The first time I opened it and it brought up the little Java prompt, I was like, "Really?"

I hope it's not kronos. That one always started with the bereavement days shown.

Yep, it's Kronos.

Fortunately, I only need to use it when I request PTO. I feel sorry for the hourly employees that use it several times a day.

A _lot_ of really shitty "web interfaces" which are actively supported/created/updated for enterprise products use java applets. They are universally pretty terrible (as are, in my opinion/experience _most_ user interfaces running on any JVM).

Lots of companies and lots of developers give lots of fucks about Java web UIs. Because Java programmers are commodity programmers. Everyone knows the language and inexperienced programmers can be productive in it without any great risks. (Not to say that there should be any strong association between knowledge and usage of JVM tech and competence, it's just anything that reaches that depth of adoption is bound to have lots of ... mediocrity)

>> They are universally pretty terrible (as are, in my opinion/experience _most_ user interfaces running on any JVM).

Including web or just client side? If the same UI's that you consider terrible on the JVM were ported to say, well pick any language/platform and ported exactly but using your preferred language and platform features; would the interfaces now be better since they are implemented on your desired language/platform?

> some horrible crusty shops still running on XP

Um, some shops still running on XP have a good reason to do so--generally some piece of hardware that the vendor never found worth the time to update the device driver.

The fact that Vista and later broke device driver compatibility with XP is THE single thing preventing those of us who would like to upgrade to a newer OS from doing so.

Microsoft thought that breaking compatibility with things like Visual Basic 6 and XP device drivers would force people to upgrade. Instead, it caused people to put a stake into the ground and never upgrade ever again.

Ugh, how I envy your reason. Unfortunately, I work in higher education, where things move at an agonizing pace. As such, I end up having to use a lot of Java applets just for the sake of compatibility with the framework the college has been using for over a decade (Adobe ColdFusion). So, as much as I'd love to kill Java applets, I still rely on them. Sadly, this is a case where culture will have to change before tech will get its chance.

You're probably right... at the very least, they should re-brand the applet container because it does create massive amounts of FUD.

As others have noted this is really a Windows issue, not an inherent flaw in Java. And as you note it seems to be a problem in the applet plugin, not necessarily the standalone J2SE runtime. It should be possible/obvious/necessary to install the two separately on Windows.

With the advent of things like NaCl, Emscripten, and WebAssembly these things should not be necessary anymore. Undoubtedly these new technologies will be able to properly sandbox untrusted obfuscated compiled code perfectly and should immediately supplant things like applets.

You can't. Plenty of expensive software runs a Java UI, browser hosted. Though, they often need older JVM versions as they don't run with the latest update.

I don't think Java is enabled by default in any install, is it? So what's the risk?

It usually is, at least that's been my experience on Windows. I have to usually disable it myself after installing the JRE, because I know where that game is going (usually ends up being disabled by Firefox automatically eventually).

In some countries banks seemingly used to have to use Java for online banking (may not be the case anymore).

my bank in brazil still uses a java applet for "security measures". i complained about a thousand times but they still think it's more secure to use a java applet than using nothing.

It's absurd that the official Java runtime for Windows comes with crapware and spyware ... Ohh, your program requires me to install Java? Then I think I'll pass. Just include the runtime (around 140mb) and your customers won't know or care that they are using Java!

Cookies are the hidden spyware far worse then ticking a checkbox that asks if you want to install something.

Plain java software can also have exploits made for them but they are not as widespread so it is not as common or not worth the trouble