LBS Development - Determining Privacy Requirements

By David H. Williams

As the market for location-based services (LBS) rapidly grows, so does the need for more sophistication in their design. Areas such as user interfaces, fixed/mobile integration, and viral networking capabilities are all candidates for further enhancement. But nowhere is the need for sophistication more important than in the design of LBS privacy infrastructure. There are already reports of abuse, such as estranged spouses tracking each other with location-enabled devices, or rental car agencies tracking their customers to make sure they were going were they said they were going.

Add to that the more general wireless privacy concerns among privacy advocates regarding the real or perceived abuses of the federal government and the Patriot Act, and incidents like the HP pretexting scandal, the awareness of and concern about wireless privacy has surged. In addition, the explosion of instant messaging and social networking sites such as Facebook and MySpace have already generated numerous privacy incidents even without location information. In fact, one in seven 10 to 17 year olds who use the Internet have received a sexual solicitation or approach online, according to the National Center for Missing and Exploited Children, which has helped spawn a new niche industry for monitoring kids online.

As online social interaction goes mobile and location is added to the mix, it moves the potential for abuse outside the home into areas with less physical protection and levels of oversite. Nothing would be more detrimental to LBS growth than a privacy disaster, such as a sexual predator using a mobile social networking application to find a victim. And privacy is not just a consumer issue; if LBS is going to be successful in the enterprise market, companies and LBS providers both will need to be sensitive to the privacy concerns of employees as well - no monitoring of employees outside of work hours and responsibilities is essential. In short, if LBS is truly going to be ubiquitous in the wireless world, world-class privacy protection is essential.

It is important for LBS developers to accurately gauge the type of privacy protections required for a particular application and target market. Protections that seem too loose relative to the concerns of their target customers will be perceived with alarm. On the other hand, protections that seem too stringent will be viewed with frustration, particularly if they result in a more complex and harder to use customer interface, and create unnecessary costs during the development cycle, customer signup, and ongoing operations. Privacy requirements will be based on the nature of the application and its potential for abuse. In particular they will depend on the type of interaction involved in using the application. Applications that are single user in a closed environment linked with data sources, such as hotel or restaurant finders or general navigation applications are the most straightforward, requiring primarily opt-in and spam filter protections to prevent abuse from third party providers. It is when applications start to provide person-to-person interaction with location information involved that privacy issues become more complex.

Applications that involve interaction only between family members generally need a relatively low level of privacy protection, as presumably they are the most trustworthy individuals a user can interact with (of course there are exceptions to every rule), whereas those that have the potential to interact with complete strangers need the highest level of protection. The diagram below provides a framework for developers to use in assessing these privacy requirements.

Privacy Requirements Pyramid. Source: E911-LBS Consulting. (Click for larger image.)

All location-enabled applications need a core set of privacy protections, which include adherence to federal and wireless carrier standards, particularly with respect to opt-in requirements and customer information confidentiality. You can read more on this topic published in the Cornell Law School U.S. Code Collection. In addition, applications that focus on family safety and/or involve minors will need capabilities that allow control by parents as to with whom and how location information is shared.

As you move down the pyramid, and potential access to a user’s location becomes available to a broader range and larger number of people, additional privacy capabilities need to be added to the core privacy protections. Adding elements such as busy/not busy or at work/not at work can provide important "presence" information to make sure friends don’t interrupt the user at inopportune times. Business applications such as technician tracking may need to have a capability to disable location tracking during off-hours, or only have it enabled within certain geographies, depending on company needs and privacy policies. Mobile social networking and mobile gaming will need particularly strong privacy protections. Apps that involved online "friends" who have not been met might benefit from "ratings" from other people with whom they've interacted, or elevated warning levels associated with their profile. Mobile gaming that uses location and involves other players will need innovative protections to allow competition yet shield players from actually being found by strangers, such as shifting the reported location of the person or reporting the person's location as an area rather than as a point. Some of these ideas are unique to the nature of LBS, but many come directly from the online world, such as instant messaging blocking/ignoring, status adjustments, warning levels, ignore lists; eBay registration and ratings of buyers/sellers; and "anonymizers" that capture key personal information on matchmaking sites. In short, there are many good ideas already in practice that provide starting points for many privacy solutions.

Developers should not leave addressing privacy until the end of the development cycle, or even view it as a separate, independent piece of functionality. Instead it should be integrated into the core application requirements in order to ensure the appropriate levels of protection and to make it as unobtrusive and convenient as possible for the user. By doing so the LBS provider will provide peace of mind to the customer (and the carrier, if applicable) and provide one more positive dimension to be judged on in the market place, AND avoid potential incidents that could be disastrous for your business and LBS in general.

Published Thursday, October 26th, 2006

Written by David H. Williams

If you liked this article subscribe to our bimonthly newsletter...stay informed on the latest geospatial technology

Sign up

© 2017 Directions Media. All Rights Reserved.