W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2010

Re: Geolocation provide API

From: Richard L. Barnes <rbarnes@bbn.com>
Date: Thu, 18 Nov 2010 08:22:24 +0100
Message-ID: <4CE4D430.2070107@bbn.com>
To: Doug Turner <dougt@dougt.org>
CC: "Thomson, Martin" <Martin.Thomson@andrew.com>, "public-geolocation@w3.org Group WG" <public-geolocation@w3.org>
>> By the same token, you could use automatically discovered network services (i.e., RFC5985/5986).
> Yeah, that is interesting.  I don't know enough about how hard that is to deploy.  If they go to maps.mit.edu, that page could serve up content which sets mit's location service as the default.  If I walk onto campus, i may not want to use their WiFi, and therefore, not have access to their network services... right?

Actually, the idea is that if I'm connected to a network that has a 
location service, the browser could use that specific location server as 
a general location source.  Not just for maps.mit.edu, but for 
maps.google.com, m.flickr.com, etc.

It's not trivial to deploy, but it's not incredibly difficult either. 
The hardest part is creating the geolocation service (natch); beyond 
that it's a couple of minor network configuration changes.  Demo code 
and instructions here:

The client side of things has a couple of minor subtleties, but there's 
a couple of implementations out there now.  We're working on a Firefox 
plug-in as a proof-of-concept that will read a URI for the local 
network's location server and update the "geo.wifi.uri" preference.

> Any case, this conversation is interesting... but out of scope, i think.

I think you're mostly right.  I also kind of agree with Nick, that if we 
could have some sort of basic taxonomy (network vs. device-only) that 
pages can use to choose it could be helpful in managing privacy.  But 
even then it would be a "weakest-link" situation, since even if one page 
does something good, other pages might not.

Received on Thursday, 18 November 2010 07:23:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:51:01 UTC