Bluetooth equivalent would be cool, then pairing bluetooth and wifi MACs based on temporal correlation. If one changes you can infer from the other. Over time you could split it to howmanylocalsaround verus howmanyvisitorsaround.
I used to do that, but my new phone has better batteries, so that isn't an issue any more. Combine that with my bluetooth headphones, and it's more convenient to just keep BT on at all times.
There's many accessories that rely on bluetooth nowadays: smartwatch/smartband, headset (moreover with the newest trend of ridding the 3.5 mm jack), etc.
Is this an important privacy issue from any practi al standpoint? The 'attacker' only gets a vague idea that some amount of smartphones are working nearby; I can't see any reasons to be concerned with such a privacy 'violation'.
Yes and no. Imho the issue at hand is that of a piece to a mosaic of over time and other sensor data.
For example, an important piece of data to pharmaceutical companies is which doctors are linked to prescriptions. Some states have rules against disclosing this information. If a company were to monitor target doctor's offices and pharmacies then the distribution data could provide clear indications of who is writing what prescriptions. Would this be a problem? To the degree that prescription filling discloses a health condition that a person considers private, the use of associational wifi monitoring might be seen as a privacy violation.
If this is seen as a problem, what could be done? In a sense, I think that the better solution is on the client/protocol side rather than attempting to enforce some "don't sniff" rule. Given the practicalities of updating clients, something on the rules side would have to be done, although I doubt it would be as effective as a speed bump.
I guess you can determine how many people are around you, that have a phone and it's switched on, with the wifi on as well (I personally turn off everything when it's not being used, mostly for battery reasons on this old clunker).
Pew Research Center says ~77% US adults own smartphones. [1] The director at Pew also tweeted a breakdown by country which shows a lot of variance. [2] Thus, this script won't work at all in a lot of places.
Is there a better way to check if an OUI is being used by a mobile phone or a router? e.g. There are plenty of huawei/apple routers and if one of them is in your neighborhood, you'd always get incorrect count. Similarly, there are many infamous smart phones and people use them but your code seems to ignore them.
Basically the OUI's I selected are from the ones with the top market share in the United States [1]. The marketshare is totally different in countries like India or Vietnam, so if people use this there they should be aware of this (maybe submit a PR to improve it :) ).
I'm open to suggestions to distinguish routers from mobile phones! Perhaps something like monitoring how "static" a mac address is (i.e. routers should never move and would be much less dynamic than signals from phones).
With two devices wouldn't it be possible to create a movement profile (disregarding the up direction)? I envision a GUI that lets me go back and forth in time with a slider and visually depicts the positions of phones/people at the time.
What kind of WiFi chip do you have? Make sure it supports monitor mode (if should list "monitor" when running `iw list`). Although, for reasons I don't understand, this may not be sufficient as my laptop built-in wifi does not see signals although plugging in the TL-WN722N allows it to work just fine.
Google have a GPS feed from a good proportion of phones, they don't need to sniff WiFi. Plus they'd have to sprinkle devices for detection throughout the world (I doubt mobile WiFi chipsets do monitor mode)
Little to do with channels, it's looking for ARP requests directly on the router. Your phone goes around screaming 'hey is STARBUCKS WI-FI' around?.. No response, so it goes to the next one it remembers.
For iPhones this only happens when un-associated [1] so this script will probably underestimate the count in public spaces. Although, I'm not sure whether the randomization includes the OUI?
In addition to collecting rogue broadcasts you can create a new virtual wifi interface in Managed mode with an ESSID like "linksys", "attwifi", or "xfinitywifi" (or all three?) and start collecting frames. This will bring out the people who don't broadcast.
I think you are right. In fact, this script might be illegal in some places as was brought to my attention. [1]
Do you know if collecting MAC addresses is illegal in UK? In US there is a statue against "intercepting electronic information" [2] but I'm not sure it applies because I don't know whether the MAC address is "electronic information".
There is some precedent, as Google got in trouble for sniffing packets, but they were actually definitely capturing information (emails/passwords) on un-encrypted networks. [3] In any case, I put a warning on the README.
Actually, it doesn't appear to be illegal (but IANAL).
The UK act applies mostly to trying to gain unathorized access to a computer system or network. If you put up your own wifi network and simply listen to your own interface's traffic, and other people access your network without your authorization, it's actually those devices connecting to your network that would be legally suspect - but intent matters, so the device accidentally connecting means they're not breaking the law.
In the US, sniffing the portion of a network which you do not own or operate is considered illegal wiretapping (or at least, it was at one time; I haven't looked into the most recent court cases). But if you own the network (your network interface in managed mode is basically your own AP), you can sniff it.
Your LICENSE should probably explicitly mention that this tool is for research purposes, that you provide no warranty whatsoever, and that anyone using it should follow all local, state, and federal laws at all times.
