| 1 |
On 20 Apr 2010, at 13:17, Mick wrote: |
| 2 |
>> ... |
| 3 |
>> "Introduced in Gecko 1.9.1: Code with UniversalXPConnect privileges |
| 4 |
>> can monitor the list of available WiFi access points to obtain |
| 5 |
>> information about them including their SSID, MAC address, and signal |
| 6 |
>> strength. This capability was introduced primarily to allow WiFi- |
| 7 |
>> based |
| 8 |
>> location services to be used by geolocation services." |
| 9 |
> |
| 10 |
> Hmm Mozilla's netlib. I had a look at the slides and bits of the |
| 11 |
> documentation on the Mozilla website, but I am still not really clear |
| 12 |
> what it does, or why it is needed. |
| 13 |
|
| 14 |
|
| 15 |
I *believe* that the idea of having geolocation accessible to the |
| 16 |
browser is so that websites should be able to provide locally-relevant |
| 17 |
information. |
| 18 |
|
| 19 |
The classic browser has no idea where you are, so if you open the |
| 20 |
homepage of Starbucks / McDonalds / Burgerking / Tesco / Sainsburys / |
| 21 |
whatever and click on "find my nearest store" then you'll need to |
| 22 |
enter your zip code in order for the site to provide you that |
| 23 |
information. |
| 24 |
|
| 25 |
I *believe* that a geolocation-aware browser would be able to tell the |
| 26 |
site where you are. So as soon as you open the webpage, the site will |
| 27 |
query your browser, your browser will tell it where you are and an |
| 28 |
AJAXy element on the page would say "Your nearest Tesco store is 13th |
| 29 |
Street... Click here for directions". |
| 30 |
|
| 31 |
I'm not really sure how this is supposed to work in practice. It's |
| 32 |
clearly in its early days. This dougt.org guy (discovered by Googling) |
| 33 |
seems to be involved with it on the Mozilla side and one of his blog |
| 34 |
posts links to the W3C "Geolocation API Specification", which was only |
| 35 |
finalised 6 months ago. |
| 36 |
|
| 37 |
It says: |
| 38 |
|
| 39 |
The Geolocation API defines a high-level interface to |
| 40 |
location information associated only with the device hosting |
| 41 |
the implementation, such as latitude and longitude. The API |
| 42 |
itself is agnostic of the underlying location information |
| 43 |
sources. Common sources of location information include |
| 44 |
Global Positioning System (GPS) and location inferred from |
| 45 |
network signals such as IP address, RFID, WiFi and Bluetooth |
| 46 |
MAC addresses, and GSM/CDMA cell IDs, as well as user input. |
| 47 |
No guarantee is given that the API returns the device's |
| 48 |
actual location. |
| 49 |
|
| 50 |
I can see that immediately that it's useful and practical if your GPS |
| 51 |
talks to your browser and thus your location information is returned |
| 52 |
to the website. |
| 53 |
|
| 54 |
In theory one could determine one's location on the basis that the |
| 55 |
locations of Fon_AP_1234, SkyHomebroadband_8797 and SmokyCoffeeShop |
| 56 |
wifi APs, detected by a scan of your laptop's wifi card, are all |
| 57 |
already known. However I am more sceptical about this in practice. |
| 58 |
|
| 59 |
Note that browsers run on mobile phones, which often have GPS built in |
| 60 |
these days, and that GPS chips are nowadays so cheap they could also |
| 61 |
be build into laptops, were there the demand. |
| 62 |
|
| 63 |
We could probably have a much longer discussion of how this could in |
| 64 |
theory all work when it's fully developed, but in practice this USE |
| 65 |
flag probably is of no use to any of us right now (unless, *perhaps*, |
| 66 |
we're installing Gentoo on a mobile phone). |
| 67 |
|
| 68 |
Stroller. |
Archives