If you know the MAC address of your equipment (e.g., automotive WiFi beacons), and the MAC address of someone else's equipment, how can you look up *where* your phone currently is?
I know that a public free easily accessible Google API maintains that information, where if you know the MAC address of the person you're trying to track, you can find out instantly if two MAC addresses are near each other from anywhere in the world:
For the Google lookup, the only *mandatory* parameters are:
MAC ADDRESS #1
MAC ADDRESS #2
A fabricated signal-strength value
However, there must be *other* MAC-address GPS-location lookup engines on the net, for example, you can track vehicle beacons here:
Do you know of other MAC address location lookup engines?
Not the MAC. You need the current IP. And the database works well only for fixed devices, not mobile. To know the current location of a mobile device you need a court order, and then tell his phone company to triangulate his signal. It is done on the phone number, not the IP, nor the MAC. Although it can be possible to correlate all figures.
Thanks for taking a risk by trying to answer the question.
You are completely correct in that the system works best for *fixed* devices, and I don't disagree one bit about that.
But ... if the intent is to track someone's wherabouts, then it has to work for a mobile device.
So, my key question is *when* does a mobile device broadcast it's MAC address (BSSID & SSID)?
Does a mobile device broadcast its MAC address when acting as a hotspot, for example?
Once the MAC address is broadcast as an AP, *all* the (poorly configured) Android devices in the vicinity will throw the user under the bus by handing that MAC address (and much more) to Google's constantly updated database.
PS: You're talking about a *different* process when you are talking about court orders and IP addresses - which is not relevant to this conversation of looking up two MAC addresses in the Google public database.
That data is broadcast only over wifi to devices in the vicinity that can listen on WiFi. There is no reason to broadcast this on internet to a google database; if this is done, you can opt out, and I have not seen the opt out for this. I have seen the opt out or in for other privacy data, but not this.
As far as I know, no. Not to google, that is. It is of course broadcast over wifi radio to those that intend to connect. It may be stored in Drive, same as password data, if you opt in to that. And it is treated as private data, so they say.
As far as I know, Android phones with GPS on listen to nearby WiFi AP traffic in order to tabulate where an SSID is located, so that later devices asking for location can be told where they are by listing what SSIDs are nearby. For this procedure a mobile AP SSID is plain useless.
You cannot. There is no necessary relationship between IP addresses and location. Now often there is some rough correlation, but that is all you can do.
Except for fun, I would not rely on it. As a trivial example, lets say I run a VPN from Vancouver to Italy. My IP will probably be an Italian one as far as the world is concerned. My computer however is in Vancouver.
I realize you're trying to help, so I will just try to be gentle at the same time I'm trying to be blunt (you can do the same with me).
Nobody said anything about IP addresses. And the *location* is inside of Google's database.
What I'm trying to understand is how the system works. And then I'm trying to see if there is a *vulnerability* in the system.
I'm not a hacker (as a hacker would have far more technical acumen and a hacker wouldn't be asking about a vulnerability on the net like this).
What I see is a *vulnerability* but you're *never* gonna see that vulnerability if you keep talking about IP addresses!
I realize you're trying to help, but just saying "Nope" wastes *everyone's* time, including yours and mine - but mostly other people have to read me responding to you, which, if all you say is "Nope" means you don't have a clue what you're talking about.
It's a *fact* that you can query Google's database to find the *location* of a BSSID. Google implemented a (IMHO weak) "security" system by requiring
It's this weak security that I'm searching for the vulnerability of.
It's a *fact* that you only need three things to get a GPS location out of the Google database:
BSSID 2 (added as a weak security feature!)
Do you dispute *that* fact?
That's not at all the point! I am probing a perceived privacy vulnerability in the Google system. I am doing this not to take advantage of that perceived vulnerability, but to better *understand* that privacy vulnerability.
Specifically, with the facts known, "if" your cellphone does broadcast an SSID, then your cellphone *can* be tracked.
Do you dispute that statement (which I have backed up in gory detail already)?
Why or why not?
*[Where is Jeff LIebermann when we need him?]*
What on earth does this question have to do with IP addresses?
I realize you're trying to help - but what you're doing is *jumping* to conclusions that *nobody* else is talking about.
VPN has *nothing* whatsoever to do with this problem. The entire Internet has (almost) nothing whatsoever to do with this problem.
The *only* way the Internet is even involved is that your neighbor's cellphone is *sending* your SSID & MAC & GPS location & Signal Strength (etc) of your router *over* the Internet to Google.
So the IP address (and VPN) is completely irrelevant to this question.
This question has absolutely nothing to do with IP addresses and VPNs. Where did you get the idea that the question had *anything* to do with the Internet? I'm sorry if I'm being too blunt, but I'm focused on getting the answer to a *simple* question.
Q: When does an Android cellphone broadcast an SSID?
NOTE: The SSID has nothing to do with the question but people get all hung up if I ask the question this way:
Q: When does an Android cellphone broadcast a BSSID?
Thank you for trying to help answer the question, as I realize answering such a deeply technical question involves risk - and we need to communicate so that we don't waste time on completely meaningless tangents.
First off we have to agree on some terms, and which are meaningful for the purpose of *this* thread:
- SSID: This is *not* very meaningful for the purpose of this thread! The SSID is only meaningful in that you can "do things" with your SSID which tell Google to do *other things*, e.g., you can append "_nomac" to the end of the SSID and Google promises to *drop* your information from its databases. But since SSIDs are not generally unique, the SSID is not the focus of *this* discussion.
- BSSID: This *is* the focus of this discussion, where each router has
*multiple* BSSIDs (aka MAC addresses) and where the focus of this discussion is *only* on the one unique MAC address that is transmitted in companion with the SSID of an access point!
It's critical that you understand that your statement is patently incorrect that the router MAC addresses that *Google* is collecting using your neighbor's Android device are easily cloned.
The MAC addresses that Google is collecting using your neighbor's poorly configured Android cellphone are *not* easily changed (you have one per each radio, e.g., 2.4GHz and 5GHz, for example).
These radio access point MAC addresses are NOT easily cloned! This has been covered in this newsgroup in detail in the past.
However, even if the router's MAC address could be cloned (it can't, at least not without desoldering and other heroic actions), it *still* would be collected by your neighbor's poorly configured Android device.
So, it doesn't matter that you can't clone the MAC address that Google is collecting by using your neighbor's Android device to automatically send that information to Google periodically during the day.
The fact is that all poorly configured Android devices are automatically sending Google throughout the day *your* MAC address of your router.
NOTE: While I'm completely aware that turning off SSID broadcast is possible (and that it's not useful for security), we are assuming for this purpose that the SSID is broadcast by the router.
I realize you are trying to help - but I must be blunt, since this *is* the critical question.
Since this *is* the critical question, a simple "No" is not enough, especially since your previous statements in this post show that you misunderstood completely the question and the situation.
I'm sorry if that sounds mean, but, a simple "No" is not believable under those two circumstances.
The correct answer might still be "No", but you don't understand the question yet, nor the technical situation, so a "No" all by itself doesn't help.
My key question is *when* does an Android cellphone broadcast the MAC but most people get all hung up about MAC addresses - so I'll dumb down the question to ask "When does an Android cellphone broadcast an SSID?".
Q: Under what conditions does an Android cellphone broadcast an SSID? NOTE: I don't care about the SSID - I care about the MAC - but people get hung up about MAC addresses so I'll ask it in the simpler form.
Hi Carlos, Thank you for responding again, as I realize it's risky when deeply technical subjects are being discussed (where is Jeff Liebermann when we need him!).
I think that you and I both know a lot and we both know nothing, because I can see huge technical flaws in your statements (and those of William Unruh) and you can (and he) can see similarly huge technical flaws in mine.
Yet, we're working torward the same goal, which is how to look up the GPS
*location* of two MAC addresses which we *presume* to be close to each other. (NOTE: This is not the *intent* of the Google database, so, all the talk about "the Internet" and "reasons for broadcast", etc., are absolutely meaningless for *this* purpose.)
For this purpose, we only care about what "is" a fact.
Basically, I can easily see a purported flaw in the system, and that's what I'm trying to publicly and openly and legally exploit by better understanding that reputed flaw.
The "flaw" is, that under certain circumstances, a device can be "tracked", using the Google public API in a valid but unusual way, which is to simply
*query* that database for two known MAC addresses.
Since we're *not* talking about *normal* purposes, but we're talking about a potential flaw, we should first iron out what we *agree* on as technical details.
GOOGLE DATABASE QUERY BY AN INDIVIDUAL
AUTOMATIC BSSID COLLECTION BY GOOGLE
MANUALLY OPTING OUT OF THE GOOGLE DATABASE
GOOGLE DATABASE QUERY: I am absolutely positive that only the following data is needed in order to run a search into the Google public API to find the *location* of a MAC address for those who own an account on the Google server: a. The BSSID (aka MAC address) of device 1 b. The BSSID (aka MAC address) of device 2 c. A signal strength of each (which can be bogus)
If you disagree, I will dig up a reference for that datapoint.
BSSID COLLECTION BY GOOGLE: I am absolutely positive that the BSSID of all access points that are
*seen* by almost all Android devices (except mine, because I know about this and therefore have turned it off) is being *sent* to Google periodically during the day by (most) Android cellphones. (NOTE: The Google cars *also* collect similar data; but this discussion has nothing to do with the Google car collection data, even though that car populates the same Google database.)
So this means that almost everyone with an Android device, who is near enough to your home to receive your WiFi signals, is both automagically
*collecting* and automagically *sending* to Google *your* access point information, under the conditions outlined below.
This includes: a. Your router's SSID b. Your router's BSSID (which is your all-important unique MAC address) NOTE: This is the nearly-impossible-to-change MAC address of your router (and not the trivially cloned MAC address of your router!). c. Your router's Signal Strength d. The current GPS location etc.
If you disagree, I will dig up a reference for that datapoint.
OPTING OUT OF THE GOOGLE DATABASE: While most of us "think" about SSIDs', and while the *collection* by Android devices consists of far *more* than *just* the MAC address, this discussion is limited to just the BSSID (aka MAC address) which is broadcast by access-point equipment, such as a home router.
I am absolutely positive that one can not stop someone else's Android cellphone from collecting your router's broadcast MAC address *except* by either: a. Turning off the broadcast (which does not hide it from the packet but which Google will respect as an indication you don't want to be in their DB) b. Appending "_nomap" to your SSID (which google will respect *after* the fact, e.g., your neighbor's Android phone *collects* your SSID/MAC/SS/etc., and your neighbor's Android phone *sends* that SSID/MAC/SS/etc. to Google, but Google (says they will) remove your SSID from their records upon receipt.
My main question here is *when* does a mobile device *broadcast* its SSID (where what really matters is the MAC address!)?
However, before we can get to that critical question, we have to understand the three technical points above.
Do you agree or disagree with the three technical FACTS as I see them?
In the following I tend to intersperse WAN and LAN as well as BSSID and MAC. The basic underlying concepts work in both environments (with some fudging).
SSID has nothing to do with cellphones. It has to do with wifi only. The same is true for BSSID.
SSID is just a name. There could be thousands of wifi access points around the world with the same SSID.
A wifi access point consists of one or more radios to create a WAN. Each radio is a BSS with a BSSID, which is also known as a MAC. Each network device/radio has (by design, but not always in fact) a unique value for the MAC.
A device wishing to connect to a wifi access point looks for a broadcast wifi packet with a particular SSID in the data field of the packet. The header to the packet contains the BSSID/MAC of the access point in source field. To connect to the access point the device sends a packet back to the sender of the broadcast by putting the access point's BSSID in the destination field of the packet and its own MAC in the source field. The rest of the connection protocol is left as an exercise for the reader.
Until things get handed over to (presumably) DHCP there is no way to communicate other than the use of MAC addresses in the appropriate fields of the LAN packets. Strictly speaking, even after an IP address is assigned to the device, all communications on the LAN/WAN is still through the use of BSSID/MAC. It is only after a packet is recieved by the router that higher levels of network communications kick in and a packet will be repackaged with the necessary outer packet to make its way to the internet.
So, "Q: When does an Android cellphone broadcast an SSID?"
A: Keying on the use of the word "broadcast" and ignoring the use of the word "cellphone" because it doesn't apply, only when it is acting as its own access point/hot-spot for other devices. After all, an SSID is only a name.
And, "Q: When does an Android cellphone broadcast a BSSID?"
A: Again, keying on the use of the word "broadcast" and ignoring the word "cellphone" the answer is the same as for the previous question. However, as mentioned earlier, the MAC/BSSID is used in every packet that is sent back and forth with the access point, but is strictly usable only within the geographic area that the radio signals reach, which is pretty much limited to line of sight communications and for which walls are only semi-transparent at those frequencies.
Now, with all that said, there is in theory nothing to stop any program running as part of the wifi access point or within the connecting device to query its own networking internals to grab its own MAC address or the MAC address of devices it is communicating with and send that info out onto the internet to some recipient along with info from its own GPS, if available.
So, while it is not part of the normal protocols to reveal that information it is not inconceivable that some user level program could be doing the nasty deed.
Furthermore, all of this is at best fleeting information because a network device's MAC address is held in ROM on the device. The network software in a device reads the ROM to get the MAC, but is in no way required to use that address when constructing packets that will go out the device. The device itself *DOES NOT* insert the address into the outgoing packets. That is all handled by software. Therefore it is trivial for the software to use whatever MAC address it wants for its outgoing packets. This is in fact how DECnet used to work, the two high order bytes of the MAC were changed to reflect the fact that a packet was a DECnet packet.
As was said before, just flip a few bits and you could suddenly appear to be on the other side of the planet.
Now, what has been left out? Oh yes, the cellphone network. How data is sent over the cellphone network is probably off topic for most of the newsgroups listed above. Therefore, I suggest you redirect your queries/confusions to more appropriate groups.
and the like. (I Googled for "Android, cellphone, collecting router SSID, location, privacy" and got those and many other articles.)
There's two broad categories: whether there are risks to the person carrying the cellphone and whether there are risks to the people around them operating a wireless router.
It looks to me like you are NOT talking about risks to the wireless router owners. You're asking about locating a cellphone owner, so I'll focus on that.
There were several ideas floating around a few years ago, as I recall.
In NYC skyscrapers and the like, there are situations where knowing more than just the street address might be useful. If the building has wireless routers, and if their locations are known, then it becomes possible to estimate which floor one is on from which router signals one hears and how strongly.
IIRC (and I might not be), there was talk of whether it would be practical to gradually replace expensive cellphone towers with large numbers of cheap WiFi access points for cellphones (femto access points, I think I've heard them called). Doing so would also help pinpoint the cellphone's location more accurately than is possible with the big cellphone towers, since the range of any particular femto-cell would be small. Cellphones able to switch between cellphone mode and WiFi mode on the fly, or even just use WiFi for data, might also reduce TelCo-metered usage.
You speak about getting a location via Google even though you enter a fake signal strength. I don't see how that can work. If you say a signal is really strong, that indicates you're close. If you say the signal is weak, you're further away. Choose any combination of places around the world and make up whatever signal strengths you like, and you probably can get a result anywhere on Earth, even if those numbers are impossible in practice.
If I have a wireless router in Google's database, and you submit something that says you hear my router (at all), I would think it'll say you're somewhere near me, even if you aren't. As you enter more numbers, you can triangulate a position, but if you're making up numbers, the answers wouldn't be meaningful.
A few specific po> "if" your cellphone does broadcast an
(B)SSID aside, all cellphones are tracked to the level of "nearest cellphone tower" whenever they're on. If they're within range of more than one tower, the range of possible locations is greatly reduced.
Huh? The wireless routers I've configured allow changing of their MAC addresses, often during the initial setup/configuration. (See DD-WRT, ifconfig options wlanbssid #id and wlanaddr #addr (the latter sets the WLAN local MAC address). Regarding some other options, 'man ifconfig' says "Note that this feature does not significantly enhance security as MAC address spoofing is easy to do.")
There once was a company that manufactured Ethernet devices that all had the same MAC address. When customers discovered that, they got upset. The manufacturer changed to providing unique addresses (I think). While customers could change the MAC address, they didn't have enough information to ensure the address they chose was unique, as the manufacturers do.
OTOH, if you meant cellphone instead of router, I'd mostly agree: cellphone handsets are intended to have unique IDs. However, I'm not sure whether that's the same as the MAC address the cellphone would use to connect to a WiFi hotspot (but maybe it is).
Whether it's changeable or not doesn't really matter: once a router has been configured, its MAC addresses are rarely changed (short of replacing the router), so once SSID X has been heard transmitting at location Y, the X,Y pair should be valid for some time. [I can also think of ways to handle the case of duplicate MAC addresses (except when the duplicates are operating so close to each other that one can be in both of their signal areas at the same time).]
Fortunately, they're irrelevant to the question of whether Google's database can be used by someone remotely to locate a cellphone user in the absence of actual signal information. I don't see an obvious way to do that. There's also the method of accessing the cellphone's own recorded location history file (see articles), but that doesn't involve Google.
The source and destination MAC address of ALL Wi-Fi packets are in the
802.11 packet headers. For broadcasts and management packets, only the source MAC address is present. The address is NOT encrypted. Note that all 802.11 Wi-Fi is done on Layer 2 (MAC layer) and does not involve Layer 3 (IP layer).
Yes. Broadcasts include the source MAC address, but no destination MAC address because they go to all devices on the network. For example, an ARP request packet, which asks "which device MAC address has this IP address?", includes the MAC address of the device that asked for the information, but nothing in the destination field.
Yep. Resistance if futile. You've already been assimilated.
The problem is the matter of user identifiable information. MAC addresses are tied to a specific piece of hardware, which is most certainly user identifiable. Dynamic IP addresses can be traced to a specific piece of equipment, but only if the local ARP table is recorded. If Google or other information harvesting service claims that they are not collecting user identifiable information, in theory, they should not be collecting MAC addresses, but might collect IP addresses from unencrypted ARP broadcasts and replies. An unencrypted captured Wi-Fi packet with the IP address must have the source MAC address included, so if Google logs IP's, they certainly can also log corresponding MAC addresses. Google collected the SSID and MAC address, but apparently was also collecting payload information, which included the IP and who knows what else.
Note: No more Q&A from me for a few more days. I sprained both wrists and it hurts to type.
Yes. I beg to differ. ALL (and I do mean ALL) 802.11 bridging is done on Layer 2 (MAC layer) and does not involve IP addresses or magic. In order for an infrastructure client radio (laptop, smartphone, media gizmo, etc) to know how to get it's packets to the central access point, it uses a table of MAC addresses to define a route. That means that every wireless device has to know the MAC address of every other wireless device and certainly that of the cental access point. Since the headers containing the MAC address are NOT encrypted, they are easily extracted. Just take any wi-fi sniffer or monitor program and sniff some encrypted traffic. You won't see inside encrypted payloads, but you'll certainly see all kinds of MAC addresses (including those from software access points) extracted from the headers.
Sorry, but that was over-simplified. In peer-to-peer wireless network, every wireless device needs to know the MAC address of every other wireless device. However, in infrastructure mode, each device needs to only know the MAC address of the central access point. Of course, the central access point needs to know the MAC address of all connected wireless devices.
"Nordstrom, the store that the New York Times focuses on in its piece (although it's not the only one doing this) installed sensors around some of its stores that would scan for smartphones with Wi-Fi turned on and scanning for networks. The sensors would then make note of the device's MAC address (an address that's unique to your phone) and use it to identify and follow the device as it moves about the store. Information about how frequently that MAC address visits the store, which departments it visits when it's in the store, how long it stays in each department, and how long it stays in the store. Granted, you are not your phone's MAC address, but if you carry your phone with you all the time, you may as well be. As the NYT explains:
Nordstrom?s experiment is part of a movement by retailers to gather data about in-store shoppers? behavior and moods, using video surveillance and signals from their cellphones and apps to learn information as varied as their sex, how many minutes they spend in the candy aisle and how long they look at merchandise before buying it."
Hi Jeff, I'm only going to respond to you, and not to the many trolls who can't even understand the question, and have never added value to *any* thread ever (namely, Andy Burns, Frank Slootweg and Kerr-Mudd John, et al.) since you are the only one here who both understands what I'm asking and who knows more than I do about what I'm asking.
I hope your wrist is feeling better (did you fall off a rooftop installing antennas over there in Santa Cruz? I thought you gave all that up!).
I am not sure if it's germane to the question, but to understand what you're saying, it's that the TCP/UDP *packet* contains the MAC address of the cellphone 2.4 GHz or 5GHZ WiFi connection (whichever is being used in the WiFI connection).
Again, I'm not sure if the packet contents are germane to the question, but, certainly I see that you're saying the MAC address of the 2.4GHz or
5GHz radio inside the cellphone is *known* to any access point that this cellphone communicates with.
Likewise, if the cellphone is acting as an *access point*, it must communicate its BSSID (aka MAC address) to any device that *wants to* connect to that access point. Right?
I appreciate your detail, Jeff, as you're always very detailed. I certainly agree that the MAC address of the cellphone 2.4GHz and 5Ghz radios is known to any access point that this cellphone connects to, and anyone who sniffs the air can also sniff out that MAC address.
But, I'm specifically asking about a specific process that Google implemnted in Android cellphones whereby most people (not me, but most people) have their cellphones set to hand over to google many times a day all the SSID/MAC/GPS/Signal Strength, etc., information that these poorly configured cellphones can hand to google.
I thank you Jeff for the details, as you are one of the few people here who back up what you say - but my specific question is all about Google.
It is well known that most Android phones (not mine but most others) are set up to send to Google periodically all the SSID/BSSID/SignalStrength information the phones see, along with GPS information, of all access points that these poorly configured phones encounter.
Specifically, that means my own dumb neighbors, plus all the idiots who drive by my house, are sending to Google "my" SSID/BSSID/SignalStrength/ and their GPS location, periodically during the day.
Even though "I" have _nomap on my SSID, the information is *still sent* to Google (Google simply promises to not put that information into its public database).
To access this public database, it is well known that you only need to know three things (the penultimte being added simply for security reasons):
The MAC address you seek
Another MAC address that is known to be nearby
The signal strength
If you hand that information to the Google publid databsae (the second only having been added for security purposes), Google will hand you back the
*gps location* of those two MAC addresses, if they are in close proximity.
Given that, it would be easy to track a specific cellphone *if* that cellphone broadcasts its MAC address such as to be included in the Google API.
What would I have to do, for example, to make my cellphone broadcast its MAC address such that one of those poorly configured Android phones (which is almost all Android devices out there) would *think* my cellphone is an Access Point - and hence it would send Google that SSID/MAC/SS and it's GPS location for inclusion in the Google public database?
That question is key, because if my cellphone MAC is included in that Google database, it can be tracked.
Hi Jeff, There really is only one question, which is the following:
- Under what conditions does a cellphone SSID/MAC/SS get put into the Google Public API by *other* (poorly configured) Android cellphones?
While I realize the *packet* contains the MAC address of the cellphone
2.4GHz and 5GHz radios, what I'm asking is under what contitions *that* MAC address is handed over to the Google Public Database (along with your SSID, GPS location, and signal strength) by most poorly configured Android devices.
This is key! My whole question is when does the cellphone (whether iOS or Android) get its MAC address put into the Google Public Database.
The Google Public Database obtains its information from poorly configured Android devices which hand to Google every day all the public APIs that these phones encounter (along with the Mac address of the API, the Signal Strength of the API, and the current GPS location of the cellphone).
So you have confirmed that any cellphone (iOS or Android) which broadcasts itself as an access point (whether it has security or not), will almost certainly already be *in* the Google Public Database.
That means that any cellphone broadcasting as an access point will have: a. Its last GPS location in the Google Public API b. Its last signal strength in the Google Public API c. Its MAC address in the Google Public API d. And its SSID in the Google Public API
So, notice the flaw? If I know the MAC address of teh ios or Android phone, and I know the MAC address of the router at the local starbucks, I can query the Google database to see if the two are in close proximity to each other.
*that* is the tracking I'm discussing.
You've confirmed that if the iOS or Android cellphone is broadcasting its SSID (whether enrypted or not) as an Access Point, then its GPS location, SSID, BSSID, and Signal Strength is already in the Google Database, because all poorly configured Android devices that encounter that iOS or Android cellphone will be reporting it to Google every single day.
However, the question remains:
- Under what *other* conditions (other than broadcasting as an Access Point) does an iOS or Android cellphone get put into the Google PUblic API by poorly configrued Android devices?
I can't think of any other circumstances where the iOS or Android device SSID/MAC/SS? and GPS location will be put into the Google Database, but that's the question.
Is there any other time, other than when acting as an Access Point, that the iOS or Android cellphone will have its SSID/MAC/SS & GPS location put into the Google Public Database by poorly configured Android cellphones?