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.