[whatwg] Geolocation in the browser

[Ian Hickson]

I include below a number of e-mails sent on the topic of Geolocation and 
possible things we should add to HTML5 around this. I haven't added 
anything, because I the W3C's Geolocation group is already working on 
providing an API for this. I encourage people who want to work on this 
topic to join that group:

   http://www.w3.org/2008/geolocation/

I didn't see anything in the feedback below that hasn't already been more 
or less said in the context of that group, so this time I haven't 
forwarded the feedback to the other group as I usually do.


On Wed, 21 Feb 2007, Ryan Sarver wrote:
>
> Hey guys. I have been watching the list for a bit and thought it was 
> time for me to jump in here and kick off a discussion on 
> geolocation-aware browsing. I tried to search through the archives to 
> see if the discussion had come up before and didn't find anything, so 
> please forgive me if it has.
> 
> I am the Dir of Product Development at Skyhook Wireless where we have a 
> Wi-Fi Positioning System - think GPS, but software-only and uses 
> Wireless APs instead of satellites. We have been working on developing a 
> plugin for Firefox that gives a website access to the user's location 
> via javascript. User's can control access to this information at the 
> domain level in much the same way they control cookies and popups.
> 
> We have been successful in exposing it through the Javascript DOM and 
> wanted to start talking with standards bodies about coming up with a 
> standard implementation to make location-aware browsing common 
> functionality at the browser level. I was hoping to kick off a 
> discussion around possible implementations and get the community's 
> thoughts on the topic.
> 
> Location could be exposed through a standard Javascript object/interface
> 
> var location = window.getLocation();
> 
>  - would it make sense to also expose it in the request headers? This 
> way the server receives it on the first request as opposed to through 
> the client after the initial page request
> 
> User-Geolocation: 43.338018, -71.817930
> 
> What are people's thoughts on location in the browser? Is the "window" 
> object the right object to attach to? Im interested to hear everyone's 
> thoughts...

On Wed, 21 Feb 2007, David Latapie wrote:
> 
> Surely you've heard of ICBM
> (<meta name="ICBM" content="46.025507, 14.300186" />)
> 
> Could elaborate on what you like and dislike on this?

On Wed, 21 Feb 2007, Ryan Sarver wrote:
>
> The ICBM standard is for geotagging the actual content whereas we are 
> talking about a standard that lets the content know the location of the 
> User or device so that the website can be location-aware.
> 
> I want to use as much of the existing standards, but have more questions 
> about where it should exist in ecosystem and how servers and webpages 
> would expect to see it and use it.

On Wed, 21 Feb 2007, Ryan Sarver wrote:
>
> That's a good point. I think you're right that the "navigator" object 
> might make more sense:
> 
> // Example
>
> var location = navigator.getLocation();
> alert(location.latitude+', '+location.longitude);

On Wed, 21 Feb 2007, Ryan Sarver wrote:
> 
> It's also important to remember that this functionality would be an 
> opt-in system - unlike your cell phone :) The prototype that we are 
> working on would allow the browser to point to a COM port where it could 
> find a GPS device or any NMEA-compatible device or software. It would 
> then read the NMEA stream over the COM port and use that to deliver the 
> user's location to the website via the DOM.
> 
> Our software positions you based on WiFi triangulation and can emulate a 
> GPS device by streaming NMEA over a virtual COM port so that the user 
> wouldn't need to have a dedicated GPS antennae.

On Wed, 21 Feb 2007, Ryan Sarver wrote:
> 
> I hear you ... the idea is really two fold -- the first part is to 
> standardize how web applications access the location information, 
> regardless of how it is determined. The second is to offer a standard 
> way of different location acquiring technologies -- GPS, Wifi 
> positioning, geocoding an user-entered address, etc -- to deliver 
> location to the browser. In this case I am proposing using the NMEA 
> standard as it is well documented and would allow for compatibility with 
> existing GPS devices.
> 
> I agree, there are very few GPS-enabled laptops - in fact the only one I 
> know if us a UMPC - but there are a lot of Bluetooth capable laptops and 
> Bluetooth antennas to provide the location. There are also solutions 
> like ours at Skyhook that are software-only and would allow people to 
> immediately begin to provide their location to the browser via a simple 
> download.
> 
> This would all obviously be configurable in the UA...

On Fri, 23 Feb 2007, Dave Raggett wrote:
> 
> Following on from Michael Smith's email on proosed W3C work in this 
> area, I thought it might be helpful to provide a litte context.
> 
> There is a great deal of interest in location based web applications and 
> the challenge is how to expose this to browsers in a way that is 
> independent of how the location is determined. Web applications may need 
> control over what format the information is provided, and how often it 
> is updated when the device is moving.
> 
> There are obviously lots of security concerns over location and this is 
> part of a broader context of giving web applications richer access to 
> device capabilities. A common approach is to ask the user for permission 
> each time the application is run. That raises usability concerns, such 
> as is the user able to discern whether the application is bona fide 
> website or whether it is a phishing site masquerading as a bona fide 
> website. This is a real problem for desktop browsers and is likely to be 
> an even greater challenge on the smaller displays on mobile devices. 
> Walled gardens provide a partial solution, but don't scale to the 
> Internet as a whole.
> 
> W3C's April 2006 workshop on transpency and usability of web 
> authentication looked at some of the issues, see:
> 
>   http://www.w3.org/2005/Security/usability-ws/report
> 
> We are now planning a further workshop for June 5-6 in Dublin, Ireland 
> to follow up with a broader look at the issues involved in declative 
> models of distributed web applications. A public call for papers will be 
> issued in the near future. An brief outline is given at:
> 
>   http://www.w3.org/2006/10/uwa-charter.html#workshops

On Thu, 22 Feb 2007, Ryan Sarver wrote:
>
> Since I am a newbie in this regard, what do you think about passing 
> something like User-Geolocation in the header of the request so that the 
> server has access to the information as well?
> 
> Obviously this is subject to some settings and privacy control on the 
> UA, but it would allow the server to process the initial page content 
> based on the user's current location.

On Wed, 21 Feb 2007, Henri Sivonen wrote:
> 
> My first thought is that it is a privacy problem. And per-site 
> configurability of the exposure of location data is a user interface 
> problem.

On Wed, 21 Feb 2007, Ryan Sarver wrote:
>
> There are obvious privacy concerns -- I feel they can be alleviated with 
> the proper level of control for the user. Currently in our prototypes, 
> the browser prompts the user for each request, which they can allow or 
> deny and then remember that preference for subsequent requests from that 
> domain. What type of privacy control are you envisioning?
> 
> As for a user-interface problem, its not much different than the 
> allowing / blocking of popups on a per-domain basis. There are 
> definitely existing standards to piggy-back ontop of in terms of UI 
> controls and dialogs.

On Thu, 22 Feb 2007, Ryan Sarver wrote:
>
> One of the other options we have is to reverse-geocode the lat/lon and 
> then return different levels of granularity based on that information
> 
> 42.351036, -71.049378 = 332 Congress St, Boston, MA 02210
> 
> So sites like fandango that would only require a zipcode, we would only 
> need to provide them a zipcode.
> 
> The biggest problem with this implementation is that it requires an 
> additional service on top of standard GPS. We have it built into our 
> service, but adding it on top of GPS becomes a hurdle. We have also 
> found that most users don't actually worry too much about the 
> specificity of the location depending on the use-case. Most of the time 
> they are more worried about the binary allow/deny of their location.
> 
> I think it makes sense as a first revision to just piggyback on NMEA and 
> just do a straight pass through of that information, with some possibly 
> fuzzying logic within the browser.

On Thu, 22 Feb 2007, Gervase Markham wrote:
> 
> I wasn't envisaging any geocoding services. In my example, the address 
> would be one the user had entered, and (assuming the machine has GPS at 
> all) the browser had remembered as being at particular GPS coordinates. 
> For desktop machines which never move, the browser may well have 
> geocoded a typed-in address once and stored the lat/long to give to 
> websites.
> 
> If the machine has GPS, the default option in the dropdown might be 
> "Here: <lat>, <long>". But there would be other options. I think it's 
> important that the user be able to give a location other than his 
> current one - for example, if he's at work, but looking for the closest 
> pizza restaurant to his home.
> 
> The "granularity" setting is for privacy; I was imagining that the 
> browser would round the actual value to the nearest whatever was 
> appropriate, in order to introduce the necessary degree of uncertainty.

On Thu, 22 Feb 2007, Ryan Sarver wrote:
>
> Gerv, this is great feedback. I agree that it's important to think of 
> fixed devices also being able to produce location information, 
> especially without needing any type of location-sensing hardware or 
> software.
> 
> In terms of user's being able to give different addresses, I feel that 
> is the job of the app itself. The browser should provide the location of 
> the UA based on the user's privacy settings, and then it would be up to 
> the app as to how they use it and give the user options on how to change 
> or use that location. I think this is simple enough as instantiating a 
> form with your current location, but letting users change that for 
> subsequent requests. Or in the case of Yahoo Local, the drop down could 
> have the following options: "Your Current Location, Home, Work, etc"
> 
> Re: granularity - I agree that's a simple and functional way of 
> "fuzzying" location.

On Thu, 22 Feb 2007, James Graham wrote:
>
> Something slightly relevant has been discussed in the context of wf2 [1]
> 
> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-June/000149.html

On Thu, 22 Feb 2007, James Graham wrote:
> 
> I believe the Apple iPhone is supposed to expose some sort of 
> geolocation data. If it is half as popular as the hype suggests it may 
> be, I suggest we try to standardise whatever Apple have done (assuming 
> it is sensible, and they haven't managed to get some absurd patent, of 
> course) since it is likely to become a defacto standrd that websites 
> will adopt and other devices will copy.

On Thu, 22 Feb 2007, Kornel Lesinski wrote:
> 
> For some applications location given in format other than lat/long may 
> be more useful and less privacy-sensitive.
> 
> For example name of the city might be good enough if you order a cab 
> from a nationwide company.
>
> Postcode would be easiest way to integrate location API with existing 
> services (especially via userjs/greasemonkey, where using 
> location->postcode database may be difficult).
>
> Additionally city/postcode information may be provided to desktop 
> browsers by the user (for example Opera collects that information 
> already).
> 
> Also different applications may be satisfied with different precision of 
> location (searching for nearest airport vs nearest starbucks :)
> 
> There's also privacy problem with giving too precise location and 
> usability problem with asking for user's permission every time.
> 
> My proposal is:
> 
> use navigator.getGeolocation instead of window.getLocation to avoid 
> conflicts with existing functions (window object is a global namespace 
> in JS) and to avoid confusion with window.location object.
> 
> navigator.getGeolocation() would return location with best precision 
> allowed by default (without asking user every time). If user set in 
> preferences that every page can get location with 10km precision, that 
> would be returned.
> 
> navigator.getGeolocation(100) would request location that has precision 
> of 100m or better. If user's default allowed precision is lower than the 
> specified one, browser would ask for permission. Browser would be 
> allowed to return location with lower precision than requested (if it 
> doesn't have information precise enough or because user decided so).
> 
> The function would return an object, which could be queried about 
> various aspects of the location - name of the city, postcode, but also 
> precision of location given (so applications would know if user is 
> really exactly in the middle of the city or if browser only knows the 
> city name).

On Fri, 23 Feb 2007, Gervase Markham wrote:
> 
> The privacy-sensitivity problem can be easily dealt with by reducing the 
> accuracy of the lat/long given.
> 
> > For example name of the city might be good enough if you order a cab 
> > from a nationwide company.
> >
> > Postcode would be easiest way to integrate location API with existing 
> > services (especially via userjs/greasemonkey, where using 
> > location->postcode database may be difficult).
> 
> The problem with suggestions like this is that they require geocoding on 
> the server side. Geocoding services are not always readily available; 
> there's no free, unencumbered implementation I know of. And you need a 
> different database for every country.
> 
> I guess I don't object to the browser returning this information 
> additionally if it knows it - but lat/long should be the baseline, 
> always-present info.

On Sat, 24 Feb 2007, Steve Runyon wrote:
> 
> What if the navigator object offered multiple geolocation-related 
> values, and the user could select which one to provide either globally 
> or on a per-site basis?
> 
> For example:
> .latLong = latitude and longitude within the mininum available error radius
> .latLongApprox = latitude and longitude within a user-defined error radius
> .postalCode = the current postal code
> .municipality = the current town/city (useful?  compare Cairo, Egypt and
> Cairo, Georgia, US)
> .state = state/canton/etc.
> .country = country
> 
> If postalCode, municipality or state is provided, country is always also 
> provided to enable the server to look up the corresponding geographic 
> area.

On Sat, 24 Feb 2007, Kornel Lesinski wrote:
> 
> But what about browsers that don't have access to GPS device nor 
> geocoding service? These browsers could still return city and postcode 
> information provided by the user and that could be enough for many 
> applications (nearest branch locators, etc.).

On Sat, 24 Feb 2007, Kornel Lesinski wrote:
> 
> Ofcourse there should be option to ask every time, but it can't be the 
> only option. Some users may prefer not to be bothered and have 
> location-based services just working. Also there are IP<>geo databases, 
> so some users may want to allow giving away information that has 
> approximately same accuracy.

On Sun, 25 Feb 2007, Gervase Markham wrote:
> 
> Every browser should be able to get access to a geocoding service once 
> or twice, I think. It's the bulk use that would be needed for server 
> operators that's harder to get.
> 
> So if the user types in an address, the browser would use any number of 
> services to geocode it once - obviating the need for every server they 
> interact with to do it again and again.

On Sun, 25 Feb 2007, Charles McCathieNevile wrote:
> 
> Not necessarily. It's sort of like the accuracy of Google - most of the 
> time you get the right language, but every so often it's just totally 
> b0rken. So while it is a useful guess, you would want to know what the 
> browser is going to submit. And often it is around the country level of 
> accuracy.

On Fri, 23 Feb 2007, Ryan Sarver wrote:
> 
> I agree with you on the idea of not always using lat/lon as the returned 
> data -- this is how we have it implemented in the upcoming version of 
> Loki to test it out. The inherent problem with this model is that 
> reliance on a reverse-geocoding service to provide that kind of 
> information. If we want to allow existing GPS and NMEA-supporting 
> devices to play in this world, we would need a reverse geocoding service 
> to supplement the lat/lon. Its interesting to think about, but I don't 
> know if its feasible on a broad level.

On Fri, 23 Feb 2007, Michael(tm) Smith wrote:
> 
> The W3C has some ongoing and planned work related to this. One of the 
> stated aims of the W3C work is:
> 
>   Develop proposals for remote eventing, device coordination, and
>   safe and secure access to device capabilities, including
>   physical sensors and effectors
> 
> Specific upcoming events related to that work include:
> 
>   - Ubiquitous Web Day at XTech (mentioned in my previous message),
>     to take place at XTech in Paris on May 15th. Open to anybody
>     attending XTech
> 
>   - Workshop on Declarative Models of Distributed Web Applications,
>     to take place in the first week of June in Dublin. The Call
>     for Participation for that will go out some time next month.
> 
> In the mean time, there are a couple of documents at the W3C site you 
> might want to look at.
> 
> The first document is a proposed activity statement for a new 
> "Ubiquitous Web Applications" W3C Activity:
> 
>   http://www.w3.org/2006/10/uwa-activity-proposal.html
> 
> And the other document is a proposed charter for a new Working Group:
> 
>   http://www.w3.org/2006/10/uwa-charter.html
> 
> Especially you might want to look at the "Leverage the DCI for
> work on enabling use of device capabilities, remote eventing and
> device coordination" section of the charter:
> 
>   http://www.w3.org/2006/10/uwa-charter.html#dci
> 
> And within that, the following:
> 
>   Enabling use of Device Capabilities
>   http://www.w3.org/2006/10/uwa-charter.html#device-capabilities
> 
> The section of the charter outlines this new work can make use of
> previous work that was done at the W3C on the "DCI", which is
> documented in the following W3C Candidate Recommendation:
> 
>   Delivery Context: Interfaces (DCI) Accessing Static and Dynamic Properties
>   http://www.w3.org/TR/DPF/

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'