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
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.
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.
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.
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.
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.
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.
to post comments)