Closed Bug 790008 Opened 7 years ago Closed 7 years ago
plugincheck encourages installing JAVA
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120824154833 Steps to reproduce: Went to: http://www.mozilla.org/en-US/plugincheck/ Actual results: In red, above step 1, the website reported: -- Missing JAVA? For your safety, Firefox has disabled your outdated version of Java. Please upgrade to the latest version. Expected results: The message is inaccurate. This is a brand new image installed from a Windows 7 Enterprise DVD. I never had JAVA installed on this computer, so it can't be "outdated." It is simply missing. But this is the real problem: Mozilla is pushing Java on people. I don't know if this is compatible with your mission, and in this zero-day exploit climate it is irresponsible of you to do so. Instead, I would expect the same treatment as any other missing plugin - simply tell me it's missing under the list of plugins. This may have been introduced in the work in bug 785837.
I don't have Java and plugincheck doesn't say it's missing.
Component: Blocklisting → plugins.mozilla.org
Product: addons.mozilla.org → Websites
Doesn't happen on IE 9 but for me it does in FF 15 on multiple fresh installs.
Have you other software using an embedded JRE (LibreOffice...)? What does the Control Panel say about Java?
The Windows control panel mentions nothing about Java. The only installed software is: 7-Zip Adobe Flash Player 11 Active X Adobe Flash Player 11 Plugin Adobe Reader X FOG Service (from http://www.fogproject.org/) Intel Network Connections Drivers MS .NET Framework 4 Client Profile MS Forefront Endpoint Protection 2010 MS Office Professional Plus 2010 Mozilla Firefox 15 Mozilla Maintenance Service Installed software that is not listed under Control Panel is: MS SCCM Client Intel Graphics and Media Control Panel (video driver plus a taskbar icon)
Did you test those links? http://www.java.com/en/download/testjava.jsp http://browserspy.dk/java.php http://javatester.org/index.htm
I hadn't yet, but here are the results: First link: "No working Java was detected..." Second link: "No or unable to detect" * 3, "Java isn't installed or doesn't work.", Java using the applet tag: "A plugin is needed to display this content. Install plugin..." Third link: "Browser has Java disabled" And with the last two FF also offered to "Install Missing Plugins..." with a notification bar at the top of the screen.
yeah i can replicate this now on my own mac, marking as confirmed and adding some webdev folks
Status: UNCONFIRMED → NEW
Ever confirmed: true
Localized versions of plugincheck are unaffected.
I am in the process of redoing this, so will take this bug into account during the rewrite.
There's been serious talk since the recent batch of exploits of encouraging people to keep Java disabled if they don't need it. Having the plugincheck page recommend that people without Java or with it disabled install a new version is highly counterproductive. If localized versions are unaffected, can we change this message to either match those, or to something more sensible, while we're waiting for the rewrite? Something like: It looks like you don't have the Java plugin installed or enabled. Firefox may have disabled it because it was outdated and insecure, in which case you can get [$url](upgrade to the latest version here). If you haven't missed it so far, great! We encourage you to keep it disabled to prevent against future exploits.
I believe this should now be considered Critical due to the fact Firefox is now forcing click-to-play on the latest version of Java. Taking the extra step of just uninstalling Java should be rewarded not punished.
Poking this again. Given the recent rash of 0-days, the fact that the DHS among others are encouraging people to uninstall Java, and the fact that the Java installers and updaters are installing add-ons which are significantly deleterious to user experience, having plugin check recommend that people without Java install it has become Very Bad Thing.
Michael, Do you happen to see an entry for "Java Deployment Toolkit" if you type "about:plugins" in the URL bar and hit <enter>?
Alex, you're late to the show. This problem was noted in a fresh Windows installation with no other software installed. I am not in a position to perform tests on fresh builds at the moment.
I've seen this my self for quite some time now, on several systems(linux). This is not a client problem, as these systems has never had java installed at all. So ya, there is a detection problem somewhere. Might it be that we hit different cdn nodes or something?
rhelmer, aiui you added this feature in bug 740544, would you mind taking a look?
Schalk, since you are elbow deep in plugincheck right now, could you take a look at this?
Assignee: nobody → sneethling
(In reply to Ed Morley [:edmorley UTC+0] from comment #21) > rhelmer, aiui you added this feature in bug 740544, would you mind taking a > look? Kev (cc'd) explained in https://bugzilla.mozilla.org/show_bug.cgi?id=740544#c0 but is still confusing - the problem is that multiple versions of Java were blocklisted (and therefore disabled), and the desire at the time was to offer an upgrade to people who saw the infobar, but there is no way from client code to tell if the user has Java installed but disabled. The assumption at the time that bug was filed was that users would want help re-enabling a safe version of the Java plugin, but this assumption may not be valid anymore (or, it's as valid as this current bug is :) )
Ok so, as everyone can see there are many similar bugs to this one that has been logged, this one I believe now being the official tracker for this. Now here is what I am wondering, and apologies if this has already been stated here or on one of the other bugs. With the Java plugin we can be in one of three states: 1) Java plugin installed and enabled 2) Java plugin installed but disabled 3) No Java plugin whatsoever For our first scenario the code is going to check whether Java is enabled, and if it is, grab the version information and send it through to the plugincheck service which will come back and indicate whether we are fine or whether the plugin is vulnerable. If it is vulnerable, we mark it as such and offer the user a link where they can find an update for the plugin. Now, if we check whether java is enabled and it is not, this is essentially where we hit a road block as there is no way past this point for us to know whether this state was arrived at because you do not have Java installed at all or, whether it is simply because you disabled it. Iterating through navigator.plugins will not help to clear this up either as it will not be listed. This leads me to believe that what people want is, unless Java is enabled and we can then reliably detect whether the user has a vulnerable version or not, we report nothing back to the user regarding Java. This means Java will only ever be reported on if it is enabled. Further meaning that the currently 'Missing Java?' message should never be shown.
I think that's essentially a good summary of the problem, except that mentioning Java is fine so long as we're not actively encouraging people to install it, or giving people confusing messages about Firefox having disabled it when we don't actually know that to be the case.
(In reply to Kris Maglione [:kmag] from comment #25) > I think that's essentially a good summary of the problem, except that > mentioning Java is fine so long as we're not actively encouraging people to > install it, or giving people confusing messages about Firefox having > disabled it when we don't actually know that to be the case. I agree and therefore it is probably best to stay out of that cage fight and simply report on what we know to be accurate and true. Thoughts everyone?
Sounds like you guys have it nailed down. I appreciate that the former code tried to help a user re-enable JAVA since an insecure version may have been automatically disabled by Firefox. But I think it's fair to instead report that JAVA is not installed 'in the browser' since if it was disabled in the browser, that's all I'd expect to see. It's really not a plugin checker's responsibility to tell whether or how to install a plugin unless there is a security issue.
When the banner was introduced, the current solution made sense. However, given the number of 0-day vulnerabilities discovered since, I think the lesser of two evils here is just to not comment on the missing plugin at all. Even replacing the wording to mention "java is not installed" (vs the current "java has been disabled"), will still lead to people trying to install it out of desperation / confusion. Ultimately we don't have a banner for other things that we blocklist, eg flash (for which there are even newer, secure versions), so I think we shouldn't make an exception for Java, particularly given how few people actually need it installed & the track record it's had in the last year. tl;dr: Let's just remove the banner entirely.
s/secure/secure for now/
Awesome, so I will make the needed changes to make the banner go away ;)
I filed bug 848049 on a similar but Mac-specific issue.
No longer seems to be a problem with the shiny new plugincheck page.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Confirmed. The page is no longer complaining about an outdated version of Java.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.