A coalition of 30 technology companies hopes to turn the web into a competitive platform for building mobile applications. They have launched a Core Mobile Web Platform (coremob) community group through the W3C to provide a venue for collaborating on next-generation mobile web standards.

Facebook and Mozilla are among the leading members of the group. In an announcement today, Facebook discussed its motivations for participating. The social networking company says users who access Facebook through the mobile website outnumber the collective audience of all Facebook’s native mobile applications.

Facebook consequently wants to ensure its mobile website matches the quality of the experience users get from the native applications. In order to make that possible, open web standards will have to evolve to offer tighter device integration.

Mozilla has been pursuing that goal with its WebAPI project. That has introduced new JavaScript APIs allowing web content to access underlying hardware components and platform functionality, such as the cameras and cellular radio. As we recently reported, Mozilla is using those new APIs in the Open Web Devices (OWD) platform, a mobile operating system that is based on the organization’s Boot2Gecko project.

Mozilla is also working through W3C to turn the APIs into open standards so they can be supported by other browser vendors. The coremob community group will provide a means for mobile web stakeholders to discuss their technical requirements and help shape the emerging standards.

Facebook also announced the release of Ringmark, a test suite for evaluating the capabilities of mobile web browsers. The tests will help developers make informed decisions about what features they can safely use in various mobile web environments. Facebook hopes such information will help developers contend with the highly fragmented mobile web browser landscape.

The Core Mobile Web Platform community group has announced Ringmark, a test suite for evaluating the capabilities of mobile Web browsers.

The tests consist of two separate “rings” which represent sets of standard web features. The inner ring focuses on fundamentals like support for HTML video, native JSON parsing, CSS animation, and the Canvas element. The second ring includes a broader feature set, such as fullscreen support, touch events, and the device orientation APIs. I ran the test suite on an iPhone 4S, which passed all of the tests in the first ring and 229 of the 306 tests in the second ring.

In addition to Mozilla and Facebook, the coremob community group also includes major mobile network operators, hardware manufacturers, mobile platform vendors, and other web companies. The lineup includes AT&T, Verizon, Samsung, HTC, Nokia, Intel, Microsoft, Opera, Adobe, Netflix, Zynga, Sencha, among others. Conspicuously absent from the list: Apple and Google.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mozilla announced today that it has partnered with mobile network operator Telefónica to deliver a complete mobile operating system built around standards-based web technologies. They plan to bring the platform to market later this year on a prototype device that they are developing in collaboration with Qualcomm.

The new operating system, which is called the Open Web Devices (OWD) platform, is based on Mozilla’s Boot2Gecko project. Mozilla launched B2G last year with the aim of building a Linux-based mobile computing environment with an application stack that runs entirely in Gecko, the HTML rendering engine that is used in the Firefox web browser.

Photo illustration by Aurich Lawson/Ars Technica

According to a statement from Mozilla, Telefónica was already evaluating the feasibility of creating its own web-centric mobile platform when the B2G project was first announced. Telefónica subsequently decided to bring its ideas to B2G and join Mozilla in a cooperative development effort.

Their initial target is to produce devices with smartphone-like capabilities that can be built inexpensively and sold at the price of a common feature phone. Telefónica believes that the unique advantages of a platform built around web technologies will potentially reduce development and production costs, enabling the company to make devices that are a good fit for regions where smartphones have historically been too expensive for widespread adoption.

“From our experience in Latin America we know that a huge part of the market is not being catered for by current smartphones,” said Telefónica Digital product development director Carlos Domingo in a statement. “With new open web devices we will be able to offer a smartphone experience at the right price point for these customers.”

As we recently reported in our hands-on look at B2G, Mozilla is introducing a number of new JavaScript APIs that expose device functionality to web content. These include APIs for measuring device battery level and communicating with a device’s cellular radio.

Mozilla has been working with the W3C to turn its new APIs into open standards with the hope that the technology will be embraced by other browser vendors. In today’s announcement, Mozilla revealed that it plans to take this effort one step further by turning the whole OWD platform into an open standard.

“Because of this initiative’s commitment to openness, this reference implementation will be submitted for standardization to W3C,” Mozilla told us in an e-mail. “The objective is that there are no proprietary APIs within the device architecture, making phones developed using it the only truly open devices on the market.”

The initial OWD prototype device will be built around a Qualcomm chipset, but the exact specifications have not yet been disclosed. In light of the focus on low cost, it’s likely that the specs will be modest. Mozilla contends that OWD is lighter than some other mobile platforms because its simple HTML-on-Linux architecture eliminates the need for a lot of the intermediate layers that would otherwise be necessary.

According to Mozilla, this lack of overhead will allow OWD to run efficiently on less-expensive hardware than its rivals. But HTML rendering engines are hardly lightweight — it is still unclear whether a user experience built entirely with HTML and JavaScript will be able to fully match the performance and responsiveness of native code on a mobile device.

It does seems clear, however, that the extensive use of HTML will help accelerate OWD development and vastly simplify the sort of customizations that mobile network operators typically make. Mozilla was able to get its B2G home screen interface up and running very quickly due to the strengths of HTML as an environment for creating interactive user experiences.

Another question that is left unanswered is which handset manufacturer will actually build the launch device for Telefónica. A number of rumors that have circulated over the past few days suggest that LG will be involved in building the first handset based on the B2G project. It’s possible that LG is involved, but that hasn’t been confirmed yet.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mozilla launched a new project last year called Boot2Gecko (B2G) with the aim of developing a mobile operating system. The platform’s user interface and application stack will be built entirely with standards-based web technologies and will run on top of Gecko, the HTML rendering engine used in the Firefox web browser. The B2G project has advanced at a rapid pace this year and the platform is beginning to take shape.

The B2G team at Mozilla is preparing to give a demo of the platform’s user experience at the upcoming Mobile World Congress (MWC) event. Mozilla’s Brendan Eich told us via Twitter that the B2G project has already attracted partners, including one that is developing its own custom home screen. This suggests that multiple parties, possibly hardware vendors, are interested in adopting the platform.

According to a roadmap recently published by Mozilla, the B2G project could potentially reach the product stage by the second quarter of 2012. That’s a highly ambitious target, but the project’s impressive rate of development suggests that it can be done. The pervasive use of HTML and JavaScript to build the user interface and application stack is no doubt speeding the project along. Web technologies are very conducive to rapid development.

The B2G platform consists of three main layers. The bottom layer, which is called Gonk, includes the Linux kernel, the hardware abstraction layer, the telephony stack, and other low-level system components. The middle layer is the Gecko rendering engine, which has been improved with new APIs that expose device capabilities. The top layer is Gaia, the B2G user interface, which is built entirely with HTML and JavaScript.

The Linux kernel that is used in Gonk is said to be “reasonably close” to upstream Linux. According to Mozilla’s documentation, Gonk uses some of the underlying bits of the Android open source project, including some minor kernel customizations, in order to make it easier for hardware vendors to get B2G running on Android hardware. B2G is not based on Android, however, and will not run Android applications. It’s currently possible to replace the Android environment on a Samsung Galaxy S II with a B2G build.

Much of the interaction between the Gecko and Gonk layers will be mediated by a B2G process that runs with a high privilege level and acts as a sort of Gecko server. The B2G process will paint to the framebuffer and interact with hardware components like a built-in GPS antenna or camera.

The wireless modem functionality is implemented in a radio interface layer (RIL) daemon, which B2G will interact with through a simple proxy process. Actual web content and multimedia playback will be handled by separate processes that communicate with the B2G process.

Mozilla aims to build the entire B2G user interface and application stack with native HTML and JavaScript. In order to accomplish that, Mozilla launched the WebAPI project, which exposes device functionality to web content through JavaScript APIs. Mozilla has already previously introduced APIs for accessing certain device capabilities, such as the accelerometer and geolocation APIs that are supported in the mobile versions of Firefox.

The WebAPI project goes a step further and adds a great deal of additional functionality for tasks like taking pictures with the built-in camera, dialing the phone, accessing the device’s battery level and status, sending and managing SMS messages, accessing the user’s address book, and making a device vibrate. These capabilities are largely made accessible to web content through a set of JavaScript APIs. This means that the B2G dialer interface, for example, is just a web page that uses a JavaScript function to initiate a call.

Mozilla is working to standardize these APIs through the W3C Device APIs working group. In theory, the same underlying JavaScript APIs that are used to enable access to underlying platform features on B2G could eventually be supported natively in the default web browsers that ship with other platforms.

The standardization effort around device APIs is especially significant. If the APIs gain widespread adoption, it would make it possible for large portions of the B2G user experience and application stack (which are, essentially, just web content) to run in web browsers on other platforms. At that heart of Mozilla’s agenda for B2G is a vision of the future in which browser-based mobile applications, built with standards-based HTML and JavaScript, will be capable of doing everything that can be done today with the native mobile application development frameworks.

Because B2G’s Gaia user interface layer is implemented in HTML and JavaScript, it can technically run in a regular desktop web browser. Of course, the device-related capabilities will only work when the content is run in an environment that has WebAPI support.

We tested the Gaia home screen user interface and several of the platform’s applications in a Firefox nightly build. All we had to do to get it running was download the code from the relevant GitHub repository and then open the homescreen.html file in Firefox.

When the page loads, the user will see the B2G lock screen, which displays the current date and time. The home screen interface can be accessed by dragging the lock screen up. The home screen displays a grid of application launchers and has a notification bar at the top. You can drag a notification slider down from the bar, much like the equivalent user interface element in Android.

B2G lock screen

If you look at the source code of the homescreen.html page, you will see that the contents of the interface, including the lock screen, are created with HTML div tags with some JavaScript code to handle interaction and populate the values. It’s quite simple and predictable web content.

The B2G home screen

Individual applications run inside of a frame in the homescreen interface. We tested several applications, including a dialer, a web browser, and a map application. Like the home screen, these are all implemented in HTML and CSS. The web browser is basically a web page with an HTML input element for the URL bar and an embedded iframe element where the page content loads.

B2G sample map application

B2G's Web browser. It's practically begging for a Yo Dawg joke

The B2G dialer

The current implementation of the Gaia environment is still simplistic and incomplete, but it offers a compelling demonstration of how conventional web content can be used to create a smartphone user experience. It’s possible to do anything in the B2G user interface that can be done with HTML and CSS, so the possibilities for styling and theming are prodigiously extensive. Such intrinsic flexibility could help make B2G appealing to hardware vendors because it would make it easier for them to create custom user interfaces that differentiate their products.

Mozilla hasn’t created an HTML-based widget toolkit for application development. The applications currently included in Gaia are just straight markup with CSS for design. It’s theoretically possible to use existing HTML widget toolkits in B2G, however, such as jQuery Mobile and Sencha Touch.

The B2G project is off to an impressive start. The underlying concept of bringing native application capabilities to the standards-based web technology stack is also tremendously compelling. It hints at the possibility that the open web could someday provide a unified application platform for mobile devices.

It’s also worth noting that the project is entirely open. As Eich pointed out to us yesterday in response to our coverage of Open webOS, the B2G project has had open governance and public source code since its first day. B2G also benefits from Mozilla’s engineering talent and potential partners. The B2G platform has an opportunity to bring positive disruption to the mobile landscape and be a serious contender.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Google issued a beta release of Chrome for Android earlier today. The browser provides support for modern web standards and includes a number of compelling features that aren’t available in the Android’s default browser. One noteworthy Chrome desktop feature that isn’t included in the mobile port, however, is the integrated Flash runtime.

Adobe has issued a statement confirming that Chrome for Android does not support Flash content. The company also indicated that it does not plan to work with Google to add Flash support to the new mobile browser. Adobe will, however, continue supporting Flash in the current default Android browser.

“Today Google introduced Chrome for Android Beta. As we announced last November, Adobe is no longer developing Flash Player for mobile browsers, and thus Chrome for Android Beta does not support Flash content,” wrote Adobe’s Flash Platform product manager Bill Howard.

Adobe struggled for years to make the Flash player plugin viable on mobile devices. Though it was able to make Flash work reasonably well on Android phones, results were mixed on other systems. Due to Apple’s unwillingness to allow the Flash plugin on iOS and the difficulty that Adobe faced bringing the Flash player to new devices, the plugin never achieved the same ubiquity on phones that it has historically enjoyed on the desktop.

These setbacks caused Adobe to abandon its mobile Flash player strategy last year. The company announced that it would phase out development of its mobile Flash player plugin and not support it on new platforms. Adobe instead focused its mobile Flash efforts on developing tools for deploying Flash content as native mobile applications. It also strengthened its commitment to native web standards and acknowledged HTML5 as the way forward for building rich mobile web experiences.

When Google eventually moves to replace the default Android browser with Chrome in future versions of the Android platform, devices that run the operating system will likely no longer be able to play Flash content in the browser.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Microsoft’s new version of Internet Explorer has barred browser plugins in the Metro environment. But Microsoft has revealed a method that plugin-dependent websites can use to leap over Metro’s walls and reach the green fields of the conventional Windows desktop, where Flash is still allowed to roam free.

The relevance of proprietary browser plugins is declining as standards-based web technologies mature. Native web technologies don’t yet supply complete functional equivalence with the capabilities of plugins, but the open web has the advantage of greater ubiquity.

The ubiquity of native web standards over proprietary plugins is set to get a major boost from Microsoft with the launch of Windows 8 and Internet Explorer 10. As we have previously reported, the next major version of Microsoft’s web browser will not display plugins in the Metro environment, which will be the default shell in Windows 8.

A plugin-dependent website prompting the user for permission to run on the desktop. Image courtesy of Microsoft

Microsoft has published a series of posts in its official IE development blog that discuss the implications of this change and what it means for users and web developers. In a new post published this week, IE program manager lead John Hrvatin highlighted the advantages of plugin-free browsing and emphasized the need for web developers to start supporting users who browse in environments that don’t have plugins enabled.

“The transition to a plug-in free web is happening today. Any site that uses plugins needs to understand what their customers experience when browsing plugin free. Lots of web browsing today happens on devices that simply don’t support plugins,” he wrote. “Metro style IE runs plug-in free to improve battery life as well as security, reliability, and privacy for consumers.”

A growing number of websites that rely on browser plugins already offer a standards-based fallback for users who are browsing on popular plugin-free devices such as as the iPhone or iPad. Microsoft has previously discussed some of the steps it is taking to ensure that those websites serve their plugin-free content to Metro users.

There will still likely be many Flash-heavy websites, however, that can’t accommodate users who are browsing without plugins. In the blog post, Hrvatin explained that such websites can ask the user for permission to jump to the conventional Windows desktop and launch the windowed version of Internet Explorer, which will have full support for plugins.

Web developers can get the browser to display the prompt by including the special requiresActiveX=true property in an X-UA-Compatible meta tag or HTTP header. Hrvatin cautions that this feature is included for transitional purposes and is intended to serve as a last resort. The preferred behavior is still for web developers to display a plugin-free version of their site to users who are browsing in the Metro environment.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mozilla has officially released Firefox 10. The new version of the open source web browser includes a handful of improvements and new features. The browser’s built-in tools for web developers got a particularly significant boost in this release. The new version also offers better support for a number of web standards.

Firefox’s developers decided last year to transition the browser to a time-based, six-week release cycle. The new release management strategy ensures that performance improvements and support for new web standards reach users as soon as possible. The faster release cycle posed challenges, however, for enterprise adopters and other users who require a longer support period. In order to address that issue, Mozilla has decided to offer an annual extended support release with a full year of updates. Firefox 10 is the first official extended support release.

A minor adjustment to the browser’s navigation bar is the biggest user-facing change in Firefox 10. The forward arrow button is no longer persistently visible by default in the navigation toolbar. It will only appear when the user navigates back a page. That means the button only shows when it can be activated. When the user clicks the forward arrow button and returns to the front of the history stack, the button will disappear again.

The distinctive keyhole shape that is formed by the back and forward buttons in Firefox’s navigation toolbar has been characterized in the past by Mozilla designers as an important part of the browser’s visual identity. Much like the angular tabs in Chrome, it’s an aesthetic characteristic that is uniform across platforms and helps make the browser recognizable.

The user interface change in Firefox 10 will make it so that the keyhole shape is only visible when the user navigates back. The feature worked predictably in our tests and didn’t pose any problems in practice. It’s worth noting, however, that it doesn’t appear to be available when the user has toggled the preference for small toolbar icons.

The new developer tools in Firefox 10

Another major change in Firefox 10 is the introduction of new developer tools. Previous versions of the browser have included a web console, a JavaScript scratchpad, and a simple tool for inspecting the Document Object Model (DOM). Firefox 10 has a new tightly-integrated developer panel with a richer DOM inspector and a tool for viewing, toggling, and modifying CSS properties.

The DOM inspector follows your cursor as you move it over elements of the page and will lock in on an element when you click. An HTML pane at the bottom of the screen will show you the markup for the target element and allow you to modify the values of element attributes. The HTML inspector pane also has a slick breadcrumb bar that makes it easy to see the position of the target element in the page hierarchy.

The CSS inspector will show you a list of CSS properties associated with the selected element, including inherited properties. Each one has a checkbox that you can click to toggle visibility. You can also click one of the values to replace it on the fly.

These built-in development tools in Firefox are simpler and less intrusive than more sophisticated alternatives such as the Firebug add-on. There are a number of additional features under development that will be included in the inspector panels in future versions of the web browser. One of the most intriguing is a tool that uses WebGL to show the user a three-dimensional representation of the page DOM. That feature wasn’t ready for inclusion in Firefox 10 and will potentially appear in the next major release.

In addition to the new inspector, web developers can also look forward to improved support for web standards. An addition of particular significance is a new full-screen API, which makes it possible for an individual HTML element to break out of the browser window and stretch itself to cover the entire screen. This feature is going to be especially useful for videos and games. You can see it in action by visiting Mozilla’s fullscreen demo page.

We first wrote about the full-screen API in November, when the feature originally landed in nightly builds. Mozilla carefully considered potential abuse scenarios when implementing the feature. It’s designed so that an element can only switch into fullscreen mode in response to a direct user action. The browser ensures this by using a technique similar to the one used to block unwanted popup windows.

Another addition in this release is support for 3D CSS transforms. This feature, which was originally created by Apple, offers a declarative mechanism for applying animated three dimensional transformations to individual HTML page elements. It’s important to note that 3D CSS transforms are entirely distinct from WebGL, which is a low-level JavaScript API for 3D programming.

Support for 3D CSS transformations is a welcome addition to the browser. Developers are already using the feature in the wild, but most of the existing 3D CSS content was authored with WebKit-specific prefixes and consequently won’t work in Firefox yet.

Firefox 10 is a solid release that expands the browser’s capabilities. Although the lineup of new features is slim, it’s a respectable update by the standards of the rapid release model. The new version will be pushed out through the Firefox update system shortly. Firefox 10 can also be downloaded directly from the Mozilla website. For more details, you can refer to the official release notes.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Mozilla is drafting a proposal for a new web standard called MediaStream Processing that introduces JavaScript APIs for manipulating audio and video streams in real time. The specification is still at an early stage of development, but Mozilla has already started working on an implementation for testing purposes.

Mozilla’s Robert O’Callahan, the author of the MediaStream Processing API proposal draft, released experimental Firefox builds that include MediaStream Processing support. He has also published a set of demos (note: you need to run the experimental build to see the demos) that illustrate some of the functionality defined by the specification.

The demos show how the APIs can be used to perform tasks like rendering a visualization of a video’s audio track in a Canvas element while the video is playing. It also shows how the APIs can be used for mixing tasks, like implementing a cross-fade between two audio streams, dynamically adjusting the volume of a video, and programmatically generating audio streams.

One of the characteristics that distinguishes the MediaStream Processing API from previous web audio API proposals is that it aims to interoperate better with existing web standards. For example, it relies on the MediaStream interface in the WebRTC specification. It also allows users to take advantage of Web Workers for threading and will work with getUserMedia to eventually support real-time manipulation of streams from microphones and webcams.

The current implementation of the specification focuses on audio capabilities. As O’Callahan explained this week in a blog post, support for video manipulation will be added in the future when the necessary graphics APIs are accessible through Web Workers. MediaStream Processing on video will be useful for doing things like QR code recognition and augmented reality in web applications, he said.

Analyzing a video's audio track and visualizing it in real time

So, when will this functionality be available in a stable Firefox release? It might take some time. According to O’Callahan, the patch needs some cleanup before the functionality can land in trunk and make it into regular nightly builds. Even then, the MediaStream Processing functionality likely won’t be generally available until the specification has solidified.

“The biggest limitation is that it’s not shipping in Firefox yet. My giant patch is messy and a lot of cleanup needs to be done. I have a plan to split the patch up, clean up the pieces and land them piecemeal. In particular I need to get some of the infrastructure landed ASAP to help the WebRTC team make progress,” he wrote. “When we ship it, much or all of the API will probably be disabled by default, behind a hidden pref, until the standards situation is resolved.”

MediaStream Processing is definitely going to be worth the wait. Some fantastic capabilities are going to be unlocked when the specification is fully implemented. It will open the door for using native web standards to perform some sophisticated real-time media processing tasks that were previously only possible with browser plugins.

This article originally appeared on Ars Technica, Wired’s sister site for in-depth technology news.

Adobe reversed course on its Flash strategy after a recent round of layoffs and restructuring, concluding that HTML5 is the future of rich Internet content on mobile devices. Adobe now says it doesn’t intend to develop new mobile ports of its Flash player browser plugin, though existing implementations will continue to be maintained.

Adobe’s withdrawal from the mobile browser space means that HTML5 is now the path forward for developers who want to reach everyone and deliver an experience that works across all screens. The strengths and limitations of existing standards will now have significant implications for content creators who want to deliver video content on the post-flash web.

Apple’s decision to block third-party browser plugins like Flash on its iOS devices played a major role in compelling web developers to build standards-based fallbacks for their existing Flash content. This trend will be strengthened when Microsoft launches Windows 8 with a version of Internet Explorer that doesn’t support plugins in the platform’s new standard Metro environment.

Flash still has a significant presence on the Internet, but it’s arguably a legacy technology that will decline in relevance as mobile experiences become increasingly important. The faster pace of development and shorter release cycles in the browser market will allow open standards to mature faster and gain critical mass more quickly than before. In an environment where standards-based technologies are competitive for providing rich experiences, proprietary vendor-specific plugins like Flash will be relegated to playing a niche role.

Our use of the phrase post-Flash isn’t intended to mean that Flash is dead or going to die soon. We simply mean that it’s no longer essential to experiencing the full web. The HTML5 fallback experiences on many Flash-heavy sites still don’t provide feature parity with the Flash versions, but the gap is arguably shrinking — and will continue to shrink even more rapidly in the future.

Strengths and weaknesses of HTML5 video

HTML5 has much to offer for video delivery, as the HTML5 video element seamlessly meshes with the rest of the page DOM and is easy to manipulate through JavaScript. This means that HTML5 video offers significantly better native integration with page content than it has ever been possible to achieve with Flash. The open and inclusive nature of the standards process will also make it possible for additional parties to contribute to expanding the feature set.

A single company no longer dictates what can be achieved with video, and your video content is no longer isolated to a rectangle embedded in a page. HTML5 breaks down the barriers between video content and the rest of the web, opening the door for more innovation in content presentation. Three are some really compelling demonstrations out there that showcase the use of video in conjunction with WebGL and other modern web standards. For example, the video shader demo from the 3 Dreams of Black interactive film gives you a taste of what’s possible.

Of course, transitioning video delivery in the browser from Flash to HTML5 will also pose some major challenges for content creators. The standards aren’t fully mature yet and there are still a number of features that aren’t supported or widely available across browsers.

For an illustration of how deep the problems run, you need only look at Mozilla’s Firefox Live promotional website, which touts the organization’s commitment to the open web and shows live streaming videos of Red Panda cubs from the Knoxville Zoo. The video is streamed with Flash instead of using standards-based open web technologies.

Flash is required to see the Red Panda cubs on Mozilla's website

In an FAQ attached to the site, Mozilla says that it simply couldn’t find a high-volume live-streaming solution based on open codecs and open standards. If Mozilla can’t figure out how to stream its cuddly mascot with open standards, it means there is still work to do.

Two of the major technical issues faced by HTML5 video adopters are the lack of adequate support for adaptive streaming and the lack of consensus surrounding codecs. There is currently an impasse between backers of the popular H.264 codec and Google’s royalty-free VP8 codec. There’s no question that a royalty-free video format is ideal for the web, but the matter of whether VP8 is truly unencumbered by patents — and also meets the rest of the industry’s technical requirements — is still in dispute.

There is another major issue that hasn’t been addressed yet by open web standards that could prove even more challenging: content protection. The vast majority of Flash video content on the Internet doesn’t use any kind of DRM and is trivially easy to download. Flash does, however, provide DRM capabilities and there are major video sites that rely on that technology in order to protect the content they distribute.

Can DRM be made to play nice with open standards?

DRM is almost always bad for regular end users and its desirability is highly debatable, but browser vendors will have to support it in some capacity in order to make HTML5 video a success. Many of the content creators who license video material to companies like Netflix and Hulu contractually stipulate a certain degree of content protection.

Mozilla&’s Robert O’Callahan raised the issue of HTML5 video DRM in a recent blog entry shortly after Adobe’s announcement regarding mobile Flash. He expressed some concern that browser vendors will look for a solution that is expedient rather than inclusive, to the detriment of the open web.

“The problem is that some big content providers insist on onerous DRM that necessarily violates some of our open web principles (such as web content being equally usable on any platform, based on royalty-free standards, and those standards being implementable in free software),” O’Callahan wrote. “We will probably get into a situation where web video distributors will be desperate for an in-browser strong DRM solution ASAP, and most browser vendors (who don’t care all that much about those principles) will step up to give them whatever they want, leaving Mozilla in another difficult position. I wish I could see a reasonable solution, but right now I can’t. It seems even harder than the codec problem.”

O’Callahan also pointed out in his blog entry that the upcoming release of Windows 8, which will not support browser plugins in its Metro environment, means that the lack of DRM support in standards-based web video is no longer just a theoretical concern. Microsoft may need to furnish a solution soon, or risk frustrating users who want to watch commercial video content on the web in Windows 8 without installing additional apps or leaving the Metro shell.

Netflix stands behind DASH

Flash evangelists may feel that the limitations of HTML5 video and the problems that content creators are sure to face during the transition are a vindication of the proprietary plugin model. But the advantages of a truly open, vendor-neutral, and standards-based video solution that can span every screen really dwarf the challenges. That is why major stakeholders are going to be willing to gather around the table to try find a way to make it work.

Netflix already uses HTML5 to build the user interfaces of some of its embedded applications, including the one on the PS3. The company has soundly praised the strengths of a standards-based web technology stack and has found that there are many advantages. But the DRM issue and the lack of suitably robust support for adaptive streaming have prevented Netflix from dropping its Silverlight-based player in regular web browsers.

The company has committed to participating in the effort to make HTML5 a viable choice for all video streaming. Netflix believes that the new Dynamic Adaptive Streaming over HTTP (DASH) standard being devised by the Motion Picture Experts Group (MPEG) will address many of the existing challenges and pave the way for ubiquitous adoption of HTML5 for streaming Internet video.

DASH, which is expected to be ratified as an official standard soon, has critical buy-in from many key industry players besides Netflix, including Microsoft and Apple. An early DASH playback implementations is already available as a plugin for the popular VLC video application.

The DASH standard makes video streaming practical over HTTP and addresses the many technical requirements of high-volume streaming companies like Netflix, but it doesn’t directly address the issue of DRM by itself. DASH can be implemented in a manner that is conducive to supporting DRM, however.

DASH and DRM

Ericsson Research, which is involved in the DASH standardization effort, has done some worthwhile preliminary research to evaluate the viability of DRM on DASH. Ericsson produced a proof-of-concept implementation that uses DRM based on the Marlin rights management framework. Marlin, which was originally created by a coalition of consumer electronics vendors, is relatively open compared to alternate DRM technologies and makes use of many existing open standards. But Marlin is still fundamentally DRM and suffers from many of the same drawbacks, and adopters have to obtain a license from the Marlin Trust Management Organization, which holds the keys.

The architecture of the Marlin rights management framework

Ericsson explains in its research that it chose to experiment with Marlin for their proof-of-concept implementation because it’s available and mature — other similar DRM schemes could also easily be adopted. Existing mainstream DRM schemes would all likely pose the same challenges, however, and it’s unlikely that such solutions will be viewed as acceptable by Mozilla. More significantly, an implementation of HTML5 video that relies on this kind of DRM would undermine some of the key values and advantages of openness that are intrinsic to the open web.

The ease with which solutions like Marlin can be implemented on top of HTML5 will create pressure for mainstream browser vendors to adopt them quickly. This could result in the same kind of fragmentation that exists today surrounding codecs. As O’Callahan said, it’s easy to see this issue becoming far more contentious and challenging to overcome than the codec issue.

What next?

The transition to HTML5 and standards-based technology for video delivery will bring many advantages to the web. There are some great examples that show what can be achieved when developers really capitalize on the strengths of the whole open web stack. The inclusiveness of the standards process will also give a voice to additional contributors who want to expand the scope of what can be achieved with video on the web.

There are still some major obstacles that must be overcome in order for the profound potential of standards-based web video to be fully realized in the post-Flash era. Open standards still don’t deliver all of the functionality that content creators and distributors will require in order to drop their existing dependence on proprietary plugins. Supplying acceptable content protection mechanisms will prove to be a particularly bitter challenge.

Despite the barriers ahead, major video companies like Netflix recognize the significant advantages of HTML5 and are willing to collaborate with other stakeholders to make HTML5 video a success. The big question that remains unanswered is whether that goal can be achieved without compromising the critically important values of the open web.

See Also:

• Damn the Torpedos: Mozilla Adds Flash to Firefox for Android
• Adobe Puts Flex Out to Open Source Pasture
• What the Death of Mobile Flash Means for the Web
• Metro-style Internet Explorer 10 Ditches Flash, Plugins