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.

Advertisement

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.

My First Chrome Extension, part 2

I was fixated on how to get Chrome to pass a feed URL to my registered feed reader, Outlook 2010. After I figured out how to pass the message, it was nearly a one-liner to modify an existing extension. How many things could be wrong with one line of code that seems to be working?

url = url.replace( "%f", feedUrl.replace( "http:", "feed:" ) );

There are two bugs that I see in here.

1: URLs can legitimately include %f

From RFC 1738:

In addition, octets may be encoded by a character triplet consisting of the character "%" followed by the two hexadecimal digits (from "0123456789ABCDEF") which forming the hexadecimal value of the octet. (The characters "abcdef" may also be used in hexadecimal encodings.)

In practice this would affect URLs that include these characters:

  • ð -> %F0
  • ñ –> %F1
  • ò –> %F2
  • ó –> %F3
  • ô –> %F4
  • õ –> %F5
  • ö –> %F6
  • ÷ –> %F7
  • ø –> %F8
  • ù –> %F9
  • ú –> %FA
  • û –> %FB
  • ü –> %FC
  • ý –> %FD
  • þ –> %FE
  • ÿ –> %FF

The simple solution is to avoid using a macro character sequence that includes valid hexadecimal values. Sticking with a single ASCII character it could be anything from ‘g’ trhough ‘z’ except ‘s’, which is already being used.

2: A feed URL could have “http:” anywhere

The scheme for a URI is always at the beginning, but it is common for one URI to encode another one inside it. That is exactly how you pass a feed URL to Google Reader.

Imagine a feed URL like “http://feedify.exmaple/q=http://mysite.somewhere/page”. In order to pass this to the feed scheme handler I need to replace the http: scheme with feed: but my original code would also replace the second http:, which would break the URL.

The solution is to use a regular expression so that I only replace the http: scheme rather than every occurrence of the pattern “http:”. In Regular Expression syntax, the ^ character means that the pattern has to start with the beginning of the string.

^http:

I JavaScript, the shorthand for a Regular Expression object is paired / characters:

/^http:/

3:URI schemes are not case sensitive

The replace() method of the JavaScript String object is case sensitive. My code would not work on a URL like “HTTP://mysite.example/stuff”.

Fortunately, the Regular Expression object in JavaScript has a case-insensitive match mode. You set this with the ‘i’ option:

/^http:/i

3 Bugs in 1 Line: Fixed

url = url.replace( "%g", feedUrl.replace( /^http:/i, "feed:" ) );

My First Chrome Extension

I am fairly hooked on Microsoft Outlook and I like to use the RSS reader function. I also have been living in Chrome 4 instead of Firefox for a few weeks now. One of the features of Firefox and IE is the ability to discover RSS and ATOM feeds and pass them to the registered feed reader.

Google has an extension for Chrome that almost does what I want. It discovers the feeds but it will only subscribe them with a web-based feed reader. What I did was hack on the RSS Subscriptions Extension (by Google) so that it would work with Outlook.

screen-shot

Outlook feeds by registering itself as the handler for the FEED scheme.

hkcr-scheme

That means anything that tries to invoke a URI like feed://somewhere.com/feed.rss, Outlook will be invoked with the /share switch like this:

"C:\PROGRA~1\MICROS~2\Office14\OUTLOOK.EXE"/share "feed://somewhere.com/feed.rss”

Outlook is very picky about the scheme on the URL. It has to be feed:// or it won’t work and that is the problem with the Google extension. It always puts the http:// scheme onto the URL and it assumes that you are going to embed this into a larger querystring to a web-based feed aggregator.

It was pretty easy to tweak the extension to do what I wanted. The meat of the change is really just one line of code:

url = url.replace( "%f", feedUrl.replace( "http:", "feed:" ) );

That makes it so that %f is a feed: scheme URI that will invoke the registered feed handler. For me this is Outlook 2010.

edit-shot

There is a little bit of supporting stuff here and there to make this work, but that’s the gist. Now, %f is the magic configuration to invoke the registered feed:// scheme application. It was surprisingly easy to get hacking on the extension and Google made it very easy to publish my work.

If this scratches your itch, you can get it from Chrome Extensions site.

Installing Google Chrome Machine-Wide

Perhaps the most brilliant and subversive feature of the Google Chrome browser is its distribution model. It has a one-click installer that will work for a limited rights user account. The way Google pulls this off is that they install Chrome into the %LOCALAPPDATA% directory for the current user rather than the secured %ProgramFiles% or %ProgramFiles(x86)% directory. What this means is that many corporate people that cannot run the Firefox installer or get Firefox to work without serious rigmarole can install Google Chrome easily. I have seen this take off in corporate offices by word of mouth.

What I want to do is run the release version of Google Chrome in Windows Virtual PC on Windows 7 and use the application publishing feature while I run the beta channel Google Chrome on my host Windows 7 machine. The problem is that in order for the virtual application publishing to work properly Google Chrome needs to be installed for all users.

I could do this by installing Chrome and then manually moving things around, edit the registry and create an All Users shortcut. Or I just discovered the Google tool to install Chrome for an entire machine.

If you use the Google Pack, you can install  Chrome Pack machine-wide. Get the pack from http://pack.google.com.

google-pack

Go, fight, win!

%d bloggers like this: