I wrote a Fire Eagle web service at Open Hack London a few months ago – that gave a nice, mobile-friendly way to share your current location, as stored in Fire Eagle.
Last week, I finally got round to updating my Fire Eagle Guest Pass web service to use the newer OAuth 1.0a.
This got me thinking that I haven’t used it very much since writing it in May… because while it let me share where Fire Eagle thinks I am, I didn’t have an easy mobile-friendly way to tell Fire Eagle where I am in the first place! 🙂
So while I had “how to do OAuth” fresh in my mind, I thought I’d start writing a quick mobile Fire Eagle client.
I wrote it in C# for Windows Mobile. There are a few interesting points in the code that deserve their own blog posts, but first I wanted to quickly show what I’ve got working so far.
Updating your location
The Fire Eagle API provides a variety of ways to update your location.
I’ve tried to use a few of them in my mobile app:
Uploading the Cell ID of the GSM tower your phone is connected to.
The accuracy of this is going to be variable, but it has several benefits such as not putting a big drain on the battery and working even when you are indoors.
Unfortunately, Yahoo!’s database of UK cell ids seems very limited, but even so, it’s a neat approach.
Uploading the phone’s latitude and longitude taken from a GPS unit.
It’s the most obvious approach, and probably the most accurate in many cases.
But it’s a battery hog, and needs you to be outdoors and relatively stationary for it to work.
If all else fails, you can manually enter all, or part, of an address.
If you know the postcode of where you are, this is a fairly quick and easy way of updating Fire Eagle.
You can even just enter any free text, and let Yahoo’s Geo API try and identify the place that you mean.
Finally, I’ve also added the ability to grab the location out of the current appointment in your mobile’s calendar.
Again, this relies on Yahoo’s GeoPlanet stuff to try and parse this into an actual place.
I’ve also embedded my Guest Pass page in the app so you can share your location once you’ve updated it.
Once I’ve figured out how to authenticate with Google App Engine from C#, I’ll do this properly from the app rather than embedding a webpage.
But this will do for now.
Authenticating with OAuth
Since the security threat identified in OAuth last April, OAuth providers have got even more cautious, and the updated OAuth protocol is even more burdensome than before.
It’s clunky, but to authenticate my app (without giving me your Yahoo! username and password) I’ve had to do the following:
First off, the app needs to send a request to the Yahoo! servers. Tapping on the button kicks this off.
This gets you a token string which needs to be entered into an authorization page on the Fire Eagle website.
To make this a little easier, the token string is copied into the phone’s clipboard, and a button is displayed to launch the authorization web page in your mobile’s default browser.
The user needs to paste the code into the text box and tap Confirm.
This takes you to a verification web page displaying a verify code.
The user needs to copy this code.
This code needs to be pasted into the text box.
The process is then completed by tapping the final “Complete Authentication” button.
Job done.
The user is authenticated, and the tokens are stored so that the user doesn’t have to go through this again.
Ugh
I know that the password anti-pattern is “a bad thing”. Asking for a user’s password on another service isn’t good.
But how much simpler would this authentication be if I could just show the user a couple of text boxes – one for a username and one for a password?
Because as user experiences go, this is fairly icky.
(It was fairly icky to code, as well!)
I know the GUI needs a little work – what I’ve got is a quick-and-dirty first implementation to get the underlying OAuth client code working. And the GUI could do more to walk the user through it.
But even so… the user still has to switch from app to web browser, copying a value across, navigate a website, then copy a different value switching back from web browser to app. This is going to be too convoluted for many users.
Ah well, it was interesting to get to grips with the OAuth 1.0a protocol, and now I’ve got an easy way to update Fire Eagle on the move.
Download
If you would like a copy, download it here.
A few provisos:
- It’s for Windows Mobile 5 (or upwards)
- It’s for touchscreen devices only
- It needs .NET Compact Framework 2 (or greater) – this comes preinstalled on Windows Mobile 6, but on WM5 devices you need to go get it yourself
- It’s the work of a couple of evenings – this was me playing around with code. It’s not a polished or finished product – think of it as an alpha release.
But if all that is okay with you, and you think you might find it useful, you are very welcome to have a copy.
(And please do let me know how you get on with it!)
Tags: fire eagle, mobile, windows mobile
I can’t really test this unless you come out with an iPhone version 🙂
What I was going to say, though, is that I’d agree that OAuth has become somewhat cumbersome. It’s also a pain if you want to access a service secured using OAuth from something headless… I suppose arguably that it’s for end user apps, but what if I wanted to build something (I don’t know, using, say, some kind of messaging middleware broker) which wanted to call an OAuth service – there’s no way to do that token exchange without user interaction.
Another issue is that many sites don’t make any effort to optimise their OAuth screens for mobile browsers, so actually hitting the right fields and buttons can be a pain too.
[…] dale lane fan of all things mobile, father of small girls, IBM code monkey, youth charity trustee… « A Fire Eagle updater for Windows Mobile […]
I understand your frustration. In some ways, perfection is the enemy of the good when it comes to creating secure technologies.
To your point, simply taking the user’s username and password is much more convenient on the surface — and for the majority of transactions, there’s probably little risk. But it’s those cases that occur because someone has become so used to tossing their username and password around where the danger reveals itself.
Fewer approaches are simpler than username and password, but fewer are as susceptible as well — especially when we’re talking about web services and mobile devices.
If you do develop an interface that you think works fairly well, please do share it with the community. Just because OAuth is now more secure doesn’t mean that it’s any more usable for end users — and sharing best practices is the only way to improve the state of the art.
Chris – Many thanks for your comment. You make a good point – the way to address the usability issue isn’t to revert back to using usernames/passwords, but to improve the usability of OAuth.
[…] I wrote a post a couple of weeks ago in which I whined about the difficulties in creating a good user experience for a mobile client that authentica…. […]
Hey – I work on the fire eagle project and we’re going to have a look and see if there’s anything we can do to optimize this experience for you a bit more. You have my complete agreement that it’s not ideal…
Congratulations on this great app – very well thought through, and a clean and efficient implementation. Two things:
First, completely agree with your sentiment towards the OAuth process. I am a software developer myself, and even with my high level of tolerance towards all things technical, the whole process seems ridiculously convoluted.
What would probably work better was if I could create ‘throw-away’ passwords at the service’s website (in this case FireEagle), which I can then enter at the related service (bLADE Locate) one time. Or until I revoke them.
Second, the GPS and Cell ID updates fail. As for the cell ID, it’s probably because I am using the app from Germany, and from your description above it seems you are checking against a British list of cell IDs only. Any information on where you got that list? How it’s updated? If and how an international list could be included? As for GPS, could it be that the lon/lat information is somehow sent out in a wrong format because of my mobile phone having German settings (most notably using ‘,’ instead of ‘.’ for decimal numbers)?
Markus – Thanks very much for your comment.
The cell ID location is provided by a Yahoo API. I’m not sure how complete their database is outside of the U.S. to be honest 🙁
There are alternatives, such as OpenCellID that let you update the database, however.
Hi! I’m the developer of a Fireeagle-based application, Shhpot!
I’m looking for updaters that I can suggest to my users, as they are quite disappointed by the scarcity of good updaters.
Can I include yours in a list of “cool updaters”? Feel free to contact me via my website http://www.shhpot.com to confirm that the project is still “alive”.
In the meanwhile, you may want to give a look to the solution we are currently using, which is the integration between Shhpot! and Navimote http://www.shhpot.com/navimote.php
This way your position is updated using cell towers and nearby access points, thanks to a small app that run in the background and only wakes up when it is queried (via push technology).