X
Business

Mozilla and Google accuse Microsoft of unfair browser competition

Microsoft will restrict third-party browsers like Firefox and Chrome to the Metro sandbox in Windows 8 for ARM devices, while treating Internet Explorer 10 as an "intrinsic feature" of Windows. Mozilla and its primary backer, Google, say that's not fair.
Written by Ed Bott, Senior Contributing Editor

With Windows 8, is Microsoft returning to its monopolistic roots?

That’s the question that Mozilla and Google seem to be asking this week. It’s taken a few months, but it’s finally dawned on both organizations that they won’t be able to deliver desktop versions of their browsers in Windows RT, the forthcoming version of Windows 8 that will run on low-power ARM chips.

Both Mozilla and Google have announced plans to create “Metro style enabled desktop browsers” for Windows 8 on x86 and x64 platforms. Like Internet Explorer 10, those will be dual-personality products that will run on the Windows desktop and in the far more restrictive Metro environment. By contrast, Microsoft’s own Internet Explorer 10 (and presumably later versions as well) will be the only browser that will run on the Windows RT desktop.

In a pair of blog posts, Mozilla project manager Asa Dotzler, who is leading the Firefox development effort for Windows 8, has called foul. Mozilla General Counsel Harvey Anderson also weighed in with a formal statement complaining about “platform lock-in.” In a statement to CNET’s Stephen Shankland, Google added its corporate voice to the chorus, expressing solidarity with “the concerns Mozilla has raised regarding the Windows 8 environment restricting user choice and innovation.”

In the first post, Dotzler argues: “Microsoft is trying to lock out competing browsers when it comes to Windows running on ARM chips. IE is allowed there but not Firefox or Chrome or Opera or any other competitive browser.”

Dotzler expands on those concerns in a follow-up in which he explains that it’s all about the APIs:

It's not precisely "running a browser in Classic" that matters for Windows on ARM. It's that running a browser in Classic is the only way that Microsoft has allowed us to get access to the APIs that a browser needs to deliver modern capabilities and performance in Classic AND Metro.

What’s confusing about all this is that the desktop version of IE10 delivered with Windows RT isn’t going to be a full-strength browser like its counterpart on the x86/x64 platform. Although desktop IE10 on Windows RT will have access to win32 APIs, it won’t be able to run plugins (like Flash or Silverlight), nor will it be able to hook into other apps running on Windows RT except through the permitted “contracts” mechanism.

The real advantage for IE10 is performance. As Steven Sinofsky explained in the most thorough outline to date of how Windows on ARM will work:

ARM SoCs for WOA have DirectX capable GPUs (DX) for accelerated graphics in Internet Explorer 10, in the user interface of Windows, and in Metro style apps.

But modern browsers rely on much more than the GPU for performance. Dotzler’s fear is that third-party Metro style browsers like Firefox will be hobbled, performance-wise, because they’ll be unable to use the same performance-enhancing techniques they use currently. And he argues in the comments section of his own post that IE10 has an unfair competitive advantage in that regard:

IE 10 on Win8 is mostly win32. They have a minimal front end coded in winRT and to hook into Metro capabilities like contracts but all of the performance critical paths are running against win32.

A Metro app also runs in a sandbox that prevents things like calls in to make memory writable -- something you need (and all browsers, including IE use) for a JIT, without which you cannot have fast JavaScript. It also prevents creating additional processes, something we use for sandboxing plug-ins and other browsers, including IE, use for sanboxing [sic] tabs.

Microsoft’s own documentation seems to agree. In the Building Windows 8 post, Sinofsky notes that the requirement for Metro-only apps on Windows RT eliminates many of the programming tricks used by Win32 app developers, including “background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques.”

The trouble with those tricks is that they also enable unreliable, memory-hogging, performance-draining apps. Ironically, Mozilla itself recognized that possibility last year when it blocked a McAfee add-on for Firefox, noting the add-on “causes a high volume of crashes.” A separate McAfee add-on was flagged earlier this year for performance problems after a Mozilla engineer said it “drags down Firefox and causes huge memory leaks.” Firefox itself has long been a target of complaints over its memory usage.

By restricting apps to the Metro environment, Windows RT will prevent those sorts of problems. It will also have a completely new security model that effectively kneecaps most forms of modern malware. Forcing all third-party apps to run in the sandboxed Metro environment and restricting delivery of Metro style apps to the Windows Store eliminates the most common vector for malware. Sinofsky again:

Our focus on delivering a new level of security for consumers using WOA is paramount. In one public event, we were asked if we would “make it easy for existing viruses and malware to run.” Now you can see the answer is decidedly, “no.” In fact, WOA only supports running code that has been distributed through Windows Update along with the full spectrum of Windows Store applications. As we all know, security is an industry-wide, multi-dimensional challenge and no system or platform can make broad claims without considering many factors.

In Windows RT, the Windows desktop is there for legacy purposes. The only apps that will run there are those that are part of a new, specially compiled version of Office 15. In a list of “intrinsic capabilities of Windows,” Microsoft pointedly includes “the new Start screen and Metro style apps and Internet Explorer" along with "the Windows desktop with tools like Windows File Explorer and desktop Internet Explorer.”

The design of Windows RT doesn’t contemplate any mechanism for including or updating Win32 apps. The only way to deliver security and feature updates is through the Windows Store (for Metro style apps) and through Windows Update (for Microsoft’s own code that runs Windows and those “intrinsic features”).

Dotzler accuses Microsoft of deliberately violating “the promises they made to developers, users, and OEMs about browser choice in documents which mysteriously disappeared from Microsoft's site.” That accusation, which is based on a dead link from a 2006 press release, seems at least partially unfounded. A significantly updated version of that document, covering open standards in general, is available at the Microsoft Open Specifications site. It doesn’t mention browsers or media players, which were the focus of the original document, but focuses instead on open standards.

At this late date, the likelihood that Microsoft will change the architecture of Windows RT to allow Firefox and Chrome onto the desktop is zero. The release candidate of Windows 8 will be publicly available in 30 days, which means the code is already firmly locked down.

The unanswered question is whether Mozilla or Google wants to elevate its complaints into a formal antitrust complaint. Given that ARM-based Windows devices have a market share of exactly 0% right now, with no guarantee that the new platform will succeed, that seems like a risky strategy. The argument is especially weak given that both companies have full access to the enormous base of x86 and x64 PCs.

In addition, it's hard to argue that consumers are being damaged. In the 1990s, Microsoft was accused of having a chokehold on the Internet with its Windows monopoly. In 2012, with the proliferation of Internet-connected mobile devices, Apple's strength in Mac sales, and iPad's stranglehold on the tablet market, can anyone make a plausible case that consumers will lack choice?

The other complicating factor is that Mozilla is likely to be seen as a puppet of Google in this regard. Remember last year, when Mozilla renewed its partnership with Google for a $300 million-per-year deal covering three years. In 2010, 84% of Mozilla’s revenue came directly from Google. With the new deal tripling Google's contribution, that percentage appears to be significantly higher, perhaps as high as 93% (Mozilla has refused repeated requests for additional details on its financing).

Given its own ongoing troubles with antitrust regulators, Google might not want to be dragged into a high-profile antitrust battle with Microsoft at this point, even by proxy.

See also:

Editorial standards