Resetting the "IE Browser Choice” preference.

We upgraded Internet Explorer to IE8.  Foolishly enough, we assumed that on a Corporate Desktop, that users would only use Internet Explorer.

Then the complaints from the vocal Firefox majority rolled in.

“How dare you force me to use Internet Explorer!”

So we had to provide those Firefox users with a “choice”.

The solution was to reset the Internet Explorer “browser choice” setting so next time IE was launched:
Browser choice

We did this by using a VBscript, that we depoloyed to all the computers:
On Error Resume Next
Set objWSH = CreateObject("WScript.Shell")
objWSH.RegWrite "HKCU\Software\Microsoft\Internet Explorer\Main\Check_Associations","Yes","REG_SZ"
Set objWSH = Nothing

Roll forward 6 months, a query from the customer:

Can you reset the browser choice, as we’re moving away from Firefox …

“Why not use Group Policy?”
As it’s a corporate environment, we restrict what the users can change via the Internet Explorer menus.  In this environment, it was less hassle to use a VBscript to reset one option compared to allowing users to modify other menu options grouped in the same menu tab.

Automatically encrypting Firefox web pages

HTTPS_Everywhere_new_logoto stop snooping eyes from viewing what you’re doing.

Well you could use the HTTPS Everywhere Firefox plugin by the Electronic Frontier Foundation. 

The idea is simple.  You go to a web site, like , and if there is a secure version (say, you’ll be automatically redirected to it.

Useful?  Maybe…

If you don’t want your employer viewing your Google search, or Twitter, it might work for you. 

The 0.2.2 release of HTTPS Everywhere currently has support for the following 27 web sites:
Amazon, DuckDuckGo, EFF, Facebook, GMX, Google, GoogleAPIs, GoogleServices, Identica, Ixquick, Live,, Meebo, Microsoft, Mozilla, Nederland, NYTimes, PayPal, Scroogle, Torproject, Twitter, WashingtonPost, Wikipedia, WordPress, zGentooBugzilla, zNoisebridge, Zoho

You can download the HTTPS Everywhere plugin here.

Bookmark and Share

Internet Explorer has issues with session cookies, fancy that.

The problem was reported thus.

Internet Explorer is not storing session cookies for XYZ website.  The session cookies are stored when we use Firefox.

Two hours later, I can tell you that:

  • I learnt more about web cookies than I will ever need to know again.
  • Firefox does things differently to Internet Explorer.

Gentle reader, Session Cookies are cookies which only exist for the time which your web browser is open for.  They are deleted when you close your browser.  They are often used to cache your user name and password.

If you don’t have your username/password cached, you repeatedly get prompted for it.  Which is annoying.  Hence the need for session cookies.

So I started investigating the cookies not being stored issue..  The first thing I noticed was that Internet Explorer wasn’t even bothering to write the cookie down to the local hard disk.  So I broke out the network sniffer (Wireshark).  It didn’t tell me much, as all the web traffic was encrypted.

The next step was to load up Fiddler, the Web Debugging Proxy.  Fiddler allows you to inspect all the encrypted web traffic between your computer, and the rest of the world.  The session cookie that the XYZ website was trying to push down, had the following details:
Web browser cookie

There are two issues with this session cookie:
Cookie - Expires Parameter

  1. It sets an Expires date.
    This normally means that it is a Persistent Cookie, and not a Session Cookie.
    In other words, we should not see Expires in a session cookie.
  2. The Expires date was set to a date/time in the past, which is not supported behaviour either.

So why does it work with Firefox then? – Firefox seems to be treating the expired Expires date as no date at all.  So it defaults to a Session Cookie.

Internet Explorer? – A bit more complicated:







Some further reading:
The Unofficial Cookie FAQ
Wikipedia HTTP Cookies

Bookmark and Share

“Mouth more closed.”

FireFox logo - no, really. Enterprise desktop support is a mindset.  If you’ve never done it, it’s likely you’ll not understand the issues of how things scale.  A solution for 5 PCs may not scale to 4000 PCs.

Today’s support problem is Firefox.  And it’s not that I don’t like Firefox, indeed, I use it myself.

But I don’t support the idea of having TWO browsers to support in an Enterprise IT shop.  Choice in Enterprise IT is generally bad, as it adds costs; in training and support.  To illustrative the problem of choice, let’s look at a hypothetical problem which arrived at a hypothetical help desk.

The FRED web application performs slowly in Internet Explorer (IE).  It works fine in Firefox.

The bozos who created the FRED application didn’t test FRED with Internet Explorer, which is what our 4000+ desktops have.  Their ineptitude becomes our problem.

We spend some time investigating.  Essentially the problem boils down to how Internet Explorer displays a web page, in comparison to Firefox.  (Internet Explorer is more fussy/strict/picky/<insert your own word here>).

Our solutions to fix FRED?:

  • Change our default browser to Firefox, on all 4000+ desktops.
    This will break some of our existing web applications which work just fine with Internet Explorer.
  • Replace our proxy server backend.
  • Tell the FRED developers to fix their application.

Here are some of the issues we’d hit if we deployed Firefox along side Internet Explorer:

  • No ActiveX support with Firefox.
  • Application compliance.
    Some customers have applications which have applications which have been rigorously tested and certified by third-party government bodies.  The customer would need to recertify these applications with Firefox.
  • Support resources.
    We don’t have the support resources to increase our workload by taking on an additional application.  Sure, we can get those extra resources.  But who pays?

Bookmark and Share