Commentary

Dave Methvin
 

Microsoft and Mozilla Agree On Browser Risks

Usually the PC press spends a lot of time pitting the number 1 and number 2 browser makers against each other. I think that's just mean, and would prefer to focus on the important issues where they agree. Wouldn't you know, Microsoft and Mozilla have found common ground on the issue of browser plugins: both companies agree they can be dangerous.

Usually the PC press spends a lot of time pitting the number 1 and number 2 browser makers against each other. I think that's just mean, and would prefer to focus on the important issues where they agree. Wouldn't you know, Microsoft and Mozilla have found common ground on the issue of browser plugins: both companies agree they can be dangerous.Microsoft started the ball rolling when Google announced the Chrome plugin for Internet Explorer. That plugin lets you avoid the limitations of IE's browser engine by replacing it with Chrome's browser engine, without leaving Internet Explorer. Microsoft responded to the announcement by saying, "Google Chrome Frame running as a plug-in has doubled the attack area for malware and malicious scripts. This is not a risk we would recommend our friends and families take." Strong words indeed.

Just yesterday, Mozilla joined Microsoft in warning about the security dangers of browser plugins. Mozilla's concern was with two plugins that Microsoft installs into Firefox: The .NET Framework Assistant and the Windows Presentation Foundation. Last week saw a record patch day from Microsoft, including fixes for security issues in these two plugins. But Mozilla went further than Microsoft, moving beyond strong words and popping up a dialog to Firefox users with a recommendation that they disable these two plugins.


More Windows Insights

White Papers

More >>

Reports

More >>

Webcasts

More >>

Both companies are right. Anything you add to a browser increases the attack surface and increases the potential for security issues. In the case of the Google Chrome plugin, though, this is mitigated by three things. First, the user must consciously decide to install the Chrome plugin for IE. Second, the author of a web page must add a META tag to request that the Chrome plugin be used for IE users who happen to have it installed. So it's unlikely that any IE user will accidentally find themselves running Chrome for a web page. Third, there aren't any particular security threats that seem to be targeting Google Chrome at the moment.

Let's compare that to the two Microsoft plugins that find their way into Firefox. Neither of them are installed with any meaningful input from the user. Windows users have them delivered through Windows Update as high-priority items; if the system is set to install updates automatically, the user will need to dig deep to even see they were installed. These plugins have documented security problems with in-the-wild exploits.

The reason Microsoft is so keen to have these plugins running in Firefox is that they support foundation Microsoft technologies. Developers are less likely to use those technologies if they are responsible for getting their users to install (and potentially update) such "Microsoft plumbing" plugins. As Firefox grows in popularity, Microsoft is in the uncomfortable position of needing to get those plugins into a browser they don't control.

So it's great to see that Microsoft's Internet Explorer group and Mozilla's Firefox group agree on browser security, and even better that Mozilla has taken steps to protect Firefox users from a security threat put there by Microsoft without user consent. Perhaps the Microsoft IE folks can have a little talk with the Microsoft .NET Framework folks and convince them not to install browser plugins that the user didn't request. Then, Microsoft and Microsoft would both agree on browser security.


Related Reading




Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

InformationWeek encourages readers to engage in spirited, healthy debate, including taking us to task. However, InformationWeek moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. InformationWeek further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
T-Shirt Giveaway T-Shirt Giveaway: Each week we're selecting one great comment from our readers. The author of the comment will receive an InformaitonWeek Community t-shirt. So get posting!
Subscribe to RSS

Resource Links