Firefox's automatic disabling of an extension and plug-in developed by Microsoft has led to a heated debate regarding the ethical aspects of the decision. ClickOnce-dependent users cried foul as they could not add a manual exception and Mozilla promised to provide a more granular blocklist override mechanism.

Last Friday evening, Mozilla took the drastic measure of adding the ".NET Framework Assistant” extension and the “Windows Presentation Foundation (WPF)” plug-in to its “Add-ons Blocklist,” citing security reasons. Both add-ons are developed by Microsoft to support some of its new technologies and were delivered as part of .NET Framework 3.5 Service Pack 1.

“.NET Framework Assistant” allows application developers to deploy their software to Firefox users using the ClickOnce technology, while the WPF plug-in enables Firefox to support XBAPs, browser applications built in XAML (Extensible Application Markup Language).

Mozilla took the decision to forcibly disable both add-ons by adding them to the blocklist after it became aware of a remote code execution vulnerability in the Windows Presentation Foundation hosting process. This bug was patched last Tuesday as part of the MS09-054 security bulletin.

Critics of the decision see major problems with this approach. First of all, a patch for the vulnerability was already available at the time of the blocking. This is not consistent with how Mozilla handled similar situations with other plug-ins.

A recent example is the Adobe Acrobat Firefox plug-in, which allows opening .PDF files directly inside the browser window. On October 8, Adobe announced that a zero-day critical arbitrary code execution vulnerability affecting the latest versions of Adobe Reader and Acrobat was being exploited in the wild. A patch for this flaw shipped five days later, on October 13, but Mozilla did not disable the plug-in during that time.

Of course, cutting support for PDF in Firefox would have affected much more users than cutting ClickOnce support, but is that a good enough reason to treat two plug-ins and developers differently? Mike Shaver, Mozilla's vice president of engineering, notes that the decision was not taken lightly and that Microsoft was informed and agreed to the plan before it went into effect.

Additionally, he explains that a few other aspects contributed to the decision as well. For one, Microsoft's patch for the WPF vulnerability was delivered as a security update for Internet Explorer and did not make it clear that Firefox users were not affected. This made it probable that some people who exclusively use Firefox would not install the security update.

“We're working with Microsoft on getting that fixed,” Shaver said on Sunday. “Microsoft and Mozilla agreed that we should block the plugin and add-on [extension] to mitigate the risk while we made sure that FF users were going to install that IE patch. This isn't an us-vs-them thing,” he stressed.

This explanation caused some people to ask why the add-ons were not blocked only on unpatched systems, as Mozilla did for other plug-ins in the past. According to Shaver, it wasn't possible in this case, because “The WPF plugin doesn't expose any version information, unlike Flash and other such systems, and it didn't get updated with MS09-054.” Microsoft's closed-approach to security did not help either. “If I had known about this vulnerability before they [Microsoft] posted [the Firefox-related info] on their blog, I would have told them to provide just such a distinction, so that we could disable only unpatched setups!“ Shaver explains.

Another reason for this weekend's slating of Mozilla's decision was the blocking of the “.NET Framework Assistant” extension along with the WPF plug-in, even though only the latter was affected. In fact, it was this unusual banning of the extension that caused most problems for users, specifically those who depend on ClickOnce applications.

Many argued that Mozilla took advantage of the situation to get back at Microsoft for the clandestine method used to ship this add-on in the first place. The “.NET Framework Assistant” extension is silently installed in Firefox at machine level, without any warning to the user, when the .NET Framework 3.5 SP1 “important security update” is deployed. This install method also causes the Uninstall button to be grayed out for this extension in the Firefox Add-ons window, making it significantly harder to remove for the average user.

Some users affected by this blocking also condemned the fact that there is no method of easily overriding it. The only solution is setting the value of the extensions.blocklist.enabled entry in about:config to false, which disables the Add-ons Blocklist feature entirely. In response, Mozilla promised to deliver a mechanism to add exceptions manually.

Meanwhile, the extension has been removed from the blocklist. “We received confirmation a couple of hours ago from Microsoft that the add-on itself is not a vector for these vulnerabilities, so we've removed it from the blocklist. You may revel in your clickonce-ing again, apologies for the inconvenience and thank you for your patience,” announced Mike Shaver yesterday evening. “We're still working on the overridable block for the WPF plugin, updates on that when I have them,” he added.

It is worth noting that starting with Windows 7, Microsoft has stopped deploying the ".NET Framework Assistant" Firefox extension with .NET Framework 3.5 SP1. "I believe that there will be a solution for Windows 7 users; we have offered our help to Microsoft on that topic, and it is a genuine offer. I don't think they want to inconvenience users any more than we do, but it's not appropriate for me to speak to their plans," said Mr. Shaver.