CHAPTER 12
Mobile Geolocation
Both mobile and desktop applications are increasingly making use of positional data to provide an improved user experience. Today’s mobile geolocation services are used to geo-tag photos, find or track nearby friends, and to find nearby businesses, among many other things. There is a definite trend towards merging social media with spatial data.
This offers the potential for greatly enhanced functionality, but also introduces risk to both its users and service providers. However, many software vendors are implementing these technologies without knowing the full impact to their customers, and many users are unaware what data is being collected and how it is being used.
In this chapter, we’ll discuss the various methods that allow for mobile geolocation, as well as best practices for both vendors and end users to ensure that these technologies are used as safely as possible. Implementation details vary from platform to platform, but we’ll give you the pointers you need to build working sample code.
Geolocation Methods
Geolocation on mobile devices has grown from being used solely for emergency and law enforcement purposes to being an integral component of consumer mobile applications. Once only performed by triangulation of cell towers, modern mobile OSes have expanded to support retrieval of positional data via wireless survey or GPS systems, giving an enhanced degree of precision and faster update times. Different methods have their own strengths and weaknesses, along with variations in accuracy.
Tower Triangulation
Accuracy: 50m–1,000m
Tower triangulation is the oldest widely used method of geolocation via cell phone. This method uses the relative power levels of radio signals between a cell phone and a cell tower of a known location—this of course requires at least two cell towers to be within range of the user. This service is used for the E911 system in the United States, transmitting location data when emergency calls are made. With user permission, however, the phone can be instructed to transmit tower triangulation data to phone applications.
Because this requires that the user be near to multiple cells, and because signal strength can be affected by many factors, tower triangulation is a fairly inexact method of positioning (see Figure 12-1).
Figure 12-1 Cell phone tower triangulation
GPS
Accuracy: 5m–15m
Using satellite signals instead of cell phone or wireless infrastructure, GPS service is often available at times when other methods are not. However, satellite acquisition is generally impaired when the user is indoors, making the use of GPS alone inadequate for some mobile applications. Additionally, initial GPS location information can take several minutes to acquire.
An advantage of GPS is that it can provide continuous tracking updates, useful for real-time applications, instead of just one-time lookups.
Assisted GPS works by providing an initial location obtained via another means (either tower triangulation or 802.11) to the GPS receiver, to reduce satellite acquisition time and correct for signal noise. This makes GPS somewhat more viable for indoor use; however, acquiring positional data this way still takes upwards of 10 seconds, still making it a relatively slow method.
802.11
Accuracy: 10m–200m (but potentially erroneous)
The iPhone was the first smartphone to add this additional method for geolocation, using an API made available by Skyhook Wireless. This location method works by doing a survey of any nearby 802.11 (Wi-Fi) wireless access points and then submitting data about them (presumably MAC address and SSID) to a web service, which returns coordinates from what is essentially a very large “wardriving” database. This allows for devices without GPS to provide potentially highly accurate location data.
This approach has the advantage of being both faster and much more accurate than cell tower triangulation, but has a couple of drawbacks. Because location data relies on specific wireless APs, if those APs move, location data can be drastically wrong. For instance, the company of one of the authors of this book relocated its offices about a mile away. Because the wireless APs were listed in the Skyhook database, any attempt to use location services near the offices reported the company as being in the previous location, making it difficult to find places to go to lunch. A more extreme example is when attending a security conference in Tokyo, one of the authors’ iPhone 2G reported being in Vancouver, B.C. (the last place the conference APs were used).
The Skyhook software development kit (SDK) has also recently become available for Android, but is not yet integrated in an official capacity. More recently, however, Google launched its “Latitude” service, which provides a newer implementation of Skyhook’s technology, combining all of the preceding methods.
A more extensive evaluation of the strengths and weaknesses of this method can be found at www.techcrunch.com/2008/06/04/location-technologies-primer/.
NOTE
The reader should not take this reference as a general endorsement of TechCrunch.
Geolocation Implementation
Each platform treats geolocation services differently, with different methods of requesting user permission, ranging from asking every launch of the application to leaving notification up to the developer.
Android
As with most services on Android, permission to use the geolocation features is requested via the program manifest and is granted by the user at install time. Either coarse or fine precision can be requested, using the ACCESS_COARSE_LOCATION (for cell triangulation or Wi-Fi) or ACCESS_FINE_LOCATION (GPS) permission (see Figures 12-2 and 12-3). These permissions are requested and controlled separately.
Figure 12-2 A permissions request for coarse and fine location services
The android.location package provides the LocationManager service, which can be called to return both geographic location and current bearing, using the internal compass (if available). Listing 12-1 provides an example of using the LocationManager service in Android.
Figure 12-3 A permissions request for only fine location services
Listing 12-1 Using the LocationManager in Android
locationManager=(LocationManager)
getSystemService(Context.LOCATION_SERVICE);
Criteria mycriteria=new Criteria();
mycriteria.setAccuracy(Criteria.ACCURACY_FINE);
mycriteria.setBearingRequired(true);
String myprovider=locationManager.getBestProvider(mycriteria, true);
Location mylocation=locationManager.getLastKnownLocation(myprovider);
In addition to this, the LocationManager can be used to register for positional update notifications as well as for an intent to be triggered when a device comes within a specified proximity of a set of geographic coordinates. See the locationManager .requestUpdates and locationManager.addProximityAlert methods for more information. It is worth noting that on some platforms geolocation is guaranteed to be available, but there is no such mandate on Android-powered devices.
More information on the LocationManager can be found on the Android developer site at developer.android.com/guide/topics/location/index.html.
iPhone
Geolocation on the iPhone requires user approval every time an application that uses geolocation APIs is launched (see Figure 12-4). The CLLocationManager returns a CLLocation object. There are several constants developers can choose from when requesting locational data:
const CLLocationAccuracy kCLLocationAccuracyBest;
const CLLocationAccuracy kCLLocationAccuracyNearestTenMeters;
const CLLocationAccuracy kCLLocationAccuracyHundredMeters;
const CLLocationAccuracy kCLLocationAccuracyThreeKilometers;
Use the least precise measurement that will meet the functionality requirements. For example, to merely determine what city a user is in, you should use either the kCLLocationAccuracyKilometer or kCLLocationAccuracyThreeKilometers constant.
The method used for geolocation is abstracted and not controllable by the developer, but any combination of Wi-Fi, tower triangulation, and GPS (on post-2G devices) may be used.
Figure 12-4 The iPhone location permissions dialog
Windows Mobile
Windows Mobile has no mechanism for a user to control geolocation API access on an application-by-application basis—all applications are allowed to access this data if location services are enabled on the device, via the GPS Intermediate Driver API’s GPSOpenDevice and GPDGetPosition.
Geolocation Implementation
Responsible developers should require the user to explicitly confirm the enabling of geolocation features. They should also provide an easy interface to disable it. Microsoft provides explicit guidelines for security and privacy for Windows Mobile 6 on MSDN at msdn.microsoft.com/en-us/library/bb201944.aspx.
Note that many WM devices (for example, the HTC Apache) were sold containing a GPS that is only accessible to the E911 service and cannot be accessed by developers.
Symbian
On the Symbian platform, signed applications can access the geolocation API without user interaction. For unsigned applications, users will be prompted upon install as to whether they want to grant the application this capability. Positional data is obtained by querying the location server via the RPositionServer, RPositioner, TPositionInfo and TPosition classes (see Listing 12-2).
Listing 12-2 Acquiring Positional Information on Symbian
RPositionServer;
RPositioner pos;
User::LeaveIfError(srv.Connect());
CleanupClosePushL(srv);
User::LeaveIfError(pos.Open(srv));
CleanupClosePushL(pos);
pos.getLastKnownPosition(posInfo, status); // cached data from last fix
posInfo.GetPosition(pos);
The program can also use NotifyPositionUpdate to request fresh data rather than cached.
BlackBerry
The BlackBerry uses the standard J2ME geolocation APIs as detailed in the JSR-179 specification. Positional data can be obtained by instantiating a criteria, setting its attributes, and passing this to a new LocationProvider instance. Listing 12-3 provides an example of this.
Listing 12-3 Creating a JSR-179 LocationProvider
Criteriacr=new Criteria();
cr.setHorizontalAccuracy(500);
cr.setVerticalAccuracy(500);
cr.setCostAllowed(false); // Whether or not services may incur costs
to the user
cr.setPreferredPowerConsumption(Criteria.POWER_USAGE_LOW;
// Three levels of desired power consumption allowed
lp = LocationProvider.getInstance(criteria);
Upon installation, the user will be prompted for the permissions they wish to grant the application. Afterward, these permissions can be changed in Options | Security Options | Application (see Figure 12-5).
Figure 12-5 The BlackBerry location permissions dialog
Risks of Geolocation Services
Although mobile geolocation services have resulted in some useful and convenient mobile applications, these services expand the potential risks to both the end user and the remote service providers making use of this data. Any tracking technology has the capacity to make software more personalized, but this very personalization is what makes it attractive to law enforcement and civil trial lawyers, as well as other malicious parties.
Risks to the End User
Positional data stored on remote servers, when it can be tied to an individual, introduces a new avenue for data theft. Not only can a compromise of a sensitive service reveal personal and credit card data, it can also reveal information about users’ historical whereabouts, potentially over an extended timeframe. This is not only a breach of user privacy, but potentially provides information that can be used against a user in court.
The classic example of this is a divorce court subpoena, in which a service provider is obligated to provide positional information to prove or disprove that a party in a divorce case has been carrying on a covert relationship. This occurs with some frequency with toll-pass systems such as FasTrak and EZPass (refer to www.usatoday.com/tech/news/surveillance/2007-08-10-ezpass_N.htm and www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2001/02/12/BU75523.DTL). Even outside of adulterous activity, positional tracking records have been subpoenaed as evidence of how much (or little) a person works, both in divorce courts and other civil cases (see findarticles.com/p/articles/mi_qn4176/is_20070608/ai_n19294734/?tag=content;col1).
Recently, it has become fashionable for services to track one’s location and broadcast this to other users of the service. This raises a whole new set of security concerns, where other users may use this information for stalking or harassment, in addition to all of the aforementioned issues. Users must be extremely vigilant to ensure that services attempting to use data for this purpose are protecting it appropriately.
Whatever the scenario, it’s a good idea to keep track of who’s keeping track of you. End users of geolocation technologies should take the following into account:
Does the application/site have a privacy policy for positional information?
Is data retained or discarded/overwritten?
If data is retained, will records be handed over to law enforcement upon request, or is a court order required?
NOTE
Remember in the past that institutions receiving a “National Security Letter” from the FBI are prohibited from disclosing that they’ve even received a request, much less that data was shared. As a user, this makes it even more important to determine what amount and type of data is being retained.
Does the provider share location data with third parties or store data with them?
Are other users of the service privy to your location data?
Are you able to easily block users?
Is this data transferred over secure channels [that is, Secure Sockets Layer (SSL)]?
Is the data accessible via other means (such as via a website)? Is this site adequately secured?
Risks to Service Providers
By maintaining extended positional records on users, service providers expose themselves to the risk of negative publicity from a data breach, legal or congressional subpoenas, and potential assistance to criminal acts by allowing third parties to track individual users. Often, this data isn’t really necessary to provide the required functionality. In some places, you as a provider will have a legal obligation to follow privacy guidelines. For example, in the UK, the Data Protection Act requires that users are made aware of who is tracking them, the purposes for which their personal data will be collected, and whether the data will be sent to a third party, including information about data retention and storage (refer to www.statutelaw.gov.uk/content.aspx?activeTextDocId=3190610). To sum up, positional data is “hot”—you don’t want to store it if there is no compelling need to do so.
To minimize the impact of these risks, there are a few basic steps service providers and application authors can take. These are discussed in the next section.
Geolocation Best Practices
Here are a few best practices when handling geolocation services. Not only do they increase the confidence of your users, but they prevent future loss of reputation, revenue, and other hassles that might befall you, the service provider:
Use the least precise measurement necessary. If your application merely needs to know the city in which the user is currently located, only request this degree of accuracy from the location API. Where “coarse” permissions are available, use these.
Discard data after use. Unless data is explicitly needed over an extended period of time, this data should be discarded. This means that either logging subsystems should not receive the data in the first place or they should be immediately expunged. Some companies take the approach of overwriting past positional data immediately when an update is received (www.eff.org/deeplinks/2009/03/exclusive-google-takes-stand-location-privacy-alon).
Keep data anonymous. If data does need to be retained, ensure that it cannot be associated with other personal data. This includes ensuring that cookies are not used for tracking mechanisms and that requests for location data go over secure channels.
Indicate when tracking is enabled. Users should be visually notified that their whereabouts are being recorded. Systems such as the iPhone and Android have dialogs to inform users about this explicitly, either on use or on install. On platforms that don’t have this capability, be sure to notify the user yourself.
Use an opt-in model. All software using geolocation data should have this functionality disabled until explicit confirmation from the user. Provide an interface to disable this at any time. Wherever possible, give the user the ability to specify their location manually, as with a ZIP code.
Have a privacy policy. Be able to provide guarantees to your users about how you use their positional data, and what you’ll do with it if it’s requested in a civil or criminal case. It’s important to have this ready before a request like this arrives.
Do not share geolocation data with other users or services. Allowing users to access other users’ positional data is very risky territory. Avoid this technique if at all possible.
Familiarize yourself with local laws. Different countries and states have different restrictions and requirements involving tracking information. Ensure that you’re aware of the ones that apply to your target regions.