Re: [Int-area] GPS over wifi

[Warren Kumari <[e-mail]>]

On Wed, Jan 22, 2020 at 8:31 AM S Moonesamy <[e-mail]> wrote:
>
> Dear Rob,
> At 04:13 AM 22-01-2020, Rob Brew wrote:
> >Having received the post from Alex I have responded. If you would
> >rather I move this RFC to antarea I will do so.  Personally I feel
> >it's more of an internet problem as GPS is being delivered using
> >HTTP protocols.
>
> The Internet-Draft (I-D) which you submitted would require some work
> as it looks more like a problem statement.

s/some work/lots of work/

I should point out that this is not "GPS" (which has a defined
meaning), this is IP based geo-location - which is already in use. See
[2] for some background / resources.


The document talks about: "The Server, with the aforementioned outline
code, knows the IP address of the WiFi hot spot." - this may come from
a misunderstanding of how wireless networks are typically provided.
When your device makes a connection to a server, the server sees an IP
from a subnet which spans a large physical area (in the case of v6),
or a NATed address which covers a subnet covering a large physical
area (v4) -- the address (generally) isn't the address of the access
point you connect to -- in order to improve the user experience (and
make the network work better / easier to manage, etc) wireless
networks try to let you keep the same address for as long as possible
(see WiFi roaming, etc)


>From the GitHub:
"providing GPS locations over WiFI using remote IP detection for a
server to respond with the correct name of clients location and the
clients GPS location.

The Java application here will look at a connection request's IP
address and from there return a latitude and longitude plus name for
that location."

This makes the assumption that a: the IP address is tightly
constrained to an area - the example video
(https://www.youtube.com/watch?v=pqURqmVVwYk) shows 82.13.105.104 as
being tightly geo-located to London bridge, but this is likely part of
a much larger subnet, spanning a much larger area than just one tube
station
and b: these geo-maps are very imprecise / and dynamic.

As an example, MaxMind's (rather good) geolocation for the above IP address is:
Address: 82.13.105.104
Location: Camden, Camden, England
Approximate Coordinates* 51.5245, 0.1567
Accuracy Radius (km): 10
Entering this into Google Maps gives: https://goo.gl/maps/9hA8ADm2TaXfywkj8

For this to work, London Underground / TfL *and every other
underground system wanting to use this* would need to be willing to:
A: have very small subnets tied to each "location" - this provides a
poor user experience as the devices need to roam between location at
whatever granularity you choose, and so change their IP, and
B: be willing to share this address -> location mapping with some
third party (and keep it up to date). This makes privacy regulators
twitch...

Many mobile devices already do something which achieves much of your
goal -- they look at the *BSSID* of the AP, and use it as a location
signal -- see e.g https://wigle.net/ as an example. This is also one
of the reasons devices like iOS say things like: "AirDrop, AirPlay and
**improved location accuracy** require Wi-Fi", and why services like
SkyHook have things like:
https://www.skyhook.com/submit-access-point [0]


So, if this were to move forward, it would need a lot more work (and
research into what already exists), and figure out if / how the
granularity and privacy concerns can be addressed.
I'm really not trying to dissuade you from this, but it will require a
lot more fleshing out / and understanding of what already exists...

W
[0]: as an interesting aside, we've had to white / blacklist the IETF
Meeting AP MAC addresses from these sorts of services to help with the
location issues. They would learn that AP101 lives in Prague[1], and
then be irritated / confused when it shows up in Singapore...

[1]: Not a bad first order guess. Other than being in a warehouse in
California, somewhere on the second floor, V Celnici 7, Prague, 110
00, CZ is indeed the most likely place to find an AP :-P

[2]: Useful resources:
https://dyn.com/blog/finding-yourself-the-challenges-of-accurate-ip-geolocation/
https://www.iplocation.net/
https://www.iplocation.net/geolocation-accuracy
https://datatracker.ietf.org/doc/draft-google-self-published-geofeeds/
https://www.maxmind.com/en/geoip-demo




>  You might be able to get
> some feedback about how to move the I-D  forward by sending your
> request to a mailing list [1] in the Applications and Real-Time Area
> instead of the Internet Area as HTTP-related specifications are
> usually discussed in that area.
>
> Regards,
> S. Moonesamy
>
> 1. https://www.ietf.org/mailman/listinfo/art
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf