Biz & IT

Google bakes Flash into Chrome, hopes to improve plug-in API

Google has announced that it will be integrating Flash in its Chrome Web …

Ryan Paul – Mar 31, 2010 9:35 am | 88

Google announced Tuesday that its Chrome Web browser will integrate Adobe’s Flash plug-in. The latest version of Flash will ship with Google’s Web browser, obviating the need for end users to download and install it separately. Google will also start regularly deploying new versions of Flash through Chrome’s update system in order to ensure that users always have the latest version.

Google has also revealed that it will be working closely with Adobe, Mozilla, and other players in the Web ecosystem to improve the API that browsers use to support plugins. Such improvements could potentially help ameliorate some of the technical deficiencies that have plagued Flash and other plugins.

A new version of Chrome with the integrated Flash plug-in was rolled out yesterday to users of the Chrome developer channel. The Flash integration is not enabled by default because it is still highly experimental. It can be turned on by activating Chrome with the —enable-internal-flash parameter at the command line. The new developer version of Chrome also has a new plugin management interface that can be used to toggle which plugins are active.

Can Flash be fixed?

Although the Flash plug-in is widely used on the Internet, it is strongly disliked by a growing number of users. Websites like YouTube are seeing strong demand for adoption of standards-based alternatives to Flash. There are signs that disdain for Adobe’s plug-in is becoming increasingly mainstream and is no longer just confined to the community of technology enthusiasts and standards advocates.

This trend is largely driven by the fundamental technical failings of Adobe’s technology. The Flash plug-in is often criticized for its awful browser integration, poor performance (especially on Mac OS X and Linux) and stability, lack of conduciveness to accessibility, and excessive resource consumption. Another major problem is its frequent security vulnerabilities, which have made it a major target for exploits.

Adobe deserves much of the blame for Flash’s defects, but the problem is also largely attributable to the underlying limitations of the framework that browsers use to enable plug-ins.

The original browser plug-in system, which is called the Netscape Plugin Application Programming Interface (NPAPI) was first introduced in Netscape Navigator 2.0. It is a historical irony that Adobe itself played a key role in influencing the earliest development of the plug-in, before even Flash existed. Several Adobe developers collaborated with Netscape to produce the API so that the nascent Acrobat Reader program could be embedded in the browser and be used to display PDF content on the Internet.

The plug-in architecture was basically designed for the purpose of running an independent program inside of the main browser window, but it has been stretched far beyond its intended capacity by modern plug-ins that attempt to provide a lot more functionality. Due to the limitations in the design of the plug-in API, Flash has to maintain its own insular universe inside of a rectangle that doesn’t seamlessly mesh with the rest of the page.

Referred to as the “plug-in prison” phenomenon, this limitation has created a lot of barriers to making plug-ins like Flash operate as a native part of the Web. You can see its detrimental impact on the browsing experience in many areas—such as scrolling, keyboard navigation, text selection, and resizing—where Flash content simply doesn’t conform with the expected behavior.

Improving the API

Mozilla and other major stakeholders have been working on an update to the plug-in API with the aim of improving the situation. It won’t even come close to fixing all the problems with Flash, but it will begin to address certain critical issues. According to the documentation that has been published so far, the update will attempt to boost consistency between implementations, augment support for out-of-process plug-ins, and improve the way that plugin rendering integrates with browser compositing in order to fix layering glitches. There will also hopefully be some opportunities along the way for improving performance, stability, and security.

Mozilla started publicly working on it last year. Google has now affirmed its intention to join the effort and contribute to improving browser support for plug-ins.

“The browser plug-in interface is loosely specified, limited in capability and varies across browsers and operating systems. This can lead to incompatibilities, reduction in performance and some security headaches,” wrote Chrome engineering VP Linus Upson in Google’s official Chromium blog. “That’s why we are working with Adobe, Mozilla and the broader community to help define the next generation browser plug-in API. This new API aims to address the shortcomings of the current browser plug-in model.

Google’s interest in this effort seems somewhat inconsistent with the company’s affinity for emerging native Web standards, but there are several relevant factors to consider. It’s worth noting that Google itself has implemented its own browser plug-ins, such as the Native Client (NaCL) technology.

Improvements that Google contributes to the NPAPI could potentially be beneficial for NaCL, enabling Google to use it in ways that might not otherwise be possible or practical. Another relevant factor is the potential opportunity for ChromeOS. Strong support for Flash could potentially look like a competitive advantage for ChromeOS-based devices relative to Apple’s competing products.

Are plug-ins still relevant?

Although there is clearly an opportunity for Adobe and browser vendors to make Flash behave better on the Web, it may never be a first-class part of the Internet. Indeed, one could argue that the idea of a proprietary vendor-controlled plug-in that loads interactive components into a Web page from a binary blob is fundamentally antithetical to the underlying design of the Web.

As the standards process accelerates and previously weak browsers like Internet Explorer start to catch up and deliver support for the latest functionality, the need for plug-ins is rapidly declining. As an example of the growing viability of the standards process, consider the nascent WebGL standard, which has gained broad acceptance and multiple implementations in a very short period of time.

There is no technical reason that prevents Adobe from participating in the Web like a good citizen. Instead of maintaining a plug-in, the company could propose new functionality for Web standards, contribute implementations to open source browsers, and then target its authoring tools to support those capabilities. The vast majority of companies that are involved in the Web ecosystem are committed to extending the Web in that manner because it’s simply more consistent with how the Web works.

Now that all of the major browsers, including IE, are aggressively adopting emerging standards, the value of plug-ins is not as clear-cut as it once was. It appears that the primary reason why Adobe still pursues a plugin-based strategy at this stage is so that it can preserve the vendor lock-in that is inherent in having a proprietary plug-in.

Ryan Paul Ars Editor Emeritus

Ryan is an Ars editor emeritus in the field of open source, and and still contributes regularly. He manages developer relations at Montage Studio.

88 Comments