This is a bit of a “specialised” topic but it might explain some weird behaviour which some people have found.
My testing so far proves that the Samsung S7 (android v6) camera app disables lat/long storage in the EXIF data unless you enable WIFI location assistance. There are also places in the phone where you get a strong hint what WIFI assistance has to be enabled and you have to mess about to continue with it disabled. I reckon they did it to facilitate the harvesting of geolocated IP and MAC data…
This is the setting, under Settings / Privacy
I am using the Photo EXIF Editor app to examine the EXIF. You can see no location data is present here:
but Oziexplorer continues to work fine – that uses the official GPS API
Re-enabling WIFI assistance (the uppermost option in the first pic) restores EXIF location into the photos
and setting it to “GPS only” removes EXIT location
and all during this test, Oziexplorer had a continuous position available
The interesting Q is why limit the GPS functionality only to their camera app? Why not just cripple the GPS API?
One clue is that on the S7 (or maybe android v6 or later) Samsung have crippled the published camera API to ensure that all 3rd party camera apps deliver poor performance. Hence these apps basically don’t work on v6+ (I have tried loads). But the GPS API evidently continues to work regardless, so eliminating 3rd party camera apps (which would have to use the GPS API) is quite effective. Of course crippling the GPS API would have been highly visible and would have resulted in bad publicity, whereas what they have done here is more subtle and will cripple stuff like the geolocated picture albums which a lot of young people like these days. Otherwise, most people never realise their pics have or have not the location stored. Social media (FB etc) remove the EXIF location data (for the publicly visible version of the image; FB retains the data internally and offers you to add it later) to limit stalking etc.
I did the above test on an airliner, to avoid any possibility of getting any genuine WIFI based location assistance 
Actually there was no WIFI at all – unlike some recent Lufthansa flights which had WIFI but there was never any data available through it.
I could repeat the test on my S6 (android v5) but it’s probably not relevant because any non-rooted S6 will now be running android v6 or v7… Only rooted phones can block the constant “update your OS” nagging which pops up many times a day.
Why bother with Samsung when you can get this (see below): I thought they were dead and buried, but apparently not.
The question is – can you under IEEE harvest IP data of a WiFi network you are not connected to?
A very good Q.
You can definitely harvest the MAC of the WIFI device. You get that instantly, on the first packet you receive, and AFAIK it can be done passively. Even if SSID broadcast is disabled.
The IP, I don’t know. Probably not, since you have to pass DHCP to get an IP allocated. But isn’t DHCP done with UDP and that needs an IP address? I don’t know any detail of this.
I think WIFI location assistance uses the MAC, not the IP, because (due to above) a smartphone user walking around a city is not going to have DHCP allocated unless he successfully connects to a WIFI AP, and nowadays 99.9% of them are secured. 10 years ago it was a totally different story, but you could still probably not harvest IPs from a moving vehicle (which is what Google were accused of, IIRC).
I very much doubt google are sharing their wifi assistance database with the likes of Samsung… but you never know It would be really controversial.
Also the goalposts are moving because better 4G is rendering WIFI pointless – unless you want to upload a 5GB video somewhere (and then you usually find the WIFI is throttled to a useless slow speed, or disconnects every 10 mins).
EDIT: google is your friend. They use the MAC. This suggests they use the SSID too.
Peter wrote:
which is what Google were accused of, IIRC
They also recorded payload data, which for unencrypted networks would mean all sorts of personal communications etc.
Very probably that was just an engineer’s idea of “let’s collect the data first and see if we can do anything with it later”, but when it became public it obviously let Google appear in a bad light.
Peter wrote:
But isn’t DHCP done with UDP and that needs an IP address? I don’t know any detail of this.
The DHCP protocol is done with UDP but it uses broadcast so initially no IP addresses are needed. When computer requests an IP address, it just broadcasts the request using the appropriate port so it will reach the server regardless of the server’s IP address. (But the server has to be on the same subnet, obviously.)
When the server offers an IP address it again broadcasts. All computers with outstanding DHCP requests will receive the broadcast but it includes the MAC address of the computer that made the request so that all recipients can tell if the message was intended for them or not.
OK; many thanks. So drive-by IP collection is not feasible unless you drive (or walk) slowly enough to complete DHCP – which won’t happen with most WIFI access points because they are secure. It will however work with the public WIFIs which appear unsecured but need a login, so I am sure that data is collected too.
It is quite aggressive of Samsung to hack their camera app in this way, especially as with android 6+ they have reportedly hacked the camera API to ensure 3rd party camera apps don’t get access to the full camera resolution…
