LBS : Could the 5o9inc approach be a solution to the privacy problem for location based services?

If you read my books, I have been sceptical of ‘Location’. In fact, I remember starting a talk with a slide called ‘Location, Location, Location?’. The ‘?’ is not a typo. It’s to say – ‘Where is Location?’(Considering all the hype around it!)

Location based services(LBS) are one of the most useful and intuitive mobile applications. Everybody understands ‘Find my nearest’ and everyone agrees that it is useful to know your nearest restaurant/gas station/ATM etc when on the move.

Understandably, LBS apps have been hyped almost from the very beginning and regrettably, location based services are still(largely) not here with us as mass market applications.

The main inhibitor to LBS is privacy and security.

In the context of LBS, privacy and security has many facets – for instance statutory and legal, working with trusted third parties, encryption of security information etc.

Due to my interest with LBS, I have been having long discussions with Peter Cranstone CEO of 5o9inc – who has been outlining me their product.

I am now fairly convinced that it fulfils a gap within the LBS value chain.I outline their solution(as I understand it) below and I seek your thoughts and feedback.

Leaving aside the legal issues for the moment(which are being addressed by the relevant regulatory body in each country – for instance – laws about protecting minors), there is still the problem of protecting the location information especially in the context of GPS(which is now driving LBS services) : for instance phones like the Nokia N95 now have inbuilt GPS

The problem 5o9inc is addressing is: how to keep the location information(and for that matter any other private data elements) secure between the phone (where that information resides) and the web server(where that information is typically processed).

This is a very real problem which we will hit as GPS and other location based solutions become mainstream

Peter is an expert at security/encryption based applications, having co invented co-invented mod_gzip(in fact, I think the approach they have taken below mirrors the mod_zip approach but in the wireless context)

The solution could work in a number of scenarios:

a) Consumer: between the device and the web server

b) Enterprise with a mobile work force and

c) The Enterprise with mobile customers hitting their web site (search, retail, ecommerce etc).

It works as follows: The client’s data is held in an encrypted database on the mobile device. Every “field of data” that he/she wishes to transmit to the content provider remains under their control. The client side app allows the user to check or un-check the data field that gets transmitted. For instance they can share name, address, phone number, email address and current real time GPS location. If they wish not to share the GPS location simply disable the field. When the data leaves the mobile device and 5o9 applies encryption to protect it during transit. It’s transparent to routers, firewalls, Carrier portals etc. The data then shows up at the web server. It’s unencrypted and then is available for back office applications.


Thus, it functions like a tollgate between the device and the web server.

Physically, the application is a mobile browser plug-in and a web server module

I can see applications for this service both at the enterprise and the consumer level.

For consumer uptake, it is designed to work with parties like device manufacturers, browser vendors or Operators because it does not change the underlying infrastructure (again mirroring the approach they took with mod_gzip).

Thus, it appears to solve a very real problem taking a relatively pain free approach (i.e. not changing the underlying architecture).

Seek your views and feedback on this approach?


  1. Johnny Fry says:

    I really like this approach. But they far from “invented” this model. It’s essentially a pubsub or syndication model. While useful, I can’t say I find it very innovative.

  2. Tomsoft says:

    I see one major issue:
    - this require a non standard plugins in browser
    - this approach works only for browser
    The issue with LBS application is not yet privacy, but more the fact that there is no technology widely deployed to enable LBS. GPS deployment will start only in mass market with N95.
    So I am not sure that the biggest issue with location will be privacy. The biggest change with GPS (compared to other techno) is that now user can choose or not to provide his location to the applications. Do we need another extra layer to do it?

  3. Quick follow up to the the current comments…
    1) The innovation is sending the data as part of the HTTP data stream. Getting GPS data along with other data is really quite simple. Making that data available to any web server is a little more challenging, especially if you consider the privacy implications of sending “protected field data which is encrypted”. That’s not something you can handle with a cookie on a dynamic basis.
    2)The platform works for any browser on any mobile device. We started with Windows Mobile 5.0 and Pocket Internet Explorer. The software has been designed to run on Windows XP/Vista/Linux/Symbian and integrate with the other major browser types. In addition we’re making the client side API’s available for developers to integrate their app and leverage our transport mechanism.
    3) It’s not just about GPS. It’s about any data that you want to send from the device. You can choose to send Zip Code, Area Code, Postal code or whatever. We’re a data transport mechanism. You decide what you want to send to the server. The GPS data can be made available (or not) to any application or any web server. The choice is yours. Another layer is not needed.
    4) It’s all about making life easier for the customer. They want convenience, privacy and control. They don’t want to have to type in data when they use their mobile device. So this makes it easy for them. Also it helps the content provider deliver a better web experience by understanding the terminal capabilities of the connecting device.
    5) It scales to other devices. So now the customer can have a consistent experience regardless of the connecting device. It’s not just about mobile it’s about any device that someone uses to connect to the Web.

  4. farooq says:

    Definitely interesting to see any progress on the LBS front. Yet, I am not sure if this addresses the entire problem due to the following reasons
    1) Firstly, as I understand it, this only addresses the security of the data transfer between the device and the web server. What about the privacy and security after decryption at the web server? Why should i trust the entity managing the server to protect my data? Of course, this problem exists even now since carriers such as Cingular and T-Mobile do have and maintain information about my location since they use a network assisted location determination technology to address the E911 requirements. But in this case, maybe I trust Cingular and T-Mobile (given that they are carriers :-) ) but not a startup.
    2) I am not sure how easy it is to get the GPS information automatically into a browser plugin. My understanding is that one needs to write an application such as in Java and use APIs such as JSR 179. And even here carriers such as Sprint have reportedly disabled the relevant location determination API in JSR 179. Verizon on the other hand requires an expensive approach since they use the BREW platform for LBS apps–again a disadvantage for startups.
    3) Finally, how does this work with carriers that do not provide handsets with GPS receivers such as Cingular or T-Mobile since they use a non-GPS approach to solve the E911 problem. Probably in this case, the user can enter his location (to any resolution namely, zipcode, street etc) manually but then what does 509inc add in such a case as compared to opening a https connection. Of course , another alternative with such carriers is to force the carrier to share the location information that they have securely but is this doable?
    My apologies for the US focus; probably some of the things are different across the Atlantic. Look forward to the replies.

  5. Ajit Jaokar says:

    thanks Farooq. Interesting questions. Have some thoughts but interesting to see Peter’s response rgds Ajit

  6. Some follow up answers to Farooq’s comments:
    1) The server module installs at the content providers site. The trust relationship is between you and the content provider e.g. . 5o9 Inc is NOT a service. We sell our server side module to content providers looking to deliver a better and more consistent experience to their mobile customers.
    2) There is no need to write anything. 5o9’s lightweight client does all the heavy lifting for you. We’re not dependant on Java. We use the operating system API’s to talk to the GPS over whatever COM/Serial port it’s using. We then stream that data out to the web server. Using this approach we can access external and internal GPS devices. Our focus is higher level operating systems such as Windows Mobile, Symbian and Linux. Also remember that our client solution also scales to the desktop/laptop which are now considered mobile devices (UMPC)
    3) There are several ways to determine location… checkout 5o9 can also use these techniques to determine location. In addition we can also leverage A-GPS if there is an operating system API to call it. We support Area and Zip code and address. ( With regard to privacy: On the device we encrypt the customers private data with 3DES. Data transmitted to the content providers web server is also transmitted using encryption.
    With regard to the carrier question. You cannot force the carriers to reveal customers location information. It’s private. The approach we’ve taken is much simpler. You (the customer) are now in control of the data you want to share with the content provider. You can choose to send a single field i.e. Name, or multiple fields. The carriers are not involved in the process. They provide the pipe that enables you to connect to the Internet. All we do is make the experience easier for you by eliminating a lot of the data entry