We all have our favorite plug-ins for our browsers. Many people can’t live without their flash plug-in for their games and watching Hulu and YouTube videos. Other people use Java applets for their enterprise applications. Still, others use Quicktime for watching .mov videos on the browser.

What happens if a rogue plug-in runs in your browser? This is when sandboxing plug-ins become apparent.

Sandboxing applications have had it’s purpose and use in Java applications, especially plug-ins, where the program is placed in a restrictive environment that is not allowed to access system functions unless it is given access to.

This allows the plug-in to run in it’s own environment without harming the other browser or system processes.

How is sandboxing applied? Either through the plug-in itself (like java, and in a lesser way, flash), or through the browser.

Newer browsers such as Google Chrome separate their browser windows through threads, allowing rogue plug-ins to crash the affected window only. Other browsers implement some sort of sandboxing of their plug-ins. Which is better?

Since most people are in the fad of flash-bashing these days, let us make a sample of a rogue flash application that crashes the browser. Here is the link.

Mind you, I would say that flash has its uses; however as someone who dabbled in ActionScript one time or the other knows that the Flash runtime has a number of quirks and bugs that are really downright bad. In my opinion, this example is one of them.

Browsers who do not sandbox their plug-ins or separate their windows as separate threads would find this page crashes their browser really bad.

This includes Firefox, IE and Safari.

The only way to avoid spectacular crashes is to use a browser which implements some sort of separation between the plug-in and the browser itself.

Opera and Google Chrome passes this test admirably.

Interestingly, due to the flash plug-in running in a separate process in 64 bit systems in Linux (through nspluginwrapper), only the nspluginwrapper crashes, and does not take the whole browser in it.

To end, this is what I like to see implemented in all browsers. Running plug-ins in a separate process, as well as limiting it’s scope in relation to access to the underlying operating system.

It seems like that the favorite browser everyone loves to hate is having a makeover.

From the msdn IEBlog site, developers from microsoft are in the process of updating Internet Explorer to have:

1. Speedier Performance – on par with Firefox 3.6.  It finally looks like that javascript will be accelerated like Firefox and Safari/Chrome builds are.
2. Standards Compliance – some HTML 5 support, as well as CSS 3 compliance are being done.  ACID 3 compliance is also being worked upon.
3. Hardware accelerated graphics and text via Direct2D.

Concerning #2, here’s a pic from the IEBlog, concerning Javascript execution speed:

On my own opinion, other browsers have the lead in JS acceleration, and IE is basically playing catchup.  By the time IE 9 gets ready to ship, developments and enhancements in Firefox and Webkit based browsers (Safari/Chrome) will have optimized their javascript engines further.  Furthermore, 3D acceleration has been in development for the other browsers as well.  What remains to be seen, and this is what I think is significant to watch, is whether HTML 5 will be able to unseat flash, considering future browsers are racing to implement HTML 5 compliance (IE included).