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

(Page 3 of 3)

because 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.

Single PageCurrently on Page: 1 2 3 previous page

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.