Geolocation today.
At the Mozilla Summit, Brad Lassey and I presented on a session called Device APIs. My first demo was on something called Geolocation. The idea, which I have spoken about before, is that we should expose the user’s physical location on earth to web sites via the DOM. This idea has become quite popular and now is being flushed out in the whatwg and w3c. Recently, I added support for an early draft of the spec to Mozilla and have a patch which updates it to the latest draft. This functionality provides the backend support to handle various geolocation providers (a geolocation provider is something that, um, provides geolocations — such as a GPS device, a Wifi->location service, etc). Missing from this implementation is the user interface that enables you to allow geolocation requests from the web. This functionality will be provided via addons or via the application itself.
For Firefox, I have created a Geolocation Addon that provides the user interface. This initial version allows you to statically set your location; it doesn’t listen to any GPS, or use any other location device. You might think that this doesn’t make sense, but for the people that have a desktop pc somewhere in their house, something like this will allow them to participate in geolocation. Of course, I see this extension expanding to support devices. In fact, I started on a NMEA geolocation provider for Mozilla. When I have time, I will merge this code into the Geolocation Addon — unless you beat me to it!
I also added a user interface in Fennec on the n810 devices to enable geolocation. If you have a n810, be sure sure to check out Fennec.
The functionality is exposed off of the “navigator” object in the DOM. So, the simplest example that is useful is probably a google maps demo:
In your webpage’s onload handler, do something like this:
navigator.geolocation.watchPosition(updateLocation);
updateLocation is called whenever your position changes and is passed the new location as a parameter. You simple need to handle it:
function updateLocation(location) {
// do something with: location.latitude and location.longitude
}
The live page is here. You can try it out if you install the geolocation addon I mentioned above, as well as applying the latest draft spec patch. The patch will land soon, and you will be able to grab a nightly to try it out.
Of course, exposing such sensitive details such as your location does raise privacy concerns. Most of our Session at the Summit dealt with how device apis, and in particular geolocation, should handled. For geolocation, if the user does nothing, no geolocation information is exposed. In Fennec as well as in the Geolocation Addon, we use something called the info bar. Below is a screenshot of the info bar we are using:
Notice there are three possibilities.
The first is “exact” which means that we will pass on the exact location the geolocation device gives us. For example, if your GPS gives back your position to the nearest foot, that is exactly what we will give to the web site.
The second is “neighborhood” which means that we are going to “somehow” modify the location so that we drop precision/accuracy. The exact algorithm to do this has not been thought through and your suggestions are welcome. The idea behind this is that you might want a mapping application to know exactly where you are, but maybe you do not want the <insert your favorite movie ticket purchasing site> knowing exactly where you are.
The last option is “Nothing” which, of course, means to ignore the request.
Get involved! You can provide feedback on draft spec, you can start filing bugs against our implementation, and you can start enabling your site for geoloccation!
Technorati Tags: geolocation, mozilla, gps, location
It seems the Web page’s JS code could/should detect that it’s running on a browsers with no navigator.geolocation at all, and if so put up its own dialog prompting the user for a geolocation.
I don’t know how closely client JavaScript can match what your Geolocation add-on will do (I’m waiting to run it!), e.g. remember well-known locations, the last five entered, etc. But at least a bare-bones prompt to let users of lesser browsers know they’re missing out, and ideally a standardized JS package in the popular JS toolkits.
Regarding modifying the location, I think it is important to do so consistently. It might seem sensible to just take a random location within a 1 mile radius of your current location, but given enough samples a website might be able to work out your exact location (e.g. if you visit a website four times, and it first gives your location as one mile due north of your real location, then one mile due west, then due south then due east. If the site assumes you haven’t moved, then it now has an exact location for you).
If you just say “they are somewhere in this grid square” then that is not a problem. One thing that would need to be carefully considered though is what to do on the edges of the grid square – if a site sees you move from one square to another then it will know you are on the border line, or worse the corner between four squares.
Having considered what Ian Thomas just said above, it may still be possible to take a random location within a 1 mile radius, but the center of the circle should be not you exact location, but a node of grid.
However, being too random means that the site would detect you as randomly moving inside the cirle instead of staying still. That’s probably not something the site is ready for.
How about that: you take random azimuth, and you take random value between 0.5 and 1 miles, and with that azimuth and value you get a constant offset from your current position. And you remember that offset permanently (for the whole life of your browser.) When you report your position, you add that offset, and even after applying the offset you report only rounded value, no more than two digits after the decimal dot of degrees. (E.g. 38.05 degrees to the east of the prime meridian, 44.57 degrees to the north of the equator.)
Such a scheme may not be compromised by a mere gathering of statistics (because the offset is permanent). Such a scheme may not be compromised by analizing your movement on the 0.01 grid (because the offset means you are never on the borderline or the corner).
Clarification/correction to the above: …because the offset means you are never actually on the borderline or the corner when your reported location crosses that borderline or corner.
The “permanent offset and then rounding” scheme supports the same level of anonimity that “rounding and then random offset” does, but the “permanent offset and then rounding” does not generate the same tremendous amount of “onUserMove” (or whatever they are called) events on random moves. That’s why the “permanent offset and then rounding” scheme is superior.
@ skierpage I am not sure if most people would even know what to fill out. Good idea, but asking the user for info every time seems like what we are trying to get away from
@ thelem For fuzzing locations, I have been looking at dropping precision from 6-8 decimals that a GPS devices can give, to 1. This gives you enough precision to be meaningful, but not enough to pin point you. We will, of course, also increase the error values in the location when fuzzing to let the web sites know that their location isn’t 35.100000 or whatever.
dougt, thanks for responding.
Please put a basic “if (navigator.geolocation) else alert()” test in your demos so the vast link-clicking herds don’t get confused and turn against you!
I modified http://www.skierpage.com/moz_bugs/dougt_gps_test.html with the four lines.
I agree asking for location every time is rough, that’s why I think JS toolkits need to implement a fairly sophisticated navigator.geolocation fallback so the new API is immediately useful to the whole web. Right now I *want* to provide my location to many web sites (every retailer’s “Find a Store” page, weather sites, what’s on local TV, etc.) regardless of my browsers’ limitations. Besides remembering my previous entries, the JS fallback should implement or link to a minimalist Web service that takes any of area code, address, zip code, IP address and hands back a geolocation (does such a service exist)?
I don’t know how to comment on the spec (I’m just part of the herd), but I see one limitation: the spec has “heading denotes the direction of the hosting device”, but that’s not enough for photo tagging and “what am I looking at” apps. 6 degrees of freedom also involves looking up-down and twisting, like an iPhone’s tilt sensor. Maybe all three belong elsewhere, in navigator.deviceOrientation. I couldn’t find standard representation for this (yaw-pitch-roll from aviation?).
Thanks for advancing the web!
@ skierpage No such service exists world wide. Reverse geolocation, as it is called, is hard. You can figure out your lat/lon based on your postal code pretty easily in the USA, but in other places it isn’t as easy. Take a look at http://jan.ucc.nau.edu/~cvm/latlon_find_location.html
The javascript addon might easily be able to show you a google map and allow you to point at exactly where you are on the globe, then get the lat/lon. This bypasses the reverse geolocation problem.
And yes, yaw-pitch-roll, acceleration, and tilt, are _not_ part of the spec. navigator.deviceOrientation is probably the right place for them.
I’ve been working in a similar area for a while now.
With regards to obscuring of information, work in the IETF has already considered the problem. The ultimate result we came to isn’t dissimilar to the one you propose, only that a distance is specified. For your purposes, you could configure different input values for “Neighbourhood” and “City” (and expose them on about:config).
http://tools.ietf.org/html/draft-ietf-geopriv-policy#section-6.5.2
Note that radius in the referenced document refers to what you are calling “accuracy”, and it refers to the radius of uncertainty that is either derived from the result, or from any purposeful obscuring performed. I’ve written a guide that also includes a more precise description of the algorithm: http://tools.ietf.org/html/draft-thomson-geopriv-uncertainty
Why does this have to be in the main branch for Firefox 3.1? This is not mission critical for viewing web pages, and I would rather not have this feature on my machines at all, disabled or otherwise. I’m pleading to have it removed so I don’t have to switch browsers. I really love Firefox, always have, but the decision to have this in the main release is enough to make me switch to any other browser… yes, even IE (as much as I hate to admit).
I’m sure you enjoy this project (what good coder wouldn’t); however, forcing that code to be in the browser by default is not good for the user.
@troy as geolocation enabled sites appear, this support will be required to view these web pages. I am trying to understand your position. What are you worried about?
for general location, perhaps
ask user to define an object with an outline, and script randomly selects a random distance .5 to 1 mile and random 360 degree, then map it to the nearest street.
is it possible to find zip code, then just use center of zip code/other zone.
Also, I’ve installed the geode addon, and its not mapping me at the correct location. its about .7 mile off in a crowded residential area.
@dougt I suspect that troy’s concerns are mostly related to privacy. The current set of options needs to be clearer (as my previous comment suggests).
Incidentally, I have another option: lying. I might want to provide an entirely different location than my actual one to a site. The Internet is built on freedoms like this–I can pretend to be an 80 year old Indonesian pearl diver if I choose. More legitimately, I might want to “lie” to my pizza delivery service so that the pizza I order before I leave work arrives at home. Or, it could be that the location information available is wrong (as many people discover Skyhook’s limitations) and I might want to just provide a better position. The other option is to assume that web developers provide the option as it suits them.