On Wed, Jan 22, 2020 at 8:31 AM S Moonesamy <[email protected]> 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 > [email protected] > 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 _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
