- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 26 Nov 2008 00:54:55 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 25 November 2008 16:54:55 UTC