Fortunately Firefox

I dropped by the Mozilla web site tonight.  I discovered on their Firefox news page, that Firefox 9.0.1 has already been released.

I am pretty excited because this version dramatically speeds up some web pages which use JavaScript.  I read elsewhere this evening that the developers used some clever optimization techniques to get the higher performance.

Apparently, MathML support has been improved too.


On a side note, this is my first post using the draft version of the new version of Google's Blogger service which will be getting an update soon.

It seems nice. This is certainly one of those changes that you notice.  The post-a-blog-entry page is nothing like the old one they have had for years.  Saying it is different is a radical understatement.

Labels: blogging, browsing, firefox, software, update, web

The Nobel Peace Prize web site and others have been infected with malware that in turn infects computers via Firefox if the user is not running the just released update of Firefox - version 3.6.12 (or the 3.5 equivalent).

The vulnerability was in the JavaScript interpreter.  It was of a category named use-after-free.  Memory was dynamically allocated, then freed - and then use continued after that.  It is not terribly uncommon in large, complex programs written in C and C++.  This type of bug cannot be written directly in Java because Java uses garbage collection instead of letting application programmers do alloc/free themselves.

Users running NoScript addon for Firefox were safe all along, unless they expressly gave permission to an infected web site to run JavaScript.

Labels: firefox, javascript, malware, mswin, security, security snafus, web

Supposedly, there is a software conflict between Google Toolbar and Personas 1.6 in Firefox, when an update for one of them came out a few days ago.

After reading some technical support pages for a different addon which was the one exposing symptoms but apparently as an innocent bystander, I decided to switch to my default Theme in Personnas and then disable:  Google Toolbar, Yahoo Toolbar, Personnas - and uninstall that other addon.

Note that since at least one of the addons was malfunctioning very badly and interfering with lots of things, including the ability to display the Addon manager window (!) I had to start up Firefox in "safe" mode.  On the Macintosh, this is easy:  simply hold down the Option key on your keyboard while launching Firefox.  I did not check any buttons on the safe mode dialog that appeared when I did this; just clicked the button to tell it to start up in safe mode.

This procedure cleared up the problem.  I was pretty concerned about this since Firefox is by far the web browser I use the most, most of the time.

I was very much relieved to discover this was simply a problem with some addons.  Firefox itself was not the problem, nor is there apparent permanent damage to my Firefox install!

Problem solved.

Labels: extension, firefox, troubleshooting

My iMac running latest, up-to-date Mac OS X (10.6.3) blue screened while I was typing in Safari and went through a reboot process.  It seemed to take extra long compared to a warm boot; seemed like a cold boot or even a boot that did some kind of update.

At the time it happened, I had Safari in the foreground and I had Firefox sitting idle in the background.

Other applications were not running.  I have 5.6 GB of disk storage free on my boot drive.  My computer was downstairs on the western facing side of the house.  So there were no free disk space or ambient temperature problems.

When the system came back up, I was naturally curious what was in the logs at the point it crashed and just before that so I ran the Console application that comes as part of the Mac OS. What I saw surprised me.

There was a process called "firefox-bin" running and it was running amuck.  The process was logging over a dozen messages per second.  Every message was the same error:


6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:10 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:11 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)
6/5/10 7:36:12 AM firefox-bin[4299] _NXGetScreenRect: error getting display bounds (1001)


Well, I am pretty sure I had not launched Firefox yet! It had not been opened, yet firefox-bin, the main Firefox application process, was already running.  Not only that, it was stuck in a loop trying to do something it could not do, over and over really quickly.

I checked and this error message repeatedly being output has been reported by other users back in late 2009, running Mac OS X 10.5 (older than my 10.6) and an older version of Firefox than I have.

Here is the discussion thread on it at support.mozilla.com: System.log shows that Firefox is spamming the following error in large chunks .  The person who posted that message listed the error message absolutely identical to the one on spotted above on my system.  They said they updated Firefox, and the problem went away.

Oh, and someone reported the same problem (same error message) being output by iCal in December 2009:   _NXGetScreenRect: error getting display bounds (1001).  Completely unrelated application gave the same error message.

I killed the process, by the way.  I am not sure why it was running, what it was doing, why it had this error and why it was apparently doing it really fast over and over in a tight loop.  Nothing about it seemed kosher or okay.

Here is me killing the rogue, runaway Firefox process:


John-intel-iMac:~ jcollins$ ps 4299
  PID   TT  STAT      TIME COMMAND
 4299   ??  Ss    19:26.69 /Applications/Firefox.app/Contents/MacOS/firefox-bin
John-intel-iMac:~ jcollins$ ps -elf 4299
  UID   PID  PPID        F CPU PRI NI       SZ    RSS WCHAN     S     ADDR TTY           TIME CMD                  STIME
  501  4299     1     4000   0  57  0   517184 189464 -      Ss    40a5000 ??        19:27.11 /Applications/Fi   4:01.47
John-intel-iMac:~ jcollins$ kill -9 4299

I am running Firefox 3.6.3 which has a reported file size of 55,240,723 bytes on my system.  I am really sure about those two numbers because I copied and pasted them directly from the Get Info pane in the Finder.

I am really disturbed by this highly unusual and unexpected behavior on my system. Nothing like this has ever happened before on this computer. In all the 2 or 3 years I have had it, it has never spontaneously rebooted.

I am going to look into this further because clearly something is wrong with my system at that point on the basis of the reboot.  Why Firefox was running and why it had this error message being logged at an absurdly rapid rate over and over is an issue too. Whether they are related or not, I cannot say at this point but I hope to find out soon.

I verified my Mac was up to date immediately after the reboot.  It was except for printer software which must have been updated in the past week.

Labels: crash, firefox, macintosh, macosx, reliability, security, snafus, software, web

Firefox 3.6.2 was released yesterday to fix a remote code execution vulnerability and some other bugs. A cross site scripting (XSS) vulnerability in SVG content handling was also fixed.

Labels: firefox, security snafus

The famous Html Validator add-on for Firefox has been updated to be compatible with the current version of Firefox 3.6.  If you have the old version, tell it to go to its home page, uninstall the old version, then install the new version from its home page.

Labels: extension, firefox, html, opensource, software

A new 3D graphics library for World Wide Web browser programmers is emerging: WebGL.

WebGL is an open, industry-wide JavaScript API that looks like it will be appearing in the major web browsers soon.  Perhaps as early as this year.  So far, Firefox, Safari, and Chrome have all endorsed it and already have it in their nightly builds.

Based on that, I think it would be very surprising if you did not see WebGL rolled out by all three leaders before the end of this year.

Internet Explorer, hardly a leader when it comes to web standards, still has not implemented the 2D graphics web standard approved back in the 1990's.  However, nobody looks to Microsoft when they want open, interoperable standards.

Sure, in areas like SQL where everything is fragmented, basic standards are difficult because the standard seems to embrace incompatible dialects.  Some say Microsoft had a hand in this a decade and a half ago.  Could be.

Nowadays, the leading web browser makers are working together in two ways:  defining open/interoperable standards and making products that follow those standards.  That is the reason the web has been advancing so quickly lately.

The idea of cloud based computing depends on having very advanced, standards-based, web browsers that do not get hacked a lot.  Since business, government sites, political, and scientific web sites are going to have a lot of statistics on them visualization is going to be a key ingredient for them to be effective at getting their message across.  That is where WebGL will really let those sites shine.

If you are interested in doing fast 3D graphics on the web, take a look at the WebGL Tutorial.

Labels: 3d, firefox, graphics, safari

Brian Krebs, independent computer security blogger and former columnist at the Washington Post reported on a commercial web browser exploit toolkit for hackers. Note when I say commercial that does not in any way imply it is legal or anyone in there right minds endorses it.

What it does say is that hackers go after web users systematically and would like no marks to get away, regardless of the browser the user has chosen.

However, the statistics published in the screenshots of the article show that the user's choice of web browser has the most drastic choice on whether he gets successfully hacked or not.

In the statistics sampled, Firefox 3.5.6 registered several successful attacks against it, but others were left unscarred.

Internet Explorer, you ask?  Oh, my god!  It gets mauled when it shows up on an infected web site!!  The article shows that IE is like some barroom brawler that cannot possibly walk away from a fight.  Though the successful attack rate against Internet Explorer has been steadily decreasing since version 5.0 (about 2/3 successful attacks) the rate of successful attacks for IE 8.0 is a little over 1/10.

Another interesting thing is that Firefox 3.5.x was seen twice as much as Internet Explorer 8.0 by the toolkit.

To me, these statistic say when Microsoft has been saying for the past 6 years that Firefox was not getting infected a lot was because few people are using it is not just one lie but two.  Apparently, Firefox is seen quite a bit by infected web sites.  However, for the most part these sites can look but they cannot touch.

The other surprise is that plugins do get attacked and sometimes the attacks are successful:  Java, Adobe plugins, etc. are attacked.  Java attacks are rarely successful but you do see a grouping of some successful attacks against a recent but non-current version of Java 6.  The lesson there is clear:  keep your Java web browser plugin up to date in all of your web browsers!

Another interesting though perhaps malleable fact is that the Adobe Acrobat Reader and Adobe Flash attacks that are wildly successful on Windows when running IE, just do not currently work against the Macintosh.  Another case for the argument that a lot of people should have switched from Firefox to Macintosh years ago.  If they had, then this web hacker industry would not be quite so large and wealthy as it is now.  There is no question the minions and gangs in this industry are making quite a lot of money.

Perhaps, if IE users want to be slightly safer on the web, they will update their browsers and avoid installing plugins - like, say Silverlight.  But if they want to cut there risk by another ten to hundredfold, they will install Firefox.  At least then they will not be reeling around like a punch drunk barfly with a glass jaw.

Lesson learned:  avoid Internet Exploder - run Firefox instead - beware Adobe plugins, and keep Java plugin up to date if you have it installed in your web browser.

Labels: browsing, snafus, statistics, web