Ramblings in Utopia

If I Designed It - Android Browser

Fri, 02 Jul 2010 14:28:56 -0700

The start of (hopefully) a series of posts describing little user experience/design tweaks I'd make for different objects/applications/services. Starting with the Android browser and Google login

I've been meaning to start a new blog (yes, another one) to start gathering my thoughts about user experience, usability and design of things I use every day, mainly of a technical variety, but about anything from mobile applications and web services to toasters and TVs. Some might be big things, others small tweaks that would make my life just a little more pleasant.

In case there are any industrial/UX designers at Google or other huge company, let me just say, the ideas I'm publishing here are there for the taking under the same license as all my other posts, Creative Commons, except these will be licensed without the non-commercial restriction, so feel free to take the idea and build it into your products.

The real post

This first post is centred about my mobile, Google's Nexus One. To be more specific, it's about Android's bundled Browser when used with web services requiring a Google account to log in.

My suggestion is small, but I think it would improve the user experience. When I choose to log into a web service using my Google credentials, I'd like the browser to trigger an intent which would cause a dialog box asking me whether to use the credentials already stored in my device. The browser would then take back control and the web service would load the logged-in page, as if I'd returned from the Google login page.

Another bonus of this could be an 'always do this' checkbox on the dialog which would then automatically process the login without showing the Google login page and without even showing the dialog.

Further bonus points would be awarded if that 'always log me into this service with this account' type of option would store an indefinite session handle (securely) and use that to keep me logged into services, without the need to even click the 'login' button on the site ever again. The options for forgetting the logins (think like OAuth tokens) could be accessed through the normal Accounts settings.

Think the idea's good/bad? Think I've missed a trick? Express your thoughts in the comments

Android App: Conference Call Dialer

Fri, 04 Jun 2010 15:34:56 -0700

After a week of my first android application being in the Market, an introduction to the app itself.

My application has gotten off to a great start in the Android Market. Over 100 downloads and over 65% active installations. So, what does the app do?

Well, it's a pretty simple application in the grand scheme of things. It just stores sets of numbers in a database, displays them as if they were contacts. The numbers relate to conference room numbers and PINs, and with a single tap on an item in the list, the phone starts dialing the preconfigured conference switchboard/bridge number and types in the right numbers to access the room, including pauses and hash key presses.

I haven't taken any screenshots of the app, since it's not very pretty, and it really is pretty simple, but I may add some more with later versions if I add some more complex elements.

Like many small applications, I made it to 'scratch my own itch', so that I wouldn't have to add several 'voice conference' contacts to the standard Contacts app, instead I could keep a completely separate list dedicated to conferences.

You can get information about installing the application over on my new Android microsite.

For anyone wondering, the test conferencing system (which is the only one I can currently say it works for consistently) is Elisa Finland's voice conference service. The numbers are completely customisable though, so don't let that stop you trying it out, it should work fine with your provider too.

The code is released as open source, and you're welcome to take it, use it in any way you like, and if you make any good additions to it, let me know and I'll put them in the official release. If you don't know how to code, you can still suggest new features, or tell me about any bugs you might encounter

Experiences coding for Android

Mon, 31 May 2010 16:11:48 -0700

Having had a Nexus One for about a month, I've just released my first small application and now I'm reflecting on the experience.

After being a Nokia fan for over 10 years (and employed by them for a few years too), it was a sad day when I retired my E71 to being my new 'backup/roaming phone'.

As I mentioned in a previous post, I was confused about which direction to go, but having played with the Nexus One my girlfriend got free as an attendee of Linux Collaboration Summit 2010, I couldn't resist... the draw of the applications was too great.

Having battled with the Maemo and S60 development kits before to no avail apart from a couple of days of headaches while attempting to follow the tutorials step-by-step, I thought I'd never get to grips with mobile coding, especially as I hate Java too.

Enter Android, a Java-only development environment that I've actually been able to get stuck into. Ok, I may have been eased into it slightly by having 2 months in the San Francisco Bay Area on a work project, spending 2 months picking up Java and OSGi architecture, but I'm still surprised I've managed to be so productive with Android's development kit.

I hope I'm not misunderstanding too much when I say this, but the concepts of OSGi that I picked up while in America have helped me appreciate the modular approach of Android development, and looking at many of the applications I've installed, it seems strange to me that so many applications have implemented the same core tools (eg. Barcode scanning), even if they're using the same library (eg. ZXing), rather than just calling for the central application to do it's job and pass back the information it gathers.

Now, as far as the documentation goes, it's a little step up from the standard Javadocs I used to see, but it's still not amazing. For a relative Java newbie it's sometimes hard to tell how exactly I have to use a particular piece of code, of how to get hold of the data I need to pass in as parameters (eg. contexts), and occasionally not realising that I need to implement an 'on...' method within a particular class. Once you've worked your way through those hurdles though, it's pretty surprising how productive you can be.

I first started with a couple of harder pet projects (having decided to skip the tutorials all together), got stuck pretty quickly in web-services stuff, and finally decided to do a more simple application to ease myself in slowly. In around 3 evenings, using the Notepad tutorial as a quick-reference now and again for the basics of SQLite usage, I've managed to build and publish my first Android application, but that'll be mentioned in full in my next post.

After my limited experience of attempting to begin developing for S60 (Java and C++), Maemo, iPhone and Android, I would say that Android is one of the quickest things to get up and running with. Couple that with the cheap $25 one-off fee to enter the market, and you've got a winner. Maemo (now MeeGo) would come a close second, but the limited amount of non-Linux development tools kind of lets it down... not that I'm advocating Windows for development, It would just be nice to be able to develop on my Macs rather than having to boot into Ubuntu.

I've created a new section of my site, dedicated to being my little slice of the Android Market, where I can place more details, more screenshots/screencasts and details about the open source applications I develop, so I welcome any critiques, reviews, comments and suggestions for things I should build next.

Paying customers not enough for CounterPath

Wed, 24 Feb 2010 16:22:32 -0800

CounterPath, developers of the X-Lite Voice-over-IP client announced on their forum that just having paid for their software wasn't enough to make them add a necessary, small feature.

A feature of any mobile phone (at least the ones I've used) within the last 10 years has been the ability to program pauses into the number. This is useful if your contact is in an office behind a PBX (company exchange system), so you need to dial an extension number after the system has answered the call. The pause for mobiles is usually displayed as 'P' for a short-pause (around 2 seconds) and 'W' for a pause until a key is pressed (useful for long voice prompts before input is allowed). Computer modems have also had the same feature. By typing a comma within the dialing number it automatically substituted each one for a one-second pause.

Since Voice-over-IP has the ability to call normal numbers, this feature is also required, and some clients do accept it, but CounterPath, the developers of X-Lite, eyeBeam and Bria (possibly the most popular VoIP clients), have decided that they're not going to implement this common feature into their applications. Not only are they denying the free X-Lite users, but also the paying customers of Bria and eyeBeam.

After several forum posts about the missing feature, CounterPath employee Derek Jacobs (supposedly part of the support team) gave very blunt answers (if at all) to each of the threads, simply informing them that the feature doesn't exist, and in one even telling them that "it simply isn't possible".

In that thread, after I and another user replied with technical reasons why it was a simple feature request, Derek Jacobs, wrote the following, more length reply:

I'm sorry; there are no plans on adding this feature to retial builds at this time.
If you interested in a bulk purchase of a custom branded soft phone, this sort of feature can be provided.

Please contact sales at counterpath dot com for pricing.

Reading the response I didn't know whether to laugh or just be shocked and amazed by the naivety of the statement.

First of all, telling paying customers that their money isn't good enough to warrant a simple feature addition surely isn't a nice message to send out - you surely wouldn't put that kind of statement on the packaging "sorry, you don't get this feature unless you buy in 'bulk'".

Secondly, their 'bulk' deal (requiring a chat with sales) must be more than their standard on-site price list, which lists discounts for 100+ licenses, so how many is considered 'bulk', 500+, 1000+, or maybe even more, I wonder?

I can see why they might want to withhold that kind of useful feature for paid versions of Bria and eyeBeam, so wouldn't include it in X-Lite, but being told that it's only on the roadmap if you buy in bulk is poor.

Quite quickly after my forum reply this evening, Derek responded, seemingly back-peddling slightly to try and make the wording sound less harsh:

I think you misunderstood
We are not witholding anything.

What I was saying is that if it is important to your organization and if you are considering the bulk purchase of a branded soft phone that we will work with you to include what you desire.
Such a feature as you describe would would be considered custom engineering specific to your needs.

Whilst I can see where they're coming from in terms of seeing this as possibly a quite business-centric feature (although I disagree with this viewpoint). I can therefore see why they want to keep it at the bottom of their roadmap unless they have a larger customer willing to sponsor the development. I just can't help thinking this is doing them more harm than good, when people who have paid for a license of their software miss out simply because of poor judgement of whomever decides on roadmap features.

It's probably worth saying that I have used X-Lite in the past, and that I was looking at purchasing Bria because of the video calling feature as well as support for Linux as well as Windows/Mac, but I had to check from the forums that it supported pauses in dialling before shelling out the money.

Am I being too hard on them? Is this feature really just a corporate-user feature? Let me know your thoughts in the comments.

The Nokia fork in the road

Tue, 16 Feb 2010 09:42:08 -0800

I've been a Nokia user since around 2000, Nokia fan since 2003, Nokia(ish) employee since 2004, and now I seem to have reached the fork in the road with their devices.

Let me be clear before my rant, I don't work for Nokia anymore, I work for Nokia Siemens Networks, which is completely split from the motherships of both Nokia and Siemens. I'm just a normal consumer at this point.

My device ownership path has been:

Philips Saavy C12 & C13
Nokia 3310
Nokia 6210
Nokia 5140
Nokia 6680
Nokia E70
Nokia N95
Nokia N800 - My current internet tablet
Nokia E71 - My current phone

I even still have all the phones, mostly in immaculate condition, or at least as good condition as I got given them (the 6210 was a temporary phone). The 6680 was my favourite, and I'll always have a soft spot for it's rock-solid stability, both in hardware and software respects. The E70 is probably my least favourite one, having far too low memory for what it needed to do, although having a higher resolution screen than even some of today's top-end devices. All in all I fell in love with S60 and the fantastic applications that most developers created for it.

So, now I've presented the backstory, here's my quandary. I'm quite happy with my E71 for now (I haven't had it for all that long), but I'm already wondering about the next device, and the options are so vast, and also potentially isolating that I'm confused.

I still love Nokia and their devices, and would like to stay with them if at all possible, but I'm not going to be stupid enough to back the wrong horse again (my parents backed Betamax in it's day, I recently backed HD-DVD, I've been stung enough). My current choices are (in no particular order):

Symbian S60v5 - Nokia 5800, N97, X6
Nokia Maemo 5 - Nokia N900
Android 2.1 - Nexus One

Ok, so why no iPhone? I'm a Mac fan, but like many others I see the iPhone platform as an artificially crippled device because of the lack of openness of Apple.

Being a Nokia fan my eyes are glancing more in the direction of the N900 or maybe the N97, but I'm also a big user of online services, and what I'm seeing happen on a lot of sites now is a lack of Nokia-based platform support. This is mainly due to the low usage of Nokia devices within america (with a focus on San Francisco), but if there's where most of the popular web services are coming from then I guess they get to weigh quite heavily towards their chosen platform.

Maemo

With the release of the N900 it all seemed like it was going to change, and it still might a developer fan-base, and I hope it will be big enough to succeed, but then there's another issue... right after announcing the N900 they let slip that this wasn't going to be the top of the line Maemo device for too long, as Maemo6 would be released in the not-so-distant future, and the N900 wouldn't suppor it. Now, I don't think I'm the only one this rang alarm bells for, and I think it might have caused developers some confusion too, about the investment of developing for a soon-obsolete platform and device.

Add to this the latest announcement from Mobile World Congress 2010 that Maemo will be merged with Moblin to make a single platform called MeeGo, the future of N900 seems destined for a lonely existance as the only Maemo5 Device.

Symbian

So, in this category of device we've got the resistive touch N97/5800 or the capacitive touch X6. Although I like the look of the capacitive touch devices, the X6 doesn't use it to it's full (multi-touch), so the benefits are a moot point. The N97 itself looks and feels wonderful and solid, and between the N97 and the N900 it's almost just a choice of platform, at least to me.

Since I'm using an E71, I see the S60v5 applications floating around, but not too many. They do seem to be becoming about as common as the S60v3 versions of applications, which is a good thing. It's also got the WRT widgets though, which seem quite easy to develop, so maybe I could make all my own content if I was that desperate for something. Again, the issue of new social web services not supporting it is a downside, but at least from what I've noticed, the N900 seems to have gotten more buzz around it than the N97, so maybe that's enough to kill it for me.

Even if you neglect the current state of applications and hope for the best for the future, there's yet another platform redundancy issue... Symbian^3 was just announced at Mobile World Congress 2010, and that might spell the end for future S60v5 devices (apart from those already in the pipeline). It's less of a shock than the MeeGo announcement, as we knew the Symbian acquisition was aiming for a converged platform from the pieces of the contributing companies, and if history is anything to go by the shift to shipping purely Symbian^3 devices might be as late as 2012 or 2013, with the first devices probably being shipped early 2011, which is quite a long time to be left in limbo as a developer wondering when it's safe to develop for the platform.

Android

Naturally, this is the platform I know the least about. I've touched an HTC Magic, and liked the feel of the device, as well as the interface. It would take a bit of getting used to, but I'm sure I could get used to it.

For applications, I'd say it on par with the iPhone for the things I need/want, but I'm a little confused about whether I have to look for applications specifically produced for a particular version of Android, are all android applications cross-compatible with the various platform versions?

So...?

To be honest, I'm torn between the N900 and an Android device. Symbian has lost most of it's spark from an applications point of view, at least until they come out with a new flagship device. I like a hardware keyboard (my experience with the N800 on-screen keyboard isn't good), and for that the N900 one would do nicely, but then again, the Motorola Milestone (The Droid in America) has one, but I don't know if I like the look of the device overall (even neglecting the fact it's a Motorola device). On the developer adoption side I know I should be leaning towards Android, but I love the look of the N900 screen and UI a lot and know that apps could look great on it.

Any thoughts? I'm open to good arguments either way.

Energy consumption monitoring with Vera

Fri, 30 Oct 2009 16:30:05 -0700

Having purchased a Current Cost home energy monitor, finally I've gotten round to ordering the USB cable, so I can see how it works with Vera.

Vera

Vera is my home automation master controller, produced by Mi Casa Verde. It's basically an Asus wireless broadband router with a custom OpenWRT firmware installed, but it has the added benefit of 2 USB sockets, one of which is used to connect a Z-Wave controller stick.

Having the Z-Wave controller connected to the router means that, with their custom web UI (which I'm not too fond of) I can control the z-Wave capable devices around my home.

The marketing all points to Vera helping a household keeping their energy usage under control by remotely monitoring and controlling the devices in your home. For instance, you can set it to send you an SMS if it's a weekday, at a time you're supposed to be at work, and certain devices are on.

That's where the Vera falls down. It tries to keep track of how much energy each device uses, but the information needs to entered manually, so is time consuming, and not very accurate (do you know exactly how much energy all your devices use?). It also doesn't take into consideration devices which you aren't controlling Vera (Z-Wave plugs aren't cheap).

Current Cost

Enter Current Cost. A device costing £40, coming in two parts, a transmitter & clamp and a remote display. You place the clamp around the power cable going into your electricity meter and by the power of induction, it magically measures the electricity throughput. From reading a few forums they're not 100% accurate, but it's a lot more accurate than guesswork/Vera and would give an overview of the total consumption, not just certain devices (although now they also sell device monitors to use in conjunction with the same remote display).

The most interesting part (for me) of the Current Cost offering is the opportunity to buy a USB cable for it (although not standard USB) and connect the display to a computer to take a stream of information from it.

Although there's no official driver for Linux, Paul Mutton put together some nifty scripts for pulling the data stream (and Jamie Bennett added a correction for USB).

Since Vera is basically a Linux box, I should be able to make the Perl scripts Paul describes run in some way on Vera. The question would then be how to make use of that data in a sensible way (ie. how to integrate it into the Vera software). Ideally I'd like to be able to trigger things to happen based on time and the reading from the Current Cost unit, so I don't have to have Z-Wave modules for every device (though they'd be the only ones I could turn off automatically).

Desktop shopping app, anyone?

Mon, 12 Oct 2009 08:15:59 -0700

Having started using the Tesco.com API, I'm trying to gauge interest in ways to implement it.

Online groceries shopping is, for me, a laborious process, even with the supermarkets' well engineered sites. I think there could be some benefit in having a desktop application which aims to help simplify groceries shopping, as well as a mobile application, and supporting website for quick access on-the-go.

Some of the main features I'm thinking of are:

Lookup from barcode scanning
Supporting in-store (offline) shopping - Being able to print the shopping lists according to the shelf locations in-store (also transferring to a mobile app for the same purpose)
Rebuy rules - Keeping track of different 'rebuy rules', knowing when certain foods go out-of-data and reminding you to buy them again
Recipe planning - Import recipes and dissect them to work out what needs to be purchased.

I'd be very interested in hearing any other feature ideas that would make your shopping experience better.

Freecycle UK - My opinion on the community's future

Thu, 17 Sep 2009 03:46:23 -0700

The UK arm of Freecycle have been arguing. Having been a (silent) member of the Fenland Freecycle Yahoo Group for a while, seeing a couple of moderator messages about a dispute with the Freecycle founders in the US, I thought I'd take a look at the issue and see what I could come up with as a suggestion for the future.

Now, the UK Freecycle community has been noted as carrying the most 'traffic' compared with other countries, and this dispute with the founders may mean that the groups get shut down, or new moderators from America get put in place instead of the current local moderators (Freecycle say they try to only have people local to the community as moderators).

What I wonder is whether we really need a central organisation of all of this. It seems to me, when I look at other similar communities gathered around a global 'aim', they don't rotate around a central core, but rather go their own direction, as with Linux User Groups (LUGs) which have many different forms and functions, some having social meet-ups, others primarily hosting events and talks.

Ultimately the current Freecycle groups (not counting the new MyFreecycle system) are hosted on Yahoo Groups (which I personally don't like), and the Freecycle.org site hosts a list of links to those groups. In theory anyone could do that, the only thing Freecycle.org have got is the name and the press coverage that makes the term well-known. I think we don't have to worry about that too much though, as the groups will float to the top of a localised Google search quite quickly once enough 'hub' sites and local blogs/press start to become aware of each group.

There are several other sites/groups/terms springing up, including GreenCycle, Freegle, RealCycle, ReUseIt and vSkips, among others. These are run in exactly the same way, listing and linking to Yahoo Groups.

What I'd prefer

I don't like Yahoo Groups, they're hard to read (even with Yahoo's effort of threading the conversations), and generally just a 'make do' solution for most communities that don't have the resources to do anything else.

What I suggest is for some web developers (myself included) to 'come to the rescue' by creating an Open Source project for a framework for hosting the things these communities aim to do... share stuff, and be social. The software produced by the Open Source project could then be installed by anyone wanting to host a 'branch' and the community can join in as they have done before, to a more targeted site. The community could then request new features from the developers (or build it themselves and contribute to the project), and after some time everyone will benefit.

The Freecycle Trademark

To get around the current strict monitoring of the Freecycle trademark I would propose a similar solution to the Linux (and other UNIX derivatives) approach of describing themselves as a UNIX-like operating system, by calling describing the groups as Freecycle-like communities, giving full credit to original Freecycle project, and also serving as a disclaimer that should clear any 'confusion' that has been noted on Wikipedia as a reason for some of the trademark disputes.

To be honest, I don't know if this post will help with any decision, and I know it might not read particularly well, but I'd be keen to hear what people think in the comments.

Choosing a home automation standard

Sun, 30 Nov 2008 14:53:42 -0800

Since I'm taking the big adventure into buying my first home, I thought I'd take my mind off it by looking at gadgets to furnish the future home. Automation is something I've been waiting years to start looking at properly.

Having taken a look at different standards several times in the past, now I'm seriously considering which standard I should settle on I'm getting slightly confused. To help me cipher this out I thought I'd start by documenting the process, and the first thing to do is to understand the different standards that I've got to choose from.

Standards

X10 and Domia

Possibly the most widely known standard, X10 works both by using the ring-main circuit to communicate, as well as having RF modules which can be used to interface with remotes. DomiaLite is a very similar (not sure if it's compatible) standard, but the same inventors.

The down-sides of X10 seem to be:

No real security - Anyone with an X10 remote can control your stuff
A bit too basic - The mechanism used is very simple and has the ability to be quite unstable. The style of the modules are also not the most aesthetic and pretty bulky.
A limited amount of devices - There are 2 dials on each device which selects the ID of the X10 switch. These two dials have 16 positions, meaning there is a limit of 256 devices. Of course this is quite a high limit but it's something to think about.
Generally, X10 controls do not have manual override controls.

Home Easy

Similar to X10, Home Easy is a simple solution. In the UK it's sold only through B&Q stores (and of course online). The best thing about Home Easy is that the modules are the cheapest of all the types I've seen and are meant for DIYers, so are easy to fit.

The modules are cheap, and although the plug-in units look pretty big and ugly like the X10 ones, the light switches look similar to those of C-Bus. Comments I've seen say that, like X10, they're not the most reliable and repeaters might need to be placed around the home to make sure the signal reaches ever device.

C-Bus

A considerably more complex standard and one of the best looking solutions.

From what I have been able to figure out, it seems that C-Bus runs using Cat5 cabling, but cannot run off your home LAN. It appears to be a little sensitive to load on the line as they have 'burden' units (small resistors) that may need to be plugged in along the way. It also seems that the system is controlled centrally, so might be harder to retro-fit into existing buildings. I hope someone can give me a little more info on this, as I have had a hard time understanding the intricate details of C-Bus.

The best thing about C-Bus is that it works in a similar way to ZeroConf computer networking. The units obtain unique IDs and the light switch units act as individual buttons, each programmable.

Although I would love to have this as an option, I don't think this is a feasible option, at least for my first attempt.

Z-Wave

The more I look at this standard the more I like it. Firstly, Z-Wave is completely wireless, so it's very easy to retro-fit. Each module is a repeater, and the system uses any route possible to get the message from the remote to the final destination module, so it seems a lot more stable than both X10 and Home Easy.

Secondly, the Logitech Harmony 895 remote is compatible with Z-Wave, so the aesthetics for the remote control are the best of all the standards I've seen. The plug-in units are a similar size to the X10 ones, but at least feature a manual override switch.

Rako

Like C-Bus, Rako seems like a 'professional' solution which would be quite hard to retro-fit. Pretty much all of the modules need to be wired-in, so again, it doesn't look too feasible for my use, at least to begin with. I'm not going to look too much into this as there doesn't seem to be too much info that I can find easily.

Price comparison

Another crucial thing for me is the price of each module. I haven't seen any price comparisons around, so I thought I'd create one. These prices are for UK plugs and wiring, in case that matters to you.

Standard	Plug-in appliance	Plug-in lamp	Single light switch	Wireless Gateway	Remote control	Computer Interface
X10	£17.61	£19.56	£17.12	£23.00	£13.80	£80.44
Home Easy	£9.98	£14.98	£39.98	n/a	£39.98	n/a
C-Bus	n/a	n/a	£92.50	£117.30	£143.75	Discontinued
Z-Wave	£34.50	£34.50	£46.00	n/a	£46.00	£50.60

For the modules above I didn't see that I could include Rako. Even C-Bus was hard to find relevant modules to list.

Conclusion so far

As ever, comments are very welcome and appreciated. My current thought is that Z-Wave would work best, but I'm yet to research fully into which modules I can't find in ZWave that might change my opinion.

Next I will be looking at the specific uses of Z-Wave (unless someone gives me a reason to choose something else), including the available module types and control software for Windows, Linux and OSX.

Firefox Security, in need of an overhaul?

Mon, 17 Nov 2008 19:34:33 -0800

With the rise of addons, Ubiquity, and general saved passwords in Firefox, is the Password Manager in need of an overhaul for the modern web?

If you save passwords in Firefox you may have noticed (if you ever venture into the depths of the password manager) that for some services you have multiple occurrences of the same login details, with slight variations on the access method. A could of examples:

For a hosting account you could have:

Control panel accessed through a specific port on the server
SSL access to the same control panel
Webmail for the account accessed on another port
SSL access to the same webmail

For a site like Delicious you could have logins for:

http://del.icio.us
https://del.icio.us
http://api.del.icio.us
http://www.delicious.com
https://www.delicious.com
http://api.delicious.com
Additional entries for Extensions and Ubiquity commands (eg. my one) that use the API and store the password within the prefs (about:config) as well as with random names within the Password manager

Each one of those logins could have your 'old' password saved, so would show you the dreaded 'wrong username/password' message when you accept the auto-filled password, as they are not synchronised with each other.

The reason these are not synchronised is because the web was once a simpler place and saving passwords was just a time-saving thing with no real thought put into designing the user experience.

The massive Password Manager security hole!

Something that really surprised me, or rather, shocked me, was when I found out that the password manager is a free-for-all. The interaction between extensions and the password manager isn't actually managed or secured in any way. Meaning that any extension can access any password! or in deed ALL your passwords with one easy command (they can even clear them all with one command too).

As far as I'm aware this is the case even if you have a master pasword set... once you've entered your master password the extension has full access to your login details.

So what should be done?

Well, firstly, I stumbled into this while making my Ubiquity command and having contributed a patch to the Ubiquity project about naming conventions for passwords saved through Ubiquity. The comments started on the Trac ticket and continued on IRC (read the full transcript):

[23:42] fern: but, using the password manager is a security risk
[23:42] dsample: oh?
[23:42] dsample: how so?
[23:42] fern: any ff extension can just get all your password and email it to anyone
[23:42] dsample: at least if you have 'master password' enabled it all gets encrypted
[23:42] fern: and if you don't?
[23:43] dsample: hmmm, there's no protection from doing that?
[23:43] fern: well, im doing that right now. im getting my own delicious password from the password manager.
[23:43] dsample: well, if you don't use master password (I don't either) it saves it all in plain text, just like the prefs file
[23:43] fern: i could email it to you, for example
[23:43] dsample: hmmm
[23:44] fern: as i said before, password manager is a security risk.
[23:45] dsample: hmmm
[23:46] dsample: has anyone attempted to look at this in the past?
[23:46] fern: i.e. ?
[23:46] dsample: I noticed that the nsPasswordManager of whatever stuff said it hadn't been touched since 2001, is that true?
[23:46] Unfocused: i see being able to use retreivePassword('anyotherverb') as a GOOD thing - users shouldn't be asked to enter their login info more than once for the same service, if two commands use the same service
[23:46] fern: yes.
[23:47] fern: Unfocused: that's true.
[23:47] Unfocused: and actually, most cases the login info should be accosated with a service, rather than any specific commaqnd
[23:47] dsample: Unfocused: true, but then the 'verb' shouldn't be the verb, it should be the service
[23:47] dsample: and password manager should be saving 'service' passwords rather than site passwords
[23:47] fern: like, delicious or jaiku
[23:47] Unfocused: i have a draft blog post on this topic, actually - i should get around to finishing it
[23:48] fern: we can start that, but how?
[23:48] dsample: then it could use the same password for the http, https sites as well as any extension
[23:48] fern: that == save service passwords.
[23:49] dsample: do you think we could create a parallel to Password Manager, maybe a Service Acount Manager?
[23:49] fern: well, we can use the password manager infrastructure to do that.
[23:50] dsample: but let's face it, the UI sucks for that kind of use
[23:50] fern: yes
[23:50] fern: for sure
[23:50] dsample: at least if we were to do it properly
[23:50] fern: but we can use it for now..
[23:50] dsample: I don't think it would be hard to create an addon that replaced password manager with another database
[23:51] fern: ummm..
[23:51] fern: use a sqlite database with cryptographed passwords.
[23:51] dsample: we 'could' use it for now, but then how would be integrate for example the 'delicious' password so that it auto-filled for http as well as https for example?
[23:52] dsample: (at the moment they would be stored as 2 passwords)
[23:52] fern: two urls.
[23:52] Unfocused left the chat room. (Quit: )
[23:52] fern: but its ugly as hell
[23:53] dsample: so we'd need to make something to add every combination of a service's URL and save them all?
[23:53] fern: urgj
[23:53] dsample: exactly
[23:53] fern: that's really ugly.
[23:53] fern: imagine? ftp, http, https
[23:53] dsample: which is why I'm thinking it would actually be as easy, and MUCH nicer to the user if we just replaced the password manager properly
[23:54] fern: but that's not easy
[23:54] dsample: yeah, then extensions have to find the right one for their use, etc.
[23:54] dsample: not easy, but we should be thinking about the User
[23:54] fern: yes..
[23:54] dsample: if we stop thinking of the user then we're building IE
...
[23:59] dsample: but then saving your passwords anywhere has that same issue
[00:00] dsample: which is why we need a new password manager
[00:00] dsample: one with security built around it
[00:02] dsample: My opinion would be that the password manager should be an encrypted 'box' of it's own, and anything that wants to use it should have to authenticate. Maybe using OAuth
[00:03] dsample: So the extension's API Key would be used to work out if it's a genuine extension and to provide the user with details about it so they can make an informed decision
[00:03] fern: yes
[00:03] fern: like a security certificate
[00:04] dsample: yes, but the problem with security certificates is that they're not free
[00:04] fern: yes
[00:04] fern: but for us, a security certificate would be a "mozilla certificate"
[00:04] fern: or a community certificate.
[00:04] dsample: with something like the addons.mozilla.org publishing process it could automatically check within the code for accesses to the password manager and make sure it's identifying itself properly
[00:18] dsample: hmmm, now I'm sketching I'm wondering... how would we define a 'service' without requiring every site developer to provide some sort of mapping to their different access-points
[00:19] fern: requiring some kind of metadata would be not good
[00:19] dsample: ie. how would we be sure that https://delicious.com should actually use the same password as http:delicious.com
[00:19] fern: yes..
[00:20] dsample: unless we require the addon developers to do that part of the work
[00:20] fern: umm.
[00:20] fern: how?
[00:20] dsample: or... would we need to create a new community site for linking and 'configuring' the 'service manager'?
[00:21] fern: that would not be ideal
[00:22] dsample: perhaps if it's flexible enough it could save passwords for sites while they're 'orphans' but when they are included in an established 'service' through the site then it changes from a site to a service and merges any of the passwords they had saved for any of the access-points into one unified account detail?
[00:22] fern: good point. really good.
[00:24] dsample: if it advances the browser into a more... dare I say it... web 2.0 way, then maybe it's worth it

So, in case you skipped reading above, basically the result was that the Password Manager really needs a redesign to make it store paaswords for services rather than sites.