shaver

There’s going to be a lot of talk this week coming out of MIX, about IE8. Early reports are interesting, if still often hidden behind “NOT PUBLISHED” links on MSDN, but the most interesting thing I’ve seen yet is their change in IE8 rendering mode default. The specific change is a good one, but even more than that I think it’s very promising as a matter of process.

The original decision to make IE8 default to matching IE7’s legacy rendering mode was made in secret, secret even from many of the web experts in the organizations linked to from Dean’s post. Once the conversation was opened to input from the rest of the world’s experts on web content compatibility, they were able to get to a much better decision, and happily that’s reflected in the updated plans for IE8. I hope that this case helps Microsoft understand more generally that significant web-compatibility decisions are too important to be left to closed groups: the web is simply too big, with too many stakeholders, for that to be a workable path to success. (Not that simply operating under “a standards body” is sure to avoid such secrecy, as they can also have related damage, but they at least tend to have more diverse viewpoints, which is a half-measure of some value.)

I was also heartened that they were able to make such a change after announcing it. We’ve all heard before that the IE team wasn’t able to talk about their plans until they were very certain, because people build businesses on those plans and will be harmed are made after an announcement. The conspicuous lack of bankruptcies attributable to WinFS being dropped from Vista aside, that they were able to listen to “global” feedback and make a significant change based on that feedback gives me hope that a new, more open process may be beginning here. Bravo and thanks to Microsoft for listening genuinely and making a change that I think will have a very positive effect on standards-based content on the web.

Some of the items listed in the “IE8 Readiness Toolkit” look pretty interesting, and in at least one case (the “XDomainRequest” API) seem pretty close to the subjects of some recent discussions in standards groups and various open projects about solving similar problems. I’m not sure if Microsoft proposed their API or semantics to that group, or shared the design thinking that went into their choices, but I’m permitting myself to hope anew!

(In light of my previous post about compatibility liability, I was also very interested to see this titbit:

[...]we do not believe any current legal requirements would dictate which rendering mode a browser must use[...]

It’s much more likely that they’re referencing the Opera suit than that they’re talking about Microsoft representatives’ previous claims of lawsuit risk stemming from changes in new product versions, but it made me smile nonetheless.)

One thing that came up periodically when people on the HTML working group were discussing version selectors was the notion that there is legal liability associated with breaking compatibility. Chris Wilson is the person who most frequently brings up this point (unsurprising, given his affiliation and experiences with IE), though he may well not be the only one. I’ll excerpt one example here:

We (Microsoft) have to be in control of our own destiny there. Unless you’re suggesting that the WG would shoulder the financial burden when we (Microsoft) are sued because we broke compatibility and caused some company’s multi-million-dollar intranet app to break.

And later, though not referring to liability but rather a government “lockout”:

A single government who locks us out of their market because we broke their intranet app (even if they were ua-switching and giving us bad content, and it was “clearly their fault”)? Probably a very big deal.

I have a couple of questions, then, for the combined legal minds of the lazy web:

• What would be the legal basis for a suit by a customer, given the provisions of typical EULAs which explicitly disclaim pretty much all warranty they can? Let’s assume that the compatibility break is caused by an upgrade to a new version of software (Firefox 2 to Firefox 3, for example) that’s under the control of the customer. You can choose your jurisdiction, and assume the worst case for the vendor having end-of-lifed the previous version, etc.
• Can anyone find an example of such a suit having been brought?
• Not a legal question, but very much on my mind: given the impact that IE7 had on Korea, why would they have gone ahead and done the release anyway, if it was such a big deal for them to be locked out of a national market?

I invite your informed, or perhaps just creative, speculation on the topic! Personal attacks on Chris Wilson, or rehashed “Microsoft is evil so they got the illuminati to block Korea’s secret sanctions in the UN” conspiracy theories are not welcome, and might well be moderated out or disemvoweled.

There are a lot of good posts describing problems with IE8’s version selector feature, so I’ll just leave you to read those for some insight into problems that it creates (and how it pushes the IE-compatibility burden off Microsoft and onto other competing browsers in a very impressive way).

They’ve announced what they’re doing in IE8, and as we know from previous conversations with Chris Wilson, they don’t announce until they’re sure:

[W]e have to be very, very careful to be 100% confident when we announce things like “that’s exactly what we’re doing,” or “that’s the date that we are aiming for.” When we don’t, we tend to get a lot of people upset with us, of course, but it’s not just them being upset with us; it’s actually, it can be damaging their business model if they bet on us releasing something in a given timeframe, or bet on us releasing a given feature, and we don’t ship it

So we’re going to see X-UA-Compatible in IE8, with very high likelihood. It’s positioned as something that other browsers could use — if they wanted to ship multiple rendering engines to make download size a further impediment to competing with Microsoft, say, or totally lock themselves out of the mobile market — and the introductory document has examples like “FF=3″ in it.

And we know from the ES4 discussions that Chris believes in different groups working out proposals together, which is why they didn’t make a specific counter-proposal to the one put forward by TG1, after all:

It’s been pointed out that we haven’t made an alternate proposal - well, I’d kinda hoped we could work it out together. “Open to input” should be the way of the web, should it not?

So that makes me wonder: why were no other browser developers involved in this discussion? I guess that would ruin the protective cloak of secrecy, though I don’t know how else people would work things out together. (If Microsoft knows, they’re not telling, but I guess that shouldn’t be surprising?)

The naming of the header is sort of generic, but unless the next big announcement on the IEBlog is the release of IE8’s source code, “render this like IE8 would” really only helps Microsoft, and I think it works against the promising trend of convergence on open standards.

Another security study making the rounds today in which someone who purports to know a lot about analyzing security — whose blog tagline, in fact, cautions that “we should try not to simplify [security] to the point of uselessness” — has decided that a product becomes less secure when the developer fixes and discloses vulnerabilities that they find in-house. What Jeff Jones, a director of Security Strategy at Microsoft, has done is simply counted the number of fixed vulnerabilities reported by each of Microsoft and Mozilla, grouping by labelled severity.

What could be simpler? Perhaps nothing. What could be more useless? Again, perhaps nothing.

You can only count what the vendor wants you to see

If Mozilla wanted to do better than Microsoft on this report, we would have an easy path: stop fixing and disclosing bugs that we find in-house. It is well known that Microsoft redacts release notes for service packs and bundles fixes, sometimes meaning that you get a single vulnerability “counted” for, say, seven defects repaired. Or maybe you don’t hear about it at all, because it was rolled into SP2 and they didn’t make any noise about it.

We count every defect distinctly. We count the ones that Mozilla developers find in-house. We count the things we do to mitigate defects in other pieces of software, including Windows itself and other third-party plugins. We count memory behaviour that we think might be exploitable, even if no exploit has ever been demonstrated and the issue in question was found in-house. We open our bugs up after we’ve shipped fixes, so that people don’t have to take our word for our severity ratings.

While Microsoft’s senior technical staff are trying to get severity ratings dialed down (unsuccessfully; kudos to MSRC for sticking to their guns), we are consistently rounding our severities up when there’s any doubt at all.

More fixes means less security?

Even if the scales were the same, and we were living in a parallel universe in which Microsoft even approached Mozilla’s standards of transparency and disclosure, the logic is just baffling: Jeff is saying that Mozilla’s products are less secure than Microsoft’s because Mozilla fixed more bugs. By that measure, IE4 is even more secure, because there were no security bugs fixed in that time frame; bravo to Microsoft for that!

I use Microsoft’s software products myself; I’m typing this on a machine that’s running Vista, in fact. Not only am I pretty upset that we see Microsoft referencing this report without disclosing that it was written by a Microsoft director of Security Strategy, but I’m also concerned for my own safety. Do people in charge of security strategy at Microsoft really believe that aggressively concealing the count of fixes that do make it out makes a product more secure? Shouldn’t they be trying to fix more bugs, rather than writing reports that would “punish” them for actively improving the security of their users rather than hoping that defects aren’t found by someone who they can’t keep quiet?

Microsoft should be embarrassed to be associated with this sort of ridiculous “analysis”. We don’t pretend that hiding the rate of fixes improves our users’ security in any way, and we never will. We’re transparent and aggressive in dealing with security issues, and 130 million Firefox users are safer for it every day.

The search engine business is a tough one. People are generally pretty bad at knowing how to phrase queries to give them what they want, to say nothing of dealing with spelling mistakes and synonyms and stemming, and you have to do all that work basically instantaneously. The relevance of search results might be the only thing more important than performance in determining if users will stick with your particular product, or make the trivial switch to another one.

So I was pretty surprised to discover how, er, idiosyncratic the search results were on Live Search for what I — perhaps naively — think of as a pretty straightforward query.

When searching for “Firefox”, the user might want to find the home page for the product, or a description of the history of the project, or maybe even a review of the software. Both Yahoo and Google give you some mix of that, with what seem to me to be pretty reasonable orderings of results.

The Live Search results are a little more difficult for me to understand, since they have the Silverlight developer FAQ as the first result, then an article about cross-site scripting, then an article about ASP.NET, and then the Wikipedia page about Firefox. You have to go to the 8th entry to get the product’s home page, well below the fold on my machine at least. I’ve saved off the results, in case you disbelieve me, or for some reason can’t reproduce them yourself.

Maybe Live Search users really are a different breed, if that’s what they would be most likely to want when searching for Firefox; a ballsy market-differentiation move by Microsoft, if so.

(Canadians don’t call their judges “Your Honour”, and Americans don’t spell honour that way, so the title of this post is a somewhat impossible reference, but I figure you’ll let that slide.)