Mozilla Labs posted a screencast yesterday of a new feature as part of the Weave project, which enables OpenID at the browser level, which will have potentially significant impact on adoption and use of portable identity technology.

Weave is a Mozilla Labs project, started back in December of 2007, which (before this latest announcement) was mostly known for their Sync service, which can synchonize (and keep in sync over time) bookmarks, saved passwords, browsing history, and tabs, keeping your firefox browser experience consistent across multiple computers. It’s quite useful for those of us who have a work desktop, home desktop, and laptop, or some other combination of multiple computers regularly used.

This new effort, however, integrates OpenID into the Firefox user experience:

Our sprint changes the browser to provide single-click login to sites with saved passwords as well as sites that support a federated identity (OpenID in this case). It also provides the option to automatically sign in when the page is loaded, essentially providing a single-sign-on-like experience regardless of the login method being used. In the case of OpenID, we intercept the login procedure and, taking advantage of the fact that you’re already logged into your browser, and then use Weave identity to let you into the site.

Screencast

Unfortunately, for now, you have to install the latest weave development build which also requires you to be running Firefox 3.5 beta, so it isn’t really quite ready for public consumption.

There’s also, of course, the risk that people will use this poorly – storing saved OpenID on shared machines, etc – but I think the model of allowing the browser – after you’ve logged into it – to login on your behalf – will be a really good UX improvement over time, and one I hope the other browsers will take up and implement themselves.

(I’m sure they meant weave as in the “weaving the web” reference – but I can’t but help think about hair weaves, and the artificial extension of the browser beyond its natural domain – a little irony in the name itself? Not that there’s anything wrong with wearing a weave, mind you.)

News Coverage:

• Mozilla Weave: More Servers for your browser (ajaxian)
• Hands on with Mozilla Weave: Personalize your own cloud (ars technica, with screenshots)
• Mozilla launches Desktop Integration Tool for Firefox (Mashable)
• Mozilla Weaves Web Platform for User Data (ReadWriteWeb)
• Mozilla Weave Helps Us Move to the Cloud (Web Worker Daily)
• Mozilla floats Weave as Web platform (Between the Lines at ZDNet)
• Mozilla Weaves Services (GigaOM)

And the original announcement itself: Introducing Weave (Mozilla Labs).

In that announcement, Mozilla Labs argues that:

Web browsers like Firefox can and should do more to broker rich experiences while increasing user control over their data and personal information.

The initial release, which requires a Firefox 3b2pre or later build, lets the user synchronize browser history and bookmarks with data storage in the cloud.

The more interesting pieces will come, however, as other kinds of data start to leverage the service. What if, for example, my social graph information – the list of people I’m connected to and in what fashion – traveled with me through weave to various browser installations, and could be provided by the browser to a social network application, with my permission?

I’m certainly happy to see that Mozilla’s started on the right foot, with the assumption of user control over their data, and that they are planning encryption as a core part of the service.

I guess the question is ultimately where the real hair stops and the weave begins – what is naturally a part of the browser (or what Mozilla Labs calls “browser metadata”) and what is part of the application. It feels a bit strange (browser-centric?) to think of my bookmarks as a bit of browser-metadata.

I’d prefer to say that the browser itself is a bit of metadata on the edge of my bookmarks – that the bookmarks are the key data, and the fact that I accessed them in Firefox is secondary at best.

If the concept is “store your bookmarks, history, and customizations to Firefox with Mozilla, and retrieve them anywhere you use our app” that seams perfectly reasonable but also non-revolutionary (even a bit passe).

If the concept is “store your personal identity and associated metadata in the cloud, and bring it with you to any site you choose to share it with” it sounds much more interesting and potentially revolutionary.

What if one of the things I “weave” into Mozilla’s cloud is my openID? Saved passwords? References to my social graph?

It’s only a 0.1 release, but well worth watching.

(Maybe another reason I’m thinking of identity in this context is the Sir Walter Scott quote which the name evokes:

Oh what a tangled web we weave,
When first we practice to deceive!

Has someone at Mozilla Labs been reading Marmion? ).

As the following image (from the Mozilla Labs Prism page) illustrates, the idea is that Prism splits apart the light coming from the cloud into separate apps. (I know, light doesn’t really come from clouds, but you get the point):

In essence, what Prism does is simply to create a single-url loading instance of firefox without all the browser chrome – so that the application gets an icon of its own, has an entry in the Start menu, is accessible via alt-tab application switching, and the like.

Its an interesting direction for WebRunner, and a good step forward for some specific use cases along the desktop application / web application continuum. Take an app which has offline sync via GoogleGears, run it inside Prism, and you’ve got a desktop application which syncs to the cloud but can also be accessed from other non-prism browsers when you are away from your machine.

(For more info on Prism, see Read/Write Web, Geeks are Sexy, Alex Faaborg’s discussion of its UI, feature suggestions on Prism Brainstorming, Mark Finkle’s discussion of changes from the existing WebRunner, and the forums at Mozilla Labs).

In the process of explaining what Mozilla Labs is up to, the (anonymous?) Mozilla Labs blog entry author said:

Unlike Adobe AIR and Microsoft Silverlight, we’re not building a proprietary platform to replace the web. We think the web is a powerful and open platform for this sort of innovation, so our goal is to identify and facilitate the development of enhancements that bring the advantages of desktop apps to the web platform.

This got the attention of Adobe’s Mike Chambers, who first posted in the comments on the Mozilla announcement, taking issue with the idea that Prism is fundamentally different from AIR. After all, he noted, AIR also runs applications developed on web standards and runs them in a desktop container with some additional desktop-like features:

So, is the main difference between something like Prism and Adobe AIR, that Adobe AIR is being primarily developed by a company (Adobe), and that Prism is being developed by Mozilla?

Later, he expanded on this issue in a blog post: “Mozilla Prism and the Disingenuous Web,” repeating the notion that AIR and Prism seem quite similar in goal and usage, and complaining:

Come on Mozilla, the web development community deserves better than that. Adobe has been an active supporter of the web development community, of open source, of web standards and of Mozilla (donating the ActionScript virtual machine from the Flash Player (Tamarin)). Adobe AIR leverages a number of open source technologies (including Tamarin, SQLite and WebKit) and we actively participate in both of those development communities, and we have been open with our development process for some time.

So what does differentiate Prism from AIR? (See also “AIR, and a Prism” at Technological Musings for another comparison)

Mozilla Prism, for now, is Windows only; Adobe AIR, for now, is Windows and Mac OS only. Both have promised Linux support in the near future.

As several readers pointed out in comments threads on both Mike Chambers post and the one at Mozilla labs, the Mozilla foundation has a better track record at porting applications to Linux than Adobe does. (Flash Player 9 notwithstanding).

(Note that Linux and MacOS X installers are already listed in the Mozilla Labs Wiki – I’m trying one out in Linux now, and it seems to work just fine).

Adobe AIR is based on WebKit (also used in Safari, originally from the Konqueror browser in KDE) for rendering HTML; Mozilla Prism is based on Firefox. AIR can handle flash content, pdf content, or Ajax (HTML/JavaScript) content; Mozilla Prism can as well, though it relies on the same plugins the Firefox browser does to support these other content types.

One significant difference is that Adobe AIR applications are created by developers, who do some “extra work” to create and package their application as an AIR application, whereas Mozilla Prism applications are created by end users, who take an existing web application and tell Prism to run it.

Finally, and perhaps most importantly, while AIR “leverages a number of open source technologies (including Tamarin, SQLite and WebKit) and [Adobe] actively participate in both of those development communities, and [Adobe] have been open with our development process for some time” (quotes from Mike Chambers’ blog post), Mozilla Prism is itself an Open Source project (Mozilla Public License).

What this means it that if the development community is unhappy with the directions in which Prism is going, they can fork, and take the existing code base in different directions.

Or, working in collaboration with the existing project, they can extend that code base, taking it to other platforms or contexts.

In other words, I’d say the difference isn’t, to answer Mike Chamber’s question, that one is developed by a company (Adobe) while the other is developed by a foundation (Mozilla), but that one consumes and participates in open source (Adobe AIR), while the other is itself fully open source (Mozilla Prism).

That’s not to say Adobe has not been a good open source citizen or contributed appropriately to WebKit, SQLite, and others – I believe they have contributed substantially to a number of projects. It’s just that an implementation which is fully open is preferable, for many folks, to one which is mostly open except for where it isn’t.

I’m surprised that is still so hard to understand.