Developments in Mozilla-land

Mozilla announced a new rapid-release cycle for its flagship applications earlier this year, but it has not slowed down on other fronts in the interim. New work in recent weeks include the Boot to Gecko instant-on project, collaboration with Google developers on WebRTC and Web Intents, a new security review process, and an initiative aimed at meeting the distinct needs of enterprise IT departments.

To the cloud

Boot to Gecko (B2G) was announced on July 27; it is aiming to build "a complete, standalone operating system for the open web." Much like ChromeOS, the idea is to build a low-resource-usage operating system for portable devices (e.g., tablets and phones) that focuses on web-delivered applications instead of locally-installed software. Notably, however, the initial announcement and the main project page both discuss the web's ability to displacing proprietary "single vendor control" of application execution environments.

Obviously, Mozilla has believed in the web as an OS-agnostic delivery platform for years, as its "open web app ecosystem" and Drumbeat outreach initiative demonstrate. But the project has never spearheaded the development of an actual OS offering before. When third-party developers launched the Webian Shell project — itself a Mozilla-based desktop environment — Mozilla offered guidance and technical assistance, but did not get directly involved in its development. At the time, some industry watchers speculated that Mozilla might be wary of stepping on Google's toes with its default-search-engine-placement deal coming up for renewal later this year.

B2G and Webian are very different, at least at the moment. Webian is replacement for the desktop environment, not a complete OS, while B2G at least plans to adopt a full software stack. B2G is also still in the very early development stage, without demos to download. But the project has outlined a number of areas where it believes new APIs will need to be developed and structures will need to be put in place to build a fully Mozilla-based OS. These include APIs for accessing hardware devices not addressed by traditional browsers (telephony, Bluetooth, and USB device access, for example), and a new "privilege model" to make sure that these devices are accessible by pages and web applications without security risks.

Interestingly enough, the B2G project pages also discuss the need for an underlying OS to boot into, and describes it as "a low-level substrate for an Android-compatible device." This suggests that B2G is going after the Android, not ChromeOS, class of hardware (although where it concerns angering Google, it is doubtful that the company would be less protective of one pet project than another).

Indeed, the B2G GitHub code currently builds only with the Android SDK and is installable only on the Nexus S 4G, although the mailing list thread in mozilla.dev.platform discusses other hardware targets. The thread (which for the moment is the only official email discussion forum for B2G) includes considerable debate about what the sub-Gecko OS needs to include, exactly what web APIs deserve top priority, and the relative merits of Android, MeeGo, webOS, and other open source operating systems as a platform.

Mozilla's Mike Shaver addressed the current use of Android as more of a project-bootstrapping move than a longer-term strategy:

In spite of that explanation, the debate over the OS underpinnings rolls on. Wherever the project heads, it makes for educational reading.

Web APIs

Tied in deeply to the B2G discussion is a new generation of web APIs on which to build the increasingly interactive and cross-domain web applications that the B2G vision relies on. On that front, Mozilla and Google seem to be working well together.

For example, the search giant released an open source real-time communications framework called WebRTC in May. WebRTC is a collection of voice and video streaming protocols and support libraries designed to be accessed via JavaScript, rather than through the binary plug-ins common in older web-chat applications. The release includes the iSAC and iLBC voice codecs Google acquired with its purchase of Global IP Solutions, the VP8 video codec it has owned since 2010, and support libraries to perform echo cancellation, automatic gain control, noise suppression, and cross-platform hardware access.

In addition to the media streaming components, WebRTC includes libraries to handle network buffering, error correction, and connection establishment, some of which is adapted from libjingle.

In early August, Mozilla announced it was going to adopt WebRTC as a core component of its Rainbow extension for Firefox. Rainbow allows web applications to access client-side audio- and video-recording hardware (i.e., microphones and webcams). Apart from the obvious use (person-to-person chat applications), Mozilla Labs reports that developers have written karaoke, QR code scanning, and photo booth applications. Unfortunately, even the most recent Rainbow release (0.4) does not support Linux, although the team claims it is a high priority. The Rainbow README says the project ultimately wants to not depend on any external libraries; a solid offering of audio- and video-handling through WebRTC should help.

While WebRTC occupies a low-level API slot, Web Intents implements a very high level of abstraction. The concept is inter-application communication and service discovery, so that (for example) a user could use an online image editor like Picnik to open and touch up photos hosted at another online service, like Flickr. Web Intents was announced by Google in November of 2010, based on the Intents API used by Android.

Web services "register" the actions they intend to support with <intent> tags in their page's <head> sections. The prototype framework defines a handful of default intents — share, discover, edit, view, and pick — and uses MIME types to allow services to indicate the type of data they understand. An intents-aware browser could then match compatible services together and present them as options to the user. In the meantime, the project has written a JavaScript shim that application authors can use to invoke the intents offered up by other services and to get back the results.

Mozilla's proposal tackles much the same problem. It was initially referred to as Web Activities in a July blog post, then as Web Actions in August. In both cases, however, the same general protocol is used: each service advertises a set of actions that it will support from incoming applications, based on a generally-agreed-upon set of common actions.

In an August 4th blog post, Google announced that it was "working closely with Mozilla engineers to unify our two proposals into one simple, useful API." With little more than basic demos to go on, the two APIs seem strikingly similar, although Mozilla's "Web Actions" is regarded as the clearer name in several articles in the technical press. It also includes a more definite mechanism for service discovery, which remains a fuzzy notion in the Google proposal. Currently applications needing to connect to a remote service must rely on either the user or the browser to locate compatible alternatives. Mozilla's proposal uses its Open Web App manifest storage to remember previously-discovered services. Everyone seems to agree on the value of a cross-web-application communication framework, so the protocol is worth watching, but it could be quite some time before there are any services able to make use of the system.

Freshening the security blanket

In late July, the Mozilla Security Blog posted a outline for reworking and "evolving" the project's security review process. The nexus of the proposal is to better integrate security review with the overall application development process: a smoother process results in less disruption for the developers and fewer hangups for the users. As Mozilla contemplates reaching a wider audience with the increased adoption of Firefox for Mobile and its messaging products, getting the process right will help the organization grow its user base.

Specifically, the goals include performing reviews and flagging bugs earlier, ensuring that reviews produce "paths" out of trouble and not just work stoppages, more transparency in the content of reviews, and a more open and transparent format for security team meetings. There is a sample outline of the new review meeting process included in the blog post, and the team has been using it for the past few months.

The experience has been a successful one so far, and preemptively caught security flaws in Firefox's CSS animation code and Server-sent DOM event handling. The full schedule of security meetings is published as publicly-accessible HTML and iCalendar data, and the results are archived on the Mozilla wiki. The new approach has also resulted in some new features being added to the Mozilla Bugzilla instance and team status pages.

Ultimately, the security team says it wants to become "fleet of foot" enough that development teams will come to it to have a review done, rather than the security team needing to initiate the review process and interrupt development.

Enterprise Firefox

In late June, PC Magazine reported that enterprise IT departments were upset by Mozilla's move to a short release cycle, arguing that the change negatively affected them by drastically shortening the support lifetime of each release. When a corporate IT consultant lamented the time it would take to test and validate multiple major releases each year, Mozilla's Asa Dotzler sparked controversy by commenting "Enterprise has never been (and I'll argue, shouldn't be) a focus of ours."

A month later, Mozilla's chief of developer engagement, Stormy Peters, announced the formation of an enterprise user working group where the project can interface with IT professionals and enterprise developers. The "enterprise developers" segment includes people who develop in-house web applications for enterprises, as well as those who use Mozilla components to develop their own software (including add-ons and XUL-based applications).

The group's wiki page lists general "help each other"-style objectives, but more importantly it outlines communication mechanisms, starting with a private mailing list and monthly phone call meetings. Each meeting has a specific topic, and both outlines and minutes are posted on the wiki. Understandably, the first few tackled the new release cycle and input from enterprise users on deploying Firefox and how it could be improved.

The output of the meetings also seems to be archived in "resource" pages on the wiki, and integrated with related information on each particular topic. Unfortunately, the minutes from the August 8th meeting on the new rapid-release cycle are not posted yet, and although the working group has its own issues in Mozilla Bugzilla, so far the only bugs filed deal with technical issues, such as configuration and LDAP support.

Nevertheless, the working group is a positive step. The brouhaha over enterprise support in June was primarily sparked by the attitude many read in Dotzler's comments; opening an ongoing conversation with more diplomatic overtones is arguably a better fix for that kind of problem than are Bugzilla issues. It would be nice to see the enterprise working group attempt to increase its openness and transparency by making its mailing list public, but that may simply be another one of those areas where "enterprises" and those of us who are merely "consumers" do not see eye-to-eye.

Busy times

The list of recent projects undertaken at Mozilla demonstrates the organization's new-found interest in taking its mission beyond the traditional desktop browser. Certainly the new approach to security review and the enterprise working group directly affect Firefox development, but with B2G and the various Open Web Application projects, soon the oft-used term "browser maker" may fail to accurately describe Mozilla. But it is encouraging to see that the diversified interests of the project include exploring areas — like web-only operating systems — that might otherwise be ceded to commercial interests alone.