> 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).
Subsequent/neighboring BSSIDs are a tricky matter: One is the case you
describe, where a dual-technology device has two subsequent (or neighboring)
BSSIDs. Giving out latitude for one and longitude for the other would
effectively give out the full coordinates of the device (if you know ho to
derive one BSSID from the other), defeating privacy.
On the other hand, companies often purchase WiFi hardware in batches, resulting
in multiple devices with adjacent BSSIDs in a single building or site. Here it
would be beneficial to have one return latitude and the other return longitude
- especially as these devices may be the only ones in range. Since the hardware
in this case is operated by an entity rather than an individual, privacy is
less of a concern.
When in doubt, privacy prevails, but we should keep in mind that there are
cases in which it is desirable to get both coordinates from two subsequent
BSSIDs.
As for excluding individual wireless technologies (as you suggest for 5 GHz
WiFi) - this would also give away their potential advantages: Shorter range may
mean a smaller coverage area, but also a higher confidence for location
measurements. This goes for 5 GHz WiFi as well as for Bluetooth (with the
proliferation of Bluetooth-based iBeacons, deployed for the very purpose of
geolocation, extending the database to include Bluetooth may become an
interesting option for the future).
Considering this, it would be best if we had a way to prevent multiple BSSIDs
(or MAC addresses, in general) belonging to the same device from returning
different dimensions.
The relation between multiple MAC addresses on the same device differs: On many
laptops, the Ethernet, WiFi and Bluetooth MAC addresses are not related at all.
Apple seems to use adjacent MAC addresses for the Bluetooth and WiFi interfaces
of its iPhones. The manufacturer of your home router uses nearby MAC addresses
for its two WiFi interfaces - in your case, the third-least significant bit is
flipped.
We're probably not going to catch the case of unrelated MAC addresses that way.
But we could tackle the other two by using not the least significant bit for
differentiation, but, say, the 5th/6th least significant.
Example: Your router's BSSIDd ends in
xxxx1000 (8)
xxxx1100 (c)
..^^.... - use these two bits to determine which dimension to return.
That would mitigate the "two nearby BSSIDs" case, albeit at the cost of the
"company WiFi setup" scenario I described above.
However, devices with multiple, closely related BSSIDs are also a potential
issue with online APIs. It would be interesting to know if they handle that
case (I can't get a location by supplying a single BSSID, but can I get one by
supplying two BSSIDs of the same device?), and how they do it.
_______________________________________________
dev-geolocation mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-geolocation
