The last couple weeks have seen me make some pretty amazing progress with the new version of Geon. I’ve settled on a name for the service, managed to get a 4 letter TLD to host it under and the Silverlight client has seen a massive redesign that drove a complete rework of the underlying API. It’s been quite a learning experience and I’ve encountered quite a few problems along the way that have served to give me some insight into the issues that the big guys probably had when they were first starting out. Whilst the system currently only has a user of one (well 3, the Anonymous user, myself and a friend’s identity I stole to test out some features) I still got to thinking about the authenticity of my data and how I was going to manage that.
I first encountered this when I was coding up the login system for Geon. Originally it was based around the built in Windows Communication Framework Authentication Servicewhich, whilst being a down right pain to get working initially, provided all the necessary security for my web application without me having to think about how it got the job done. Unfortunately though this wouldn’t work too well when I moved away from the .NET platform, namely to either Android or the iPhone, as they don’t have any libraries that support this. So as part of my complete client redesign I thought it best to not rely on anything that I couldn’t use on my other platforms and that meant building the Silverlight client as if it was a mobile phone.
In all seriousness I would’ve been completely lost if I hadn’t stumbled upon Tim Greenfield’s blog, specifically this postwhich outlined the core ideas for implementing a secure login system that uses RIA services. After doing some rough designs and mulling the idea in my head for a couple weeks I got a working implementation of it a couple weeks ago, allowing a user to login without having to rely on the built in Microsoft frameworks. Initially everything was looking good and I went ahead coding up the other parts of the application thinking that my bare bones implementation would suffice for the use cases I had in mind.
However after a while I began to think about how easy it would have been to a nefarious (or just plain curious) user to be able to wreck untold havok on my system. You see the login function needed 4 parameters: the user name, password, IP address and whether or not this session should be remembered next time the user visits the page. The IP address was for security as if someone manages to get your session ID they could theoretically use that to hijack your session and do all sorts of mean things with your account. In my implementation the IP address was passed up as part of the request which meant that anyone looking to perform a session hijack would simply have to pass up the valid IP for that session and I’d be none the wiser. Realising that it would be an issue I implemented server side IP detection which would make it quite a lot harder to get the magic combination session ID and IP address correct, making my service just that more secure.
This got me thinking about the authenticity of the data which I was going to be collecting from my users. I’m not putting any limitations on where people can post but I’m going to be flagging people as “out of area” when they’re posting or responding to something that’s not near their current location. However since I want to make the API open I have to make the co-ordinates part of the update request which will unfortunately open it up to the possibility of people faking their location. Not that there would be a whole lot to gain from doing so but if my feed reader has taught me anything recently its that the geo-social networking space is constantly grappling with this issue and there’s really no good solution for it.
There seems to be two schools of thought on the idea of data authenticity when it comes to the location space. The Foursquare approach is one of mostly indifference as whilst they have a cheater code to deal with people trying to get that elusive mayor title they seem to have no problem with those who check-in where their friends are or if you create a fake venuefor others to check in to. I’m not surprised at their reaction as both of those kinds of behaviour mean people are using their service and are finding new, inventive ways of using it which could potentially translate into new features for their service. The second is of strict “no fakery here” policy that Gowalla has taken with their 6 commandmentsof their API. Whilst they’re still opening themselves open to abuse the no tolerance policy on it suggests that they value data integrity much higher than Foursquare. Clamping down on fake check-ins would mean that their data is more reliable and thus more valuable than Foursquare’s but that comes down to what you’re using it for, or who you’re selling it to.
Personally I’m in favour of the Gowalla route but only because there’s little value in faking location data in my application. Sure there are potential scenarios where it might be useful but since I’m not placing any restrictions (only identifying out of area people) I can’t really see why anyone would want to do it. That might change when I put in the social game mechanics in and I actually get some users on the service but that’s a bridge I’ll cross when I come to it. Right now the most important thing is trying to get it out the damn door.
I’m hoping that will be soon as once I get the core in I get to buy a Macbook Pro to code on, yay! 😀
