Why GeniusPro and GeniusEnterprise Support IE6
If it was up to our development team, we would have stopped supporting IE6 years ago. However, since several important customers are stuck on IE6, we are forced to maintain compatibility with a browser approaching eight years of age. What other eight year old tech product are you still using?
We don’t fault our users for using IE6. Many companies have internal applications that only work in IE6 due to its ubiquity (97% market share in July 2003) when those applications were initially developed and they thus rely on non-standards compliant features only supported by IE6’s JScript. For example, during a college internship at imaging giant Radnet I ran into such a situation. 90% of Radnet imaging centers used a billing and medical history application called IDX. IDX only supported IE6. While this was a pain, it was better than the other 10% of sites that still used a DOS based application called Radman. Brand new LCD screen machines running a DOS application. This is not a situation unique to Radnet or IDX. While we wish everyone would upgrade to a current browser, we know that this is not always feasible. Thus, as a SaaS company, the sales and marketing products we sell support IE6.
Why The eng.genius.com Blog Does Not Support IE6
This blog, however, is entirely under our control. Thus, we launched the blog with a WordPress plugin, the Anti Internet Explorer 6 Plugin, that conditionally meta-refreshes to a static page if someone has a version of IE less than or equal to IE6. We’re part of a growing content provider constituency that is taking proactive measures to stop the pain. It includes blogs, SaaS applications, social networking sites, and media. While we know it will inconvenience some people who, by way of corporate policies, have no way to upgrade IE or download another, better browser, we feel that it’s a necessary pain that the internet community needs to inflict to force companies to upgrade to a modern browser or at least give users an additional browser that can be used for sites that do not depend on IE6. It will help web developers and make companies that depend on IE6 more secure.
An example of one such visitor who became frustrated by our IE6 policy:
www.genius.com has decided to make the content unavailable to those of us running IE6. Why am I still running IE6? Because <INSERT COMPANY> financial accounting system requires it.
The page renders just fine, and I start reading the story. However, a few seconds into my reading, some widget loaded by the page re-directs to http://www.timo-ernst.net/stop-the-ie6/ and puts up a commercial for a newer browser.
I respectfully suggest discouraging sending any more links to broken pages like this one.
Another example from news.ycombinator.com:
Seeing as I’m at work and can’t upgrade from IE 6.0 I can’t view this site. Ahh Well.
We truly are sorry that we add to your pain by not allowing views from IE6 but we hope you understand that it is for a greater good.
StumbleUpon and IE6
StumbleUpon is a different story. While it may seem that the only possible problems with StumbleUpon and IE6 are problems they create with bugs on their site, we found out the hard way that this is not true.
Drew Stephens added our April 20 post on Java Semaphores to StumbleUpon at about 6:45PM PDT and then we waited to measure its effect on site traffic. The total number of visits continued to climb but our referral count from StumbleUpon remained at 0. As night set in, traffic to the site slowed and our referral count from StumbleUpon stayed at 0. Shortly after the day rolled over to be April 21 in San Mateo, hits from StumbleUpon began to pour in. By 1:15AM PDT, over 80 visitors had come from StumbleUpon. Interested in what may have caused this sudden burst of late night interest, I found the post on StumbleUpon and immediately noticed the apparent cause. The title had changed from being the URL of the post (the default value) to be “Stop the ie6”. Ah ha! The reason our post was so popular was because people thought it was about stopping IE6. That also explains the low star rating, after all, that post (unlike this one) is decidedly NOT about ie6.
Why Our StumbleUpon Posts All Have The Title “Stop the ie6”
You might be asking, “If the post is not about IE6, why did StumbleUpon report the title as being ‘Stop the ie6’?”
That’s a very good question and the answer took some digging (no, not the site with the new annoying StumbleUpon-esque page cloaking) to uncover. Upon greping through our access logs for “74.201.117.” (StumbleUpon.com pings to 126.96.36.199) I found:
188.8.131.52 - [21/Apr/2009:01:49:04] "GET /blog/2009/04/20/javas-semaphore-resizing/ HTTP/1.1" 200 50966
184.108.40.206 - [21/Apr/2009:01:50:10] "GET /blog/2009/04/20/javas-semaphore-resizing/ HTTP/1.1" 200 50966
220.127.116.11 - [21/Apr/2009:07:46:29] "GET /blog/2009/04/20/javas-semaphore-resizing/ HTTP/1.1" 200 50823
18.104.22.168 - [21/Apr/2009:07:46:30] "GET /blog/wp-content/themes/default/style.css HTTP/1.1" 200 15777
22.214.171.124 - [21/Apr/2009:07:46:30] "GET /blog/wp-content/themes/default/print.css HTTP/1.1" 200 2329
126.96.36.199 - [21/Apr/2009:07:46:30] "GET /blog/wp-content/themes/default/helpers.js HTTP/1.1" 200 284
Clearly the first two requests were simply to verify the post’s existence during submission by Drew. The following requests appear to indicate that StumbleUpon has some sort of batch job that took roughly six hours to pick up the post for full indexing.
This, coupled with two additional nuggets of data:
- GoogleAnalytics only showing one visitor to our site with IE6 out of our first 111 visitors on the 21st
- Our installation of the “Anti Internet Explorer 6 Plugin” for WordPress
lead me to one logical conclusion: StumbleUpon uses IE6 or spoofs IE6 when crawling pages.
Unsatisfied with a mere untested hypothesis, I did some additional digging. I setup a page that does nothing but record the current request as stored in the php $_SERVER super global variable. I then registered this page with StumbleUpon and watched the generated logs. At 9:41 am PDT, during the registration process, I saw a request hit the page:
[HTTP_USER_AGENT] => Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20071127 Firefox/184.108.40.206
[REMOTE_ADDR] => 220.127.116.11
[REQUEST_TIME] => 1240332078
At 9:50 am PDT I saw another request hit the page:
[HTTP_USER_AGENT] => Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
[REMOTE_ADDR] => 18.104.22.168
[REQUEST_TIME] => 1240332623
Thus confirming my speculation. StumbleUpon not only performs their picture grab/screen capture/title grab with a tool based on IE6 (or one that at least spoofs it), but also uses/spoofs an unsupported version of Firefox (22.214.171.124) for the initial confirmation ping. This is not only disappointing, but error prone. More and more sites are leaving IE6 support behind and so, if we assume that StumbleUpon’s screen capture tool embeds IE6 for the visualization, the screen grabs the tool takes are likely to be less and less accurate.
I’d be remiss if I didn’t mention my favorite April Fools gag and leave you with a screenshot of four eng.genius.com posts on StumbleUpon: