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.

We’ve all seen the html 5 upcoming features and admittedly, it is very exciting.

Features such as canvas, and even a way for communication between servers (like a chat client), and geolocation are just one of the few highlights that html 5 offers.

One of the most anticipated features is the <video> tag which allows for embedding video without the use of an external browser plugin (ie flash).

Many pundits would say that it is the beginning of the end for Adobe Flash.  And I would agree, to an extent.  I believe that Flash’s days as a premium source of progressively streaming video content are numbered somewhat.

Things to keep in mind though:

1. HTML 5 does not include options for LIVE video streaming.  We can say that there is H264 streaming by the open source darwin server (created by apple).  But let’s be real.  Quicktime is a resource hog, and it’s frankly, its awful in windows.  And flash is practically present in over 90% of the computers worldwide – computers are then mostly live streaming content ready.

2. Games and RIA – Canvas and javascript have some neat tricks in HTML 5 (freeciv.net comes to mind).  One thing that flash trumps HTML 5 is how flash makes it easy for developers to create games (and elaborate ones at that!), with sound and effects to boot.  Flash simply trumps HTML 5 in Rich Internet Application features.

3. HTML 5 final draft is on 2022.  What would happen here is that as browsers race to implement HTML 5 features this early, they will have their own implementation.  We have already seen this in the implementation of the <video> tag.  Safari, Chrome support H264.  Firefox and Opera support Theora – IE has no support for the <video> tag.  From experience, I have to contend with different implementations of javascript, dhtml, and even css for different browsers.  What I am hoping is that HTML 5 will not descend into a web developer’s nightmare of supporting different browsers.  For flash, backwards compatibility is largely maintained: AS2 will still run on the newest Flash runtime, and developers will just develop flash applications without worrying that their applications won’t run on linux, windows or macs.

4. One thing about the video tag is that the actual video file is linkable, and thus, downloadable.  Content providers don’t like their videos readily downloadable by users, especially for premium video content.  Although not perfect, Flash offers a way hamper downloads of video content by users.  We live in the real world, and the fact is, however we want our videos to be openly available, content providers would think otherwise.

5. Concerning the video tag, is Firefox’s and Opera’s refusal to support H264.  Fact of the matter is, H264 is patent encumbered, and in order for Firefox and Opera to use H264, they would have to shelve off H264 licensing fees.  As a blog of a Mozilla developer states: “In other words, if you’re an end user in a country where software patents (or method patents) are enforceable, and you’re using software that encodes or decodes H.264 and the vendor is not on the list of licensees, the MPEG LA reserves the right to sue you, the end user, as well as the software vendor or distributor.” – Flash on the other hand, has licensed H264 for use in their player.

6. Flash has some excellent authoring tools available, which makes development easy.  One thing which bugs me in the Open Source world is that IDEs are found mostly wanting.  I wouldn’t mind an open source IDE as good as Visual Studio – Eclipse comes close, but I hate the bloatedness of the application, causing me to have out of memory errors for large amounts of source code (and that was during my Java coding days).

In short, will HTML 5 obsolete Flash completely?  My answer: in some ways, yes, in other ways, not.  What I believe is that both technologies will coexist together for quite some time, until of course, a new version of the HTML spec comes, which may drive Flash into obsolescence once and for all.

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).