Closed Bug 914690 Opened 11 years ago Closed 11 years ago

In Firefox 24 and following, mark all versions of Java as unsafe

Categories

(Toolkit :: Blocklist Policy Requests, defect)

Product:
Toolkit
Component:
Blocklist Policy Requests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: benjamin, Assigned: jorgev)

References

Details

(Whiteboard: [The blocks have been reverted. Please read comment 80])

The history of security vulnerabilities in Java and poor response times means that Java is likely to be permanently unsafe. In order to protect most users, while still allowing users to override per-site, we intend to: * mark the most recent version of the Java plugin as unsafe without an available update. * mark older versions of the Java plugin as unsafe with an update available. The effects of this change is that the user can still enable java permanently for particular sites, but will not be able to enable java for all sites. This change should be applied to Firefox 24 and later only, because we have improved the click-to-play UI so that it is more discoverable and usable. Jorge, I believe in practice this means the following: * The Java version 6 blocks need to be extended to cover all versions of Java 6, including future versions. Oracle is no longer providing end-user updates to Java 6. ** This is p412, p414, p416 * New blocks need to be staged for Java version 7 update 25 on mac/windows/linux. Alex or Bhavana, do you have an opinion of whether we can deploy these to the Beta audience immediately and let them ship with Firefox 24, or whether we should wait to deploy them a couple weeks after Firefox 24 to separate the feedback and potential issues? Tracy, are you the right person to coordinate testing the staged blocks?
Flags: needinfo?(twalker)
Flags: needinfo?(release-mgmt)
Yes, all things Fx24 QA are my responsibility to coordinate, either internally or with our team in Romania. We'll take care of it.
Flags: needinfo?(twalker)
(In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > Jorge, I believe in practice this means the following: > > * The Java version 6 blocks need to be extended to cover all versions of > Java 6, including future versions. Oracle is no longer providing end-user > updates to Java 6. So, if there are no future Java 6 updates planned and we already cover all existing versions, does it make sense to take any action? Would Oracle release an update in a sufficiently urgent case? > * New blocks need to be staged for Java version 7 update 25 on > mac/windows/linux. The easy way to block all of Java is to make one block without version restrictions that applies to Firefox 24 and above. However, that block would either need to have "update available" or "update unavailable" set. To satisfy these requirements: > * mark the most recent version of the Java plugin as unsafe without an available update. > * mark older versions of the Java plugin as unsafe with an update available. we would need to update the blocks every time a new Java update is released, which I would rather not do. Alternatively we could do this temporarily and make a change in-product so that having a single block for Java is possible in the future.
> So, if there are no future Java 6 updates planned and we already cover all > existing versions, does it make sense to take any action? Would Oracle > release an update in a sufficiently urgent case? Oracle may release private updates to particular customers, and we don't know what those versions will be. We do know that they are not backporting all of their security fixes regardless and recommend the Java 7 update, so I believe we should extend this to all Java 6 versions. > we would need to update the blocks every time a new Java update is released, > which I would rather not do. Alternatively we could do this temporarily and > make a change in-product so that having a single block for Java is possible > in the future. Why would you rather not do it? Are you worried about the maintenance burden? I'm confident that this is the UI that I want to present, and I'm interested in figuring out (both short- and long-term) how to achieve that.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > > we would need to update the blocks every time a new Java update is released, > > which I would rather not do. Alternatively we could do this temporarily and > > make a change in-product so that having a single block for Java is possible > > in the future. > > Why would you rather not do it? Are you worried about the maintenance > burden? I'm confident that this is the UI that I want to present, and I'm > interested in figuring out (both short- and long-term) how to achieve that. Yes, it's the maintenance burden. If we were to have a single block for all of Java, then I just need a block that filters by the file names for the 3 platforms, and it would work for Java 6 and Java 7. The current situation is that for every Java block update I need to deploy 6 new blocklist entries (Java 6, Java 7, 3 platforms) that use regular expressions to match the version number in the description, and also update the previous 6 entries so they say that an update is available. Multiply this by 2 if staging is required, which I believe is no longer the case. Since this seems to be a permanent solution, I'd like to find a way to make it work more smoothly on my side.
Short-term, I'd like to accept the maintenance burden of doing this one a quarter or whenever they issue a 0-day patch. I'd be happy to share that burden with you if you want me to drive the blocklisting site. Long-term I agree that we need something better, and I'll send around an email to see what we can do.
QA Contact: anthony.s.hughes
Two quick things here - (In reply to Benjamin Smedberg [:bsmedberg] from comment #5) > Short-term, I'd like to accept the maintenance burden of doing this one a > quarter or whenever they issue a 0-day patch. I'd be happy to share that > burden with you if you want me to drive the blocklisting site. Long-term I > agree that we need something better, and I'll send around an email to see > what we can do. I've been in discussions with the Security Assurance team. Each block request should likely be coming from them in the future, since they're tracking attack vectors for Firefox and the slow/cautious rollout of CTP by Release Management is complete. mcoates, does that line up with your thinking? (In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > Alex or Bhavana, do you have an opinion of whether we can deploy these to > the Beta audience immediately and let them ship with Firefox 24, or whether > we should wait to deploy them a couple weeks after Firefox 24 to separate > the feedback and potential issues? As for doing this in 24 and up, that's fine. Let's wait till a couple of weeks after the release to rollout, since we don't want non-urgent blocks to be associated with release. At this point we don't need to stage the blocklists in Beta first. We should also notify the enterprise list of the upcoming block, along with a reminder of the tool Jorge created to whitelist sites across your deployment.
Flags: needinfo?(release-mgmt) → needinfo?(mcoates)
(In reply to Jorge Villalobos [:jorgev] from comment #4) > The current situation is that for every Java block update I need to deploy 6 > new blocklist entries (Java 6, Java 7, 3 platforms) that use regular > expressions to match the version number in the description, and also update > the previous 6 entries so they say that an update is available. Multiply > this by 2 if staging is required, which I believe is no longer the case. After this point the Java 6 ones won't ever change so fwiw that halves the work. (In reply to Benjamin Smedberg [:bsmedberg] from comment #0) > * New blocks need to be staged for Java version 7 update 25 on > mac/windows/linux. The current Java 7 is Update 40. Is that what you meant? 1-39 should be blocked with update available, and 40 should just be blocked. I don't believe Oracle publicly released anything between 25 and 40 but they must have burned the numbers somehow. It doesn't hurt to block them in case they are being used in corporations with support contracts.
There were no releases between 25 and 40. Numbers are now being skipped in order to better address cases where version numbers needed to be changed due to unplanned versions. https://blogs.oracle.com/java/entry/new_java_se_version_numbering 7u40 is a bug fix only release and does not have any security fixes. Release notes: http://www.oracle.com/technetwork/java/javase/7u40-relnotes-2004172.html List of bugs: http://www.oracle.com/technetwork/java/javase/2col/7u40-bugfixes-2007733.html 7u25 is still the most secure version of Java, 7u40 adds bug fixes to 7u40. http://www.oracle.com/technetwork/topics/security/javacpujun2013-1899847.html
Jorge, can we stage this now that FF24 has been unthrottled for a while now?
Given bug 927273, I suppose the new plan is to block up to version 40 for all Firefox versions and block 45 in 24 and above. Is this correct, Benjamin?
Flags: needinfo?(benjamin)
correct!
Flags: needinfo?(benjamin)
The blocks are staged now: Java Plugin 7 update 45 (click-to-play), Mac OS X https://addons-dev.allizom.org/en-US/firefox/blocked/p461 Java Plugin 7 update 45 (click-to-play), Windows https://addons-dev.allizom.org/en-US/firefox/blocked/p459 Java Plugin 7 update 45 (click-to-play), Linux https://addons-dev.allizom.org/en-US/firefox/blocked/p457
Keywords: qawanted
Ioana, please have someone on your team verify that the blocks in comment 12 are working correctly on staging.
Flags: needinfo?(ioana.budnar)
Paul is the QA owner of CTP, so he'll take over this.
Flags: needinfo?(ioana.budnar)
(In reply to Jorge Villalobos [:jorgev] from comment #12) > The blocks are staged now: > > Java Plugin 7 update 45 (click-to-play), Mac OS X > https://addons-dev.allizom.org/en-US/firefox/blocked/p461 > > Java Plugin 7 update 45 (click-to-play), Windows > https://addons-dev.allizom.org/en-US/firefox/blocked/p459 > > Java Plugin 7 update 45 (click-to-play), Linux > https://addons-dev.allizom.org/en-US/firefox/blocked/p457 This is NOT working on Linux.
(In reply to Paul Silaghi, QA [:pauly] from comment #15) > This is NOT working on Linux. Can you please elaborate? What are your steps and results? Also, can we assume Windows and Mac OSX are working okay?
Blocks: 873733
Looks like Oracle has changed the strings again. Java 7u45 on Linux: > Java(TM) Plug-in 10.45.2 > File: libnpjp2.so > Path: /usr/lib/jvm/jre1.7.0/lib/i386/libnpjp2.so > Version: 10.45.2 > State: Enabled > Next Generation Java Plug-in 10.45.2 for Mozilla browsers Java 7u6 on Linux: > Java(TM) Plug-in 1.7.0_06 > File: libnpjp2.so > Version: > Java plug-in for NPAPI-based browsers. It looks like we may need to capture the strings for all versions again so you can update the blocklist correctly, Jorge.
(In reply to Paul Silaghi, QA [:pauly] from comment #18) > Done. https://wiki.mozilla.org/QA/Plugins/About:Plugins#Linux_2 Jorge, I trust the information provided by Paul is what you need to move forward with this?
Flags: needinfo?(jorge)
The Linux block was updated with the new information, and all three blocks are now live. Please give this about an hour before testing. Java Plugin 7 update 45 (click-to-play), Linux https://addons.mozilla.org/en-US/firefox/blocked/p464 Java Plugin 7 update 45 (click-to-play), Windows https://addons.mozilla.org/en-US/firefox/blocked/p463 Java Plugin 7 update 45 (click-to-play), Mac OS X https://addons.mozilla.org/en-US/firefox/blocked/p462
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(jorge)
Resolution: --- → FIXED
Is This correct? Java 7u45 is the latest Oracle version.
Yes, this is correct, we are intentionally marking even the latest release version of Java as insecure. Please see comment 0.
Hi thanks for answer. I'am asked because https://addons.mozilla.org/en-us/firefox/blocked/p463 shows that the plugins is blocked. So with this change Java will blocked at all and have to enable per site right?
That is correct.
Block is working as expected.
Status: RESOLVED → VERIFIED
Keywords: qawanted
There's a long trail here, but I fail to see any justification why java 7 update 45 is getting the block treatment. Your blocks are redundant to the red-box warnings from the java plugin itself, which are presented every time an unsigned or untrusted java applet is run.
No way to activate it on http://www.pogo.com/games/risk?pageSection=fp_gamebar_1_risk#game:robots Using latest Firefox and JRE.
@tyl2: New Firefox plugin behaviors always cause trouble for the Pogo community. That's why the http://news.pogo.com/java-update-45-just-released/ news item has 930 comments -- most of them incorrectly blaming Pogo for broken functionality and disrupting business operations there because of unexpected Firefox behavior. You may find this useful: https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked The security concerns of Java have been known _long_ before OP's post on 10 September so the fairly new auto-block implementation of _current_ Java releases is just another confusing move by the team.
This is really annoying. What's the next step, prevent people from installing Java altogether?
Have you all suddenly gone insane? Java is one of the three core technologies behind dynamic content! You start pulling out a sledgehammer to go smash a few bugs and you all talk calmly about it as if it were some minor UI tweak? WT* did they slip into the coffee pot down at Mozilla HQ? Now, of course Java has potential vulnerabilities in it. It is a very powerful platform. But the same applies to FF, Windows, and all sorts of platforms and plugins you continue to support. I quote: http://nakedsecurity.sophos.com/2012/08/30/how-turn-off-java-browser/ "Many modern businesses operate business and database front-ends that operate entirely on Java-based virtual environments. I do NOT recommend disabling your java without considering effects to your existing systems. There was little reassurance in the article that the world would be a better place when you disable java. Shouting from the rooftops to turn off your java right now or the sky *might* fall -- not a good idea. Given the volume of exploits within Windows, you may as well write another article, 'How to turn off your Windows computer - and why you should never turn it on again.'" If the folks at Mozilla are really concerned, they should wrap it in an additional cocoon of security sandboxing, since I suspect most users will either habitually ignore the warning, or will switch to a browser that doesn't hassle them. Some malicious sites I have noticed are circumventing browser protection by requiring users run an executable downloader to receive whatever media they are after. Human stupidity is as impossible to be designed against as it is to legeslate against. By trying, you only make yourself look like this guy: http://dilbert.com/strips/comic/2007-11-16/
Hi, At Ephox, we write a WYSIWYG web page editor that deploys as a Java applet. It's the leader in our field and integrated into most of the major enterprise content management systems. Its codebase is about 250 KLOC and has implements functionality that would be difficult or impossible to implement in current javascript - e.g. image editing. This behavior change severly inconveniences our users. We believe it is sufficient to warn the user of the security risk, but allow them to make an informed choice. We do not believe that blocking every java version has any effect on the security of the browser, but it does have a negative impact on the usability of our product. The last few months have been an utter battle to appease the whims of people in your position. Every java update, we have to add new applet params or jar manifest properties, or change our build process. Or we have to give our users a new set of instructions on how to actually run java. Or java becomes flat-out broken or blocked. Our company and our users are legitimate users of Firefox. We have needs and requirements - one of those is for Java to work. My advice to you: either support Java or do not support it. If you choose to support it, make it usable. Remember that you need to provide good usability in addition to security. The two do not need to be in conflict. Regards, Dylan Just Senior Software Engineer Ephox
Seconded! Between Firefox and Oracle, I feel like one of the Knights running for the Red Queen.
Hi, sorry for an explicit message, but, as a user: who took such an ultra-irresponsible decision to block java on FF?! It made me unable to log in to my online trading account because of this. The app used by my bank only displays 'required java version >1.5" in a message box, with no trace of any security issues. It simply doesn't work. This WILL HURT ALL USERS and hurt your user base, as ALL people in a similar situation (many, I believe) WILL switch to IE. How can I rely on FF if such things happen? Regards, Tom
If you want Firefox to be used as a product you must resolve this issue now - by quickly making it possible to use Java/Javascript in the most secure possible way. If there are problems in the relationship between the Mozilla community and Oracle - please do not make this a problem for the users. I reckon Firefox are losing millions of users by the hour, as the effects of this issue propagate to the users. What is really put to test here is if the community-based software development model works in practice when more complex problems arise. In a "normal" product, owned, developed and maintained by a company, technical issues would never be allowed to risk the product (or company) itself. There would be a product owner or CEO that would take a pragmatic (non-technical-based) decision that would not risk financial values, but still allowing important technical issues to be resolved at a later stage. Personally, I just joined the Bugzilla community, in order to be able to comment on this specific issue. This means I am not too familiar with Mozilla principles. However, the way this issue seems to have been handled, it appears that there is not sufficient "owner" control of the product, that enables to override technical-based decisions, that probably are counter-productive in the long run. I am actually a bit surprised that the issue has been handled in this way. I have been a Firefox user in many years and during this time, similar complex/strategic problems would most certainly have occurred before. I have never noticed before, though, that Mozilla decided on a solution that rendered the complete browser unusable for the majority of the users. If Mozilla continues this war against Oracle, the result will be a product used by only a few, technically oriented users, while hundreds of millions of users, who primarily wants their browser to support Facebook, Youtube and Gmail sufficiently well, will quickly move to Chrome, and never look back again. At the moment this issue is not about "security vulnerabilities in Java and poor response times [from Oracle]". The issue is rather "Bug 914690 solution has made Firefox 24 unusable". It should be reopened and resolved immediately. best regards Michael Andersson (who will continue to work in parallel with both Firefox and Chrome for a few days, hoping that you will come to senses)
Yes, blacklisting every Java update before any security vulnerability has been discovered yet is way overkill. For every Java release I have to go back to every single one of my 200 clients to re-enable it, so that my users can view their lab results. When I talk about 'lab results', I talk about blood and urine tests in a hospital. Not quite the type of thing my users can do without for any length of time. (No, teaching my users how to re-enable the plugin themselves is not an option. It's been tried before. The result has always been a variation of "This is IT stuff, it's not my job, I don't know how to do it.") We know Oracle are a bunch of morons. We know they don't care about security, users, or software in general. We know they deserve to be blacklisted. But you have to understand that we can't _afford_ Java to be blacklisted and unusable. Because Java may be used to write 5-min games, but it's also used to write mission-critical apps. Apps that CANNOT BE REWRITTEN ON A WHIM.
Seconded! Our business depends on using some java applications. Blocking java the way you did it, simply means: We can't use Firefox in our company anymore. We replace Firefox with chrome. This turn was pending a while. Many thanks to the mozilla security and quality assurance teams for clarifying the issue. Regards Ralf Hemberger System Administrator
I don't understand reasons to block latest updated Java plugin (Java Plugin 7 update 45). Our business highly depends on using Java and after blacklisting we can't use Firefox anymore. Please make blocking procedure be optional.
(In reply to Ralf Hemberger from comment #36) (In reply to nixon from comment #37) You can still use Firefox. Just use the red icon next to the address bar: https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked
(In reply to David T from comment #38) > (In reply to Ralf Hemberger from comment #36) > (In reply to nixon from comment #37) > > You can still use Firefox. Just use the red icon next to the address bar: > https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked You're correct. I can. And 500 users take their phone and ask me, cause they can't. Inacceptable!
Java Plugin 7 update 45 should not be blocked! It affects all citizens of Denmark, as the national login is blocked. All Danes have to use Google Chrome :-(
(In reply to David T from comment #38) > You can still use Firefox. Just use the red icon next to the address bar: > https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked Yes, sure. Give me, please, you telephone number. I'll give it to our customers because my phone is red like icon on the address bar.
(In reply to Ralf Hemberger from comment #39) > You're correct. > I can. > And 500 users take their phone and ask me, cause they can't. > Inacceptable! (In reply to nixon from comment #41) > Yes, sure. Give me, please, you telephone number. > I'll give it to our customers because my phone is red like icon on the > address bar. It doesn't matter if it's 500 or 5000 users. After three phone calls you should see recognize the pattern and send an email to all your users informing them of this one-time setting. Explain to me why you cannot do that instead of whining on bugzilla?
Is there a way to NOT do this on the ESR?
(In reply to David T from comment #42) > (In reply to Ralf Hemberger from comment #39) > > You're correct. > > I can. > > And 500 users take their phone and ask me, cause they can't. > > Inacceptable! > > (In reply to nixon from comment #41) > > Yes, sure. Give me, please, you telephone number. > > I'll give it to our customers because my phone is red like icon on the > > address bar. > > It doesn't matter if it's 500 or 5000 users. After three phone calls you > should see recognize the pattern and send an email to all your users > informing them of this one-time setting. Explain to me why you cannot do > that instead of whining on bugzilla? So you wanna teach me? You wanna protect me? What will be your next lesson for me? Which deep knowledge you have to claim that java 7_u45+ is more vulnerable than shockwave-, flash-, citrix-, silverlight-, office- etc plugin? Are they next on your crusade? You can't recognize the pattern and give an explanation to all Firefox users? You couldn't code an intuitive way to resolve this annoyance? You know about pepper and icedtea? Did you read the posts 26++? By the way, I'm not whining. We'll simply abandon FF.
(In reply to David T from comment #42) > It doesn't matter if it's 500 or 5000 users. After three phone calls you > should see recognize the pattern and send an email to all your users > informing them of this one-time setting. Explain to me why you cannot do > that instead of whining on bugzilla? Really, it does matter. Some customers don't know how to write a different address in the address bar or open email box in other browser. And then you propose me to explain needed actions for them. Bullet to the head is a perfect solution instead of this.
Damned, I landed here after an hour of cursing and googling. (In reply to David T from comment #38) > (In reply to Ralf Hemberger from comment #36) > (In reply to nixon from comment #37) > > You can still use Firefox. Just use the red icon next to the address bar: > https://support.mozilla.org/en-US/kb/how-to-enable-java-if-its-been-blocked It does not work for every user. Clicking the icon does not do anything. Maybe it works just for admin-rights user? I can not find any site-specific java setting, I can not make Java run for this user - it is account manager and the app is our bank web app. What am I supposed to do? To tell him "yes, you can not pay any bills, but you're really safe, nobody can hack you through java!"? Are they there in FF team joking? Do they suppose I will reenable/reinstall Java on a hundred PCs with every Java update for every user to be able to run our well-known java apps? And common, strict, no-warning, no-user-deciding disabling of newest java version is next level of idiocy. Thank you very much, really!
AFAIK, this change brought Firefox up to where Google Chrome already was in blocking Java by default (https://support.google.com/chrome/answer/1247383?hl=en) Google is also going ahead with blocking all NPAPI plugins in January 2014 (except for a few popular exceptions, specifically not including Java as an exception). (http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html) Both Mozilla, Google (and the Sophos website linked above) say that Java is insecure and should not be enabled by default. Sophos even recommends you consider disabling it in the browser you use the most often; and then use a separate browser for sites that need Java. I do think doing this as part of a release (aka Fx 24/25) would have been much better from an Sys Admin perspective. That way we could have tested it out and noticed ourselves this was an issue and provide a whitelist, before deploying that update. It would have also given time to let sites that would be affect know that it's coming through the Beta release and provide outreach opportunities.
Bryan, I understand that Google has gone ahead with standard blocking Java. However, their UI for enabling it seemed more user friendly. Aside from this, I have a problem with the visual display after accepting a fully EV certificate signed applet. Instead of a red icon which flickers a green would be better. Also the information given to the user is very negative. It tells them that by definition even a signed applet is a security risk. We took many precautions, hard work and the necesarry expenses (like buying the necesarry certificates, both extended validation for java and https), so our users know that our products are safe to use. Our name depends on our service and security. I think that the user interface of accepting java needs to be improved, so the user can easely understand how and where to use java. I would like to suggest the following. When java tries to load, you might start a popup that blocks the browser, kinda like java does with certified applets. This is a lot more visible to the user then a red icon next to the adressbar. Second, let site administrators register their applets to a standard databasw by using their signing certificate. This way you can show a positive message in the popup before using their java applet. If they misuse java, you can blacklist them easely. Now you have a certain control over the security around java applets and you can help the user select more easely what is ok and whats not.
(In reply to David T from comment #42) > It doesn't matter if it's 500 or 5000 users. After three phone calls you > should see recognize the pattern and send an email to all your users > informing them of this one-time setting. Explain to me why you cannot do > that instead of whining on bugzilla? Oh, that's easy to explain, so I'll do that. Because my users 1) don't all have an email, 2) don't always read it, 3) can't or won't follow those instructions. You are used to deal with people familiar and comfortable with IT in general and GUIs in particular. You know your way around computers and can adapt when faced with new situations. My users are not that. For the purposes of this bug, my users are mostly nurses. Some of them don't even have computers at home, they don't understand IT, they don't WANT to understand IT. Computers are a chore at best. They use them because their job demands it at certain times, but they don't have the reflexes we "IT people" have when confronted to a software problem. A 16x16px red icon means nothing to them, they don't see it, they're not trained to look for it the way we are. And even when I point the solution to them, they'll have forgotten as soon as the issue is resolved. They will not look for it the next time. Because it's IT work, and they're not IT people. There's no real solution for this problem from the user side. I can't train them on the job, because they're 500 and I'm alone. I can't send them to training sessions, because there's no such thing and even if we found one, it's not really job-related and there's no way we can justify the expense. I can't ask them to self-train, because knowing about computers IS NOT THEIR JOB, and you can't ask 40- or 50-year old people with no affinity to IT to just develop an interest in computers just because it makes your life easier. (Well, that's valid regardless of age, actually.) The only solution to this problem is to make IT as hidden as possible. The less interaction they have with it the better. Automate as much as possible. Hide everything they don't use, reduce dialog boxes to a minimum. Etc. That's been my everyday job for the last 13 years. My colleagues in other, nearby hospitals have the exact same issues with their own users, whether they have less (~300) or more (~2000) users, or whether they have an IT team of 1 (like me) or ~10 (for the biggest of my neighbours). So, yeah. "Look for that icon. Click on it then say 'Enable always' everytime Java updates". Not gonna happen. They don't even understand the concept of a plugin or what Java even DOES. Now, again, I understand your position from a software engineering POV. I'll even agree that it makes sense. Unfortunately, it doesn't make sense anymore once Firefox is installed and in the hand of actual, non-IT-oriented users. I'm sorry.
Thank you all for your comments. Please understand that this is a bug-tracking system, and isn't designed to be a discussion forum. 1) If you believe you have found a bug in the implementation, such as clicking in the UI doesn't work, or there is no way to enable Java for a site, please file a bug to track that issue in product "Core" component "Plug-Ins" and CC me. 2) If you are a system administrator and want to unblock Java on particular sites for your users, please see my post to the Mozilla enterprise mailing list, and if necessary follow up on that list: https://mail.mozilla.org/pipermail/enterprise/2013-October/003673.html 3) If you disagree with this decision, please make sure that you have read the following historical context: * https://blog.mozilla.org/security/2013/01/29/putting-users-in-control-of-plugins/ * https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in-firefox/ * comment 0 of this bug * the thread "Click to play, the next big problem for many smaller companies" in firefox-dev August and September 2013 If you think that there is additional data which is relevant to the discussion or would cause us to change our mind about this block or about click-to-play by default which is coming in Firefox 26, please post to the firefox-dev list: https://mail.mozilla.org/listinfo/firefox-dev
Whiteboard: [Please read comment 50 before commenting]
If you're a systems administrator you can use Click-to-Play Manager (https://addons.mozilla.org/addon/click-to-play-manager/) to manage whitelisted domains. It also includes some utilities to deploy whitelists to other computers. We just uploaded a new version that adds support for security-blocked plugins, which wasn't included before.
Look I understand this is a bug tracking system...and not a discussion board, but there is a bug here, a process bug! I haven't been able to get VPN-ed in for days, until I figured I could still use the Juniper SSL VPN from Internet Explorer. I find it amazing the casualness with which a small group of developers just shut off an entire set of functionality with no regard for its size, utility... You just broke millions of peoples software, and then you complain about this being a bug list, and you can simply do this, or simply do that. You guys just kind of cavalierly through us under-the-bus ... Hell I don't even like Java...but my VPN client used it... and to be clear, the due to reasons I can't tell you when I tried to login to the VPN... I didn't get any red block, instead of login in it just kept asking me to download some installation. It took me 4 hours, and lots of google-ing and reading and re-reading stuff to figured out that I had to go and click the far left of the address bar, click more information, then click permissions, and then go to the bottom, and turn of default for Java (and java related) and set to accept. Yes its a major bug that I and 10X of others have had to waste time and resources to fix a bug, that you created, and than casually dumped on us.... Lord I Love your browser, but the unending, and rapid versions combined with these kind of things are a enough to drive you both crazy and to some-other browser... please just apologize to all of these people and don't repeat this kind of behavior...
Totally agree (with shiloh.enriquez)
Guys - let me add a POV. Java has become a de facto applet base programming base. We all know it's a buggy as hell. I work in Spanish local government. Just about ever ministerial applet is written in JAVA - and since yesterday we're screwed - Why because we have no way to permanently activate the actual JAVA version in FF. These applets first job is to make sure Java is up to date. If it's not - teh applet fails - and if Java is blocked - it screws up. Is there no way to FORCE acceptance despite your concerns. I'm b*ggered if I can see an ACTIVATE ALWAYS option. We use the Spanish version naturally. I run FF up to date. We run FF because it's SAFER than Explorer. I hate Chrome. Most of my users have trouble with basic office tasks - Are low paid base level civil servants and simply DO NOT WANT TO KNOW - they want it to work.
Now what we should use if we need more then HTML5? -Silverlight ...FF promote a closed technology against the somehow open Java?? -Flash ...which is on a downhill now? C) -Java ...users need to be IT experts to enable it One thing I would like to see: MS should ban FF because it is insecure :)
And another POV, we're running a browser game integrated through a thin Java applet wrapper into the browser. This "fix" is really bad for us. I agree that Java applets shouldn't run automatically. But if the user has installed the latest Java version, then the plugin warning should be less scary (innocent until proven guilty, right?). The plugin area should display a green icon instead of that red scare warning, and the user should be able to start the plugin with a single click. JS+WebGL is the future, but you guys really have to give us a realistic time window :/
I could live with Java applets not being run automatically, and understand the desire for the browser itself to not trust the plugin enough to allow it to decide what should be trusted. However, the UI is simply terrible. Users (including myself) simply don't notice they have a UI option to allow the plugin. Is this by design, and the ability to allow the user to choose what they run has been deliberately obfuscated? As this is a bug report system not a soap box I was going to try to avoid commenting on the decision itself, but I can't resist pointing out that in 2013 the Oracle JRE had 11 code execution vulnerabilities reported in the CVE system. The Adobe flash player had 51. Source: http://www.cvedetails.com/product/19117/Oracle-JRE.html?vendor_id=93 http://www.cvedetails.com/product/6761/Adobe-Flash-Player.html?vendor_id=53 Given security researchers have much more open access to Java compared to Flash, I assume there are many many more existing, but unreported problems in Flash. Why have you started this experiment with Java, a system that gives the user much stronger control over what they run compared to Flash. Flash would seem a much more urgent case for this type of intervention. Please consider replacing the tiny red icon with something more prominent in a future release. Will a future Java version be allowed to be on by default if there are no known security problems with it?
I reported this big issue forme in the developper forum. al java version, even recent ones, ALL are considered, (not like flash...) as a "permanent unsecure virus" by Firefox. - How can the Mozilla team can think they can get away with this ? This behavior is all but neutral from firefox ? - So I have to drop my software that I programmed in 7 years ? Benjamin Smedberg is an extremist. I went 4 days ago in the developper forum to discuss about this : --------------------------------- Me: "A red no entry sign" is too radical for recent java player I think. My users give me a phone call to tell me "No way I will accept to install your software with this red warning"... Even the people who know me, tell me they got so scared they have really hesitated to accept java. Now I do understand at a time when java had urgent security issue this scary red-message was necessary. But I really wish that Firefox checks the java version installed ... and give a less-scary-warning-sign or a "go !" if the user has a recent java version (like the latest on java 1.7 update 30). Benjamin Smedberg: "We fundamentally disagree about the risks of the Java plugin. We believe the Java plugin is unsafe, and we want to present that to our users". -- Is there a boss at Mozilla ? someone who cares about developpers. And yea Benjamin, you know, java is open source by the way. **** you idiot ! Thierry
(In reply to jonesr from comment #57) > Please consider replacing the tiny red icon with something more prominent in > a future release. Will a future Java version be allowed to be on by default > if there are no known security problems with it? Could you file a new bug for that? Here, it's going to be lost very quickly in the noise.
Flags: needinfo?(jonesr)
Added as (In reply to David Rajchenbach Teller [:Yoric] from comment #59) > (In reply to jonesr from comment #57) > > Please consider replacing the tiny red icon with something more prominent in > > a future release. Will a future Java version be allowed to be on by default > > if there are no known security problems with it? > > Could you file a new bug for that? Here, it's going to be lost very quickly > in the noise. Added as: https://bugzilla.mozilla.org/show_bug.cgi?id=929444
Flags: needinfo?(jonesr)
As a number of people have pointed out, blocking Java will be very disruptive and will break many existing applications in that businesses depend on. Further, Since the Java 7 update 10 release *every* applet prompts the user prior to running. Oracle has been making (and will continue to make) significant changes in applets to eliminate abuse vectors through unsigned code, repurposing of applications and malicious use of Javascript. I'd respectfully request that you first talk with the Java team at Oracle and try to work out a strategy the protects the existing investment in Java before implementing such a highly disruptive approach.
This is ridiculous. Bye bye Firefox...
Even if people can be trained to look for the icon and click the always enable thing (which I might add does not even work, I had to click it every time before I installed that click-to-play manager). Wouldn't that just beat the entire point you're trying to make, because people will just blindly click it and enable it. The plug-in screen shows options for always activate, ask to activate and never activate. But even when using about:config there is no way to set Java to always activate. Let the users decide. Windows doesn't prevent me from uninstalling my Anti-virus, now does it? I can decide for myself what I want, and if I, or anyone else, chooses to go with convenience over security then you will have to accept that. I don't even know what this whole Java is insecure thing is about, since I never had any problems with it until now, and I am an IT person. How would non-IT people understand your ridiculous move?
Oh, and speaking of security, why does this thread link my real life name to my e-mail address for everyone to see? Guess I am glad I kept my last name out of it. And for those complaining we aren't talking about bugs, this thread isn't about bugs to begin with. The very first post was someone whining that Java should be disabled. One person does that and it gets disabled. Hundred others do the opposite, nothing gets done.
Jorge, SUMO is getting reports of users who aren't even seeing the CtP icon on some Java-using banks, probably because we remove the icon if the site creates the plugin and then immediately removes it from the page. That is tracked in bug 926605. So I think we should revert this block (the R45 block) until we can make that experience work correctly. The block for older Java should stay in place.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
The history of security vulnerabilities in Windows and poor response times means that Windows is likely to be permanently unsafe. The history of security vulnerabilities in Flash and poor response times means that Flash is likely to be permanently unsafe. The history of despotism in Mozilla and poor logical reasoning ability means that Firefox is likely to be permanently in decline.
@Henk - check your bugzilla user settings. I'd like to request (along with actual functionality fixes, of course) this bug be reverted until usability has been better addressed. I run an interactive educational website used by many thousands of students around the world, and complaints about difficulties getting the applets to run have already been quite difficult this year; several times I've had to refund whole-year subscriptions. My applets are signed, sealed JARs that explicitly restrict themselves to the sandbox; but that's the limit of what I can do, and usability could be far better *without* sacrificing the security concerns. I'm comfortable with what I've read about "click to play" for plugins in Mozilla; the approach looks fairly usable. What I'm seeing with this release falls far short of those proposals. There is no dialog prompting the user to enable the Java plugin to run on this site; there's no dialog or obviously clickable interface at all. There is just a patchwork of boxes full of black stripes and frightening DO-NOT-ENTER signs -- for any interactive content, and even for any attempt to use Java's deploy.js script to check if Java is installed (so even my attempts to ease the user into getting the plugin they need now only serve to make the page scarier-looking). The only obvious UI on the warning boxes is an "x", which makes the warning vanish (leaving behind just empty background). Can't recover from that... reload. There is (I learned by reading here) a small icon that appears in the address bar -- I didn't notice it during several minutes experimenting, so I have no hope my students will a) see it, and b) try clicking it. If I try clicking randomly at the warning itself, I finally get the popup I expected, but it's broken as well. It asks me "Allow emusictheory.com to run plugins?", then shows a jumble of other UI and warnings, then Okay/Cancel. Well, the answer to the question is "yes", so I hit Okay. Nothing happens. Ah, right -- my students will have to figure out that the jumble of UI is a two-item list (one for the Java Deployment Toolkit, the other for the JRE itself), where they must click "Show all" to show the second item(!), then change both dropdowns from "Block plugin" to "Allow and save", THEN they can click Okay. At this point Java itself starts its security prompts. These are less scary, because the applets are signed and explicitly sandboxed as well. Just one click, on "Run", and the applet actually runs. The new Firefox changes have added 7 extra clicks through an extremely-confusing UI, before the user can be stopped again by Oracle. Related question: comment #0 mentioned ongoing vulnerabilities, but no mention at all if these are vulnerabilities that are exploitable *after* the user has approved Oracle's warnings, or *before*. Is there actual data supporting the assumption that exploit victims are insufficiently protected by Oracle's own "click to play" interface? Frankly, Oracle's interface has more information on the applet (e.g., is it signed?), and can tone down the scare factor while still enforcing click to play. Oracle also shows additional dialogs if your plugin version is not the latest. So my impression is that this patch is killing usability for sites like mine, without actually adding anything real to security for firefox users. I'll try to bring up some of these issues on the dev list.
Disclaimer: I'm in the Java SE Product Management team at Oracle. Just to add to my colleague in Engineering Joe McGlynn's comment #61 -- we're happy to help here however we can. We do frequently speak with mcoates, but are happy to plug into any other channels the mozilla team think would be worthy (as we seemed to somehow miss this one until it was too late I think we need more contact/channels). For example, I think we can help address questions related to the Java 6 (and Java 5, for that matter) updates as they are still supported and do receive updates along with the latest public baseline(s). As comment #50 notes, bugzilla is not forum software - so I'll leave it at that and send @bsmedberg a quick note and continue to try to catch up wit @coates.
@ Donald: Is there any way to take a certain Java applet by signature, certificate or something along those lines and fully whitelist it so that the user never gets any "Java Secrutiy" prompts when running that applet in the browser? In Re: Firefox's side of it: Is it still possible to fully disable the blocklist as was possible in Firefox 17? Will Firefox 24's installer place a blocklist already blocking Java at install time? And should this solution be enough to allow Java to run on any site? I absolutely will not instal a 3rd party plugin for this, especially since it can't fully whitelist the latest Java plugin in all sites.
"Quote" - The plug-in screen shows options for always activate, ask to activate and never activate. It may in the English version but in FF24 Spanish all I get is ask to activate and never activate. Chrome (in Spanish) blocks too but at least gives me the always activate option. Due to the EXTREME IMPACT this has on the Public Sector here - and that we're somewhat forced to use M-Soft for other applications - We had to return to Explorer yesterday. Sorry - But moves like this could well kill off the use of Firefox. Java applets are continuously used in the piping of Digital signatures to secure ministerial sites. This includes PRIVATE citizens. IMO Java has to be "trusted" even if we don't. Otherwise the use of Firefox WILL DIMINISH. 90% of users have NO BLOODY IDEA. I am a firm fan of Firefox at home - but at work it's causing me more hassle than it's worth.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #50) Also going to chime in that this is an unintended side effect from the implementation choice for the user experience that's baffling or confusing. To me, that's a bug. We've got an organization of over 300 firefox users with VPN clients; this essentially causes us to either run a native app that doesn't work with OSX, or use bundled in Silverlight and try to get IE everywhere. I love firefox at home, but at work I'm typing this from Chrome because I can't get my Cisco VPN client to work with the new firefox. Please revert the change at least for supported Oracle JDK's, and try talking to them about your "security concerns". Everyone has security issues, as is the nature of software -- people don't just dump ship on Firefox because you guys get a secvuln bug report, or two, or three, or twenty -- as long as you're responsive to the community in addressing the issue. With java, the user base is so large and so old, that while I hate Oracle in general, dumping support completely just isn't the right answer for the typical end user. > Thank you all for your comments. Please understand that this is a > bug-tracking system, and isn't designed to be a discussion forum. > > 1) If you believe you have found a bug in the implementation, such as > clicking in the UI doesn't work, or there is no way to enable Java for a > site, please file a bug to track that issue in product "Core" component > "Plug-Ins" and CC me. > > 2) If you are a system administrator and want to unblock Java on particular > sites for your users, please see my post to the Mozilla enterprise mailing > list, and if necessary follow up on that list: > https://mail.mozilla.org/pipermail/enterprise/2013-October/003673.html > > 3) If you disagree with this decision, please make sure that you have read > the following historical context: > > * > https://blog.mozilla.org/security/2013/01/29/putting-users-in-control-of- > plugins/ > * > https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in- > firefox/ > * comment 0 of this bug > * the thread "Click to play, the next big problem for many smaller > companies" in firefox-dev August and September 2013 > > If you think that there is additional data which is relevant to the > discussion or would cause us to change our mind about this block or about > click-to-play by default which is coming in Firefox 26, please post to the > firefox-dev list: https://mail.mozilla.org/listinfo/firefox-dev
(In reply to bobby.smith from comment #71) I want to add that I understand that making software (especially open sourced) is often about making really painful decisions that might divide the user base, so I do support Mozilla's tenacity in putting a foot forward on the oft-insecure unsigned applet problem; I just think it had a lot of untended side effects especially around a development shop used to cutting edge browser technologies vs everyone else using 8 year old technology that might have 6+ figure investments in upgrading. > (In reply to Benjamin Smedberg [:bsmedberg] from comment #50) > > Also going to chime in that this is an unintended side effect from the > implementation choice for the user experience that's baffling or confusing. > To me, that's a bug. > > We've got an organization of over 300 firefox users with VPN clients; this > essentially causes us to either run a native app that doesn't work with OSX, > or use bundled in Silverlight and try to get IE everywhere. I love firefox > at home, but at work I'm typing this from Chrome because I can't get my > Cisco VPN client to work with the new firefox. > > Please revert the change at least for supported Oracle JDK's, and try > talking to them about your "security concerns". > > Everyone has security issues, as is the nature of software -- people don't > just dump ship on Firefox because you guys get a secvuln bug report, or two, > or three, or twenty -- as long as you're responsive to the community in > addressing the issue. With java, the user base is so large and so old, that > while I hate Oracle in general, dumping support completely just isn't the > right answer for the typical end user. > > > Thank you all for your comments. Please understand that this is a > > bug-tracking system, and isn't designed to be a discussion forum. > > > > 1) If you believe you have found a bug in the implementation, such as > > clicking in the UI doesn't work, or there is no way to enable Java for a > > site, please file a bug to track that issue in product "Core" component > > "Plug-Ins" and CC me. > > > > 2) If you are a system administrator and want to unblock Java on particular > > sites for your users, please see my post to the Mozilla enterprise mailing > > list, and if necessary follow up on that list: > > https://mail.mozilla.org/pipermail/enterprise/2013-October/003673.html > > > > 3) If you disagree with this decision, please make sure that you have read > > the following historical context: > > > > * > > https://blog.mozilla.org/security/2013/01/29/putting-users-in-control-of- > > plugins/ > > * > > https://blog.mozilla.org/futurereleases/2013/09/24/plugin-activation-in- > > firefox/ > > * comment 0 of this bug > > * the thread "Click to play, the next big problem for many smaller > > companies" in firefox-dev August and September 2013 > > > > If you think that there is additional data which is relevant to the > > discussion or would cause us to change our mind about this block or about > > click-to-play by default which is coming in Firefox 26, please post to the > > firefox-dev list: https://mail.mozilla.org/listinfo/firefox-dev
Jorge, comment 65 is for you.
Flags: needinfo?(jorge)
I think the actual implementation of this requires some scrutiny. I hope it's ok for me to raise my concerns here since, at the very least, I believe this should be considered a RFE. In my opinion, the way the click to run option is being presented to the user is creating more of a security issue than it's solving. Applets from legitimate, trusted sources are being displayed with a large do not enter sign. Users are going to be trained to ignore the warning and the advice is going to be coming from a trustworthy source. What's going to happen the next time those users encounter an unsigned, possibly malicious applet and are presented with a warning that looks the same as the one they've become accustomed to bypassing? Are they going to observe the second (actually third) warning from Oracle, which does a better job of conveying the different levels of risk involved, or are they going to lump everything together as "the java warnings" while clicking yes, yes, yes. If the safety of users' is the actual goal here, the implementation needs to be much better. The warning needs to do a better job of communicating the actual risk to the user and needs to do a better job of helping the user to understand the level of trust they should place in the different types of signed or unsigned code. Users should also be guided towards the correct choices. As an example of what I think would be better, unsigned code should present the user with a red do-not-enter sign. Self signed code should be a yellow yield sign. Code signed with a personal code signing certificate should be relatively neutral, perhaps a blue circle. Finally, code signed with an EV certificate should get a green shield. Each level of trust should have an appropriate, yet brief description of the risks. I would go so far as to suggest that giving users yes / no choices when it comes to security is almost useless. Users will learn they need to click 'yes' for their stuff to work and eventually it ends up being little more than muscle memory. In this case, by the time a user has gotten past the current click to run implementation, they've already said yes twice. The second (now duplicate / redundant) warning from the Java Plugin, which provides a better explanation of the risk involved in running the applet, is much more likely to be ignored because the user has been put into yes, yes yes mode. If Mozilla is adamant about Java being click to run only, the implementation needs some serious work. The current setup is a step backwards in user security, at least in my mind.
Here's one work-around until a less intrusive patch can be implemented. 1) Exit Firefox 2) Create/Update C:\Program Files (x86)\Mozilla Firefox\defaults\pref\local-settings.js: pref('general.config.obscure_value', 0); pref('general.config.filename', 'firefox.cfg'); 3) Create/Update: C:\Program Files (x86)\Mozilla Firefox\firefox.cfg lockPref("app.update.services.enabled", false); lockPref("toolkit.telemetry.enabled", false); lockPref("extensions.blocklist.enabled", false); lockPref("extensions.blocklist.interval", 99986400); lockPref("extensions.blocklist.url", ""); 4) Delete C:\Program Files (x86)\Mozilla Firefox\blocklist.xml
Sorry in step #2 the path listed is for Firefox 20 and below. For Firefox 24 use the path: C:\Program Files (x86)\Mozilla Firefox\browser\defaults\pref\local-settings.js
(In reply to Andreas van dem Helge from comment #76) Hello, i'm confused, with our computers the path of blocklist.xml is C:\Program Files (x86)\Mozilla Firefox\browser\blocklist.xml and the path of local-settings.js C:\Program Files (x86)\Mozilla Firefox\defaults\pref\local-settings.js Did I miss something? And could i be less radical and delete the Java 7 entries from blocklist.xml or use the FF23-blocklist and deploy it?
important action information in this bug is now getting lost in advocacy noise, so I'm going to restrict commenting on this bug to members of the community with editbugs.
Flags: needinfo?(mcoates)
Restrict Comments: true
The blocks have been reverted. It'll take roughly a day or two for most systems to update their blocklists and have Java working again.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Flags: needinfo?(jorge)
Resolution: --- → WONTFIX
Whiteboard: [Please read comment 50 before commenting] → [The blocks have been reverted. Please read comment 80]
We still want to do this again once we fix up the UI, right? So we should leave this open?
(In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #81) > We still want to do this again once we fix up the UI, right? So we should > leave this open? I hope not. What we did here was wrong. It was essentially an out of band update to Firefox that blocked Java. Hopefully this has created a conversation between Oracle and Mozilla so this problem can be solved in the correct way. Either way, that would need a new bug, since this one is already filled with noise.
We certainly will be making java CtP by default when the UI is fixed (along with all other plugins). Whether or not we want to use the scarier UI is still an open question. In any case, I don't think it makes sense to re-use this bug, given its size already. When we decide to re-block, I'll file a new bug and comment in this bug to link them up.
Resolution: WONTFIX → INCOMPLETE
Restrict Comments: false
... Pointing out once again that the current versions of java are effectively already made click-to-play by Oracle, so when you reinstate some version of this patch, it should apply only to older versions of java that do not have this feature.
Note that in order to enable a plugin the user must have the "Navigation toolbar" shown. Firefox should present the user with choices (a dialog?) if the toolbar is not being used. To reproduce, just: 1. turn off the Navigation toolbar 2. go to a page where the applet is loaded via javascript (HP Ilo, Raritan, or any vendor 3. if you don't have the bar shown, you can't eanble the plugin
I think that this is a good thing for Mozilla to do. At Mozilla the safety of users obviously comes first. I really do not see what the big issue is. Java can still be enabled on a site-to-site basis. It is not like Java has been disabled all together. Even Google Chrome is taking similar measures. This action was taken, not because Mozilla is an "Oracle hater", but to protect users from hackers trying to exploit Java. I personally have not had Java enabled for almost a year because of this reason. I experience very little functionality issues.
wob1997: I'm happy for you. However, those of us who use Firefox in a corporate, educational, or non-US context find that we need Java on a daily basis. Most of the users I support never saw the red icon in the address bar, and some of them wouldn't have known what an address bar was if I told them to look there. The simple fact is, it wasn't obvious what had happened or how to change it; for many of us, things we used every day simply stopped working, and we had to dig around to find out what was going on. THAT is why everyone is upset. Not because of the attempt to add security, but because of the moronic way it was done.
Andy: Please be advised that the Java disabling has been rolled back.
Also don't forget that one of the reasons people choose Firefox is that it always used to stand for customisability. The about:config page is a good example of that. So the user should still be allowed to choose to enable plug-ins, maybe not trough the GUI but it should be possible through about:config.
(In reply to Benjamin Smedberg [:bsmedberg] (Away 24-25 October) from comment #83) > We certainly will be making java CtP by default when the UI is fixed (along > with all other plugins). Whether or not we want to use the scarier UI is > still an open question. > > In any case, I don't think it makes sense to re-use this bug, given its size > already. When we decide to re-block, I'll file a new bug and comment in this > bug to link them up. I get where you are coming from, Java is a pain, the problem is that it's also well implemented pain. And in Norway only a few onlinebaks let you use their services without a java plugin installed I would say that 90% of all househoulds in Norway, Sweden and Denmark need a Java pluging just for banking. So when you suddenly decided to block ALL Java without prior notice, I had to do 8 house calls and field 15 phone-calls from friends, neighbors and family. I would have been fine with it if this was given with decent prior notice, but the public communication about this crackdown would not only be a bug, but close to a epic failure. At least once a week i wish I could send the Java SE team out walking on burning charcoal (preferably with a trip wire) and I understand it has to go, but please make sure the PR department does a good job telling the world before you pull the trigger.
Java SE Engineering manager... [and faithful FF user] We are seeing a significant number of people report on java.com that FF indicates that Java 7u45 is vulnerable. Many are saying that their solution is to use IE. Searches for related terms are though the roof. Not sure if this was the intended end user solution when the FF team implemented this. The confusion about the messaging and how to allow Java to run appears to be a usability issue. Are there any stats on how this new block is affecting FF users behavior? To get FF users beyond the warning we are putting messaging together to instruct users on how to allow Java to run. Unfortunately such messaging is often too little too late, especially in security conscious enterprises. Hopefully we can get them to stay on their browser of choice. -Roger
Changes were already rolled back, Roger. See above.
Al, thank you for clarifying.
(In reply to Roger from comment #94) > Al, thank you for clarifying. Yeah it's nice to have a forum where users can track bugs in their chosen products and have access to very helpful, engaging, and tolerant engineers isn't it Roger??? Do you not think that yourself, Donald Smith, and Joe McGlynn should put down those stones and busy yourselves with the numerous outstanding Applet activation issues that your team has introduced such as: - https://blogs.oracle.com/java-platform-group/entry/liveconnect_changes_in_7u45 (God only knows what Caller-Allowable-Codebase was supposed to achieve) and an associated long-standing LiveConnect bug: - http://bugs.sun.com/view_bug.do?bug_id=9005723 JNLP and WebStart have introduced so many attack vectors that you've had to unilaterally disembowel the whole sandboxed Applet paradigm that has served untrusted and unprivileged html-tag-loaded applets for decades. Vulnerabilities can be fixed but need not burden the beauty and functionality of traditional Java Applets with the inherent vulnerabilities of JNLP and Web-Start! Now if only there was an Oracle/Java forum with the quality of engineering input as this then I wouldn't have to use up my annoyance quota with the Mozilla people and you would have felt enough justifiable heat from the suffering (Pavlov's Dog) user-base that you would reverse some of your more perverse Applet activation hurdles.
Anyone wishing to comment on this bug further, please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html If you think you are encountering a bug in Firefox please file a new report. If you are having an issue with blocklisting, Java, or Firefox please report it to support.mozilla.org. If you wish to discuss blocklisting, Java, or Firefox more broadly please take it to our mailing lists. You should only be commenting here if the rollback of the blocklist has broken your use of Firefox. If you do comment in this bug, or any bug for that matter, please ensure you are being respectful. Thank you
Blocks: 938698
Restrict Comments: true
Restrict Comments: false
Product: addons.mozilla.org → Toolkit
You need to log in before you can comment on or make changes to this bug.