Java Deployment Toolkit plugin & Firefox.

[choi_choi]

This thread is meant to be an updated discussion on the "Java Deployment Toolkit" firefox plugin. This plugin is not to be confused with the "standard Java" plugin needed for Java content in the browser, that one is called: "Java(TM) Platform SE." Oracle likes to call Java Deployment Toolkit, "Java DT." The Java DT plugin is not related to your general usage of Java (and is not required to be activated/running to enable Java content in the browser so it's safe to "delete" it without losing your Java functionality on various websites.) As of 9 October 2014, the latest version of the Java DT plugin is still considered to be "vulnerable" by Mozilla and is blocked by default. The Java DT plugin is also not designed for ordinary people like you and me -- it's designed for an exceptionally small number of people who either tend to be "Rich Internet Application" developers or network admins commonly using IBM's HMC and who need firefox due to software restrictions. I chuckle at that last part because in my previous work experience, firefox usage was globally banned everywhere.

(9 October 2014 edit...)

Here's instructions on how to "delete" the Java DT plugin "for now." Note: it probably will come back when you update Java in the future:
1. Open "about:plugins" without quotes as a URL in firefox. (You might need to click "yes/OK" to a cutesy message that pops up saying something like, "changing these settings could void your Firefox warranty!" or something along those lines.)
2. In the about:plugins page, scroll down to where it says "Java Deployment Toolkit", make note of the associated .dll file (it's probably "npdeployJava1.dll" but it could be different for you), and then copy the path to the .dll file (everything before "npdeployJava1.dll".) The path can be different depending on which version of Java and OS you have installed. For me (as an example), I had a 32-bit version of Java v7 installed on Win7 x64 and that path was: "C:\Program Files (x86)\Java\jre7\bin\dtplugin"
3. Close all Firefox windows, this is important.
4. Now browse to the path location you copied and from there you can delete the .dll file that's associated with the Java DT plugin (again, it's probably "npdeployJava1.dll"). There might be more than 1 .dll file in that location but just delete your noted .dll file that was associated with Java DT.
5. Open Firefox and the Java DT plugin in your list of plugins should be gone.
Additional notes:
1. It's possible there may be more than 1 .dll file listed for the Java DT plugin(s), for example you have multiple versions of Java installed like v6 and v7 at the same time and in that case there might be a v6 DT plugin and a v7 DT plugin. I've confirmed Java v8 also has a DT plugin as well so be sure to note exactly what "about:plugins" is saying about the Java Deployment Toolkit plugin(s).
2. As stated above, the Java DT plugin will probably "come back" when you update Java. My recommendation: a more permanent solution to get rid of these plugins (and if you don't need Java content running in the browser) is to turn off Java completely for the browser and Oracle has a good, simple guide on how to do that. Following that guide will get rid of all the Java plugins immediately (so you wouldn't even need to follow the previous instructions) and will also prevent these plugins from reloading/reinstalling in the future when you update Java. This method is ultimately safer because you wouldn't need to worry about the sensationalized "drive-by" Java exploit attacks on the browser if you were to accidentally allow a malicious Java web applet to run.
3. I wouldn't be surprised if these instructions are out of date in a couple months considering how many changes are made to the Firefox config and GUI on a monthly basis. A lot of people here like to hold onto ESR versions of Firefox and legacy versions of software like Java v6 because they're resistant to change and I kinda frown on that behavior from a security standpoint. Or, it could just be that the applications you use are out of development and you simply need legacy versions of browsers/Java in order for them to work -- I've been in that situation before and understand you. However, if you're the kind of person who is resistant to change, I don't believe Firefox is the right browser for you. In case these instructions aren't working, I suggest replying to this topic (if it's still open) and make a few comments if things aren't working. I might update these instructions periodically.

(continuing my original post from 6 October...)
Anyway, after finding many mozillaZine threads (and countless more Mozilla support questions) on this plugin and also finding somewhat dated information on the Knowledge Base article, I'm interested in bringing up the discussion again due to this plugin's affinity to cause mass confusion and its ability to come back when you think you've deleted it. It will come back once you update Java. It came back for me and I was just curious if any of you experienced the same. I guess I'm looking for a way to permanently never see these plugins again, and turning off all Java content in the browser seems to be the answer for me. Sites like Pogo are already moving away from Java-based gaming and my Java applications like Minecraft will still run just fine in a standalone (non-browser) environment.

Doing a little bit of digging, I'm finding quite a bit of Mozilla drama in regards to this plugin and I question why Oracle would keep reinstalling this plugin when the user updates "Java." I'm assuming that Oracle knows that firefox is still perpetually blacklisting this plugin as "vulnerable" until security issues are resolved. Why wouldn't Oracle offer Java DT as a "niche" download if it was intended for a niche audience who are keenly aware of its security implications? Why cause the mass hysteria and bundle it with Java SE? Might be a question for Oracle and not here though.

P.S. For those of you looking for "alt fixes," I would strongly discourage things like registry hacks. Firefox configuration settings get turned on a dime every other week. Before you know it, your entire installation will probably get corrupted in an attempt to prevent firefox from auto-scanning new plugins.

[costark]

viewtopic.php?f=38&t=2632007
Start at post #9 Oma1942 instructions (With the Toolkit ENABLED in Plugins) and then #12 Daledoc1 Reply

[Oma1942, I tried your approach again after a night's sleep (even though I thought I had done it all correctly the first time or two)...
... the "about:plugins" step was the key, as the correct file path on this x64 system turned out to be c:\Windows\SysWOW64\npdeployJava1.dll
There it was!
Deleted it and now the Java Deployment Toolkit is gone!

Is above any Different than your Prior Attempts??? [Note: Doing this did NOT result in a Toolkit Re-load for my Win 7 Hm Prem.]

[choi_choi]

http://forums.mozillazine.org/viewtopic.php?f=38&t=2632007
Start at post #9 Oma1942 instructions (With the Toolkit ENABLED in Plugins) and then #12 Daledoc1 Reply

[Oma1942, I tried your approach again after a night's sleep (even though I thought I had done it all correctly the first time or two)...
... the "about:plugins" step was the key, as the correct file path on this x64 system turned out to be c:\Windows\SysWOW64\npdeployJava1.dll
There it was!
Deleted it and now the Java Deployment Toolkit is gone!

Is above any Different than your Prior Attempts???

Well I don't know about version v7u10 as indicated in that thread (from 2012), but for me a recent install (pre-v7u67) pegged the plugin in "C:\Program Files (x86)\Java\jre7\bin\dtplugin". Even though I have a x64 version of windows, I still opted to only install the x86 (32-bit) version of java (due to extremely lazy programmers ) and this is where the "about:plugins" listed the Java DT plugin. In my case, I simply renamed "npdeployJava1.dll" to "npdeployJava1" in that folder and voila, the plugin was gone...until I updated to v7u67, when it came back. It could be that the u67 Java installer saw the misnamed file and simply appended a ".dll" on it and that resulted in a re-load, but I'm not sure. Also, I didn't actually "activate" it since there was nothing to "ask to activate" with -- it was just sitting there in the list of plugins being defaultly blocked by firefox, but the "about:plugins" had no problems locating it.

Like I said in my situation I just removed all Java content from browsers via Control Panel -> Java (32-bit) -> Security tab -> unchecked "enable Java content in the browser" and now all of the plugins are gone...and I'm assuming will be gone if I update again. Although, who knows, Oracle could pull another fast one and just revert all the settings again on an update. Btw, bonus setting in that Java control panel: switch to the Advanced tab and scroll all the way to the bottom then see 2nd option from the bottom

[Note: Doing this did NOT result in a Toolkit Re-load for my Win 7 Hm Prem.]

I'm assuming you also have a x64 version of Java like Oma1942 and you've also updated to a recent version of Java since deleting the plugin file. However, when was the last time you updated your x64 version of Java? The Java updater tends to pick up on the x86 version being out of date but the x64 is a standalone version that you need to manually update yourself it seems.

[choi_choi]

You know I just realized something -- I did have JDK installed at one point in time when I was fooling around with compiling some Java code for an old Object-Oriented Programming class I had a few years ago. However, JDK has long been uninstalled from my list of programs. It's possible (and I'm really speculating here) that the new JRE installer indeed saw that I had JDK installed at one point in time and thought it might be a "good idea" to go ahead and reinstall the Java DT plugin because hey, I was a programmer at one time and might possibly need such a developer tool in the future. Maybe that's what user "TheOldFox" meant when he said,

You may need to do this after each update as Java has always reinstalled JDK with each update.

I'm assuming that Oracle's clever /sarcasm naming convention is also adding "term confusion" to us technical people as well.

So perhaps this annoyance is only bugging those of us who have had JDK installed in the past.

Also, a side note when browsing the Java downloads that are available today...Java v8 has been out for some time now (nearly 7 months) and is probably worth an install over v7 by now. I'm assuming that a lot of you are still holding onto v6 with a tight clench. If Java v8 was that bad, I would also assume we would have been hearing more complaints about it by now. So, I think I'll take the plunge and see how many applications will break because of it...wish me luck.
Here's to knocking on wood that the DT plugin will probably get reinstalled again as well.

[choi_choi]

Thought I'd pop back in to give you guys an update on my experience so far on the Java v8 upgrade...no issues so far! In fact, some applications like Minecraft actually seem to be performing noticeably faster over v7 so I would say it's a pretty compelling download if you're interested in keeping things on the "up and up." That game is running smoothly on high settings on my 5 year-old GPU with legacy drivers and that's pretty impressive, imo. No changes need to be made to other existing applications too which I like...I would say though first uninstall v7 (and/or v6) before installing v8 because applications might be tempted to use an existing v7 (or even v6) Java installation first and then you'd be guessing at that point if v8 is making any difference. Haven't tried the x64 version yet and probably won't. Good news is that the v8 installer actually "remembered" my old (uninstalled, no less) settings of "no Java content in the browser" and gave a nice reminder message about this in the install process -- no additional plugins were installed/reloaded. Bad news for you XP lovers: v8 is incompatible.

Here's a "laugh out loud" moment for those of you closely following along before deciding to install: http://imgur.com/oKgBX1L
(and yes, the MD5 (side lol, MD5 ) checksum "checked out" on Oracle's site)

To get back on-topic though, I also installed v8 over v7 on my 4 year-old netbook as well (32-bit Win7 OS). Turns out there's a v8 Java DT plugin (still defaultly blocked by firefox, lol) that gets installed if you've deleted the older v7 plugin. TBH, I kind of expected this. I also had JDK installed on that netbook as well some time ago when I was a college student so who knows. I decided to turn off Java content in the browser on that machine as well and then the plugins were gone. Hopefully that's the end of it.

[choi_choi]

I updated my original post with (hopefully) clear instructions on how the delete the plugin and some of my own recommendations. I didn't realize that some of the older guides were way out of date so that's why I just decided to write my own. Mods, I trust everything looks copacetic to you and I look for any feedback on this. I was wondering about possibly providing screenshots as well but hopefully the "layman" just stopping by can understand the post enough?

[choi_choi]

I believe this important update warrants a bump here: just yesterday Oracle announced they put out another quarterly "critical patch update" fixing a whopping 154 vulnerabilities across various Oracle products, including 25 new Java SE vulnerabilities. They describe that in their security advisory page, they mention that you will see a "stronger than previously-used statement about the importance of applying security patches without delay." Other than a boldface "normal font sized" paragraph, I'm not really finding any evidence of that claim.

Considering the fact that there is no "automatic" deployment of Java patches (unlike Windows updates), I can see why they complain that they routinely continue "to receive credible reports of attempts to exploit vulnerabilities for which fixes have been already published by Oracle years ago, but their non-application by customers, particularly against Internet-facing systems, results in dangerous exposure for these customers." Well herpa-derpa geniuses, the sad fact remains that if you never design an "automatic" update mechanism, MANY users of your product will NEVER update the software.

Getting back on-topic once again, in this new update (at least for v8u25 for me), get ready for another unexpected design change which basically adds more confusion (you Firefox users should be completely used to this by now.) The "Java control panel" is no longer located in the Windows control panel (flash's panel is still there btw.) The new Java control panel is now located in the Windows start menu, in the Java directory (good luck finding it Windows 8 users ). Thankfully, Oracle has another handy guide on how to find it. For you Win8 users, "Press Windows logo key + W to open the Search charm to search settings" -- pretty convenient huh?

So again, moral of the story, update your Java "without delay" or you can wait for the Java update "notifier" to wait until Friday noon for its default "weekly" check -- "without delay." I'm seeing some reports that the default installation on Java.com now being offered is in fact Java 8 now, that's a nice move by Oracle as it was originally planned for this to happen not until some time in 2015. Much better to offer it (and install it) sooner. I suggest if you find that Java 8 was installed and your apps seem to be working fine, go into your list of installed programs (in the Windows control panel) and then uninstall previous versions of Java like v6 and v7 if you see them listed -- you wouldn't want these old versions hanging around and causing potential trouble in the future.

P.S. The next scheduled quarterly patch update is 20 January, 2015. So mark your calendars people.

[mightyglydd]

Well choi_choi, the moral of the story is, if one has to use the damn thing, keep it updated to the latest version .
FWIW, updated to 8 U 25 (Plugin 11.25.2) on Linux today, runs 'fine'; until tomorrow when no doubt there will be more vulnerabilities........
Oracle should rename it Swiss CheeZe.

[rsx11m]

Since there have been two requests made now to move this to Mozilla Tech I'm going to moving it there, though the discussion as such is also specific to the plugin(s) seen by Firefox once it is installed.

[choi_choi]

FWIW, updated to 8 U 25 (Plugin 11.25.2) on Linux today, runs 'fine'; until tomorrow when no doubt there will be more vulnerabilities........
Oracle should rename it Swiss CheeZe.

I'm not quite sure the Java bashing is warranted. Oracle's PR problems only really started in the past year and half when many in the security community were quick to point out the "zero day" exploits and the apparent lack of "out of band" fixes. Priorities for Oracle at that point were not firsthandedly consumer software like Java SE; they make the bulk of their money at the enterprise-level so their efforts were focused elsewhere at the time and likely didn't have private connections with security researchers like the way Microsoft has. You can see they tried appropriately responding by adding security prompts to running all applets and that was a good move. Mozilla wasn't winning any "usability" favors by overreacting to the situation and defaultly blocking everything related to Java at that time and the "click to play" block release method consisted of unintuitivly clicking a small, 16x16 icon of a red lego brick in the URL bar. In my mind, 2013 was an important year in Firefox's history that saw more of the single-minded "do the right thing" and "we know what's best" attitude that I honestly believe drove away a lot of people...but that's probably another discussion thread so I'll end that talk here. I think we should recognize that Oracle was kind enough to support even Java 6 for as long as they did, and this I think follows a general "good user playability" computing philosophy with older versions of software like even how Microsoft follows and their (still) current support of old software like IE9.

Anyway, I'd hate to see Java get massively discouraged over something that can be traced to a simple item like a lack of an auto-updater and as a result -- over-sensationalized security drama. The technology has been impressive and I enjoyed coding in Java too. I'm honestly surprised at how Adobe has been fairly unscathed in their Flash product; one could arguably say it's been subject to even more vulnerabilities over Java but perhaps their update method is more intuitive/automated.

Wanna know why scary images like these don't make it to local news outlets anymore? Most people have auto updates turned on and security researchers carefully coordinate with Microsoft to keep quiet until patch Tuesday -- no doubt in my mind at all. It's too much of a non-issue (before enough time elapses to make it an issue) these days.

[pol098]

A couple of brief comments to points discussed:
1. I've just updated to JRE 8u25, and I still get the control panel applet under Win7/32. The installation procedure said it was uninstalling JRE 7u67, but I find it's still listed in the (2) versions installed; the control panel applet reports 8u25. I might uninstall 7u67 manually later.
2. A crude technique that can often block installers from installing stuff you don't want, so long as the file pathname is not changed, is to create a write-protected dummy file in that pathname (e.g. c:\Program Files\Java\jre1.8.0_25\bin\dtplugin\npdeployJava1.dll or c:\Windows\SysWOW64\npdeployJava1.dll) I haven't tried this with the Deployment Toolkit. I sometimes use this to prevent myself from inadvertently installing a newer version of a program where I need features of an older version.

[mightyglydd]

I'm not quite sure the Java bashing is warranted.

Oh I am, a while back a security update wouldn't even allow their test page to work..until that security slider was set to its lowest level.. You may want to search/read a number of Java threads here ........the rest; tl;dr..

[choi_choi]

The installation procedure said it was uninstalling JRE 7u67, but I find it's still listed in the (2) versions installed...

Well that's odd. Perhaps a last-minute managerial decision thought it would be a good idea to keep v7 around in case your apps stop functioning and they would fall back to v7 in that case. I've noticed that the installers like to keep old versions around -- I can see why managerially, but they should really uninstall old versions because so few people will eventually go back and manually uninstall older versions because they've now become "security concerns." I'd be curious to see what your PATH variables are (the default directories where java.exe and javaw.exe are fetched from when your apps call for them.) I have a request for you: go into your system properties (right click Computer->Properties)->Advanced system settings->on that advanced tab click "Environment Variables..."->then under "System variables" scroll down and double click "Path" and copy everything in the "Variable value" field and post that here. The first thing listed for me is "C:\ProgramData\Oracle\Java\javapath" which is where the java executables are located, and this directory is unique for Java 8. Any directory listed before another is where apps are going to be looking first and in a case where multiple versions are installed you might have a jumbled list of Java directories so again, please post that -- that should give you a clue on which version of Java your apps are actually using. Btw, I did forget to mention just as a general statement, make sure every app that uses Java is closed before installing/updating Java.

A crude technique that can often block installers from installing stuff you don't want, so long as the file pathname is not changed, is to create a write-protected dummy file in that pathname (e.g. c:\Program Files\Java\jre1.8.0_25\bin\dtplugin\npdeployJava1.dll or c:\Windows\SysWOW64\npdeployJava1.dll) I haven't tried this with the Deployment Toolkit. I sometimes use this to prevent myself from inadvertently installing a newer version of a program where I need features of an older version.

I wouldn't recommend this, especially if your intention is to delete the Java DT plugin or prevent it from reinstalling when you're updating Java. Other apps and their installers may work for you but in this case, you're dealing with an advanced installer which I'm sure its code will include case conditions where read/write permissions in certain directories are denied. Often, installers execute alternative code unforeseen to you and very notoriously, won't inform you about it (in a bid by the installer to "not confuse" the user by giving him confusing error messages.) You may very well end up in a situation where you're breaking many other things in order to fix one thing. The (good) installer takes the standpoint where it "knows best" and operates under the assumption that the user isn't intentionally circumventing its methods. I would say again, to get rid of Java plugins, use the guide by Oracle to very easily remove them permanently.

a while back a security update wouldn't even allow their test page to work...

You know, that might have been one of the very few functions that the Java DT plugin performed as a "normal pc user function" a while ago, but I'm assuming that since Oracle saw that Java DT was being blocked by default anyway, they must have changed around a few things on their site since then. Perhaps this is what Oracle eluded to when they say that "version detection mechanism is disabled" when Java DT is blocked. I seem to recall from a recent visit (at least on the "do I have the Latest Version of Java?" page), default settings worked while Java DT was still listed and blocked. Not sure about their "test page" though. Irregardless, I have no use for Java applets anymore so I won't poke around again. Also, the Mozilla plugin checker page will work fine as well in regards to what I was doing.

[pol098]

Thanks choi_choi for reply.
Before anything else, I'm not asking for support, I can cope fine, and will manually remove JRE7 and edit path-related variables (why JRE6?). This is in case it's of interest or of use to anyone; otherwise ignore.

I'd be curious to see what your PATH variables are

This is the output from SET, with totally unrelated items deleted, and my comments in [*** brackets]

ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\<UserName>\AppData\Roaming
CommonProgramFiles=C:\Program Files\Common Files
ComSpec=C:\Windows\system32\cmd.exe
HOMEDRIVE=C:
HOMEPATH=\Users\<UserName>
JAVA_HOME=C:\Program Files\Java\jre6 [***!!!]
[*** Note: existing directories with sizes and dates are as follows. JRE6 was discontinued many revisions ago:
c:\Program Files\Java\jre1.8.0_25\ 135.5M 16 10 14; ~\jre6\0b 12 09 12; ~\jre7\ 123.3M 06 08 14 ]
LOCALAPPDATA=C:\Users\<UserName>\AppData\Local
Path=C:\ProgramData\Oracle\Java\javapath;C:\Program Files\Broadcom\Broadcom 802.11 Network Adapter;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Dell\DW WLAN Card;C:\Program Files\Java\jre6\bin;C:\Program Files\Calibre2\;C:\Program Files\Kofax\Imgctls\bin;C:\Program Files\QuickTime\QTSystem\
[*** I know what all the paths are and they're not a problem, e.g. Kofax relates to an HP scanner. It's curious though that the very old JRE6 is the only Java path]
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
PROCESSOR_ARCHITECTURE=x86
ProgramData=C:\ProgramData
ProgramFiles=C:\Program Files
PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
PUBLIC=C:\Users\Public
SESSIONNAME=Console
SystemDrive=C:
SystemRoot=C:\Windows
TEMP=C:\Users\<UserName>\AppData\Local\Temp
TMP=C:\Users\<UserName>\AppData\Local\Temp
USERNAME=<UserName>
USERPROFILE=C:\Users\<UserName>
windir=C:\Windows

you might have a jumbled list of Java directories

Indeed ...

make sure every app that uses Java is closed before installing/updating Java.

Good point; I didn't explicitly do that, but every time I update Java I think I'm reminded to close my browser (FF), and I am not explicitly running anything that uses Java (I don't usually keep much open, typically a VNC connection to a server, Notepad++). A few years ago all old versions of Java were retained and had to be removed manually; but more recently I update with no particular precautions and old versions automagically vanish (directories and all, except for the empty JRE6 I just found).

(much trimmed paraphrase) don't use dummy read-only programs to block files being changed

Good detailed reasons not to block with read-only, thanks, I've added them to my archives. I will continue to do this (not for the JDT), but will watch out for side-effects; so far it's always worked for me. I'm always well backed-up in case of trouble.

Thanks again