The Browser Geolocation Wars: Skyhook’s CEO on Why Google Maps is Misreading Your Location

[Updated 9:20 p.m. EDT 7/10/09 with responses from Google; see the sections marked “Update” below]

Yesterday Google announced that the “My Location” feature familiar to anyone who’s used Google Maps on a mobile device—the little blue button that shows you your position on a map—is now available to people accessing Google Maps from their laptop or desktop computers as well (as long as they’re using the latest versions of the Firefox or Chrome browsers). But there’s a problem: Users are reporting in large numbers today that the My Location feature is erratic, placing them in the wrong city and occasionally on the wrong continent.

Behind this phenomenon, it turns out, is a story about competing ideas on the best way to endow Web-based applications like mapping programs with an awareness of their location—and about the race between companies like Google, Microsoft, and Boston’s Skyhook Wireless to control the way location information is fed to these applications. Skyhook’s CEO, Ted Morgan, gave me his perspective on the Google Maps development in an interview this morning. (See below for our Q&A.)

You might think that all browsers would handle location-finding in the same way. And that’s the ideal—the Cambridge, MA-based World Wide Web Consortium (W3C) has a draft Geolocation API (application programming interface) specification that spells out how browsers should pass the details about a computer’s location from the computer itself to the Web applications running inside the browser. But as Morgan explains, the W3C standard doesn’t specify where or how the browser should get this information from the computer—which leaves room open for competing approaches, and potentially for back-room deals.

Several years ago, Skyhook developed a browser plugin called Loki that taps into a computer’s Wi-Fi chip, takes a reading of all nearby Wi-Fi access points, and uses Skyhook’s proprietary database of access point locations around the world to triangulate the device’s location. The Apple iPhone uses this Skyhook technology whenever its Safari browser or its built-in Google Maps application request location data.

But when Google rolled out the “My Location” feature for laptop and desktop computers, the company decided to use its own geolocation algorithms rather than Skyhook’s. That was possible because the Mozilla Foundation built Google’s algorithms into the latest version of its open-source browser, Firefox 3.5, which was released on June 30. (Google also built the algorithms, not surprisingly, into its own Chrome browser.)

Google’s geolocation technology is similar in principle to Skyhook’s—it also depends largely on information about nearby Wi-Fi access points—but the accuracy of the locations actually produced by the new “My Location” feature seems to vary wildly, as users have been discovering over the last day and half. Judging from posts on Twitter, the Google system is placing some people thousands of miles away from their actual locations.

An unusual number of people, for example, report that the My Location feature shows them as being in downtown Austin, TX, even if they’re half a continent away. “Google Maps’ new ‘Show My Location’ feature puts me in the middle of Austin, TX. I’m actually downtown Manhattan,’ PhoneTag.com co-founder Mark Dillon tweeted today.

While Austin may be the center of the tech world for some South by Southwest addicts, it clearly hasn’t experienced any actual jump in population since Thursday. The problem, according to Skyhook CEO Ted Morgan, lies in the way Google collects the data behind its Wi-Fi-based positioning system. For information about the locations of access points, Google relies on crowdsourcing—it quietly gathers local readings every time someone uses a Google app on an iPhone or a Blackberry, or some other mobile device.

Crowdsourcing is an inherently sloppy approach, according to Morgan. Skyhook’s own approach is to send Wi-Fi-sensing vehicles down every highway, street, and alley, methodically establishing the position and strength of every access point they pass (most are broadband routers owned by local businesses and residents). Morgan says Skyhook has also developed ways of correcting for the fact that access points sometimes move—for example, when someone relocates their home from Austin to Manhattan.

[UPDATE: Google offers a different reason for the inaccuracies. Reached by e-mail this evening, Google communications officer Elaine Filadelfo said users having issues with accuracy “are likely users who are not using Wi-Fi, for which we can generally provide a more accurate location. Without Wi-Fi, we base location on IP address, which can be inaccurate depending on your ISP and its location.”]

Morgan would like to give every developer working on location-aware Web applications the opportunity to tap into Skyhook’s more accurate database through Loki. The problem is that the Mozilla Foundation—whose Firefox browser now occupies about 28 percent of the browser market—has now baked the Google geolocation system directly into the 3.5 version of its browser. Considering Firefox’s popularity, that could put pressure on Web developers to write software that favors Google’s system over Skyhook’s. (Skyhook’s technology is built into the Opera browser, Morgan says, and will be included in Apple’s Safari browser upon the release of the new “Snow Leopard” version of Apple’s Mac OS X operating system.)

Morgan suggests that Mozilla went with Google because the search giant provides most of the foundation’s revenue (in the form of fees for placing a Google search box in the browser’s top-level toolbar).

[UPDATE: To explain Mozilla’s decision to use Google’s technology to provide location information for Firefox, Google’s Elaine Filadelfo pointed to two online sources. One was an April 30 blog post by Mozilla engineer Doug Turner, who said three principles—“protecting user privacy,” “enabling web developers to use the API in an unencumbered way that would work in all browsers,” and “preserving user choice”—led to Mozilla’s choice of Google to provide location services for Firefox. The other source was an April 30 TechCrunch article in which Mozilla said that it turned to Google because the two organizations “saw eye-to-eye on privacy issues.”]

As you might expect, Microsoft is also a player in the location wars—its Internet Explorer still has the largest share of the browser market—and it has its own preferences when it comes to determining location. All of which makes life more difficult for a startup like Skyhook.

Morgan says he just wants a chance to compete and demonstrate the high accuracy of Skyhook’s location-finding technology. “Developers really care about good location,” he says. “They shouldn’t be forced to go down one path or the other.” In our interview (transcribed below), we talked about the huge opportunities opening up for businesses and consumers if software makers can get the geolocation formula right. But that’s apparently a process that’s going to play out in the competitive marketplace rather than in the more civilized boardrooms of standards bodies like W3C.

Xconomy: Can you explain the basic similarities and differences between Google’s approach to browser-based location finding and Skyhook’s, and why you say Skyhook’s system produces more accurate locations?

Ted Morgan: There’s a couple reasons why it’s similar. We have known the Google folks for years. Mike [Shean, Skyhook’s co-founder and senior vice president of business development] and I were just joking yesterday about how when we first built Loki, it was built as a prototype to show Google exactly what they just launched yesterday: a button on Google Maps that would show you where you are. We worked together [with Google] on the Apple deployment [Google Maps on the iPhone]. But the systems are built very differently. There are really two major differences. One is the data, and two is the fundamental algorithms that capture your location.

On the data side, we’ve been doing it a lot longer and taking a very different approach. What the Google folks do is something they call crowdsourcing the data—trying to collect [the locations and IDs of Wi-Fi access points] off of all the Android phones and Google apps running on Blackberrys and other devices. Which is an easy way to grab the data, but unfortunately you get very low-quality data, and it’s susceptible to being spotty around cities, and to being hit by data viruses—you can get bad data in the system and there’s no way to know, and it ripples through the system. That’s how we started the company five or six years ago [i.e., using crowdsourced data], and we found that that model doesn’t work. So we physically drive the streets by hand, so we can ensure that every nook and cranny has been covered.

We also have complete control over the quality of the data, so that we know that this person was on this street corner when they scanned a particular access point. We get broad coverage across the United States and Europe and Asia, so that wherever you go, you know that the system has the same level of coverage. Whereas with Google’s system you might get great coverage in Manhattan, but if you go out to Newton, MA, you get nothing. That is a hard thing to communicate to users—that it will work great in some areas but crappy in others.

The algorithms side is the hardest part. Collecting the data is a physical exercise, but being able to build the algorithms to not only triangulate your position well, but also detect change, is the most important thing. These access points move all the time, and being able to reconstruct when they have moved, and where they have moved to, and which ones you’re confident in and which ones you’re not, is a very complicated experience and it’s something we’ve spent a lot of time building. The Google system will tell you that you’re in Phoenix when you’re actually in Boston not because the triangulation is wrong, butbecause somebody moved their Phoenix access point into Boston, and Google’s system couldn’t detect the discrepancy.

At a high level, what it comes down to is that this is all we do. We obsess about continually trying to make the system better, constantly driving around, and talking with device makers and developers and testing things out. Other folks have many more things on their plate.

X: Explain what’s going on right now in the world of browsers. Skyhook’s Loki system performs the same function as the Google location-finding algorithm—but it’s not a built-in part of Firefox or Chrome the way that Google’s algorithm now is, correct?

TM: They are all fundamentally the same thing. With Loki and with Google and with what Microsoft is doing, we’re all trying to adhere to this W3C geolocation spec. The reason Skyhook is familiar with the spec is that we actually wrote it, the original one. We have been pushing this for years. The whole point of Loki was to try and convince folks like Microsoft and Google and device makers to provide a standard for websites, so that [Web applications] could just grab your location and not have to care about the system underneath. We knew that it would take many years to convince people to do that and to have a standard adopted. Loki was a way to shortcut that, so that you can push location regardless of the browser.

We have deployed it in a bunch of different ways—as a plugin, an extension, a toolbar. But in the end, it should be done just as Mozilla has done it with Firefox and as Microsoft has done with Internet Explorer, which is to bake it into the browser. What’s happening is that Google is trying to push it toward their system. The geolocation API that W3C has adopted does not allow a website to show a preference [for one location algorithm over another]. But if you are coming at it from Firefox 3.5, now Firefox is going to force you to use the Google stuff.

X: So, you’re saying that Web developers should have access to Skyhook’s geolocation API if they want it, but it’s coming down to a competition over whose technology is going to be baked into the browser as the default?

TM: Unfortunately, it is a competition. We tried to work with these folks for years. I’m sure you know that Google isn’t the easiest organization to do business with. We have struggled. And the Firefox 3.5 launch is an example of our inability to find a way to work with folks like Google. Mozilla is an interesting organization; they are basically located on Google’s campus, and they receive the lion’s share of their revenue from Google. That is a difficult relationship to get into the middle of—particularly with a group that doesn’t want to pay for anything. I think all of this shows that Google is willing to go to great lengths to try to stay in the middle of all location activities, and that is clearly a competitive threat to us.

X: How important is the browser to Skyhook as a battleground, really, considering that you also have other markets for your technology like mobile devices, cameras, and netbooks?

TM: We think it’s enormously important, which is why we went down that path [with Loki] four years ago and have been pushing the browser makers. We don’t see that there should be a difference for developers. Whether they are building native applications or Web content, they are all going to have to have location and they shouldn’t be forced to go down one path or the other. We think there are tons of opportunities for new types of browser-based content, whether it’s news or social networking or mapping or geotagging. Geolocation is just a new piece of data that the browser should be sending off [to Web servers]. If you go to Mapquest or Flickr, they are using the Loki API today. If you look at Safari on the iPhone, it’s using Skyhook location. So this is a really great area. The dream in all of this is not only is it a better user experience, but you can use location to target advertising and give developers a whole new way of making money. So we’re putting together pilots for some of the largest advertisers and publishers on the Web to use Skyhook’s very precise location to drive targeted advertising and to demonstrate a huge uplift in the cost-per-click or cost-per-action publishers can charge. That’s all built on browser-based location.

X: What can you do to influence the W3C or browser makers to be agnostic about the location APIs used in browsers?

TM: It’s in everyone’s interest to have a standard on that. You’ll never see us force developers to have to build things three different times [for browsers with different location APIs]. What we need to do is convince browser and device makers that good location matters. It can’t be just okay. If people don’t have the conviction that it’s going to work 95 to 99 percent of the time, they are not going to use it. Microsoft launched a very similar service [to Google’s] three years ago, under the same concept and approach. It was called Locate Me, using user-contributed and crowdsourced data in exactly the same way, and they had exactly the same poor performance, and they finally shuttered the project about a year ago. That’s the same path these guys are on, and unfortunately that affects Mozilla users in a giant way. Safari and Opera have Skyhook, and everything we have seen in the early builds of Snow Leopard has it as part of the Mac OS too. We just have to keep showing why quality matters. I think what you will see is that developers really care about good location.

Wade Roush is the producer and host of the podcast Soonish and a contributing editor at Xconomy. Follow @soonishpodcast

Trending on Xconomy

By posting a comment, you agree to our terms and conditions.

16 responses to “The Browser Geolocation Wars: Skyhook’s CEO on Why Google Maps is Misreading Your Location”

  1. anon says:

    I am not in the slightest interested in a website being able to determine where I am, and along with the horrendous URL bar, FF3 is not something I will be running.

    The IE using crowd will be fawning over these kind of things, but anyone who was attracted to FF by its initial philosophy is now pretty sick of FF and the way it has gone.

    Edit: spreading articles over multiple pages just to stick more adverts in visitors faces is not friendly, and will ultimately mean users will just block adverts, killing your revenue totally.

  2. Marco says:

    @anon 2:48pm

    Noted. By the way, there’s a nice new Italian restaurant just two blocks south from your current location.

  3. Dennis says:

    How in the world could anon have turned this into some sort of anti-FF screed?

  4. My personal experience with skyhooks was that the technology was unable to live up to the claims of the marketware. No idea if Google is going to be able to do a better job, but competition is almost always a good thing.

  5. Epicanis says:

    “taps into a computer’s wifi chip”, “proprietary database”…While I’d have no objection to the company offering an addon, I’m glad this proprietary service wasn’t installed by default as it was in early test releases of Firefox’s geolocation API.

    It still boggles my mind that there’s no “manual entry” option for this, though. You’d think a simple “enter your latitude and longitude” dialog would have been the first thing put in just to test the geolocation API when it was originally being developed.

  6. personne says:

    I’m not impressed by Skyhook’s position. Covering “the United States, Europe and Asia” (hi from Canada!) using drivers in cars seems silly, if they’re not doing an alliance with an international shipping company at least. Correlated crowdsourcing is the better idea, and much more internet (non proprietary, many individuals involved rather than one company) in nature. Ultimately both methods are prone to errors, gaps, and spoofing.

  7. jobbe says:

    What is described is not “triangulation”. Possibly “trilateration” is used, at least in the binary sense of being in or out of range of a (set of) WiFi access points.

    I would think that the Google camera cars for Street View are doing exactly what Skyhook sys should be done, obtaining quality readings by driving own logging cars down every street. Surely Google did not miss the opportunity to add WiFi logging to the camera cars?

    The qualiaty data obtained from the camera cars can also be used to assess the reliability of any mobile device taking part in the crowd-sourcing of locations not yet covered by the Steet View cars. Seems a good approach to me.