Community backlash is building against a routine .NET Framework update for Microsoft Windows that quietly installs a browser add-on for user who surf the Web with Mozilla’s popular Firefox browser.  From WaPo’s Brian Krebs:

I'm here to report a small side effect from installing this service pack that I was not aware of until just a few days ago: Apparently, the .NET update automatically installs its own Firefox add-on that is difficult -- if not dangerous -- to remove, once installed.

Annoyances.org, which lists various aspects of Windows that are, well, annoying, says "this update adds to Firefox one of the most dangerous vulnerabilities present in all versions of Internet Explorer: the ability for Web sites to easily and quietly install software on your PC." I'm not sure I'd put things in quite such dire terms, but I'm fairly confident that a decent number of Firefox for Windows users are rabidly anti-Internet Explorer, and would take umbrage at the very notion of Redmond monkeying with the browser in any way.

Big deal, you say? I can just uninstall the add-on via Firefox's handy Add-ons interface, right? Not so fast. The trouble is, Microsoft has disabled the "uninstall" button on the extension. What's more, Microsoft tells us that the only way to get rid of this thing is to modify the Windows registry, an exercise that -- if done imprecisely -- can cause Windows systems to fail to boot up.

The Firefox extension is delivered through an update to Microsoft .NET Framework.  Once installed, it seems to be difficult to remove depending on your Firefox browser version and other factors, as the in-browser Uninstall button is disabled.  Manual removal instructions – which aren’t for novice users, as they involve some registry hacks – are here.

On my browser, Firefox 3.0.10, the add-on is present and uninstallable via the browser, although I can kill the extension through Add/Remove Programs.  Other reports suggest that there is a 1.1 version of this .NET Framework Assistant that allows the add-on to be removed directly within Firefox.

Questionable design decisions here.  Microsoft wants people to update their systems automatically, which requires implicit trust.  When an OS vendor starts shipping unpublished modifications to competing browser platforms, it’s a great way for users not to trust your updates.

If the functionality is important, then publish what you’re doing and explain why – provide notice and set context.  Don’t assume you have the rights to do what you want to a user’s applications, regardless of your intent.  As an OS vendor, this sort of thing isn’t tolerated well.  A simple Google search gives you the zeitgeist opinion of the situation, and it’s not what I would want to see.

(Crossposted from Unfiltered)

Surfin' Safari:

The Acid 3 test is far more complex than the Acid 2 test. It covers a wider range of standards and consists of many more individual tests. Browsers have to render a sequence of boxes that display dynamically in a stairstep pattern. For every cluster of tests passed successfully, the boxes will fill in with a color, which signifies that all of the tests covered by that block have passed. If you run Acid 3 on the shipping versions of current browsers (Firefox 2, Safari 3, Opera 9, IE7), you’ll see that they all score quite low. For example Safari 3 scores a 39/100. This percentage score is a bit misleading however. The situation with all four browser engines really isn’t that bad. You can think of the Acid 3 test as consisting of 100 individual test suites. In order for a browser engine to claim one of these precious 100 points, it has to pass a whole battery of tests around a specific standard. In other words it’s like the browser is being asked to take 100 separate exams and score an A+ on each test in order to get any credit at all. The reality is that all of the browsers are doing much better than their scores would have you believe, since the engines are often passing a majority of the subtests and experiencing minor failures that cost them the point for that section. Shipping Safari scores a 39/100 with some significant rendering errors. We’ve been working hard since the test surfaced and are pleased to report that we’ve entered the “A” range on the test with a score of 90/100.

My current default browser on OSX is Firefox 3b4. When the new Safari is released, I'm hoping I can jump ship over to it -- or that it's at least as good as the current Firefox 3 beta version. I have one issue that must be addressed, though, before I can even think about it. Link [via DF]

I use Firefox as my default browser on my Mac. I like it well enough, but the vast improvements in Safari under Leopard (specifically the improvements made to WebKit) have made me try to make the switch to Safari full-time. One issue remains however, and for me it's a real problem: Safari doesn't work well with Wordpress.com's web interface. Example: if I compose a post using Wordpress' web interface under Safari, it starts out well enough.

After publishing, though, things start to go to hell. This, obviously, renders Safari 3 relatively worthless for an all-purpose browser, seeing how using Wordpress' web controls is something I do regularly. (Even though I compose most of my posts with ecto, I often do edits/updates to posts using Wordpress itself.) This is the one bug that I'd really like to see fixed. I'm somewhat surprised that this happens under Safari, because in every other dimension of my web life, Safari doesn't miss a beat. With Wordpress, however, it does, and quite badly at that. If anyone knows a way around this, I'm all ears. Until then, I'm all about Firefox.