On 08/07/14 13:47, Gervase Markham wrote:
On 07/07/14 08:43, sam tygier wrote:
I suggest that something similar is done with the database download, by
only giving weak information about each hotspot. For example either its
latitude or longitude (depending on something deterministic such as the
last bit of the BSSID). Now an individual hotspot can't be located, but
a group known to be close together can. There are a few alternatives,
for example a hot spot could either be coarse (integer part of
coordinates) or fine (fractional part of coordinates), but I am not sure
this is any better.
If you can provide a mathematically strong way of doing this, I for one
would be most interested. (I'm not sure it's possible.)
Gerv
If you only have the longitude of a given hotspot then I can't see there being
any method to find its full location. It does not even help to combine with
other information you might have (there are lots of other ways you might know
an approximate location e.g. person lives in this city, person regularly visits
this location). I guess there is a weakness if the latitude is +90deg or
-90deg, so the poles might need to be left out of the database.
One potential problem is hotspots with 2 BSSIDs. This is common dual band (2.4
+ 5 GHz) routers. For mine the BSSIDs are the same apart from the last byte
('c' vs '8'), but on a router that used a different chipset for each band,
there might be no relation. These hot spots would also be locatable on with the
hash buck method. I suggest the database only include 2.4GHz hotspots (5GHz are
rare, and have shorter range anyway).
There is a big problem if you change the scheme at some point and someone has
access to the old and new databases. So if the longitude of hotspot is
published, then latitude must never be published in a future database. Deciding
which based on the BSSID should be safe.
There is an issue if you can only see a small number of hotspots. There is a
chance that the might all have 0 as the last bit and all give latitude. If you
can see 4 hotspots, there is a 12.5% chance they are all giving you the same
coordinate. This can be improved by adding diagonals.
last bits 00 : longitude : x = c
last bits 01 : latitude : y = c
last bits 10 : diag + : x-y = c
last bits 11 : diag - : x+y = c
(The database would just contain a hash of the BSSID and c for each hotspot).
Now there is a 75% chance that the second hotspot gives you different
direction, letting you solve your location. Now for 4 hotspots there is only a
1% chance that they all give the same direction.
The main difference I see compared to the hash bucket method, is the
computational complexity of combining the weak information into a location
(finding intersections of lines is easier that finding nearby pairs on lists).
This may be an issue for low power devices.
Sam
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation
