This version demonstrates many of the functions and technologies that will be used as we develop the project further but it’s not much to look at yet.
It may be useful for:

• developers that are keen to learn more about how KeeFox will be architected
• developers that would like to help understand KeeFox in order to help me get it past version 0.1 and on the road to a beta release early next year.
• developers that are interested in seeing how a Firefox C++ XPCOM extension can be built using Visual Studio 2008
• developers with a particular interest in the Firefox 3 nsILoginManagerStorage interface
• people who think attempting to compile visual studio projects is even more fun than eating cake

Compilation requirements and guidelines are on the sourceforge KeeFox project site

It seems as though the authors of the interface had similar ideas:
“For example, if you wish to provide operating system integration with a native password manager system, implementing and registering a storage module for the Login Manager is how you do it.”

I’ve even had a good attempt at implementing this and made some good progress as can be seen in the imminent version 0.1 of the KeeFox source code. However, I have come across a few issues that have made me think about how feasible this is in the long run.

I’m particularly struggling to see how some of the interface definitions can be sensibly applied to a third party manager without crippling the existing functionality that the 3rd party manager offers. This is best explained through an example:

Take the removeAllLogins method. The key points are that any password manager implementing this method must delete all logins from its database without first requiring the user to authenticate with a master password. Notwithstanding the questionable benefit of this feature in the standard Firefox password manager I find it hard to see how any third party password manager would ever be written in such a way that permits this type of action.

Would a user have any hope of understanding that clicking “delete private data” in Firefox will lead to the destruction of their password database in a third party application or native operating system password manager system? This is just one example but I think it’s just one of many ways that the overall user experience could be reduced by the use of this interface for integrating existing password managers.

With that in mind it seems to me that the only option for integrating a separate password manager through this interface would involve disregarding the Mozilla specification which is likely to lead to further confusion for both developers and users. I can’t see how that could be a good idea.

So who might actually implement this interface to its official specification? I suppose that someone may wish to write an extension that stores firefox passwords in a different format or using a different encryption algorithm. Or maybe someone will find some compromises that are suitable for a particular use on an intranet and/or an internal proprietary password management system.

I do think it is an interface worth having and I can see that it will have its uses but my feeling is that it may not quite live up to the full ambitions stated in the official documentation without introducing significant compromises into other aspects of the user experience.

I think I may need to make an early change to my KeeFox plans in order to ensure that the extension provides an alternative to the standard firefox password manager as early as possible. Maybe I could still tell Firefox to send the standard password management requests KeeFox’s way but simply ignore them or tell the user to not use them now that they have installed KeeFox…