A "modern browser" needs a "modern operating system," and Windows XP doesn't qualify. Much to my surprise (well, not really, I know that XP is still used and, apparently, loved by many), many doubted the characterization of XP as "obsolete," and they questioned my lack of surprise at this decision.
Simple things first. Windows XP is not a new operating system. Windows XP was released in 2001, and it has been succeeded by not one, but two newer operating systems: Windows Vista, and Windows 7. The other major desktop platform vendor—Apple—doesn't even begin to support anything that old, and the company routinely restricts its software compatibility to only the most recent version or two of its operating system.
Now, it's true that software is not like physical goods; while the ravages of time may make hardware break down, Windows XP works as well today as it did when it was new. Better, if you consider the extensive capabilities added in Service Packs and free downloads. But the computing world does not stand still; working as well as it did when it was new means that Windows XP hasn't kept up with computing's advances. The next generation of hard disks (or indeed, current generation, for Western Digital users), for example, are at risk of suffering severe performance penalties on XP systems. To get the best from the technology that for many has replaced spinning disks—the solid state drive—requires support for the TRIM command, found natively only in Windows 7. XP similarly lacks any built-in support for Blu-ray discs.
But what of Web browsers? A Web browser doesn't much care about, say, disk technology, so although it's undoubtable that XP requires more effort to use on modern hardware, this alone shouldn't be a reason for a Web browser to skip the platform. Do Windows Vista and Windows 7 offer capabilities that XP lacks that are relevant to IE9?
I think a pretty compelling case can be made that yes, in fact, they do. IPv6 is—fingers crossed—a technology that will become far more prevalent in the coming years, as the IPv4 address space finally starts to run out. XP does support IPv6 in a limited way, but it can only be configured using arcane command-line syntax. Windows Vista added GUI configuration and made IPv6 a first-class citizen on the network, and Windows 7 rounds out IPv6 support by including support for ancilary technology such as DHCPv6. XP is simply ill-prepared for an IPv6 world.
Web browser security is a problem
Web browser security is a notorious problem, as the recent pwn2own event has once again demonstrated. Windows Vista and Windows 7 have much greater systematic protections against security flaws than Windows XP does. The Address Space Layout Randomization feature makes existing flaws harder to exploit by making systems less predictable to attackers. This protection is not perfect, and there are indeed techniques that allow its circumvention, but every obstacle makes would-be hackers' jobs harder. The protection ASLR offers is also boosted by the use of a 64-bit operating system, another area where XP falls behind (64-bit XP is a bastard hybrid of Windows XP and Windows Server 2003, with the result that much 64-bit software that works properly on Vista and 7 fails to work properly or at all on XP 64).
More substantial protection is provided by the Mandatory Integrity Control feature of the two modern OSes. By marking a process as "Low Integrity," Windows prevents that process from being able to write to the majority of the hard disk and registry. The result is that even if the Web browser is compromised, the attacker is greatly restricted. Though an attacker can read most data (though this too can be restricted), he can't install rootkits, trojans, spyware, or anything else, because he cannot write to the parts of the file system required to do this.
Importantly, this protection has no real means of circumvention. Features like ASLR (and DEP, which is found in XP) are designed to make hackers' jobs harder, but do not erect any hard, kernel-enforced barriers, which is why, with skill, they can be bypassed. MIC erects a much harder barrier; to bypass MIC a hacker would have to find and use an exploit that allowed a process to elevate its privileges to strip itself of the "Low Integrity" label. If the attacker cannot do this, then he is forever trapped in the Low Integrity sandbox, unable to install his malicious software.
Privilege escalation vulnerabilities—software flaws that trick the kernel into giving a process more rights than it should have—do exist, so even MIC is no panacea. But they're substantially rarer than common browser flaws, and they are more likely to be fixed more quickly, because of their scope. Most important is that they can be fixed—they're a result of bugs in the kernel. DEP and ASLR can't be fixed as such; the circumvention mechanisms are to an extent inevitable.
The browser itself is a problem
The track record of Web browsers is pretty lousy. Actually, it's not just Web browsers; the track record of computer software is pretty lousy. Bugs are absolutely rife. But Web browsers are particularly important here, because Web browsers are exposed to potentially hostile code all day long. An exploitable bug in my MP3 player or word processor is bad, sure—it's something that I would prefer not to be there—but with these programs the main thing I'm going to use is my own MP3s and documents that I (or my colleagues) have written. And these files are going to be harmless. But the main thing I do in my browser, practically the only thing I do, is to look at webpages that were put up by other people. Other people who may or may not have good intentions; people who may or may not secure their servers properly, audit their code, or virus-scan their machines.
The result is that my Web browser is exposed to potentially hostile code like no other program on my PC. My e-mail client comes in second, and it's a distant second; even when I get hundreds of e-mails a day, most of these are from colleagues rather than spammers/phishers/other miscreants and ne'er-do-wells. As such, isolating the browser with MIC isn't just something that's a good idea—it's something that you would have to have a really good reason not to do. And frankly, no such reason exists. The Web is unfortunately a dangerous place.
Of the big five, only two browsers currently use this protection on Windows; Internet Explorer (7 and 8), and Chrome. For this reason alone, I'd be hesitant to use Safari, Opera, or Firefox. Their security track record isn't really any better than Microsoft's, and the consequent exploitability of these browsers is much greater.
This advantage is not one that is merely hypothetical, either. In common with other vendors, Microsoft assigns a risk rating to every security flaw, and Internet Explorer flaws on Windows Vista and Windows 7 have quite consistently had lower risk ratings than those same flaws on Windows XP. Why? Because the flaws are greatly restricted by the MIC barrier. Microsoft might be biased, but there are security researchers who concur; Charlie Miller, so successful at pwn2own, regards Chrome and IE 8 on Windows 7 as arguably the safest Web browsing platform. It's no coincidence that these are the browsers that use MIC sandboxing. The protection works.
Windows XP supports none of this protection, nor will it ever. Denying XP users access to its latest and greatest browser isn't a bad thing: Windows XP users should be strongly discouraged from using their machines in any hostile environment. Far from saying that IE9 should be supported on XP, we should be demanding that the other three browsers start supporting these security features and dropping XP support, too. These really are features that everybody should be using.
Graphically speaking
The biggest single reason for dropping XP is not, however, security; it's graphics. Internet Explorer 9 already boasts high-performance, hardware-accelerated graphical capabilities. In particular, Microsoft has shown off IE9's SVG capabilities. (SVG is a W3C standard that enables vector graphics to be embedded into webpages.) These graphics can be manipulated using JavaScript, opening up a whole new world of possibilities for standards-compliant webpages—widespread support for SVG might very well allow standard pages to start doing the kinds of tasks that hitherto have required plugins like Flash or Silverlight to accomplish.
SVG support is found in a number of other browsers, but it's not without its problems. One particular issue is performance. SVGs are mostly pretty slow; static images work fine, but even simple animations suffer poor frame rates. The result is that currently, SVG is only really good for static graphics. That's still useful, but there's a world of difference between a static graphics format and a moving, programmable graphics format. To use SVG for Flash-type tasks requires strong animation support.
The way that Microsoft has decided to achieve this is to use Direct2D for all of IE9's rendering. Direct2D is a 2D vector graphics API that's layed on top of Direct3D, and Direct3D is, of course, fully hardware accelerated. Direct2D is in many ways a pretty good match for HTML, CSS, and SVG rendering; unlike Windows' old graphics API, GDI, Direct2D is vector-based (so allows for easy, high-quality scaling and animation), but unlike OpenGL or Direct3D, it offers a simple programmatic interface that's tailored towards 2D graphics, without the complexity that 3D entails.
Similarly, for text, Microsoft is using DirectWrite. Again, the technology is high-performance, hardware-accelerated, and it integrates cleanly with Direct2D.
Is this the only way to do it? Well, no. An enterprising developer could certainly develop a Direct2D-like API (that is, a 2D API that simplified use of, and was accelerated by, OpenGL or Direct3D) by hand for XP, such that it could be used with, say, Direct3D 9c. DirectWrite is a bit trickier, as hardware acceleration of DirectWrite is dependent on some Direct3D 10-level features, but a reasonable approximation could probably be achieved.
But the thing is, Microsoft has already done the development for these APIs, and they're already shipped, supported, and available to third-party developers. They just require an OS that's been released in the past three and a half years (they're built in to Windows 7, and available as a free download for Windows Vista). It's ridiculous to expect the company to just ignore that it's done all this work, and then do it all again (and this time, to do it as something built in to IE, rather than as a general-purpose library available to any developer).
The other compatible option—abandoning 3D acceleration completely—seems even less palatable. It might be possible to create a high-performance, high-quality SVG implementation using nothing other than GDI, but no vendor has managed to do so thus far. It's certainly not clear that it's worth the development effort, given that an effective solution already exists: use Direct2D. Giving up entirely—throwing performance concerns out the window—leaves you with an SVG browser that's useless for animations, and as such, is severely restricted when compared to one that's a workable animation platform.
As large a company as Microsoft is, its resources are nonetheless finite. Moreover, the lack of scalability of software projects is well-known; getting more productivity by throwing more developers at a project is possible, but it takes considerable care, and can't be done willy-nilly. As such, the company absolutely has to choose where it spends its development time. Re-creating Direct2D, or writing a high-performance GDI-based graphics layer just isn't a good use of its resources. Most significantly, it's duplicating work that's already been done on a more modern platform.
Conclusions
Microsoft wants IE9 to be a first-rate browser, and to achieve that, the company is exploiting modern operating system features. That's precisely what Microsoft should be doing—these features have been developed so that developers can use them, and that includes Redmond. XP can't do the things that the new OSes can do. Kernel-enforced protected mode would be essentially impossible to provide on XP; a Direct2D equivalent would be doable (though DirectWrite might not be), but would require substantial effort, and in any case, an application simply shouldn't have to do such things. These are jobs the OS should be doing—jobs that Windows Vista and Windows 7 do, in fact, do. And not it's not just XP and Vista that support these capabilities.
Courtesy of Compiz and Cairo, Linux has 3D-accelerated desktop composition, and a 3D accelerated 2D vector API; Quartz Extreme and QuartzGL offer the same for Mac OS X. Mac OS X 10.6 also incorporates a security framework offering similar capabilities to Windows' Mandatory Integrity Control, and SELinux has long given Linux equivalent protection. This is not to say that these features are necessarily as widely used as they are in Windows Vista or Windows 7, but these abilities are clearly part of modern operating systems.
The new graphics APIs, coupled with the security advantages of Windows Vista and Windows 7—advantages that all Web users should be demanding that their browsers support, because they're really that good—make it clear that the new OSes have indeed advanced beyond the capabilities of Windows XP. Yes, I acknowledge that XP still does all that it does just as well today as it did when it was new . But I would also say that people should be demanding more of their OS. A 2001 feature set isn't good enough any more. I know it's also popular to claim that Windows Vista, in particular, really offers nothing new. But it does offer new features; it has just taken a while for software to exploit these new abilities. In sum, there are modern operating systems out there, operating systems that are ideal platforms for modern browsers. XP really isn't one of them: it's obsolete.
