Mozilla's open web app platform

The Mozilla Labs project is rolling out a framework it calls Open Web Apps intended to improve the "stickiness" and operating system integration of web-based applications. The framework uses HTML5 features like local storage and existing standards like OpenID to create an installation workflow that more closely mimics the process traditionally used with desktop applications. Officially announced in October, the first bits of code have now started to appear on Github.

Based on the initial announcement in October and a foreshadowing post from May, the theory underlying Open Web Apps seems to be that, under the current paradigm, users have little more than their browser's bookmarking system to keep track of web applications that they frequently use. As a result, web applications (in spite of their growing popularity) remain segregated from the rest of the OS experience — they do not have a persistent presence, they all behave differently in regard to sign-on procedures, and so forth.

On top of that, the May post suggests that as more web developers build web applications disguised as mobile applications for consumer smartphones like Android or Apple's iPhone, they have grown to like the browsable, searchable, rate-able interface of the "mobile app store."

What it is

The Open Web Apps experiment attempts to solve both of these problems at once. On the web apps' side, it describes a JSON-based application "manifest" file that each application would serve up to describe basic metadata about itself — name, icon, creator, launch path, verification URL, and a set of basic capabilities. On the browser side, it lays out a standard for a web app "repository" (which could be implemented directly in browser code, as an extension, or via JavaScript) made up of a locally-stored collection of these manifests.

The repository has two APIs: one that web sites can use to offer the user an "install this web app" option, and one that the browser can use to show the user his or her currently installed web apps. There is a JavaScript-based demo running at myapps.mozillalabs.com that uses this user-facing API to create a dashboard, showing a launcher for each app in the repository as well as an uninstall option.

At apps.mozillalabs.com (be sure to note the absence of "my"), the project has several demonstration implementations of the server-side code that illustrate different possibilities. A simple app can "self-publish," meaning that it offers its own manifest file and "install me" button, but interested third parties could also build directories, cataloging manifests found in the wild and presenting them to site visitors in categories and with rankings. The is also a "store" demonstration that illustrates the optional verification scheme, which can be used to hand off login via OpenID or even to charge an online payment before returning a successful install.

At the moment, the feature set offered by the demos is a little thin. There are a half-dozen apps available, but the only one that uses the paid-verification architecture is a fake app called TaskTracker which does not actually charge any money ... but neither is it a real app. The dashboard demo has big, glossy icons, but it also does not offer any genuine functionality beyond the standard Firefox bookmarks the system is supposed to be replacing.

As a result, it is easy to imagine that the manifest system could be good for web app developers if the "app store" model does indeed take off (Mozilla makes it clear repeatedly in the documentation that it is not interested in running such a store or directory). The ranking and sorting could be beneficial, and the unified verification/payment method would simplify sign-up. But there is not as much to like from the end user's point of view. Launchers are just launchers, regardless of the size of the icon.

Extending the idea

Moving forward, however, there may still be some interesting offerings in future versions of the architecture. The capabilities field, for example, has yet to be fully explored, but exposing what an application can do in advance could help users search for the apps they want. The wiki lists a handful of proposed capabilities, including geolocation support, media capture, read/write file access, read access to contacts, and so on.

Apart from geolocation, few current web applications make use of capabilities that users might care to seek out or specifically avoid, but more are presumably on the way. Mozilla's own Rainbow project exposes desktop audio and video recording hardware to web applications, for example. The existing capabilities list comes from the W3C's Permissions working group. Elsewhere the documentation and blog posts mention 3-D rendering, which might also be a viable candidate.

A blog post from November introduces an enhancement to the original scheme that does offer clear benefits to the user: synchronization of repositories between multiple computers. Code for this feature is already available on Github, though interestingly enough, as a separate server. The functionality to synchronize client data between browsers is already present in Firefox Sync (formerly Weave), though, so app repository synchronization may make it there someday.

Some of the features described as possibilities for future client-side enhancement cannot be implemented in the JavaScript-based demo dashboard running at myapps.mozillalabs.com due to the need to access lower-level browser code. The project says that add-ons-based implementations will follow — presumably for Firefox first, and Firefox for Mobile, though possibly for other HTML5 browsers as well.

Another proposed enhancement to the architecture that has implications for app developers is support for cryptographically signed manifests, which would allow the browser to verify that a manifest has not been altered by an attacker. The manifest specification is still undergoing revision, including a discussion on how best to let an application delegate installation authority to a third-party — i.e., allowing an app manifest to specify which stores and directories are authorized to sell (or perhaps even list) it.

Further out, the project mentions several ideas for extending the repository and dashboard functionality to provide better OS integration, such as a notification framework, cross-application search methods, and possible support for cross-site user-experience schemes like OExchange, which could be used to link user content from several different apps into a single unified set of documents.

Security

Wherever cross-site functionality is concerned, security becomes an issue. The project has a dedicated page outlining all of the possible security and privacy concerns it knows of in the Open Web App architecture, and where possible, potential solutions.

Because the system is primarily used as a way to connect to third-party sites, most of the potential attack vectors are not direct exploits of the web app in question (such as stealing a user's GMail password); those would be security holes in the service itself. Rather, the page describes attacks against the repository, the installation and verification functions, and the dashboard.

Some aspects of the system do not introduce any new attack vectors. Tampering with the repository itself or any installed app's manifest amounts to an attack on the browser's implementation of HTML5 local storage — though it should also be noted that the signed manifests proposal mentioned earlier is a safeguard against this. Likewise, intercepting application launch via a man-in-the-middle attack amounts to performing the same attack against the existing site's OpenID login implementation.

On the other hand, it would be possible to build a man-in-the-middle dashboard that intercepted installation or launch requests and delivered tainted goods to the client. This is only possible with a JavaScript-based, hosted dashboard, as opposed to a native browser dashboard implementation. The demo dashboard at myapps.mozillalabs.com, of course, is one such hosted dashboard. The project page suggests implementing dashboards only over HTTPS to provide a layer of protection against this attack. It also notes, however, that if browsers begin to implement the dashboard in local code, the attack vector disappears.

Finally, it would be possible to build a malicious "app store" that, through iframe defacement, tricks the user into installing a different application than the one they intend. The page notes that Firefox 4's Content Security Policy can protect against this vulnerability.

Appzilla returns

Strangely absent from the Open Web App project documentation is how the scheme could fit in with Mozilla's other web application / desktop integration product, Mozilla Prism. Prism is the renamed XULRunner browser, which can be used to launch sites in separate processes that behave more like a native application on a desktop system — living in the system tray, running at startup, and so forth. Some of the proposed extensions to the Open Web App architecture sound like they would be a good fit for Prism, but there is no indication that native repository functionality is headed in Prism's direction.

The major challenge facing Open Web App's growth, however, is not lack of browser support, but the effort that would be required to convince web developers to create browser-agnostic sites. Written all over the Open Web App documentation (starting with the name) is the notion that compliant apps should be based on free and open standards: HTML5, CSS, and JavaScript. But just saying that doesn't make it happen. Nothing in the system prevents developers from building IE-only or iPhone-only sites and slapping a compliant manifest file up on the server — it will just fail to work properly once installed in a different browser.

Still, that is a hurdle that can only be overcome with evangelism, not with specifications. The development community is at least aware of the difference. On Tuesday, Google unveiled a similarly-themed "app store" designed to function solely with its Chrome browser. During the press conference, a Twitter message from one reader was re-tweeted multiple times, asking "So why again are we building web apps 'for Chrome' instead of for the Web?" If Mozilla is correct about the growing desire of web application developers to have an "app store" model in which to hawk their wares to the public, it can only find that question encouraging — but it may still face a long slog uphill to make truly cross-browser applications the standard.