As I spend more and more of my free time digging around in reptilian mailing lists and such, I find that I’ve begun feeling itchy. Here are four little itches that might be interesting for someone to scratch, micro-projects if you will:

Pass Files through NPAPI

Plugins like Adobe flash and Yahoo! BrowserPlus often implement their own native file selection dialogs, and (in the case of the latter), native drag and drop support. Especially as e10s takes off, this is fragile code at best, justified because improved file selection and dnd support are both of high value to users.

What should happen is UAs should (and are) implementing improved file (multi) selection and file system sourced Drag and Drop, and then should be able to securely transmit these files through NPAPI, in such a way that the plugin author can know that the file was selected through user interaction, giving her implicit permission to read the file selected.

I wrote up my initial thoughts on this a while ago, what needs to be done is a proper proposal needs to be figured out, fleshed out, and perhaps a patch provided. Doing this would improve plugin security and stability as well as UI consistency for all plugins that operate on files.

Explore Simplified web Scriptable API exposure in JetPack

There is a class of extensions/jetpacks that will want to expose scriptable APIs to webpages. This class of jetpacks is especially interesting to me, as it becomes a way that many new proposed “HTML5” APIs can be sketched up at (for instance, see the checksum project idea below). Currently it looks like you have to bend over backwords to make this work: Two functional solutions were provided by Atul and Ben, neither of which are particularly satisfying.

There are two parts to this problem, one is crafting a specific API in the context of the evaluating page, and the forthcoming page mod API should provide this, the next is the question of plumbing, an efficient means of message passing between trusted and untrusted code that is e10s proof.

The question: What types of abstractions beyond what’s planned today should be provided to make the process of exposing web callable functions simpler and more secure?

Browser to expose checksums for currently installed plugins

This is from a conversation on plugin-futures@mozilla.org which is motivated by the desire to improve the plugin-check tool. Ryan did a fair summary of the tradeoffs of a “guid approach” (requiring vendors to encode ownership and version metadata in their plugins), vs. a “md5 approach”.

This micro project would be to sketch up a jetpack which adds an web accessible API to get plugin md5, then sketch up the system which collects user contributed plugin identification information. It could take a couple days or a couple weeks.

Key question: How does a system which identifies plugins primarily on their signatures compare from a system that uses metadata embedded by plugin vendors?

AOB on top of git?

There’s some discussion around how users get code into and out of FlightDeck.

One approach to address this need would be to have AOB expose an API that would allow third party tools to read and write the revision history of a project. The other approach would be to have AOB use a DVCS as its backing store and directly expose read or read/write access to that.

Key questions: How viable would it be to move AOB’s add-on storage on top of a DVCS, and expose read (and later write) access? What do you win? What do you lose?