Was Google Location Accuracy (now is How to Spoof Wi-Fi Location)

Andrews wrote on Sat, 26 Oct 2024 05:47:36 -0000 (UTC) :

I realized while answering Andy's questions that what is needed is not to "spoof" any particular Wi-Fi access point location, but to zero it out.

That is, any app that requires Wi-Fi access point information would get nothing so the app would have to fall back on GPS information instead.

Which can easily be spoofed.

Note: You don't use this stuff when you're routing; you use it for apps like a weather app that don't really need your exact location but they require it for the app to work (because they're mining your data).

So the question morphs to: How to we make sure ZERO Wi-Fi access point data is utilized when precise location is turned on with Google Location Accuracy?

Andrews, 2024-10-26 07:47:

On a real device? You can't do this.

With an Android emulator you can spoof any location you want for the apps. But this is only possible because the emulator is controlled by the host PC. On a real device you would need to fake the database which is used to derive the location based on the Wi-Fi SSID(s) the device can see.

No, it is not "GPS location" it is really just the location of the Wi-Fi access point which Google recorder earlier when other devices had GPS

You can't.

I'm wondering if carrying a Wi-Fi access point around with you might offer some benefits. Most (not all) Wi-Fi protocols allow only allow your phone to join only one wi-fi network at a time. The older protocols have this useful limitation. Later protocols, such as those which support seamless roaming, can connect to more than one access point.

If your phone is connected to a wi-fi access point that is under your control and is NOT connected to the internet, all the access point can do is provide your position when it last connected to the internet. In other words, instead of zero location data, give Google old or erroneous location data.

Reminder. I'm retired and am not keeping up to date on such things. I also don't have the time and resources to investigate this further. I have no plans to do any testing. Also, thank you for the long lists of URL's on the topic. I'm sure these would make interesting reading, but right now, I'm dealing with other projects and have other priorities.

Jeff Liebermann, 2024-10-29 18:17:

I don't think so. Because this access point can be seen by *other* devices which may report its current position. This is how Google learns the positions of Wi-Fi access points anyway.

Arno Welzel wrote on Wed, 30 Oct 2024 11:39:52 +0100 :

With Jeff's suggestion, we're finally making progress on the solution.

What Arno said is true that any access point (that advertises itself on airwaves as not hidden) will be seen (& uploaded) to the AP databases.

This upload is not done by you - but by all the rude people around you. Which is pretty much everybody who owns an Android phone (9,999 of 10K).

For the one out of 10,000 people who doesn't want to be in the AP db Google was forced to create an "opt out" mechanism to that upload.

Apple & Mozilla "say" they will respect Google's opt-out mechanism too. Microsoft uses a different opt out, though, namely xxx_optout_nomap

Notice it "can take up to five business days" for these outfits to scrub you from their access point databases, which means, effectively, as long as a rude Android owner is near you within those five days, you're screwed.

That's why you also need to set your SSID broadcast to "hidden" since all respectable companies will honor hidden broadcasts as "private" in intent.

Overall, that means your SSID needs only to have these three things: a. You start with the Google/Mozilla/Apple opt out (SSID_nomap) b. Then you add the Microsoft opt out (SSID_optout_nomap) c. Then you turn off the public broadcast (aka, hidden network). (See the sig for clarification on hiding the access point broadcast.)

I love that Jeff Liebermann has come up with a potential solution. I will dig into the references to see if what he suggests might work.

Any other ideas for Wi-Fi access point privacy are invited as Jeff, Andy, Arno and I seem to understand the goal of zeroing out Wi-Fi AP uploads while we're forced to use precise location for apps that don't need it.

Note: We don't zero it out during routing - but an insect lookup app which requires precise location doesn't really need it. They're mining you.

Andy Burns wrote on Mon, 28 Oct 2024 09:08:01 +0000 :

I realize I told Jeff Liebermann a slight mistruth when I said in the post that Andy is responding to...

"I just have to figure out HOW to tell what the heck they're spoofing. Maybe WireShark, Netstumbler, WiGle, etc., might tell me. Dunno.

You're the Wi-Fi expert who taught me everything I know, way back in the day when I was trying to spoof my MAC address (now the AP MAC addresses are spoofed by default on iOS and Android).

You told me, long ago, that you can't spoof the ROUTER's WAN-facing MAC address though - which - unfortunately - is the one we'd want to spoof!"

Since this thread wasn't about randomizing a MAC address, I didn't notice that what I said above is slightly wrong in "what" MAC address is randomized.

To be clear on the current state of Android MAC address randomization:

1. The home router's outward-facing (WAN) MAC address is NOT randomized (unless the router software allows that - which I don't know about).
2. What's randomized by default now is the mobile device MAC address that connects to the router's LAN-facing access point. This default mobile device (iOS & Android) randomization is per access point.
3. For Android only in Developer options" is another privacy setting to randomize #2 per connection (so it changes every time you connect).

When Jeff Liebermann and I last spoke about MAC randomization (oh, maybe ten or fifteen years ago or so), this default randomization didn't exist.

Now both iOS & Android do MAC randomization (per AP) by default.

To get info about what an AP (access point) can hear, dumping the ARP (address resolution protocol) table or collecting broadcasts seems like likely methods. There are various ways to limit the scope of the ARP table. The easiest way is to reduce the number of entries in the table one entry and assign a static ARP entry. Only one pre-specified device can connect. Another AP might be able to hear broadcasts from the pocket AP, but I suspect that it will not add ARP table entries for devices which cannot connect. This needs to be tested (not by me).

Jitsi meeting beckons. Later...

Andrews, 2024-10-30 14:55:

Not *people* - *devices*! People just use their devices and may not even be aware of this!