Browser updates…too many too fast?

We’ve finally reached the point where the number of browser updates is out of control. There’s an all-out war between the various browser companies to see who can push out the most updates and improvements in the shortest period of time.

All these updates are causing a ripple effect on everything else that is dependent on the browser; for example, plug-in vendors, IT support staff, computer and smart phone vendors, application developers, any company that has a website, and your average consumer.  I’m guessing that on average the pace of updates is starting to outpacing business and consumer’s ability to keep up…and it seems to be accelerating.

Yes, I wholeheartedly agree we benefit from the advancements. No argument there. However that is balanced by reality. And, reality is architecting our products to support the latest and greatest. There is also the fact that most of us also have to maintain support for older versions of browsers and there is a cost associated with backward compatibility. And, there is a cost to upgrading. Not everyone is able to update all the time.

As a case in point, let’s take a look at Firefox since it’s fairly easy to find an archive of their older releases. We are only seven months into the year 2011 and Firefox has had two major releases: Firefox 4 and Firefox 5. However, if you include releases candidates, betas and updates to Firefox 3.x the total number climbs to around twenty-two releases so far this year. Yikes!

Sure, most consumers only saw the two major updates: Firefox 4 and Firefox 5. But, they also experience a plethora of plug-in updates. For example, Flash Player has had eight updates so far this year. Silverlight has had three general distribution releases this year and one beta release of Silverlight 5. And, I wasn’t counting but it seems like I’ve had a bunch of Adobe Reader updates in the last few months.

My concern is that the speed of browser innovation is starting to cause businesses and consumers to get fatigued. It begs the question: how long can the ecosystem of browser consumers maintain this pace? Or, at what point do people just start jumping off the bandwagon and simply starting skipping releases? Do most consumers really care if their browser is now 100ms faster in parsing JavaScript? How many new ways can we create tabs?

In summary, I think browser vendors should slow down and become better custodians of their systems. How about also focusing on innovation in security, memory leaks and best practices documentation and vendor-provided validation engines? Indeed, they have sparked tremendous innovation across the entire world wide web since Mosaic released in 1993. But, depending on how many websites you visit, you can still experience slow web pages, in-consistent cross-browser support and browser crashes. I know there are no easy answers because competition breeds creativity. Perhaps we’ll all go back to just looking at basic text, pictures and videos in the future. And, there will just be specific widgets with very focused functionality for other things.

References:

Flash Player Archive

Firefox Archive

Silverlight Release History

URLStream, Adobe AIR and FLEX security permission issues on Windows 7

I had a particularly vexing problem that took nearly a half a day to dig to the bottom of. I was successfully able to connect to a streaming API using Adobe’s URLStream class, and I could see the passing of packets back-and-forth between the client app and the remote server using WireShark. So, there was definitely a valid connection and hand-shaking happening in the background. And, another key piece to the puzzle was the app ran just fine as a Flex app using the default bin-debug run-time settings. But, other than that running it as an AIR app or a Flex app from IIS, I simply couldn’t get any of the URLStream event listeners to acknowledge any type of connection whatsoever.

I knew this was a permissions issue, but finding documentation on AIR and Flash runtime permissions is, well, not easy. So, after quite a few searches on the internet and many dead-ends, there buried deep in some ancient scrolls of Adobe documentation were a few articles that provided the key to finally unlock the treasure chest.

You may have never heard about it before, but there is a User Flash Player Trust directory that typically contains at least one configuration file. And, in those files you can specifically grant application access to a particularly directory. In theory, there is also a Global Flash Player Trust directory. I originally thought I made the changes to that, but actually I never was able to locate it, and I ran out of time anyway. So, if someone knows where that is on Windows 7 please let me know.

Solution:

I added the pathname to the AIR executable installation directory to the air.1.0.trust.cfg file and bingo the application worked as expected.

The file typically resides in a path that looks like this: C:\Users\<username>\AppData\Roaming\Macromedia\Flash Player\#Security\FlashPlayerTrust

And, I add the following line to the file: C:\Program Files (x86)\BasicStreams.

References:

[Flash Player] Administrator Controls

[Flash Player] User Control document

Adobe Online Doc – Restricting Network APIs