Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: How to look up the GPS location of your MAC address or car on the Internet
43 views
Skip to first unread message
Horace Algier
Sep 14, 2016, 12:40:49 AM9/14/16
to
On Wed, 14 Sep 2016 00:24:59 -0000 (UTC), William Unruh wrote:
>> 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?
>
> 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.
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 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:
>> https://developers.google.com/maps/documentation/geolocation/intro
>
> Nope.
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
*two* BSSIDs.
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:
1. BSSID 1
2. BSSID 2 (added as a weak security feature!)
3. Signal Strength
Do you dispute *that* fact?
>> For the Google lookup, the only *mandatory* parameters are:
>> 1. MAC ADDRESS #1
>> 2. MAC ADDRESS #2
>> 3. A fabricated signal-strength value
>
> Except for fun, I would not rely on it.
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?
> As a trivial example, lets say I run a VPN from Vancouver to Italy.
*[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.
> My
> IP will probably be an Italian one as far as the world is concerned. My
> computer however is in Vancouver.
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?
>> 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?
>
> 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.
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 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:
>> https://developers.google.com/maps/documentation/geolocation/intro
>
> Nope.
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
*two* BSSIDs.
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:
1. BSSID 1
2. BSSID 2 (added as a weak security feature!)
3. Signal Strength
Do you dispute *that* fact?
>> For the Google lookup, the only *mandatory* parameters are:
>> 1. MAC ADDRESS #1
>> 2. MAC ADDRESS #2
>> 3. A fabricated signal-strength value
>
> Except for fun, I would not rely on it.
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?
> As a trivial example, lets say I run a VPN from Vancouver to Italy.
*[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.
> My
> IP will probably be an Italian one as far as the world is concerned. My
> computer however is in Vancouver.
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?
Horace Algier
Sep 14, 2016, 12:41:06 AM9/14/16
to
On Wed, 14 Sep 2016 00:27:22 -0000 (UTC), William Unruh wrote:
>> So, my key question is *when* does a mobile device broadcast it's MAC
>> address (BSSID & SSID)?
>
> Those have nothing to do with the MAC addresses. And the Mac address of
> a device ( a wireless card-- that is what a MAC address is the address
> of) can be changed at will
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.
>> Does a mobile device broadcast its MAC address when acting as a hotspot,
>> for example?
>
> No.
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.
>> So, my key question is *when* does a mobile device broadcast it's MAC
>> address (BSSID & SSID)?
>
> Those have nothing to do with the MAC addresses. And the Mac address of
> a device ( a wireless card-- that is what a MAC address is the address
> of) can be changed at will
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.
>> Does a mobile device broadcast its MAC address when acting as a hotspot,
>> for example?
>
> No.
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.
Andy Burns
Sep 14, 2016, 2:35:39 AM9/14/16
to
Horace Algier wrote:
> I'll dumb down the question
Doesn't matter if the hat says "Alice J", "Aardvarks" or "Horace",
> I'll dumb down the question
people don't want to go over the same ground again ...
Frank Slootweg
Sep 14, 2016, 3:55:00 AM9/14/16
to
Horace Algier <hor...@horatio.net>... oops I mean "Aardvarks"... oops I
mean "Paul M. Cook"... oops I mean "VPN User"... oops I mean "Joe
Clock"... oops I mean "Marob Katon" ... oops I mean "Chris Rangoon"...
wrote:
'question' isn't a question, but a false statement.
HTH.
mean "Paul M. Cook"... oops I mean "VPN User"... oops I mean "Joe
Clock"... oops I mean "Marob Katon" ... oops I mean "Chris Rangoon"...
wrote:
> 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.
You don't ask a dumbed down question, but a dumb question and your
> 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.
'question' isn't a question, but a false statement.
HTH.
bruce
Sep 14, 2016, 6:47:06 PM9/14/16
to
> 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?
Oh, what the hell. I'll give it a try.
> 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?
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.
Whew!
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.
Bruce .
--
Kerr Mudd-John
Sep 15, 2016, 6:53:13 AM9/15/16
to
--
Bah, and indeed, Humbug
Horace Algier
Sep 16, 2016, 3:56:55 PM9/16/16
to
On Wed, 14 Sep 2016 18:41:22 -0400, bruce wrote:
> Oh, what the hell. I'll give it a try.
Thanks Bruce. I'm always nice if someone is sincerely trying to answer the
> Oh, what the hell. I'll give it a try.
question, and, I do realize that most people don't even *understand* the
question.
> 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).
and 2.4GHz radios in the iOS or Android cellphones we are trying to track.
That MAC address is also called a BSSID.
Google also logs the SSID, the signal strength, and the GPS location, but
they are not of importance for *this* discussion.
Only the MAC address (aka BSSID) is important for *this* discussion.
> SSID has nothing to do with cellphones. It has to do with wifi only.
> The same is true for BSSID.
As Jeff and I just discussed, if an Android or iOS cellphone acts as an
Access Point, then that cellphone will broadcast an SSID.
If that iOS or Android cellphone broadcasts an SSID, it also broadcasts a
BSSID, which is unique to that cellphone. In fact, it broadcasts *two*
BSSIDs, one for each radio (5Ghz and 2.4Ghz).
It's *those* unique BSSIDs which are captured by poorly configured Android
devices and uploaded multiple times a day to the Google Public Database,
along with the GPS location of the poorly configured Android device and the
SSID and Signal Strength of the access point.
Notice this allows such iOS or Android cellphones to be tracked!
> SSID is just a name. There could be thousands of wifi access points
> around the world with the same SSID.
promises to *drop* that SSID from its' public database.
However, you must realize that the Google Public Database contains *more*
than the SSID! It contains the *unique* BSSID associated with that SSID,
and furthermore, it contains the Signal Strength of that access point at a
specific GPS location of the poorly configured Android device that is near
that access point.
Anyone who doesn't *understand* that paragraph above can't possibly
understand the topic of this thread - so it's critical that the paragraph
above be *understood*.
> 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.
access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
a. The cellphone AP SSID
b. The cellphone AP BSSID
What you must understand to understand the question, is that poorly
configured Android devices will *send* to Google not only that information
above, but *more* information!
Poorly configured Android devices will send to Google:
a. Your cellphone AP SSID
b. Your cellphone AP BSSID (aka MAC address)
c. Your AP signal strength seen by the poorly configured Android cellphone
d. The GPS location of the poorly configured Android cellpone
> 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.
both iOS and Android devices is sent in the clear in packets whenever those
cellphones connect to an access point.
But I'm not talking about that.
I'm only talking about when an iOS or Android cellphone has the following
four bits of information *sent* to the Google database by poorly configured
Android devices:
a. Your cellphone AP SSID
b. Your cellphone AP BSSID (aka MAC address)
c. Your AP signal strength seen by the poorly configured Android cellphone
d. The GPS location of the poorly configured Android cellpone
> 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.
Public Database, to obtain MAC addresses of devices.
For example, this web site from wardriving software:
https://wigle.net/
But *this* question is complex enough for most people (almost nobody
understood the question) if I simply stick to the Google mechanism.
Lord knows how complex this question gets if I bring in the Wigle
wardriving mechanism (which even I don't understand).
> 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.
Or anything from Marius Milner (e.g., netstumbler).
> 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.
Jeff Liebermann explained in the past why it would take an heroic effort to
clone the MAC address of the radio that is sending out the packets.
The cloning is on a different MAC address, which is not the MAC address of
concern here.
Too bad, becuase if it were easy to change the Access Point MAC address,
then I would change mine daily.
> As was said before, just flip a few bits and you could suddenly appear
> to be on the other side of the planet.
You're confusing the easily cloned MAC address with the one that would take
desoldering to change.
bruce
Sep 17, 2016, 4:47:05 PM9/17/16
to
Horace Algier <hor...@horatio.net> writes:
I purposely kept my earlier post at a fairly high level, mostly because
from your other posts I was left with the opinion that you weren't
handling the information you were presented with very well. I attempted
to provide some background for the discussion so that we could at least
agree on the meaning of various terms and the concepts that use those
terms.
While your reply was cordial, for the most part, you did with me as you
have done with others, namely rejected statements which are easily
verified as true.
> On Wed, 14 Sep 2016 18:41:22 -0400, bruce wrote:
>
>> Oh, what the hell. I'll give it a try.
>
> Thanks Bruce. I'm always nice if someone is sincerely trying to answer
> the question, and, I do realize that most people don't even
> *understand* the question.
>
>> 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).
Again, here I was attepting to lay a background.
>
> All we care about, for *this* discussion, is the MAC address of the
> 5GHz and 2.4GHz radios in the iOS or Android cellphones we are trying
> to track.
>
> That MAC address is also called a BSSID.
>
> Google also logs the SSID, the signal strength, and the GPS location,
> but they are not of importance for *this* discussion.
>
> Only the MAC address (aka BSSID) is important for *this* discussion.
And here you are trying to bore down to a lower level prematurely, IMHO.
>> SSID has nothing to do with cellphones. It has to do with wifi only.
>> The same is true for BSSID.
>
> This is not true that "SSID has nothing to do with cellphones".
Yes, I'm afraid it is true. To reject it implies that you believe that
all cellphones do wifi. I have two on the shelf in this room that do
not do and never did do wifi.
> As Jeff and I just discussed, if an Android or iOS cellphone acts as
> an Access Point, then that cellphone will broadcast an SSID.
This is consistent with what I wrote above and what I wrote below. This
action has nothing to do with it being a cellphone but to do with it
acting at this point as a wifi device.
> If that iOS or Android cellphone broadcasts an SSID, it also
> broadcasts a BSSID, which is unique to that cellphone.
Not necessarily. The protocols allow the creation of a BSSID on the
fly. It only has to be unique within the (very short) range of the
radios in use.
> In fact, it
> broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).
Actually, any wifi device acting as a BSS can identify itself as up to
32 BSSIDs and 1 or more SSIDs per radio. So, yes, a single radio can
simultaneously be using 32 different BSSIDs/MACs.
> It's *those* unique BSSIDs which are captured by poorly configured
> Android devices and uploaded multiple times a day to the Google Public
> Database, along with the GPS location of the poorly configured Android
> device and the SSID and Signal Strength of the access point.
As I said below, poorly configured has nothing to do with it when any
user level program running on the BSS or within the cellphone can access
the very same wifi information and pass it on to whomever it wishes.
> Notice this allows such iOS or Android cellphones to be tracked!
Did I ever say anything to contradict this? I merely pointed out that
cellphone configuration, if done "properly" (whatever that means) won't
cure the problem when user level code running on the equipment can
accomplish the same thing. In fact, it might be through user level code
that it is being accomplished right now.
>> SSID is just a name. There could be thousands of wifi access points
>> around the world with the same SSID.
>
> I agree. SSID is "just a name". If the name ends with "_nomac", Google
> promises to *drop* that SSID from its' public database.
While Google might honor the use of the suffix (for now) it doesn't mean
that anybody else will.
> However, you must realize that the Google Public Database contains
> *more* than the SSID! It contains the *unique* BSSID associated with
> that SSID, and furthermore, it contains the Signal Strength of that
> access point at a specific GPS location of the poorly configured
> Android device that is near that access point.
>
> Anyone who doesn't *understand* that paragraph above can't possibly
> understand the topic of this thread - so it's critical that the paragraph
> above be *understood*.
That "paragraph above" means absolutely nothing until one understands
that even in a "properly configured" phone user level code could be
gathering the same information (or more) and sending it to agents
unknown.
>> 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.
>
> I agree. Specifically, if an iOS or ANdroid cellphone is acting as an
> access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
> a. The cellphone AP SSID
> b. The cellphone AP BSSID
>
> What you must understand to understand the question, is that poorly
> configured Android devices will *send* to Google not only that information
> above, but *more* information!
>
> Poorly configured Android devices will send to Google:
> a. Your cellphone AP SSID
> b. Your cellphone AP BSSID (aka MAC address)
> c. Your AP signal strength seen by the poorly configured Android cellphone
> d. The GPS location of the poorly configured Android cellpone
As stated above, poorly configured is not the problem, and Google might
not be the only recipient.
>> 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.
>
> This part is understood that the BSSID of the 5Ghz and 2.4GHz radios
> in both iOS and Android devices is sent in the clear in packets
> whenever those cellphones connect to an access point.
>
> But I'm not talking about that.
>
> I'm only talking about when an iOS or Android cellphone has the
> following four bits of information *sent* to the Google database by
> poorly configured
> Android devices:
> a. Your cellphone AP SSID
> b. Your cellphone AP BSSID (aka MAC address)
> c. Your AP signal strength seen by the poorly configured Android
> cellphone
> d. The GPS location of the poorly configured Android cellpone
Get off this poorly configured fixation you have. A perfect config-
uration with any amount of user-level programs has potentially the same
nasty possibilities.
>> 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.
>
> Yes. You are correct that there are *other* methods, other than the
> Google Public Database, to obtain MAC addresses of devices.
>
> For example, this web site from wardriving software:
> https://wigle.net/
>
> But *this* question is complex enough for most people (almost nobody
> understood the question) if I simply stick to the Google mechanism.
>
> Lord knows how complex this question gets if I bring in the Wigle
> wardriving mechanism (which even I don't understand).
>
>> 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.
>
> Yep. Wardrivign software.
> Or anything from Marius Milner (e.g., netstumbler).
Or maybe even "Angry Birds" does this too!
>> 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.
>
> This is not true.
Actually, you are partially correct. DECnet changes the leading four
octets (notice, the proper term is octets, not bytes; I was too casual
in the above paragraph) to "AA 00 04 00". The remaining 2 octets make
up the node within a DECnet network. How do I know this? I'm an
ex-DECie. (Actually, I'm still a DECie but they don't pay me anymore.)
If you want a reference on this a brief desctiption may be found at
<https://en.wikipedia.org/wiki/DECnet> which contains the following:
"The Ethernet implementation was unusual in that the software
changed the physical address of the Ethernet interface on the
network to AA-00-04-00-xx-yy where xx-yy reflected the DECnet
network address of the host. This allowed ARP-less LAN operation
because the LAN address could be deduced from the DECnet address."
I've avoided making any references to 802 so far here. And my DECnet
references mostly concern(ed) 802.3, 802.<whatever> all have the same
underpinnings. DEC was one of three companies that colaboratively
"invented" ethernet (at least the hardware specs, that is). The origin
of ethernet comes from the amateur radio two meter band protocols used
in Hawaii, which was called "Aloha Net".
> Jeff Liebermann explained in the past why it would take an heroic
> effort to clone the MAC address of the radio that is sending out the
> packets.
Without reference I can not comment on this, but what I'm talking about
for MAC has nothing to do with cloning.
> The cloning is on a different MAC address, which is not the MAC
> address of concern here.
Huh?
> Too bad, becuase if it were easy to change the Access Point MAC
> address, then I would change mine daily.
You might want to look into this then.
>> As was said before, just flip a few bits and you could suddenly
>> appear to be on the other side of the planet.
>
> Not true.
> You're confusing the easily cloned MAC address with the one that would
> take desoldering to change.
That statement is most definately true. I can assure you that when a
VAX computer was moved from one location to another nobody went running
for a soldering iron.
If changing the MAC address (also called the hardware address) was so
difficult, why do you suppose the capability exist in ifconfig(8) to
change it?
Bruce .
--
I purposely kept my earlier post at a fairly high level, mostly because
from your other posts I was left with the opinion that you weren't
handling the information you were presented with very well. I attempted
to provide some background for the discussion so that we could at least
agree on the meaning of various terms and the concepts that use those
terms.
While your reply was cordial, for the most part, you did with me as you
have done with others, namely rejected statements which are easily
verified as true.
> On Wed, 14 Sep 2016 18:41:22 -0400, bruce wrote:
>
>> Oh, what the hell. I'll give it a try.
>
> Thanks Bruce. I'm always nice if someone is sincerely trying to answer
> the question, and, I do realize that most people don't even
> *understand* the question.
>
>> 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).
>
> All we care about, for *this* discussion, is the MAC address of the
> 5GHz and 2.4GHz radios in the iOS or Android cellphones we are trying
> to track.
>
> That MAC address is also called a BSSID.
>
> Google also logs the SSID, the signal strength, and the GPS location,
> but they are not of importance for *this* discussion.
>
> Only the MAC address (aka BSSID) is important for *this* discussion.
>> SSID has nothing to do with cellphones. It has to do with wifi only.
>> The same is true for BSSID.
>
> This is not true that "SSID has nothing to do with cellphones".
all cellphones do wifi. I have two on the shelf in this room that do
not do and never did do wifi.
> As Jeff and I just discussed, if an Android or iOS cellphone acts as
> an Access Point, then that cellphone will broadcast an SSID.
action has nothing to do with it being a cellphone but to do with it
acting at this point as a wifi device.
> If that iOS or Android cellphone broadcasts an SSID, it also
> broadcasts a BSSID, which is unique to that cellphone.
fly. It only has to be unique within the (very short) range of the
radios in use.
> In fact, it
> broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).
32 BSSIDs and 1 or more SSIDs per radio. So, yes, a single radio can
simultaneously be using 32 different BSSIDs/MACs.
> It's *those* unique BSSIDs which are captured by poorly configured
> Android devices and uploaded multiple times a day to the Google Public
> Database, along with the GPS location of the poorly configured Android
> device and the SSID and Signal Strength of the access point.
user level program running on the BSS or within the cellphone can access
the very same wifi information and pass it on to whomever it wishes.
> Notice this allows such iOS or Android cellphones to be tracked!
cellphone configuration, if done "properly" (whatever that means) won't
cure the problem when user level code running on the equipment can
accomplish the same thing. In fact, it might be through user level code
that it is being accomplished right now.
>> SSID is just a name. There could be thousands of wifi access points
>> around the world with the same SSID.
>
> I agree. SSID is "just a name". If the name ends with "_nomac", Google
> promises to *drop* that SSID from its' public database.
that anybody else will.
> However, you must realize that the Google Public Database contains
> *more* than the SSID! It contains the *unique* BSSID associated with
> that SSID, and furthermore, it contains the Signal Strength of that
> access point at a specific GPS location of the poorly configured
> Android device that is near that access point.
>
> Anyone who doesn't *understand* that paragraph above can't possibly
> understand the topic of this thread - so it's critical that the paragraph
> above be *understood*.
that even in a "properly configured" phone user level code could be
gathering the same information (or more) and sending it to agents
unknown.
>> 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.
>
> I agree. Specifically, if an iOS or ANdroid cellphone is acting as an
> access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
> a. The cellphone AP SSID
> b. The cellphone AP BSSID
>
> What you must understand to understand the question, is that poorly
> configured Android devices will *send* to Google not only that information
> above, but *more* information!
>
> Poorly configured Android devices will send to Google:
> a. Your cellphone AP SSID
> b. Your cellphone AP BSSID (aka MAC address)
> c. Your AP signal strength seen by the poorly configured Android cellphone
> d. The GPS location of the poorly configured Android cellpone
not be the only recipient.
>> 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.
>
> This part is understood that the BSSID of the 5Ghz and 2.4GHz radios
> in both iOS and Android devices is sent in the clear in packets
> whenever those cellphones connect to an access point.
>
> But I'm not talking about that.
>
> I'm only talking about when an iOS or Android cellphone has the
> following four bits of information *sent* to the Google database by
> poorly configured
> Android devices:
> a. Your cellphone AP SSID
> b. Your cellphone AP BSSID (aka MAC address)
> c. Your AP signal strength seen by the poorly configured Android
> cellphone
> d. The GPS location of the poorly configured Android cellpone
uration with any amount of user-level programs has potentially the same
nasty possibilities.
>> 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.
>
> Yes. You are correct that there are *other* methods, other than the
> Google Public Database, to obtain MAC addresses of devices.
>
> For example, this web site from wardriving software:
> https://wigle.net/
>
> But *this* question is complex enough for most people (almost nobody
> understood the question) if I simply stick to the Google mechanism.
>
> Lord knows how complex this question gets if I bring in the Wigle
> wardriving mechanism (which even I don't understand).
>
>> 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.
>
> Yep. Wardrivign software.
> Or anything from Marius Milner (e.g., netstumbler).
>> 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.
>
> This is not true.
octets (notice, the proper term is octets, not bytes; I was too casual
in the above paragraph) to "AA 00 04 00". The remaining 2 octets make
up the node within a DECnet network. How do I know this? I'm an
ex-DECie. (Actually, I'm still a DECie but they don't pay me anymore.)
If you want a reference on this a brief desctiption may be found at
<https://en.wikipedia.org/wiki/DECnet> which contains the following:
"The Ethernet implementation was unusual in that the software
changed the physical address of the Ethernet interface on the
network to AA-00-04-00-xx-yy where xx-yy reflected the DECnet
network address of the host. This allowed ARP-less LAN operation
because the LAN address could be deduced from the DECnet address."
I've avoided making any references to 802 so far here. And my DECnet
references mostly concern(ed) 802.3, 802.<whatever> all have the same
underpinnings. DEC was one of three companies that colaboratively
"invented" ethernet (at least the hardware specs, that is). The origin
of ethernet comes from the amateur radio two meter band protocols used
in Hawaii, which was called "Aloha Net".
> Jeff Liebermann explained in the past why it would take an heroic
> effort to clone the MAC address of the radio that is sending out the
> packets.
for MAC has nothing to do with cloning.
> The cloning is on a different MAC address, which is not the MAC
> address of concern here.
> Too bad, becuase if it were easy to change the Access Point MAC
> address, then I would change mine daily.
>> As was said before, just flip a few bits and you could suddenly
>> appear to be on the other side of the planet.
>
> Not true.
> You're confusing the easily cloned MAC address with the one that would
> take desoldering to change.
VAX computer was moved from one location to another nobody went running
for a soldering iron.
If changing the MAC address (also called the hardware address) was so
difficult, why do you suppose the capability exist in ifconfig(8) to
change it?
Bruce .
--
Horace Algier
Sep 17, 2016, 10:30:43 PM9/17/16
to
On Sat, 17 Sep 2016 16:12:40 -0400, bruce wrote:
>> This is not true that "SSID has nothing to do with cellphones".
>
> Yes, I'm afraid it is true. To reject it implies that you believe that
> all cellphones do wifi. I have two on the shelf in this room that do
> not do and never did do wifi.
OK. You found a corner case, where not all cellphones do WiFi.
>> This is not true that "SSID has nothing to do with cellphones".
>
> Yes, I'm afraid it is true. To reject it implies that you believe that
> all cellphones do wifi. I have two on the shelf in this room that do
> not do and never did do wifi.
Since I also have iOS equipoment, all my iOS equipment has WiFi also.
While I am sure they exist, I personally have never seen a cellphone that
doesn't do WiFi; but I also have a limit on cellphones of 16GB minimum,
1GHz minimum, 1GB RAM minimum, etc., where the cost is never below $200 so,
the cellphones "I" have bought *all* have WiFi.
I did goof with the wife's $200 Moto G, which only has 2.4GHz WiFi, since I
simply *assumed* that all of the WiFi cellphones had *both* 2.4GHz and 5GHz
WiFi ... so I agree with you on the wide range of what Android phones do.
>> As Jeff and I just discussed, if an Android or iOS cellphone acts as
>> an Access Point, then that cellphone will broadcast an SSID.
>
> This is consistent with what I wrote above and what I wrote below. This
> action has nothing to do with it being a cellphone but to do with it
> acting at this point as a wifi device.
discussed in person, because the mere fact that the BSSID is encapsulated
in the clear in the WiFi packet is *absolutely meaningless* for the purpose
of this discussion *if* all those poorly configured Android devices don't
*upload* that BSSID to the Google Public Database.
The *only* BSSID that matters for this discussion is the BSSID which is
*uploaded* to the Google Public Database by all those poorly configured
Android devices.
>> If that iOS or Android cellphone broadcasts an SSID, it also
>> broadcasts a BSSID, which is unique to that cellphone.
>
> Not necessarily. The protocols allow the creation of a BSSID on the
> fly. It only has to be unique within the (very short) range of the
> radios in use.
has to be unique on the subnet, e.g., you can use DE:AD:BE:EF:CA:FE on your
own network and it won't matter, as long as only a single device on your
network has that BSSID.
Up until Jeff's later responses, I had thought that the BSSID that matters
(which is the one *uploaded* to the Google database by poorly configured
Android devices!) was hard to change, and it is, for a typical
factory-software router.
But Jeff explained that certain firmware will enable that all-important
BSSID (which is the one that is *uploaded* to the Google database by poorly
configured Android devices) *can* be changed on a router.
In addition, Jeff noted that, for Android devices which are *rooted*, that
all-important BSSID (which is the one *uploaded* to the Google publid
database by poorly configured Android devices) *can* be changed.
Unfortunately, a quick search on Google shows a history of Apple *breaking*
any jailbroken device's ability to change that specific BSSID with each new
OS version - so we can effectively say it can't easily be done on iOS
(which is another reason why iOS has less privacy than Android in certain
situtations).
>> In fact, it
>> broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).
>
> Actually, any wifi device acting as a BSS can identify itself as up to
> 32 BSSIDs and 1 or more SSIDs per radio. So, yes, a single radio can
> simultaneously be using 32 different BSSIDs/MACs.
radio"?
It's possible - but remember, the *only BSSID that matters* for this
conversation is the one that is *uploaded* to the Google Public Database by
poorly configured Android devices.
All other BSSIDs are meaningless for the purpose of this discussion.
Given that, are you saying that you have *32* different SSIDs which are
being uploaded, as we speak, to the Google Public Database by all poorly
configured Android devices in your vicinity?
>> It's *those* unique BSSIDs which are captured by poorly configured
>> Android devices and uploaded multiple times a day to the Google Public
>> Database, along with the GPS location of the poorly configured Android
>> device and the SSID and Signal Strength of the access point.
>
> As I said below, poorly configured has nothing to do with it when any
> user level program running on the BSS or within the cellphone can access
> the very same wifi information and pass it on to whomever it wishes.
Jeff already noted that there are *plenty* of situations where a BSSID is
found, in the clear, in the context of WiFi communications.
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.
nospam
Sep 17, 2016, 10:54:12 PM9/17/16
to
In article <nrku8g$9od$1...@news.mixmin.net>, Horace Algier
<https://admin.mashable.com/wp-content/uploads/2014/03/motorola-dynatac-
8000x1.jpg>
<hor...@horatio.net> wrote:
> >> This is not true that "SSID has nothing to do with cellphones".
> >
> > Yes, I'm afraid it is true. To reject it implies that you believe that
> > all cellphones do wifi. I have two on the shelf in this room that do
> > not do and never did do wifi.
>
> OK. You found a corner case, where not all cellphones do WiFi.
> Since I also have iOS equipoment, all my iOS equipment has WiFi also.
>
> While I am sure they exist, I personally have never seen a cellphone that
> doesn't do WiFi;
this one doesn't:
> >> This is not true that "SSID has nothing to do with cellphones".
> >
> > Yes, I'm afraid it is true. To reject it implies that you believe that
> > all cellphones do wifi. I have two on the shelf in this room that do
> > not do and never did do wifi.
>
> OK. You found a corner case, where not all cellphones do WiFi.
> Since I also have iOS equipoment, all my iOS equipment has WiFi also.
>
> While I am sure they exist, I personally have never seen a cellphone that
> doesn't do WiFi;
<https://admin.mashable.com/wp-content/uploads/2014/03/motorola-dynatac-
8000x1.jpg>
Horace Algier
Sep 17, 2016, 11:43:35 PM9/17/16
to
On Sat, 17 Sep 2016 16:12:40 -0400, bruce wrote:
>> Notice this allows such iOS or Android cellphones to be tracked!
>
> Did I ever say anything to contradict this? I merely pointed out that
> cellphone configuration, if done "properly" (whatever that means) won't
> cure the problem when user level code running on the equipment can
> accomplish the same thing. In fact, it might be through user level code
> that it is being accomplished right now.
>
> Did I ever say anything to contradict this? I merely pointed out that
> cellphone configuration, if done "properly" (whatever that means) won't
> cure the problem when user level code running on the equipment can
> accomplish the same thing. In fact, it might be through user level code
> that it is being accomplished right now.
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.
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.
>>> SSID is just a name. There could be thousands of wifi access points
>>> around the world with the same SSID.
>>
>> I agree. SSID is "just a name". If the name ends with "_nomac", Google
>> promises to *drop* that SSID from its' public database.
>
> While Google might honor the use of the suffix (for now) it doesn't mean
> that anybody else will.
It's even worse than that.
>>> around the world with the same SSID.
>>
>> I agree. SSID is "just a name". If the name ends with "_nomac", Google
>> promises to *drop* that SSID from its' public database.
>
> While Google might honor the use of the suffix (for now) it doesn't mean
> that anybody else will.
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.
2. However, most of us don't "hide" our SSID from being broadcast (since
there is almost zero security value in hiding the SSID broadcast).
3. 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.
4. 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.
>> However, you must realize that the Google Public Database contains
>> *more* than the SSID! It contains the *unique* BSSID associated with
>> that SSID, and furthermore, it contains the Signal Strength of that
>> access point at a specific GPS location of the poorly configured
>> Android device that is near that access point.
>>
>> Anyone who doesn't *understand* that paragraph above can't possibly
>> understand the topic of this thread - so it's critical that the paragraph
>> above be *understood*.
>
> That "paragraph above" means absolutely nothing until one understands
> that even in a "properly configured" phone user level code could be
> gathering the same information (or more) and sending it to agents
> unknown.
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.
>>> 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.
>>
>> I agree. Specifically, if an iOS or ANdroid cellphone is acting as an
>> access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
>> a. The cellphone AP SSID
>> b. The cellphone AP BSSID
>>
>> What you must understand to understand the question, is that poorly
>> configured Android devices will *send* to Google not only that information
>> above, but *more* information!
>>
>> Poorly configured Android devices will send to Google:
>> a. Your cellphone AP SSID
>> b. Your cellphone AP BSSID (aka MAC address)
>> c. Your AP signal strength seen by the poorly configured Android cellphone
>> d. The GPS location of the poorly configured Android cellpone
>
> As stated above, poorly configured is not the problem, and Google might
> not be the only recipient.
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.
>>> 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.
>>
>> This part is understood that the BSSID of the 5Ghz and 2.4GHz radios
>> in both iOS and Android devices is sent in the clear in packets
>> whenever those cellphones connect to an access point.
>>
>> But I'm not talking about that.
>>
>> I'm only talking about when an iOS or Android cellphone has the
>> following four bits of information *sent* to the Google database by
>> poorly configured
>> Android devices:
>> a. Your cellphone AP SSID
>> b. Your cellphone AP BSSID (aka MAC address)
>> c. Your AP signal strength seen by the poorly configured Android
>> cellphone
>> d. The GPS location of the poorly configured Android cellpone
>
> Get off this poorly configured fixation you have. A perfect config-
> uration with any amount of user-level programs has potentially the same
> nasty possibilities.
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.
0 new messages