How to look up the GPS location of your MAC address or car on the Internet

this one doesn't:

This is an interesting paper...

Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network Discovery Mechanisms

"We present two attacks that reveal the real MAC address of a device, even if MAC address randomization is used.

In the first one, we create fake hot spots to induce clients to connect using their real MAC address. The second technique relies on the new

802.11u standard, commonly referred to as Hotspot 2.0, where we show that Linux and Windows send Access Network Query Protocol (ANQP) requests using their real MAC address. ...

We show that *all* implementations of MAC address randomization fail to provide adequate privacy."

This is correct.

Everyone knows how to clone the "WAN MAC Address", which is as simply as pressing a button and typing "DE:AD:BE:EF:CA:FE".

It's the WLAN MAC address which doesn't have a "clone" button in the manufacturers' software/firmware.

I think what Jeff Liebermann was saying was that, for *routers*, you can change the WLAN MAC Address if you use the right custom firmware.

But we were talking about phones, so, Jeff also added that for Android phones, you can change the WLAN MAC address if you're root using the typical Linux commands we use all the time on Linux.

The situation would be likewise for jailbroken iOS phones, with the exception that, in practice, Apple seems to prevent that with each iOS upgrade, so, effecitvely, you can't change the WLAN MAC address easily on an iOS phone.

I got all my information from Jeff - who told me, a couple of years ago, that the "clone" in the consumer-class routers is for the wrong MAC address.

The only MAC address that matters, for this discussion, is the MAC address that the poorly configured Android devices in the vicinity are *uploading* to the Google PUblic database.

While what you're saying is true, that people don't change their WLAN Mac addresses even if they could, I have used only Netgear and Linksys and D-Link routers, and *none* of them have allowed me to change the one MAC address that matters for this discussion, which is the MAC address that is

*uploaded* to the Google Public Database by poorly configured Android devices in the vicinity.

The main question is:

1. Under what circumstances is an iOS or Android *phone's* MAC address

*uploaded* to the Google PUblic Database by poorly configured Android devices in the vicinity?

1. How can someone *exploit* that fact to locate the phone?

Since *this* discussion is *only* about exploring privacy flaws in the Google Public Database, the only BSSID that matters for this discussion is the BSSID that is *uploaded* to the Google Public Database by all poorly configured Android devices in your vicinity.

It's even worse than that.

1. While we all know that *hiding* the SSID is futile, it's actually

*useful* to hide your SSID in that the poorly configured Android devices apparently do *not* upload "hidden" SSIDs to the Google Public Database.

1. However, most of us don't "hide" our SSID from being broadcast (since there is almost zero security value in hiding the SSID broadcast).

2. Hence, our SSIDs are being *uploaded* to the Google Public Database by poorly configured Android devices whether or not we have "_nomac" at the end of the SSID.

1. What's worse, the *unique* BSSID of the radio is also uploaded at the same time (along with the signal strength of the SSID and the current GPS location of the poorly configured Android device).

Therefore, the SSID is the *least* of our privacy worries (unless we're dumb enough to name our SSID after our first and last name or something similarly identifiable).

The privacy concern is the association of the *hard-to-change* unique MAC address with its GPS location.

These two critical pieces of metadata are *uploaded* to the Google Public Database by poorly configured Android devices, whether or not you put "_nomac" on the SSID.

Bruce .... you're trying to argue that the world contains a lot of parameters, and nobody (not even me!) is disagreeing with you.

You may as well tell me that every radio has a MAC address or that every radio has an antenna or that every computer on the net has an IP address or that the BSSID is in every packet, etc.

Nobody is disputing what you're saying - but what you're saying has

*nothing* whatsoever to do with the topic at hand!

The topic at hand is *only* about the BSSIDs that are *uploaded* to the Google Public Database by poorly configured Android devices.

The two related questions are: a. Under what circumstances is your phone's BSSID uploaded to the Google Public Database? b. How would an attacker *exploit* that public database to track the

*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic here that "I" am trying to find out more about.

The two related questions are: a. Under what circumstances is your phone's BSSID uploaded to the Google Public Database? b. How would an attacker *exploit* that public database to track the

*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic here that "I" am trying to find out more about.

The two related questions are: a. Under what circumstances is your phone's BSSID uploaded to the Google Public Database? b. How would an attacker *exploit* that public database to track the

*location* of the phone?

If you want a *different* topic, then just say so - but *that* is the topic here that "I" am trying to find out more about.

It's interesting that all the operating systems implement the MAC address reandomization differently ... as outlined in that paper ...

2.1.1 iOS Apple added MAC address randomization to its devices starting from iOS 8 [42]. In iOS 8, randomized addresses are only used while unassociated and in sleep mode [18]. iOS 9 was extended to also use randomization in what Apples calls location and auto-join scans [42]. Based on our own experiments, this means that randomization is now also used when the device is active, i.e., when the screen is turned on. 2.1.2 Android Android 6.0 uses randomization for background scans if the driver and hardware support it [2]. Unfortunately, we did not have a device to test and verify this in practice. Although Android versions before 6.0 do not support randomization, several applications supporting this feature have been released [9, 3]. Common features of those applications are a periodical update of the MAC address to a random value, but also the manual modication of this address by the user. Note that those applications require root privilege to operate, which reduce their impact for the average user. 2.1.4 Linux Linux added support forMAC address randomization during network scans in kernel version 3.18. The address should be randomized for each scan iteration [24]. Drivers must be updated to support this feature. The mvm module of the iwlwifi driver supports randomization since kernel 3.18. The brcmfmac driver added support for this in kernel 4.5. The privacy-oriented Linux distribution Tails [1] does not support MAC address randomization during network scans. Instead, it generates a (new) random MAC address at boot. This random address keeps the rst 3 bytes of the original address, the Organization Unique Identier (OUI), and only randomizes the last three bytes. While not as optimal as periodical address changes, it does prevent tracking over extended periods of time. 2.1.3 Windows Microsoft supports randomization since Windows 10 [45]. Enabling randomization is possible if the hardware and driver support it. Interestingly, not only does Windows use random addresses for probe requests, it also uses a random address when connecting to a network. To assure the client always uses the same address when connecting to a particular network, a per-network address is calculated as follows [27, 28]: addr = SHA-256(SSID; macaddr; connId; secret)[:6] (1) Here SSID is the name of the network, macaddr the original MAC address, and connId a parameter that changes if the user removes (and re-adds) the network to its preferred network list. The secret parameter is a 256-bits cryptographic random number generated during system initialization, unique per interface, and kept the same across reboots [28]. Bits in the most signicant byte of addr are set so it becomes a locally administered, unicast address. This hash construction is similar to the generation of IPv6 interface identiers as proposed in RFC 7217 [21]. It assures that systems relying on xed MAC addresses continue to work as expected, e.g., when authentication is performed based on the MAC address. Users can also manually instruct the OS to daily update the per-network address randomly.

The cut and paste from PDF to newsagent went awry, so I'll use VIM instead for the cut and paste from PDF ...

2.1.4 Linux Linux added support forMAC address randomization during network scans in kernel version 3.18. The address should be randomized for each scan iteration [24]. Drivers must be updated to support this feature. The mvm module of the iwlwifi driver supports randomization since kernel 3.18. The brcmfmac driver added support for this in kernel 4.5. The privacy-oriented Linux distribution Tails [1] does not support MAC address randomization during network scans. Instead, it generates a (new) random MAC address at boot. This random address keeps the first 3 bytes of the original address, the Organization Unique Identier (OUI), and only randomizes the last three bytes. While not as optimal as periodical address changes, it does prevent tracking over extended periods of time 2.1.2 Android Android 6.0 uses randomization for background scans if the driver and hardware support it [2]. Unfortunately, we did not have a device to test and verify this in practice. Although Android versions before 6.0 do not support randomization, several applications supporting this feature have been released [9, 3]. Common features of those applications are a periodical update of the MAC address to a random value, but also the manual modification of this address by the user. Note that those applications require root privilege to operate, which reduce their impact for the average user. 2.1.1 iOS Apple added MAC address randomization to its devices starting from iOS 8 [42]. In iOS 8, randomized addresses are only used while unassociated and in sleep mode [18]. iOS 9 was extended to also use randomization in what Apples calls location and auto-join scans [42]. Based on our own experiments, this means that randomization is now also used when the device is active, i.e., when the screen is turned on. 2.1.3 Windows Microsoft supports randomization since Windows 10 [45]. Enabling randomization is possible if the hardware and driver support it. Interestingly, not only does Windows use random addresses for probe requests, it also uses a random address when connecting to a network. To assure the client always uses the same address when connecting to a particular network, a per-network address is calculated as follows [27, 28]: addr = SHA-256(SSID; macaddr; connId; secret)[:6] (1) Here SSID is the name of the network, macaddr the original MAC address, and connId a parameter that changes if the user removes (and re-adds) the network to its preferred network list. The secret parameter is a 256-bits cryptographic random number generated during system initialization, unique per interface, and kept the same across reboots [28]. Bits in the most significant byte of addr are set so it becomes a locally administered, unicast address. This hash construction is similar to the generation of IPv6 interface identifiers as proposed in RFC 7217 [21]. It assures that systems relying on fixed MAC addresses continue to work as expected, e.g., when authentication is performed based on the MAC address. Users can also manually instruct the OS to daily update the per-network address randomly

wait.

Notice this bit in the article:

Ie, the sensors only track those smartphones that are searching for networks. A phone that doesn't search will not be logged, can't be. And I guess that phones using wifi, ie, clients, can't either.

I don't think that those "poorly configured smartphones" track the clients of an AP. Too much traffic to be sending possibly over the poor user dataplan.

On the other hand, google already knows the location of all android phones, the instant they register. It doesn't need to ask "poorly configured smartphones" for that data.