Mozilla and Microsoft work together on WPFClickOnce plugins


 image Recently some friends mentioned that they saw Firefox had block-listed some Microsoft WPF\ClickOnce add-ons. As Mike Shaver (VP Engineering for the Mozilla) noted in his blog post, this action is the result of Mozilla and Microsoft working together to protect customers in relation to Security Update MS09-054.

I think it is very important for Microsoft and Mozilla to collaborate so actively to help protect customers… in this case we all agreed it made sense to add the Microsoft add-in to the block-list. We also heard clearly that many customers, especially enterprise customers are relying on this add-on for their daily work. As such Mozilla and Microsoft are working together to give these customers the best possible experience. Like Mike mentioned, as we learned more about MS09-054, we felt mutually good about re-enabling the clickonce addon and as this security fix hits market saturation, we expect to feel comfortable with re-enabling the WPF add-on as well.

We’ve heard loud and clear from customers how we need to work better with Mozilla around how our plug-ins and add-ons interact with Firefox. And I can promise you that our group will continue to collaborate with Mozilla to more proactively notify them of the effect of updates in the future to help ensure customers have interoperable solutions for their business needs.

I’d like to thank Mike and his team at Mozilla for their great work on this issue and look forward to working with them in the future.

Comments (15)

  1. David Nelson says:

    Someone needs to step up to the plate here and acknowledge that actively disabling critical functionality on end user machines without any way for them to override was the WRONG thing to do. All I keep hearing is how both companies worked together to come to the decision, but no one will admit that both companies were WRONG!

    I know Mozilla is working on a "soft block" for Firefox that will at least give users the option in the future. That is not the point. The point is that, given what the situation was at the time, both Mozilla AND Microsoft chose to take the decision out of the hands of users and instead force feed their own decision to users, which was to completely lock out critical functionality without any consideration of the risk versus the necessity of the functionality, or even whether there was still any risk at all.

    It is decisions like this that continue to make Microsoft despised for its attitude towards end users, and will soon drag Mozilla into the same category if they repeat this kind of action. I don’t want to hear "we are working towards a better solution." That gives me no confidence that anyone involved understands how badly this was mishandled. I want to hear "we screwed up, we know it, this is how we are changing our policy to make sure this kind of thing never happens again".

  2. This looks all very nice but you have to wonder: is Mozilla going to disable Flash next time they have a security issue?

  3. CGomez says:

    @David Nelson

    Your analysis is fine until the point where you decide to blame just MSFT.  Why didn’t Mozilla provide user options as you aptly pointed out?  Like I said, you were doing great until the hyperbole of "dragging Mozilla" got ramped up.

    I have seen the add-ons in question, and I don’t use them, but I’m sure some people do and needed the functionality for those days.  Perhaps both companies will open up a little.

  4. Yeah I agree there has got to be a better way than just uni-laterally disabling addons. It threw a curve ball into debugging firefox’s Blinking Close Button Bug… which by the way is still an open bug. At least we know now .NET and WPF are not culprits for THAT BUG!

  5. Mike Shaver says:

    @Bertrand: we might if Adobe agreed that it was the best way to deal with a vulnerability, or to provide "safe cover" for an update to get deployed.

    @CGomez: we did, within 72 hours of the initial block — we had to build the capability into our server software in a hurry, because of how the timeline played out.  Is it not overridable for you?

  6. John says:

    Brad,

    A big part of this problem is that Microsoft bypassed the standard Firefox plugin distribution mechanism.  A lot of people who never asked for .NET integration in Firefox were exposed to a security problem.

    Will Microsoft commit to NEVER AGAIN shipping a Firefox plugin via Windows Update?

  7. Calvin says:

    @CGomez:

    I was able to enable the WPF plugin in my Firefox (3.5).  Anybody not able to re-enable the plugin?

  8. Sriram says:

    Why so much of negativity here.. If a security flaw is discovered, it should *immediately* be addressed to – and thats what Microsoft and Firefox did in this instance. You(they) cannot afford to say ‘there is a serious vulnerability and gee, all you enterprise customers or otherwise, we will have a fix coming in the next couple of days/weeks and hopefully your PCs wont be affected by the vulnerability’..

  9. Timothy Bussmann says:

    I remember seeing the dialog saying the plugins were blocked.  My first thought was that Mozilla and MSFT had an internal spat and Mozilla decided to take a hard line against MSFT.  Clearly that wasn’t the case.

    It sounds to me like Mozilla should have provided a message to go along with the block notice, indicating why the block was put in place, the fact that the decision was made in collaboration with MSFT, how to override the block, and where to go to get more information.

  10. CGomez says:

    @Calvin and @Mike Shaver:

    I don’t have a problem.  I was reacting to the vitriol and hyperbole of the first commenter.  My belief is it was okay to be upset, but some of the comments were just ridiculous.  

    He wants to hear "we screwed up, we know it, this is how we are changing our policy to make sure this kind of thing never happens again" and my point is: Who says that isn’t going to happen?  What if the new policy isn’t done yet and the whole (very fresh) incident is still being examined?

    I just was greatly disappointed in some of the coverage around the web… many of the tech blogs (that are really nothing more than tabloids) accused MSFT of "sneaky add-ons" as if MSFT was trying to introduce bugs into Mozilla.  Give me a break.

    I’m not having any problems at all, thank you very much.  I was commenting on the vitriol and that I think it is uncalled for at this point.

  11. David Nelson says:

    @CGomez,

    Don’t get me wrong, I DO blame Mozilla. Both for not having a soft block option in the first place, and for choosing to block both the plugin and the extension when they knew it would disrupt their users. But this is not a Mozilla blog, and Brad doesn’t work for Mozilla, so my comments on his blog were directed towards Microsoft’s actions.

    Microsoft has already been roundly chastised for the way the plugin was rolled out in the first place. I have no interest in revisiting that tired discussion. My only interest at the moment is how both companies handled the situation they found themselves in on Friday the 16th.

    I do not believe that my comments were vitriolic, nor do I believe there was any hyperbole. I would thank you to point out where you believe you saw that in my comment. I offered my (admittedly strongly worded) analysis of what I believe was a critical error by both companies. Perhaps you are mistaking passion for vitriol?

    You say that they might yet announce some new policy after the incident is examined. Why would you believe that when both companies have stated repeatedly that they believe they did the right thing? The purpose of my comment is to help them understand that it is NEVER the right thing to unilaterally deny potentially critical functionality to end users.

    Ultimately what both companies need to understand is that it is not their job to decide for me that security should be at the top of my priority list. Security is a trade-off, and it is one that I am responsible for making for my organization. A vulnerability is discovered; ok, that’s bad news, and it puts me in the position of having to make an unpleasant choice. But it is MY choice to make. I am responsible for weighing the risk of the vulnerability versus the effort of patching our systems versus the cost to my organization of having our critical workflows disrupted. Neither Mozilla nor Microsoft can make that decision for me. The fact that they chose to do so announced loud and clear that they believe they are better at determining security policy for my organization than I am. That is an unacceptable attitude, and I will not apologize for demanding that it be changed.

  12. cmb says:

    So, taking the other side of the argument here.  

    If Mozilla and Microsoft chose NOT to block access to the plug in, and then the security flaw was exploited causing identities to be grabbed, data to be stolen, virus’ to infect corp networks, whatever.  People would be screaming "Why was this not blocked with your blocklist when you found out about it!   Stupid Microsoft, Damn Mozilla…blah blah blah blah"

    I am not going to get into the argument about Microsoft installing their firefox plug-in and not providing an easy way disable it/uninstall it.  They did it, it was wrong, but it’s in the past.  Get over it.

    The same goes with Mozilla’s block list.  The built it such that people can’t override it. (well you can, I read about a property in about:config to turn the blocklist off).

    In this day and age when everyone seems to be concerned about viruses, identity theft, data being stolen, etc.  I would have assumed everyone would be happy that these companies aired on the side of caution and blocked the issue to protect you/companies until the flaw was fixed.  

    I guess this only applies when people aren’t inconvenienced by the security flaw.

    cmb..

  13. David Nelson says:

    @cmb,

    The flaw WAS fixed. A patch was released to Windows Update two days prior to the add-ons being blocked (see the complete time line on Mike Shaver’s blog at http://shaver.off.net/diary/2009/10/19/update-on-the-net-framework-assistant-and-windows-presentation-foundation-plugin-blocking-from-this-weekend/). Had no patch been available, I probably still wouldn’t agree with the decision to unilaterally block the add-ons, but at least I could understand it.

  14. Rockee says:

    Great cooperation team work!

    Thanks

  15. Tim says:

    I have no problem with companies being able to register components info FF like this. If running click-once etc. involved telling users to install .Net 3.5, and then go find the correct add on…. etc etc.. it would be a pain!

    However it should have been clearer when isnatlling  the framework.

    However I think FF should just alert users when it next starts up and discovers any new add-on,  and/or when a plugin is first used!

    Also why does something like the WPF plugin have to be enabled or disabled! Why not have an ‘ask on use’ option?  

    Lastly I dont know why MS didnt just add clickonce as a new registered protocol i.e. clickonce://host/app.application or ms-wpf://host/app.xbap