Adobe’s browser plugin Flash has received lots of bad press recently. Steve Jobs claimed that Flash was the leading cause of Macintosh browser crashes, and he banned the plugin from the iPad and iPhone after much public discourse. Meanwhile, the web browser manufacturers have made lots of changes to the ActiveX and NPAPI interface to handle Flash better. Examples of this include Mozilla’s new crash message, process timeout limits in Mozilla and Chrome, User Account Control on Internet Explorer, and Safari’s ability to run plugins in a separate process. Some of these problems are the result of sloppy programming and mission creep, but there is a deeper issue here related to the way that Adobe has positioned and promoted Flash. Nobody so far has really explained WHY Flash has security problems.

Have you ever seen that little dancing guy on the cnn.com website who is trying to get you to apply for a new mortgage? Did you go there to see him dance? Probably not. He is there because Flash is an easy way to animate something, and when the add space was sold the webmaster was told to include the file. In fact this has been central to Adobe’s strategy to sell Flash as a tool: the client runtime had to be ubiquitous. And as a result end users can be bombarded with a Flash animation on almost any web page they go to without notice. This dear reader is the root of Flash’s security problem.

What would happen if this situation was turned around? What if you had a plugin that end users wanted because it delivered a vastly better user experience for interoperating with cloud data? What if the end user had a subscription to the application, or a relationship with the company that built the application? What if a company tried to sell finished applications to end users instead of selling technical delivery systems to webmasters? In my view this is a much more appropriate usage of plugin technology, and as a result many of the associated security problems are avoided.

For example, my company delivers our cloud service applications with the DreamFactory Player, an NPAPI and ActiveX plugin for Windows and Macintosh. When customers navigate to their cloud platform of choice they see a progress dialog showing their application being downloaded. They see the developer name, the application name, the source URL, and the destination folder. If they have any questions about what our application is doing they can look in the audit logs maintained by the DreamFactory Player and find out everything that has happened. If for some reason they saw this progress dialog on a web page where it was not expected they could cancel the transaction and investigate. We are not secretly bombing the end user, instead they are asking for our product.

This is a totally different situation from Flash, and a much more appropriate usage of plugin technology. The attack vector is ruined because of the transparency and accountability inherent in the relationship between the customer and the developer. As such and after much deliberation I have come to the conclusion that Flash was an ill conceived usage of the NPAPI interface. Plugins should not try to be a ubiquitous part of every web page, but rather a way to implement special capabilities when users want them. I hope the current bad press about Flash doesn’t hamper the usage of plugin technology for more appropriate applications like cloud services.