I’ve just released the first preview release of Ubiquity 0.2, which implements some of the functionality outlined in the Ubiquity 0.2 Architecture Proposal.
In particular, we now have support for something called Feed Plugins, which makes it possible for Ubiquity to draw from a much wider range of functionality: imagine, for instance, if end-users saw Greasemonkey and CoScripter scripts no differently from standard Ubiquity command feeds, and used the exact same interface to subscribe to and use functionality that’s been implemented with any number of web technologies.
Until now, including a command script on a page has involved putting the following in the <HEAD> element of a web page:
<LINK REL=“commands” HREF=“myfeed.js”>
A feed plugin is triggered by the text in the REL attribute above; in this case, the value commands tells Ubiquity to use what we’re now calling the Default Feed Plugin (DFP), which is the one that Ubiquity users and developers are familiar with. But with version 0.2, we’ll be able to create all sorts of new feed types, which will allow us to not only hook into pre-existing scripting technologies like Greasemonkey, but also experiment with a variety of security models.
As I’ve written about before, one of the big issues confronting users of Ubiquity and other generative tools like GreaseMonkey is that of how to trust functionality. I don’t know exactly what the answer is, but I think that one great way to find out is by empowering people with the tools they need to discover it together.
As a proof of concept, I spent a few hours today creating a Locked-Down Feed Plugin (LDFP), which has syntax reminiscent of the DFP but is intended to be completely secure. While DFP feeds have the ability to do whatever they want to your computer, LDFP feeds actually have less freedom than web pages: they can’t even make outbound network connections. While they can effectively modify your current HTML selection, any HTML they inject into a page is decontaminated by the excellent HTML sanitizer created by the Caja project to ensure that cross-site scripting attacks aren’t possible. I’ve written a sample LDFP feed that showcases some of its security and functionality; if you’re familiar with JavaScript, take a look at its source code.
Since LDFP feeds are capable of so little, clicking on the Subscribe button when visiting a command feed doesn’t result in the terrifying warning of doom that’s shown when you subscribe to a DFP feed from an untrusted domain. In fact, clicking the button just results in an unobtrusive notification message confirming your subscription. This is clearly a win for the end-user, since it makes subscribing to functionality as painless as visiting a webpage.
Of course, with this security comes less freedom, so it’s not possible to be nearly as creative with LDFP as the Ubiquity community has been with all the DFP feeds it’s created over the past few months. My guess is that the real solution to the problem will be at least twofold: strong technical security—perhaps an object-capability model as some have suggested—to help individuals with technical expertise make decisions about what functionality to trust, combined with a social web-of-trust model that helps both technical and non-technical users delegate their decision-making to individuals that they have a high degree of faith in. It’s my hope that the Feed Plugin mechanism will help us explore this and many other ideas.
The Feed Plugin API is still in flux, however, so we haven’t yet written any documentation for it. The source code for the Locked-Down Feed Plugin itself is fairly short, though familiarity with JavaScript security and XPConnect wrappers can help one understand it, but feel free to take a look at it if you’re really eager. Look for a solidified, documented API and a final release of Ubiquity 0.2 in the next few weeks.
In he meantime, if you’d like to try it out, feel free to download the latest Ubiquity 0.2 preview release; if you’d like something more stable, we just released Ubiquity 0.1.3 yesterday.
As always, you’re welcome to drop by #ubiquity on irc.mozilla.org or visit the ubiquity-firefox Google group if you’d like to contribute or ask any questions.