Mobile Geolocation : Geolocation Implementation & Risks of Geolocation Services

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 1).

Listing 1. 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 2 provides an example of this.

Listing 2. 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 1).

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.