Web Devout tidings

Today, someone asked me why I had deleted my last few posts here. I didn’t. It turns out, during a series of server moves, VMWare updates, and other shifting around, somehow the system clock got set back to January and NTP wasn’t kicking in. As a result, the posts made since January were considered “Scheduled” posts and weren’t appearing on the blog. I’ve now fixed the time issue, and all posts are visible again.

In case you haven’t noticed, I haven’t exactly made a lot of progress on the standards support testing. And I don’t anticipate that changing any time soon. I don’t have much time outside my day job (which has been increasingly demanding in the last couple of months), and the free time I have is usually spent taking a break from work or working on other projects that have higher importance for me.

I know I’ve been saying this for a long time, but I think the solution is to build a community-driven system that lets the public file, categorize, and vote on bug reports. Reports that have been confirmed by enough users would get added to a table structure like we currently have. A simple wiki wouldn’t be sufficient; more than 95% of the change requests I get in the current system are incorrect or of unusable quality, which has led me to basically ignore those submissions altogether. I really think a more robust system, with test cases and links to the bug reports on the vendor’s bug trackers, would be ideal. But then it’s an issue of actually writing such a system, and that again requires free time.

At some point, I’ll do something. When I start making promises about how I plan to use my free time, that’s when I tend to suddenly lose motivation to follow through on those plans. So, for now, I suggest looking into other resources for standards support information, but stay subscribed to my RSS feed.

I just realized today that I hadn’t seen any Secunia vulnerability updates in a long time. I knew they had done some site redesign work, and I figured they just changed the URL of the RSS feed. So I sat down at my computer to find it, but there didn’t seem to be one anymore. A quick hop on Google led me to this forum post explaining that Secunia no longer provides a free RSS feed for vulnerabilities:

As you have noticed we no longer provide our vulnerability intelligence through the Secunia RSS Feed.

Explanation:

Today a large number of businesses and governments are subscribed to the commercial Vulnerability Feed from Secunia.

Over the past couple of years, Secunia has noticed that numerous businesses and governments have signed up for the Secunia RSS feed, as a result there has been a loss of revenue for Secunia which has limited us in our endeavors on providing sustainable and quality solutions.

It is naturally not fair toward our customers that larger IT departments are receiving intelligence free of charge – using our RSS feed – as others would have to invest in it.

The service that will replace the need for our RSS feed, will be the Secunia Vulnerability Intelligence Feed – VIF. This is naturally a commercial solution, please see attached PDF for further clarification.

In my opinion, this was a very dumb move by Secunia. Keep in mind that the RSS feed didn’t provide anything that wasn’t already public; it just provided it in a different format. In a few minutes, I could write something that generates a similar RSS feed from the HTML output of Secunia’s website (although their terms of service are also excessively heavy-handed about this). This is a common sense usability feature, not a product that should require a paid subscription. For Secunia to restrict its availability to paying customers is akin to if Google were to suddenly make message collapsing in Gmail conversations only available to people who fork over cash.

One of the things that made Secunia so appealing to me was how accessible their information was. Now, it’s like the site is living in the 1990s. It’s a real shame when a company is willing to cripple their service like this rather than find a legitimate business model. Secunia has some very valuable assets; if their business really depends on profit from a mere RSS feed of already-available data, they’re doing something wrong.

Because of the removal of the RSS feature, my Web browser security summary page is likely outdated. I’ll go through Secunia’s advisory archives and update my data sometime soon.

Okay, it wasn’t quite that dramatic, but the graphics card on my Windows laptop putzed out today (just as Michael Scott was sneaking back into the building), and I won’t be able to get it fixed/replaced until at least next week. That means I’m not going to have any IE 8 standards support updates this weekend. I still have my Linux desktop computer, so I’ll use this time to work on the information for other browsers instead.

I need to start this post with a giant asterisk: I’ve barely done any regression testing yet. With the exception of one regression a commenter found, my initial results assume that IE 8 doesn’t have any standards support bugs that weren’t in IE 7. This is a big assumption, since IE’s CSS engine was largely (perhaps entirely) rewritten for IE 8. I expect IE 8 to have a number of new bugs which aren’t yet documented in my tables, and those bugs will be discovered and documented over time.

Alright, now that that’s out of the way, let’s get to the current results. IE 8 has fixed almost every single CSS 2.1 compliance bug from IE 7. I’m currently counting a total of 17 “Incomplete” values (7 of which are due to the single regression mentioned above), with everything else being a “Y”.

This is a huge deal. While I can’t yet comment on the CSS 3, HTML, or DOM support, IE 8’s CSS 2.1 support is now right up with the competition. We still have to see how it holds up after more regressions are found, but it is currently ranking as the #1 most CSS 2.1-compliant web browser I’ve tested. This is truly excellent work from the IE team.

In the next version of IE, I would like to see some focus on getting rid of a number of “temporary glitches” I’ve noticed. They appear to be similar to the reflow bugs that plagued Firefox 2, in that merely hovering your mouse over the element or interacting with stuff around the element will often correct the glitch. An example is the tabs in the Webpage test system. I don’t think there’s any neat little box in my tables where I can document these issues; they seem more related to IE just losing track of stuff during painting.

I’m going to do the CSS 3 testing next.