[Nikker]

Now that the MACs are random does that really solve the problem? A probe request sends out the real MAC of the AP it's looking for as well as the AP ESSID. By using anyone of many translators you can get a map of each ESSID with GPS co-ordinates. While many people will be probing for Starbucks and McDonalds they will always have a unique probe for their own home AP. So now there is no "neat" way of using the MAC as a primary key you can still infer the user by the AP least in common with anyone else, i.e. which probes are NOT McDonalds et al.

So if my home AP ESSID is Einstein, MAC=deadbeef every time I enter a store my home AP MAC is still being recorded as well as the relative movement throughout the store. As well inter-relational data could be inferred by other AP MAC addresses if I visit a friend or family member it's likely that probe will connect us.

TL;DR Relations are based on unique data just because some of the data is 'scrambled' it's reliance on static data is it's weakness.

[hubert3]

Your assumption is incorrect - Probe requests do not contain the MAC of the AP, only the SSID. Wifi clients usually only save the name and security type/PSK of previously joined networks. In many situations, the same SSID is broadcast by multiple different APs with different MAC addresses in the same area so it wouldn't make sense to remember a specific SSID/MAC pair.

If the same client (iPhone) probes for a list of SSIDs with one random MAC and then probes for the same list again a short while later with a different randomised MAC, you could still track that individual based on the list of networks they probe for.

If the client MAC is randomised for every single new 802.11 probe that makes it harder but you could still track based on a single unique SSID probed for (i.e. something more unique than NETGEAR).

I'm going to look into this and possibly update my tool iSniff GPS.

[thefreeman]

each individual probe request will be coming from a randomized MAC, so there shouldn't be any "list" of SSIDs to compare.

[cpeterso]

The randomized MAC address doesn't help here. If two probe requests have different MAC addresses but the same SSID list, then the tracker can guess that they are the same device.

[Nikker]

Each device sends beacons out at an interval. By sorting all the probes by these intervals (10Hz or what ever) each will likely be slightly different from each other. So my device sends probes out at 0s another will send it out at 0.5s. Also by co-relating these beacons by signal strength well the random MAC doesn't really matter.

[nolite]

unless Apple also decided to stop sending out the SSID list..

[jdthomas]

This only occurs for 'hidden' networks. If you do not have any hidden networks in your known network list than you will not be broadcasting SSIDs. This is yet another reason to avoid setting your AP to hidden.

[codfrantic]

>This only occurs for 'hidden' networks.

Incorrect, this occurs for all networks! I've had some fun with Wifi Pineapples before.

http://nakedsecurity.sophos.com/2012/10/02/what-is-your-phon...

[xraystyle]

Do you have a source for this? Is there any documentation of this in the 802.11 spec? I'm also wondering if devices send a single probe per SSID they're looking for, or one probe with a list of SSIDs?

[jedberg]

I'm under the impression that every request is a different random MAC, until you connect to the wifi network.

[simoncion]

I'm under the impression that most "mobile" WiFi-enabled devices will actively probe [0] for APs that they've been associated with in the past. It's the SSIDs and MACs of these APs that will be used to figure out who you are, despite your ever-changing client MAC address.

[0] By the gods, this is such a stupid idea. Aren't beacons often sent at a 10Hz rate? Assuming that we've associated with a network that actually sends beacons, why wouldn't remaining silent, listening for the beacon, then associating work just as well as probing?

[userbinator]

I think this is a great example of how security and privacy gets sacrificed for convenience -- everyone seems more concerned with how fast they can connect to the first open WiFi network they find when they're roaming than what info they're broadcasting, and software's behaviour and interface reflects that. I'd like finer control over what my device does, like

- whether to automatically connect to any networks

- whether to use active scanning (and if it's off by default, I should be able to force one); passive scanning is fine unless you need to connect to networks without SSID broadcast, since it's just listening. Probably saves a tiny bit of battery too.

- better management of SSID list; I find the design where items in the list appear/disappear dynamically while you're trying to manipulate it rather irritating to use. I would prefer if there was an option to control whether the list gets updated, so it will stop accumulating useless networks. Finally, one for iOS (and Windows 8, which has regressed in this area): make it possible to forget and/or otherwise manage networks that are not in range.

[ENGNR]

I think they're saying you can still identify a device with pretty good certainty by the probe requests it sends. Probe will include the MAC of your home AP and other known APs, which are unique enough, even if your phone's MAC is changing with each probe.