The internet is all about data, but figuring out where that data resides in the real-world—geolocation—wasn’t exactly written into the job description. It shouldn’s no surprise, then, that an application wanting to know where its users are located has little option but to ask nicely and pray that the client is in a receptive mood.
The good news for real-time games, location based coupons, and every augmented reality application that ever made it past the compiler is that it usually works out pretty well. Mobile devices have plenty of ways to figure out where they are—GPS is quite good, cell lookup isn’t too much worse—and they’re usually willing to share. But what about when they aren’t?
Geolocation problems usually arise from one of three sources:
- Missing responses. If a device is incapable of responding to a geolocation request (as in older and incompatible devices) or when a user denies the request outright, the location is not returned to the requesting application.
- Botched lookups. If the technique being used to determine a device’s location is unable to resolve it accurately, the location returned may not reflect the actual coordinates of the device.
- Pure malice. Let’s face it: who wouldn’t want to win a territory-capture game by spoofing their location to teleport around a virtual city? There are a plethora of reasons users might seek to obscure or alter their reported location.
Of these, only the first will trigger any kind of error. Once a location has been returned, the burden of deciding whether it is valid or not rests solely on the application at the other end. And there really isn’t a good way to sort out the good from the bad.
Not that that’s stopped application developers from trying. Over the years, a range of crude techniques have evolved in an ongoing attempt to help applications determine where their clients are located. None of the approaches are very good, but some of the best include:
Many services are available for correlating IP addresses to real-world locations. IP-based geolocation has been around for quite some time, but even without mentioning words like “proxy” or “tunnel” its purported accuracy is only as good as the lookup database that drives it. That may mean a few hundred meters, but resolutions much more typically range from somewhere in a given city on up to country level.
Making a unique code available only at a specific location can confirm a user’s presence there. A QR code on a storefront window can indicate that the user is at the store, but only if the user pauses long enough to scan it. And as soon as its value is known, it may be duplicated, transmitted, and used by anyone anywhere to pose as if they’re in the same place.
Reality, extrapolation, call it what you will: if a plane travelling from Chicago is heading for LA at cruising speed, odds are that it will still be heading in roughly the same direction at approximately the same speed a moment later. Unfortunately, common sense only applies when reliable references are available. Even then, it remains much better at identifying noise than at correcting errata—hardly a practical solution.
None of these techniques is absolute, and each introduces as many new problems as they solve. The story still can’t be verified. The client still can’t be trusted. So what’s an application developer to do?
Sometimes, the best recourse is to meekly accept the limitations of the state-of-the-art and design with its limitations in mind. This means two things:
- avoid relying on geolocation for mission-critical tasks
- offer opportunities for users to manually input/correct their location
The first speaks for itself. If geolocation is supposed to be an all-seeing, all-knowing Orwellian surveillance tool, it’s surprisingly gullible. Using it to determine someone’s location when that location actually matters is just asking for trouble. Preempt potential issues by minimizing exposure or designing them out of the application entirely.
The second is a little subtler. Even when a location isn’t being deliberately spoofed, the accuracy of any geolocation lookup will vary based on the physical limitations of the technique used to obtain it. Users know where they are, even when geolocation results are off by a city or two. Giving them an opportunity to provide this information helps ensure that geo-aware applications can provide relevant information regardless of whether the geolocation API is working correctly or not.
Geolocation has opened enormous opportunities for developers to connecting virtual data to the real world, but it remains an emerging technology and needs to be treated as such.