A Closer Look at the Microsoft h.264 Extension for Chrome

Today I took a closer look at how the “Windows Media Player HTML5 Extension for Chrome” works. To recap for a moment, Google announced that they are revoking native h.264 playback for the HTML5 <video/> tag in Chrome. A huge kerfuffle ensued. Yesterday, Microsoft announced that they were providing an extension to Chrome that provides h.264 support for the <video/> tag in Chrome on Windows 7.

I downloaded the CRX file and unzipped it. This is the contents:

PS> ls | select Length, Name | ft -AutoSize

Length Name
------ ----
  6540 contentscript.js
   678 manifest.json
163256 np-mswmp.dll
 59413 wmp eula.rtf
  3489 wmp releasenotes.txt
 28177 wmp128.png
   569 wmp16.png
  2233 wmp48.png

The np-mswmp.dll file looked familiar. And that is because it is the NSAPI plugin for Windows Media Player for Firefox.

ns-wmp

The remaining interesting file in the CRX is contentscript.js. In a nutshell, what this script does is look for <video/> elements that are referencing h.264 or WMV content and dynamically replace them with <object type=”application/x-ms-wmp” /> element referencing the same content.

Interesting Side-Effect

The Windows Media NSAPI plugin is installed into Chrome along with this extension which means any pages which explicitly embed the Windows Media Player will work.

wmpChrome

Also, this extension enables support for WindowsMedia Video content in <video/> elements.

var supportedMimeTypes = ['video/mp4', 'video/x-ms-wmv'];
var supportedVideoExtensions = ['.mp4', '.wmv', '.mp4v', '.m4v'];

Windows 7 Not Really Required

The Windows Media NSAPI plugin was released by the Port 25 group at Microsoft in April 2007. It doesn’t rely upon Windows 7 to work. The issue is just that Windows 7 is the first version of windows to ship with an h.264 codec for Windows Media Player. The extension should work on Windows XP and Vista if you have an h.264 codec for Windows Media, such as from the K-Lite codec pack.

Pointing the Way for Alternate Cross-Platform Implementations

This general approach also points the way for a 3rd party that has an NSAPI plugin that supports h.264 to extend Chrome (and Firefox) to support h.264 and whatever else the video player can support in the <video/> element. In particular it should be straightforward to create an extension that uses the VLC NSAPI plugin to extend the <video/> tag codec to support h.264 as well as DivX, QuickTime and MPEG-2.

Microsoft Puts h.264 Back into Chrome

Is I suspected they would, Microsoft has released an h.264 codec extension for Google Chrome to support h.264 in the <video /> tag. They provide the same mechanism for Firefox.

http://www.interoperabilitybridges.com/wmp-extension-for-chrome

This Extension is based on a Chrome Extension that parses HTML5 pages and replaces Video tags with a call to the Windows Media Player plug-in so that the content can be played in the browser. The Extension replaces video tags only if the video formats specified in the tag are among those supported by Windows Media Player. Tags that contain other video formats are not touched.

The Extension also checks if the browser version already supports MP4 (H.264) video codec, if so the extension is not used.

 

http://blogs.msdn.com/b/ie/archive/2011/02/02/html5-and-web-video-questions-for-the-industry-from-the-community.aspx

Any browser running on Windows can play H.264 video via the built-in Windows APIs that support the format. Our point of view here is that Windows customers should be able to play mainstream video on the Web.

 

Interesting.

Shocking: Google Removing h.264 Support from Chrome

To that end, we are changing Chrome’s HTML5 <video> support to make it consistent with the codecs already supported by the open Chromium project. Specifically, we are supporting the WebM (VP8) and Theora video codecs, and will consider adding support for other high-quality open codecs in the future. Though H.264 plays an important role in video, as our goal is to enable open innovation, support for the codec will be removed and our resources directed towards completely open codec technologies.

via The Chromium Blog

I’m very, very sad to see this announcement. h.264 is the web video standard while WebM is a new Google codec that nobody uses and nobody uses Theora. We really don’t need video codec fragmentation in HTML5. The likely result of that will just be standardization on Flash video. Do we get to re-hash the video format wars of the 1990s in the 2010s?

This sucks and basically shows that HTML5 is not standardized and not ready for prime time. Not cool at all.

This is an opportunity for Microsoft to look like a hero and fix this for Google like they did for Mozilla.

Chrome MSI Works Great with AppLocker

Google has released a version of the Chrome installer packaged as an MSI rather than using the ClickOnce installer. The major difference is that the MSI creates a global installation under %ProgramFiles(x86)%. Transparent updates continue by default, managed by the Google Chrome Update Service (gupdate). Gupdate also updates Google Apps Sync for Outlook if it is installed. The key advantage of an MSI package is that it is compatible with managed deployment using Active Directory and Google has provided a set of policy templates to allow managing Chrome via Group Policy in the same way that Internet Explorer is managed.

Because all of the code is installed in %ProgramFiles(x86)%, Chrome is fully compatible with the default AppLocker EXE and DLL rules even though the bundled Flash DLL is not signed. “Chrome Enterprise” runs fine with the default rule set and no special publisher rules at all.

Chrome MSI download here.

Policy templates here.

via Chromium Blog.

Mitigate Adobe Reader Vulnerabilities with Google Chrome PDF Viewer

Adobe Reader has a growing list of exploits and a current unpatched vulnerability. The crux of the problem is that PDF documents are not simply documents. PDFs can contain arbitrary code in the form of Javascript or Flash as Adobe Reader embeds a full Javascript runtime and a private Flash runtime environment. Javascript can be disabled via the options but the Flash engine cannot be disabled via the GUI.

An interesting development is that Google Chrome 6.x includes its own PDF rendering plugin. This plugin converts PDF to HTML5 and renders it with the webkit engine. It is very fast and a fundamentally different approach from Adobe Reader. Commodity attacks on Adobe Reader should not be effective on Chrome.

The Chrome Beta channel includes the Chrome PDF viewer plug-in but it is disabled by default. Go to the about:plugins page to enable it. You can also disable the Adobe Reader plug-in while you are at it.

chrome-pdf

Sandboxing Flash with Chrome

Perhaps the most brilliant feature of Google’s Chrome browser is that it installs itself without any admin rights required inside each user’s profile directory. The first important consequence of this is that Chrome can go viral inside of corporate departments officially standardized on IE6 because it doesn’t require any tech savvy to install Chrome outside of the protected “Program Files” directories. The second consequence is that, since the user always has full permissions to its install directories, Chrome can and does silently and continuously update itself.

The updating works extremely well. It happens quietly in the background. After an update has occurred, the next time Chrome is started it is the new version. Chrome does have security bugs, but it uses Integrity levels to sandbox itself and patches are continuously and silently rolled out which keeps the browser safe.

chrome-bundled-flash

Recently Chrome started distributing its own private copy of Adobe Flash. That means that Google believe that Flash is necessary. Since Flash is necessary, Chrome will always have the latest version of Flash and it will be silently updated along with Chrome itself. For all other browsers, there is no automatic update process for Flash. The standard ActiveX installation process for IE is painful and failure prone. For this reason alone, Chrome distributing its own Flash is great but since Flash is also riddled with security problems, this is a huge win.

Adobe seems to be happy with this Google-love, especially since they are being flamed publically and repeatedly by Steve Jobs. It is interesting but I think what is really going on is that Google recognizes that if Flash doesn’t work right or you get a malware while using their Chrome, Google takes the blame.

Whatever the motivation, it is a win. I’m ready to let Chrome handle updating my Flash and stop wasting my time worrying about whether I have the current version and whether it is safe. In fact, I can’t think of a good reason to have Flash floating around on my system as a global service outside of its Chrome sandbox.

Adobe provides a tool to globally uninstall Flash which removes both the ActiveX and Netscape-compatible plug-in versions but leaves Chrome’s private Flash runtime untouched.

uninstall-flash

Google Developer Dashboard: “An error occurred: please try again later.”

When I use the Google Developer Dashboard to upload an update to my extension, it will often fail. The dashboard says, “An error occurred: please try again later.”.

Trying again later doesn’t help. For me, the fix is to log out and log back in again.

Follow

Get every new post delivered to your Inbox.

Join 86 other followers

%d bloggers like this: