Tag Archives: Alternative Browser Alliance

Don’t Block Internet Explorer

Apparently there are websites out there that are redirecting Internet Explorer users to the Alternative Browser Alliance. This is, IMHO, both counter-productive and counter to the open spirit of the web.

For all the same reasons that you shouldn’t block visitors using Firefox, Safari, Chrome or Opera, or anything else unless there’s an actual, genuine technical reason (and unless you’re doing serious multimedia that has no fallback option, there is rarely a genuine technical reason), you shouldn’t be blocking visitors using Internet Explorer…

Because you’re not going to change them. You’re just going to make them angry.

They arrived at your site looking for something. Slapping them in the face and sending them off to another site is not going to get them to change their behavior and come back. It’s just going to make them look somewhere else for someone offering the same thing who won’t make them jump through hoops.

Case Study

Last week I received a message through the Alternative Browser Alliance’s contact form asking, “What does this have to do with cpanel?” I wanted to reply, “Nothing, why do you ask?”…but the person who asked the question hadn’t left an email address, just the name “King Kong.”

(Tip: If you want an answer to a question, give people a way to contact you!)

So I checked the server logs and saw that he(?) had arrived on the Why Alternative Browsers? page and had left no referrer. Great, another dead end.

I was ready to write it off as spam, but then I decided to search the logs for cpanel, and found several hits referred by a cpanel tutorial. I visited the page and didn’t see any links to my site, but when I looked at the source, I spotted this script:

if(navigator.userAgent.indexOf("MSIE")!= -1)
{
   window.location = "http://www.alternativebrowseralliance.com/why.html";
}

Wow. They just redirected all IE users with no explanation — not even pointing out that they were being shunted off to another website! Imagine opening the front door of a computer repair shop and walking inside to find a political activist’s office instead!

Presumably “King Kong” had searched for cpanel, followed a link to this tutorial, and found himself looking at a page about alternative web browsers. No wonder he didn’t leave a contact address. He didn’t want an answer. He was angry and blowing off steam — at me, for something that someone else did.

And did badly, I might add: Three of the five visits I could actually identify in the logs claimed to be Opera Mini, not Internet Explorer. I don’t recall whether Opera Mini can masquerade as another browser (the current Android version doesn’t offer the option, but this claimed to be an older Java version), but the desktop version certainly can. Older versions of Opera used to deliberately identify themselves as IE (with a tag adding that, no, actually it’s Opera), and would have been caught by this script!

The User-Agent isn’t a reliable indicator. It was never intended to be. If you must single out Internet Explorer for some reason, use conditional comments. That’s what they’re designed for.

If what you want to do is block IE visitors, though, think about what you’re really accomplishing. And please, don’t just silently shove the “problem” visitors onto someone else.

Alternative Browser Alliance Update

Just a quick note: I finally got around to updating the Alternative Browser Alliance website. Not the full rewrite that I was planning to do two months ago, but at least it’s now current on things like Google Chrome, Firebug, Dragonfly, etc.

I’ve also released that site under the Creative Commons Attribution-Share Alike 3.0 license, which should simplify matters for translations.

Finally, as a compromise between a full blog and little notes on the home page, I added another Twitter account, AltBrowser, where I’ll post not just site updates but random bits of news, comments, tips, etc. related to the topic.  I don’t have time to maintain yet another blog.  And I’m not convinced the net needs one.

I still hope to do that major rewrite, but this should bring it mostly up-to-date.

The New Browser Switch Campaigns

Rather than looking at campaigns for specific browsers, I’m looking at a class of campaigns that are either promoting a group of browsers, or advocating against the current dominant player: Internet Explorer.

Browse Happy — the classic.

  • Goal: Move users away from Internet Explorer.
  • Target Audience: IE users.
  • Promotes: Firefox.  Also Safari, Opera, and… um… Mozilla.  Hmm, someone needs to update that.
  • Pitch: IE is dangerous.
  • Method: Banners

Alternative Browser Alliance

  • Goal: Keep multiple standards-compliant browsers viable.
  • Target Audience: All users
  • Promotes: Opera, Firefox, Safari.  Also Flock, SeaMonkey, K-Meleon, Camino,etc.
  • Pitch: Competition is good for everyone.  See what’s out there.
  • Method: Banners

End 6! (end6.org)

  • Goal: Move people off of IE6
  • Target Audience: IE6 users
  • Promotes: Firefox, Opera, Safari, Flock, IE7
  • Pitch: IE6 is outdated, buggy, and unsafe.  Use something modern instead.
  • Method: Overlay for IE6 visitors

Save the Developers (savethedevelopers.org)

  • Goal: Move people off of IE6
  • Target Audience: IE6 users
  • Promotes: IE7, Firefox, Safari, Opera
  • Pitch: Coding for IE6 is a pain.  Stop putting us through that.
  • Method: Animated drop-down at top of page for IE6 visitors

(Yeah, I’m catching up on old draft posts.)

Suggestions Wanted: Alternative Browser Alliance Relaunch

Alternative Browser AllianceYou may have seen my website, the Alternative Browser Alliance. I put it together in 2005, when flame wars between Opera users and Firefox users were at their height, to show that we shared a common goal: opening the web. The most popular page on the site is a list of web browsers, which is linked as a resource from a number of sites and also gets a steady stream of traffic from people searching for alternative browsers.

Of course, things have changed a lot since 2005, so I’m planning an overhaul of the whole site. Continue reading

The Spammers, The!

I recently noticed that the mail server was experiencing 4 times the typical number of SMTP connections. It didn’t seem to be under any stress, though, not as far as server load went. So I watched the log file trail, and saw a bunch of messages coming in to nonexistent users with the pattern, FirstnameLastname@alternativebrowseralliance.com.

My first thought was that someone was running a dictionary attack against the domain, trying many different addresses to see which might be valid. Then I noticed that they seemed to be coming from <> — in other words, they were bounce notices.

Great. A Joe Job.

I enabled a catch-all temporarily. That did cause the server to slow down, as it was now actually processing the quadruple load instead of kicking back 3/4 of it with a “User unknown” error. (I hadn’t thought to disable spam scanning on the domain first.) In the 30 seconds before I turned it off again, it picked up 25 non-delivery notices. And those are just the ones that got past the spam filter.

As it turned out, they were just random junk. Some spammer had picked the domain and was using it to forge random From: addresses, and we were getting the bounces. In the old days they made up the whole address, but it’s easy to check whether a domain exists. So now they pick some real domain and make up a fake address. That’s harder to detect unless the domain in question uses some sort of verification system like SPF or DKIM.

So it wasn’t a Joe Job: no one was trying to besmirch the site’s reputation. It still meant extra traffic to the mail server, though.

This problem is called backscatter, and it exists for two reasons:

  1. The sender address on an email message is easy to forge, like writing a fake address on an envelope.
  2. Many mail systems will accept a message first, then process it. If it then decides to reject it, it can’t respond to the actual sender, only to the one listed in the message—and in the case of spam, it’s usually forged (see #1).

I don’t send any mail using the domain. The only reason it even has mail pointed anywhere is so that I can receive mail sent to the webmaster for the Alternative Browser Alliance. I suppose I could set up a -all (no servers are authorized) SPF record, and hope some recipients decide not to send bounces. But I’m not sure how much it would actually accomplish.

Anyway, the two lessons to take away from this are:

  • Reject messages to bad recipients in the initial SMTP transaction. It’ll protect your server from backscatter (and dictionary attacks), because you won’t have to queue and process all the extra junk.
  • Don’t generate bounce messages after the fact based on something as easily forged as the supposed sender. Otherwise, you’ll be contributing to backscatter.