Early IE9 Platform Preview results show promise

We've argued that Microsoft needs to engage more with Web developers to give a better understanding of what the company is doing with its Web browser, allow them to provide feedback throughout the development process, and more broadly get them engaged with the development process. With Internet Explorer 9's Platform Preview, Microsoft has indeed taken steps to do exactly this. Though Microsoft still isn't releasing the nightly builds that other browsers offer, the Platform Preview definitely represents progress; it provides early access to IE9's core rendering and JavaScript engines, and will be updated approximately every eight weeks.

The eight-week cycle was chosen because Redmond felt this provided the best trade-off between getting regular updates into developers' hands, ensuring that the preview releases are reasonably robust, and getting useful feedback that integrates well with Microsoft's own development processes. Each version will undergo reasonably extensive testing during the eight-week period, giving ample opportunity for bugs to be filed. For its part, the IE team has committed to investigating every single bug filed, and resolving all that it can.

Indications are that the Platform Preview has thus far been quite successful. Sources close to the matter state that some 700,000 copies of the preview have been downloaded, and that interest has been global in spite of the preview being a US English-only release. The top three bug report areas are SVG, compatibility, and then CSS, which certainly indicates that developers are taking an interest in testing the browser's new features and ensuring they work correctly. Of the hundreds of bugs filed thus far, the same source says that around 60 percent of them have been addressed by the development team.

These download numbers are substantial, and it could be make a good case in favor of this slower release strategy. The Mozilla group's weekly Status Meetings include information about the number of users of different prerelease versions of Firefox. During the lead-up to the release of Firefox 3.5, several hundred thousand people used the major betas, but the nightly releases were much less used, with perhaps 10,000-15,000 users. The Platform Preview is not anything near as usable as the Firefox betas, so 700,000 downloads is a strong showing.

Ars talked with IE General Manager Dean Hachamovitch briefly about the Preview. He said that IE9 testers seemed particularly interested in the browser's performance and graphical capabilities, as these areas of the IE 9 Test Drive site had received most traffic. This is also reflected in some third-party reactions. NVIDIA recently used the IE9 Platform Preview to promote the graphical capabilities of its new Ion2 platform—capabilities that IE9 can, of course, exploit due to its extensive hardware acceleration (the same hardware acceleration that leaves Windows XP users out in the cold).

Stability vs. automation

Microsoft's approach to browser development shows a strong commitment to the ideal of a stable, versioned platform, something that developers could reliably target for consistent results. This attitude is carried through to the Platform Preview. Unlike, say, Chrome's dev channel which automatically updates about once a week, ensuring that developers always have access to an up-to-date version, the IE9 Platform Preview will require manual updating. Though this has the obvious downside that developers might forget or not notice that a new version has been released, and hence may result in testing of obsolete versions, it maintains the important (to Microsoft) notion of predictability. With Chrome, a page might work one day and be broken the next by an automatic update, a behavior that can be confusing at best. Microsoft doesn't want IE developers to face a similar experience; instead, they will have to take deliberate action to update.

On the other hand, automatic updates are, in a sense, part-and-parcel of the Web experience. Websites can change their appearance overnight, and while this can be confusing to some, it's an unavoidable fact of Internet life. The case can certainly be made that browsers should follow websites' lead and update themselves; this gives users a browser that (by and large) keeps on getting better—faster, more capable, and with new features. Though occasional regressions will happen (wherein a new version breaks something that used to work) a robust development process should make these rare.

These advantages were acknowledged by Hachamovitch, especially for the more savvy, technically aware user (that is, users who are unlikely to be fazed by new features and improvements appearing within their browser automatically). But the company still prefers to take the more conservative approach to avoid problems of users being surprised by changes.

Hachamovitch was noncommittal about what the second Platform Preview release would contain when released next month. At MIX10 we saw demonstrations of HTML5 video in a build of IE9. The version released last month, however, didn't include video support. HTML5 video is surely one of the most eagerly anticipated IE9 features. It will ship in a Preview release eventually, but we do not know when.

The Platform Preview program is still in its early stages, and this is the first time that Microsoft has developed its browser in this way; there may yet be refinements to the program as both the company and third parties learn the best way to work together, and there's no news yet of what will happen once IE9 moves into beta.

Thus far, at least, it looks like the scheme has been successful at getting third-party developers involved with IE9's development, which has to be good news for both sides.

Source: Arstechnica.com

IE8, Safari 4, Firefox 3, iPhone fall on day 1 of Pwn2Own

The first day of the annual Pwn2Own contest in which security researchers can win cash and hardware if they successfully compromise machines using zero-day exploits is finished. Internet Explorer 8 on Windows 7, Firefox 3 on Windows 7, Safari 4 on Mac OS X 10.6, and iPhone OS 3 were all compromised during the competition. Google's Chrome was the only browser left standing—and in fact, was completely untested. None of the researchers at the competition even tried to attack Chrome.

So far, little is known about the successful exploits. Until vendors have been informed of the flaws and those flaws have been patched, details will not be made public.

The iPhone was not successfully hacked in 2009's competition, but was predicted to fall this year, and those predictions have come true. A zero-day Safari flaw was used to gain access to text messages stored on the device by Vincenzo Iozzo from German security firm Zynamics and Ralf-Philipp Weinmann, a post-doctoral researcher at the University of Luxembourg. Notable in the exploit was that it bypassed both iPhone's Data Execution Protection as well as its requirements that all code be signed.

A little more is known about the IE8 exploit, including an (abridged) video of the browser being taken down. The successful researcher, Peter Vreugdenhil, has published a rough outline of the techniques used to bypass IE8's DEP and ASLR protections.

The Safari hack came from Charlie Miller; this makes three years in a row now that Miller has pwned—and hence owned—a Mac at pwn2own. Thus far, nothing further about either this exploit or the Firefox one appears to have been published.

Neither the iPhone exploit nor the IE8 exploit managed to escape the OS-supplied sandboxes that protect these platforms. Without escaping the sandboxes, the impact that flaws can have is reduced, preventing, for example, writing to hard disk (and hence, preventing installation of malware). Nonetheless, read-only access is still valuable for data theft.

It is this sandboxing that might explain why Google's Chrome was untouched; no researcher even attempted to attack it. It is certainly not the case that Chrome has no security flaws—a couple of days before the Pwn2Own draw was made to decide who got to attack which machine and in what order, Google published an update to Chrome that fixed a range of security flaws, some of which were deemed to be high-risk. Google's sandboxing shouldn't be impenetrable, but it is sufficient to make the standard harmless exploit payload—starting up Windows calculator—harder to do.

Source: Arstechnica.com

Browser ballot already hurting Internet Explorer market share

The first few weeks of the browser ballot, Microsoft's solution to put an end to the EU antirust case, has already resulted in Redmond's browser losing market share to its rivals, according to web stats firm StatCounter.

In France, IE usage has dropped by 2.5 percent, Italy by 1.3 percent, and the UK by 1 percent. Browser developers Opera and Mozilla have reported strong growth within Europe, with Opera claiming that downloads have doubled since the ballot was introduced, and a Mozilla spokesperson claiming, "We have seen significant growth in the number of new Firefox users as a result of the Ballot Choice screen :As the ballot is rolled out across the rest of Europe, Mozilla expects further gains to be made.

The ballot isn't universally popular. Although 12 browsers are offered, only the top five are immediately accessible. The remaining seven are only visible after scrolling horizontally. As the seven minority browsers expected, their presence in the ballot has done little to boost their market share. A spokesman for the Flock browser said, "To date, new downloads of Flock originating from the browser choice screen have only contributed marginally to growth in overall downloads. This is also the case for the other browsers not on the main screen."

The remaining browsers have petitioned the EU to try to get the ballot changed. For its part, Microsoft still maintains that the browser ballot is compliant with the EU's demands. With some 200 million European users due to be shown the choice screen, and the benefits of being included becoming increasingly clear, time is clearly of the essence for the seven smaller browsers.

Source: Arstechnica.com

IE9, standards, and why Acid3 isn't the priority

Microsoft's development direction of Internet Explorer 9 is unambiguous: implementing HTML5 Web standards is the name of the game, with the intent of letting developers use the "same markup" to work everywhere. As IE General Manager Dean Hachamovitch said at MIX10 this week, "We love HTML5 so much we actually want it to work."

Redmond is targeting real-world applications based on real-world data. For example, every single JavaScript and DOM API used by the top 7,000 websites was recorded. IE9 will deliver support for every API used by those sites.

That obviously gives rise to a chicken-and-egg situation—what about the APIs that developers can't currently use because of a lack of widespread support, but would like to? Beyond the top 7,000 data, Microsoft has a number of HTML5 usage scenarios that it's targeting. The company has not said much on what those scenarios are, but given the demonstrations of HTML5 video and SVG animation, it seems that these are clearly viewed as core technology for a future HTML5-powered Web.

This dedication to HTML5 does not, however, mean that Microsoft is going to devote considerable effort to, for example, the SunSpider benchmarks or the Acid3 test. As the browser develops, the scores in those tests will likely improve (it currently gets 55/100, a marked improvement on IE8's 20/100), but they're not the number one priority. Acid3 is a scattergun test. It's not systematic—you can implement a high proportion of a particular specification and not pass the test, or a much lower proportion but still pass—and though many of the features it tests are useful, that's probably not the case for everything, and it's certainly not testing the one hundred most useful HTML5 features or anything like that.

More fundamentally, there are different degrees of "supporting a standard." Some demonstrations of the highly desirable and widely demanded CSS round borders helped explain this. The IE9 Platform Preview and WebKit both purport to support CSS3's rounded borders, and the Gecko engine (in Firefox) has an extension to provide rounded borders (the extension is nonstandard, but implemented in such a way as to not interfere with standard features). Rounded borders are something that developers are particularly keen on, since without CSS support, they have to be approximated with images, which is much less flexible (you can't easily change the colour or thickness of a border if it's done with images, for example). So in terms of desirability, they rank pretty high.

Unfortunately, they don't look consistent. At all:



These are two browsers that both support a feature. But they look completely different. This has two interpretations: either one or both of the browsers is wrong, or the specification is lousy (such that both browsers are doing what the specification says, even though it's surely not what any developer would want). In general, this kind of discrepancy isn't something that a test like Acid3 will reveal. It needs systematic, thorough suites of tests that verify each individual part of the specification, and ensure that the different parts of the specifications work together.

In developing these tests, sometimes errors in the specification will be revealed. But it's also likely that errors in implementations will be revealed, even implementations that are widely perceived to "support" feature X or Y. Acid3 can't show just how much of the HTML5 standards a browser supports. It can't even tell you very much about which parts of the standards aren't supported. To do these things requires much more thorough testing.

It's for this reason that Microsoft is continuing the work it did for Internet Explorer 8. With IE8, Microsoft developed, and delivered to W3C, a huge library of CSS 2.1 tests. Systematic testing was the only way to ensure that the browser truly lived up to the demands of the specifications. So for IE9, the company is developing a new raft of tests, the first batch of which have already been submitted to W3C. Microsoft doesn't want IE9 to have the same kind of test results as other browsers presently do; a feature isn't done until all the tests pass.

A case could be made that these other browsers are perceived as more compliant than they really are; while there are certain browsers that excel in certain areas (Opera's SVG support has long been extensive), other browsers also have considerable gaps. Sure, not as big as the gaps that IE8 presently has, but substantial nonetheless. All vendors clearly have plenty of work to do before the "same markup" goal really becomes reality.

Scoring well on the SunSpider JavaScript benchmark is similarly not an explicit target for IE9. SunSpider is useful, and tests JavaScript performance in many ways, but just as real web pages aren't written like the Acid3 test, real web applications aren't written like SunSpider. Real applications do things like optimize their design so that the basic page loads quickly, and then complex activities happen asynchronously in the background. SunSpider doesn't really test this style of development, and yet this is how real applications actually work.

This doesn't make SunSpider bad, but it explains why it's not a priority. It would be a mistake to optimize specifically for SunSpider, as SunSpider is not representative of real-world usage. Developers should optimize for reality, not for specific microbenchmarks.

Microsoft wants its HTML5 support to be stable and robust. This means that Internet Explorer 9 is unlikely to support every single part of the various specifications that make up HTML5; some parts are presently too much of a moving target to be viable. Other parts may be stable, but not relevant to the scenarios that the company is using to guide its development effort. But what the company will deliver will be thorough in a way that isn't necessarily the case with other browsers. Clearly the company has an up-hill struggle if its browser is to be perceived as highly conformant with Web standards. But it's certainly heading in the right direction.

Source: Arstechnica.com