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

[Horace Algier]

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:
https://developers.google.com/maps/documentation/geolocation/intro

For the Google lookup, the only *mandatory* parameters are:
1. MAC ADDRESS #1
2. MAC ADDRESS #2
3. 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:
https://wigle.net

Do you know of other MAC address location lookup engines?

[Carlos E.R.]

On 2016-09-13 08:00, Horace Algier 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?

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.

--
Cheers, Carlos.

[Horace Algier]

On Tue, 13 Sep 2016 15:34:26 +0200, Carlos E.R. wrote:

> 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.

Hi Carlos,

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.

[Carlos E. R.]

On 2016-09-13 18:06, Horace Algier wrote:
> On Tue, 13 Sep 2016 15:34:26 +0200, Carlos E.R. wrote:
>
>> 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.
>
> Hi Carlos,
>
> 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)?

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.

> Does a mobile device broadcast its MAC address when acting as a hotspot,
> for example?

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.

> 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.

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.

--
Cheers,
Carlos E.R.

[William Unruh]

On 2016-09-13, Horace Algier <hor...@horatio.net> 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 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.

>
> 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.
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.

[William Unruh]

On 2016-09-13, Horace Algier <hor...@horatio.net> wrote:

> On Tue, 13 Sep 2016 15:34:26 +0200, Carlos E.R. wrote:
>
>> 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.
>
> Hi Carlos,
>
> 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)?

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

>
> Does a mobile device broadcast its MAC address when acting as a hotspot,
> for example?

No.

[Horace Algier]

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?

[Horace Algier]

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.

[Horace Algier]

On Wed, 14 Sep 2016 00:20:13 +0200, Carlos E. R. wrote:

>> So, my key question is *when* does a mobile device broadcast it's MAC
>> address (BSSID & SSID)?
>
> 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.
>
>> Does a mobile device broadcast its MAC address when acting as a hotspot,
>> for example?
>
> 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.
>
>> 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.
>
> 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.

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.
1. GOOGLE DATABASE QUERY BY AN INDIVIDUAL
2. AUTOMATIC BSSID COLLECTION BY GOOGLE
3. MANUALLY OPTING OUT OF THE GOOGLE DATABASE

1. 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.

2. 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.

3. 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?
1. GOOGLE DATABASE QUERY BY AN INDIVIDUAL
2. AUTOMATIC BSSID COLLECTION BY GOOGLE
3. MANUALLY OPTING OUT OF THE GOOGLE DATABASE

[Andy Burns]

Horace Algier wrote:

> I'll dumb down the question

Doesn't matter if the hat says "Alice J", "Aardvarks" or "Horace",
people don't want to go over the same ground again ...

[Frank Slootweg]

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:

> 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
'question' isn't a question, but a false statement.

HTH.

[bruce]

> 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.

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 .

--

[Winston]

I assume you're referring to things like:

http://arstechnica.com/information-technology/2014/11/where-have-you-been-your-smartphones-wi-fi-is-telling-everyone/

http://www.zdnet.com/article/how-google-and-everyone-else-gets-wi-fi-location-data/

http://www.theregister.co.uk/2011/04/22/google_android_privacy_concerns/

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 points:

Horace Algier <hor...@horatio.net> writes:
> "if" your cellphone does broadcast an
> SSID, then your cellphone *can* be tracked.

(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.

> However, even if the router's MAC address could be cloned (it can't,
> at least not without desoldering and other heroic actions),

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.

Have I completely missed the point?
-WBE

[Kerr Mudd-John]

It's a xposting troll.

--
Bah, and indeed, Humbug

[Jeff Liebermann]

On Tue, 13 Sep 2016 16:06:47 +0000 (UTC), Horace Algier
<hor...@horatio.net> wrote:

>So, my key question is *when* does a mobile device broadcast it's MAC
>address (BSSID & SSID)?

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).

>Does a mobile device broadcast its MAC address when acting as a hotspot,
>for example?

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.

>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.

Yep. Resistance if futile. You've already been assimilated.

>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.

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.
<https://www.grc.com/nat/arp.htm>
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.
<https://www.wired.com/2012/05/google-wifi-fcc-investigation/>
<https://www.wired.com/2013/09/googles-wifi-wiretapping/>

Note: No more Q&A from me for a few more days. I sprained both
wrists and it hurts to type.

--
Jeff Liebermann je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558

[Jeff Liebermann]

On Wed, 14 Sep 2016 00:27:22 -0000 (UTC), William Unruh

<un...@invalid.ca> wrote:

>> Does a mobile device broadcast its MAC address when acting as a hotspot,
>> for example?

>No.

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.

[Jeff Liebermann]

On Thu, 15 Sep 2016 08:45:37 -0700, Jeff Liebermann <je...@cruzio.com>
wrote:

>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.

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.

(wrists hurt. gotta stop now...)

[AL]

On 9/15/2016 8:31 AM, Jeff Liebermann wrote:
> On Tue, 13 Sep 2016 16:06:47 +0000 (UTC), Horace Algier

>> 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.
>
> Yep. Resistance if futile. You've already been assimilated.

And Google is not the only assimilator... 8-O

"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."

http://lifehacker.com/how-retail-stores-track-you-using-your-smartphone-and-827512308

[Horace Algier]

On Thu, 15 Sep 2016 08:45:37 -0700, Jeff Liebermann wrote:

> 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.

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!).

> 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.

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).

> 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.

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?

> Since the headers containing the MAC address are
> NOT encrypted, they are easily extracted.

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.

> 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.

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):
1. The MAC address you seek
2. Another MAC address that is known to be nearby
3. 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.

[Andy Burns]

Horace Algier wrote:

> 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

I'm going to ask you a direct question, is "Horace Algier" the latest
nymshift for "Alice J and "Aardvarks"?

If so, you should remember I gave you detailed explanation of google
GPS/MAC address tracking some months ago, before it was obvious how
heavily *you* were trolling.

[Horace Algier]

On Thu, 15 Sep 2016 08:31:02 -0700, Jeff Liebermann wrote:

> Note: No more Q&A from me for a few more days. I sprained both
> wrists and it hurts to type.

Hi Jeff,
There really is only one question, which is the following:

QUESTION:
- Under what conditions does a cellphone SSID/MAC/SS get put into the
Google Public API by *other* (poorly configured) Android cellphones?

>>So, my key question is *when* does a mobile device broadcast it's MAC
>>address (BSSID & SSID)?
>
> 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).

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.

>>Does a mobile device broadcast its MAC address when acting as a hotspot,
>>for example?
>
> 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.

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.

>>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.
>
> Yep. Resistance if futile. You've already been assimilated.

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:

REMAINING QUESTION:
- 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?

[Horace Algier]

On Thu, 15 Sep 2016 08:51:22 -0700, Jeff Liebermann wrote:

> 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.

Hi Jeff,

There are two *different* questions, only one of which I am asking.

What I'm probing is a specific flaw in the Google public API database.
I'm probing a flaw where we can *circumvent* the Google (flawed) security,
and by doing so, we can track a mobile phone.

We can already track a non-mobile router, but that isnt' the flaw that I'm
probing. Likewise, the *packet* contains the MAC address of either the 5Ghz
radio or the 2.4GHz radio of the mobile phone, but, I'm not discussing that
packet information *unless* that packet information makes it into the
Google public database.

What I *know* makes it into the Google Public database is the SSID/MAC/SS
of any access point that is both "broadcast" and which doesn't have
"_nomac" at the end of the SSID.

How this makes it into the Google Public Database is also well known, which
is that most Android phones are poorly configured such that *they* send
Google this access point information many times a day in the background.

But, as noted, most SSID access points remain in one place. So, finding the
location of a *static* access point is trivial.

What I'm trying to understand is how to probe the flaw in the Google Public
API that allows one to track *mobile* devices.

Specifically, if I *know* two MAC addresses that are already *in* the
Google Public Database, then I can ask the database if they're currently
next to one another at any given moment.

Given I know the BSSID of, say, the Starbucks in town, all I need to know
is the BSSID of the phone, to know whether the phone is at that Starbucks.

So that's why I ask the question:

[Horace Algier]

On Thu, 15 Sep 2016 09:49:06 -0700, AL wrote:

>> Yep. Resistance if futile. You've already been assimilated.
>
> And Google is not the only assimilator... 8-O

The Nordstrom example is interesting, but it's not the mechanism that I'm
looking at in this question.

In *this* question, what's only germane is what conditions an iOS or
Android device is put into the Google Public Database by poorly configured
Android devices in its vicinity.

So far we've confirmed what I already knew, which is that any iOS or
Android cellphone acting as an Access Point, will already be in the Google
Public Database because it will have encounted numerous poorly configured
Android devices which tell Google every day all the SSID/MAC/SS & GPS
Location information of *every* access point they encounter (encrypted or
otherwise).

The question is... under what *other* conditions (other than acting as an
Access Point) does an iOS or Android mobile device get put into the Google
Public Database by poorly configured Android devices?

[Horace Algier]

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".

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.

I agree. SSID is "just a name". If the name ends with "_nomac", Google
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.

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

> 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

> 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.
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.

Not true.
You're confusing the easily cloned MAC address with the one that would take
desoldering to change.

[Jeff Liebermann]

On Fri, 16 Sep 2016 18:43:57 +0000 (UTC), Horace Algier
<hor...@horatio.net> wrote:

>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 tripped over a broken concrete walkway at a customers while doing my
best to not pay attention. I came down on my knees and wrists. Some
skin missing from the knees, stiff knee muscles, and sprained wrists.
I was recovered enough yesterday to get talked into helping move a hot
tub. Now, I feel worse. The wrists are sufficiently healed that I
can now function without a pain killer. I think I'll live.

>> 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.
>
>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).

Not exactly. 802.11 does nothing more than gift wrap ethernet packets
which in turn carry TCP/IP packets. Just as ethernet needs to know
the source and destination MAC addresses to make it through a switch
(also known as a multiport bridge), so does 802.11 packets need to
know the source and destination MAC addresses of the wireless devices
involved in the wireless network. In other words, 802.11 is nothing
more than ethernet done without wires. A better example of the
similarity is a "wireless switch" which is literally a smart ethernet
switch that uses wireless access points to connect to computers,
printers, and such.

>> 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.
>
>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?

The cell phone is playing access point and bridge. The access point
is easy. It encapsulated ethernet packets inside 802.11 packets and
sends them via 2.4GHz to a wireless client. The bridging is a mess.
You have the:
Wireless client(s) talking to cell phone. The wireless client radio
is a bridge between ethernet and wi-fi.
The soft access point in the cell phone bridges wi-fi to the data
modem in the cell phone, which is another bridge.
Every hop along the way is bridging, usually with MAC addresses
involved.

>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.

That wasn't your original question. However, I can easily answer
that. Google got into trouble because they were also sniffing and
storing the Wi-Fi payload. Google believes that it is entitled to
collect any data that is does not constitute user information, which
is loosly known as metadata. Worst case is that it might not record
your credit card number sniffed during drive by, but might record the
time and date when a credit card was used. Less extreme might be
Google recording when and from whom something was purchased, but not
what was purchased. The dividing line between acceptable data
collection and the invasion of privacy is a moving target. I had
hoped that the courts would have settled the matter by now, but that's
hardly the case.

>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.

"We want you to understand what data we collect and use."
<https://privacy.google.com/your-data.html>
Hmmm... doesn't mention wireless sniffing because Google has announced
that it no longer collects wifi data:
<http://www.pcworld.com/article/196372/google_privacy.html>
<http://www.dailymail.co.uk/sciencetech/article-2292624/Google-hit-7M-fine-wifi-snooping-Street-View-cars-intercepted-emails.html>
Note that metadata and data are quite different.

Gotta run. I'll attack the rest later (time permitting). I can
explain how wi-fi works, but I can't explain every detail of how
Google collects wireless data. It would be helpful if you actually
asked a question. Tacking a question mark on an assertion is
difficult to decode.

[Jeff Liebermann]

On Fri, 16 Sep 2016 19:30:07 +0000 (UTC), Horace Algier
<hor...@horatio.net> wrote:

>On Thu, 15 Sep 2016 08:31:02 -0700, Jeff Liebermann wrote:

>>>Does a mobile device broadcast its MAC address when acting as a hotspot,
>>>for example?
>>
>> 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.
>
>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.

Which MAC address? A cell phone can easily have several. Instead of
a cell phone, look at the web page setup for a typical home router.
Each interface has a MAC address. There's one for the WAN port, 4
addresses one each for the LAN ports, and 1 for the Wi-Fi port which
is actually a 5th port on the ethernet switch. Often, 3 of these
numbers are printed on a sticker near the serial number tag.

When some of these functions are performed by a cell phone, only a few
of these MAC addresses will be publicly accessible. Since the traffic
is moving by wi-fi, the wi-fi port MAC address can be logged. Since
the phone is acting as a bridge between wi-fi and cellular data,
methinks there should be another MAC address on the wireless data
port. That address does NOT go throught the wi-fi to cellular data
bridge, so it will NOT be accessible. So, the answer is that only the
MAC address of the wi-fi device get harvested. Turning the wi-fi
device into a software access point doesn't hide anything because the
wi-fi device MAC address has to be exposed no matter what software is
using it to move data.

[Horace Algier]

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> I assume you're referring to things like:
> http://arstechnica.com/information-technology/2014/11/where-have-you-been-your-smartphones-wi-fi-is-telling-everyone/
> http://www.zdnet.com/article/how-google-and-everyone-else-gets-wi-fi-location-data/
> http://www.theregister.co.uk/2011/04/22/google_android_privacy_concerns/

THANK YOU WINSTON FOR UNDERSTANDING WHAT THIS THREAD IS ABOUT!
(sorry for shouting)
I'm just so happy that not only Jeff, but someone else also understands
what this thread is asking!

Also, thank you Winston for looking up the issue so that we could talk
about the topic of the thread.

Yes. You are correct.
This is a problem on both Android & iOS phones.

Looking at each of the three articles, here's a quick summary review:

1. WhereĄŚve you been? Your smartphoneĄŚs Wi-Fi is telling everyone.
Every time you use Google or Apple mobile location services, youĄŚre not
just telling the services where you are. YouĄŚre also shouting many of the
places youĄŚve been to anyone who happens to be listening around youĄXat
least if you follow GoogleĄŚs and AppleĄŚs advice and turn on Wi-Fi for
improved accuracy.

2. How Google--and everyone else--gets Wi-Fi location data
Google doesn't use StreetView cars to pick up Wi-Fi location data any more.
They use your smartphones and tablets instead.
Eitan Bencuya, a Google spokesperson, tells me that Google no longer uses
StreetView cars to collect location information. So, how does Google
collect Wi-Fi location data? They use you.

Or, to be more exact, they use your Android phone or tablet. But, it's not
just Google. Apple and Microsoft do the same thing with their smartphones
and tablets.

3. Google location tracking can invade privacy, hackers say
Unique IDs + router addresses = potential abuse
In October, Google pledged to stop using its world-roving Street View
vehicles to collect Wi-Fi data and said it instead would rely on Android
handsets to get the information. When phones running the Google OS detect
any wireless network, they beam its MAC address, signal strength and GPS
coordinates to Google servers, along with the unique ID of the handset.

Unfortunately, the lookup that was at that web site says Google disabled
the web site (but the lookup still works from the Google API):
http://samy.pl/androidmap/

Notice though, that this web site says:
"android map exposes the data that Google has been collecting from
virtually all Android devices and street view cars, using them essentially
as global wardriving machines. You can use this tool to accurately locate
virtually any router in the world, as well as position *iPhones* and
*Android phones.*

So notice that all I'm asking is for more information about that last
sentence:
- You can use [query the Google Public Database] to accurately locate
...the position of *iPhones* and *Android phones.*

[Horace Algier]

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> 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.

While you're correct, the only risk I'm looking at is how to *abuse* the
Google Public API database in order to *track* the *current* location of a
cellphone whose BSSID (aka MAC address is known to you) and where you also
know the BSSID of the AP of, say, the local Starbucks.

The Google API (as a "security" measure) requires *two* MAC addresses
before it will spit out the GPS location of *both*.

So, if you *think* the cellphone is at Starbucks, and if you know both MAC
addresses, you can *prove* the cellphone is at Starbucks.

That's all I'm asking about.

When does a cellphone's MAC address & Location & SSID & GPS coordinates get
captured into the Google Public Database?

That is the question!

[Horace Algier]

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> 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).

I am only talking about cellphones, and their MAC addresses of their 2.4GHz
and 5GHz radios, but in the case of cloning, nobody understands what Jeff
Liebermann understands.

The MAC address you *want* to clone to keep it out of Google's database
can't be easily cloned. Jeff and I am sure you can go through heroics, but
it would be easier to buy a dozen routers a year and just replace them each
month than it would be to try to change the MAC address of the radio that
is broadcasting the SSID.

[Horace Algier]

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> Huh? The wireless routers I've configured allow changing of their MAC
> addresses, often during the initial setup/configuration.

Everyone on the planet knows that you can clone *one of* the router's MAC
addresses. But that's the *wrong* MAC address.

Look in the record for alt.internet.wireless for example:
http://tinyurl.com/alt-internet-wireless

I think this is the thread, but it doesn't matter because you can't clone
the MAC address you *want* to clone for *this* purpose!
https://groups.google.com/forum/#!topic/alt.internet.wireless/-PK03bCEheM[1-25]

Here is what Jeff Liebermann said in that thread:
Cloning the router's mac address can't work.
Using the router feature of MAC address cloning or
changing only changed the MAC address for the WAN (internet) port.
That's useful for the few remaining ISP's that authenticate by MAC
address, but not really a good privacy measure. The MAC addresses for
the LAN side, including the wireless, remains unchanged. Since Google
wants the LAN MAC address for their directory of wi-fi devices, you're
stuck with the MAC address delivered by your wireless router vendor.

The only way I can currently think of changing the wi-fi MAC address
is to plug a wireless card into a PC or SBC (single board computah),
set it up to act as an access point, and change the MAC address in
Linux.
<https://wiki.archlinux.org/index.php/software_access_point>
I haven't tried this.

[Horace Algier]

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> (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.

I'm *not* asking about cellphone triangulation.
That's totally different.

[Horace Algier]

On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:

> 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.

Google added the need for the *second* BSSID for security reasons, so that
you'd actually have to know *both* BSSIDs in order to do a lookup.

Of course, if you're *at* the location, you can *easily* obtain two BSSIDs
and their relative signal strength, so that's why Google gives any app that
asks, the GPS coordinates if you give the Google database three things:

1. BSSID 1
2. BSSID 2

3. Signal Strength

Again, if you are actually at that point, then it would be trivial for you
to have the BSSIDs, and the signal strength.

However, if you're faking it, then you have to fake the signal strength.

The way to fake the signal strength is to give both BSSIDs the same (or
similar) signal strength. (That means they're together.)

That way, you're talling Google that *you see* both access points together.

One of two things will happen, if I understand the "system" (and assuming
the hubby's ios or Android cellphone is one of the access points and the
other access point is the Starbucks nearest his girlfriend):

a. If the two access points *are* together, then Google will gladly report
back the GPS coordinates. BINGO! That's your test that hubby is at the
Starbucks over by his girlfriend's home!

b. If the two access points are *not* together, then Google will NOT report
back the GPS coordinates.

Pretty simple if you ask me.
This only works though, if the iOS or Android cellphone is being betrayed
by other poorly configured Android devices.

So that's why I ask under what circumstances does an iOS or Android
cellphone get its SSID/BSSID/SS and GPS position reported to the Google
database?

[Horace Algier]

On Fri, 16 Sep 2016 13:16:49 -0700, Jeff Liebermann wrote:

> Which MAC address?

The only MAC address that matters is the MAC address that is harvested by
poorly configured Android devices.

We *know* that poorly configured Android devices harvest the SSID of all
access points that they encounter, and along with the SSID, these poorly
configured Android devices also harvest the MAC ADDRESS of the access point
(both 2.4GHz and 5GHz MAC addresses) and they also harvest the signal
strength of each access point. In addition, they know their own location,
so they give Google the GPS of their location along with that access point
data above.

See this:
https://blog.ouseful.info/2016/01/27/looking-up-the-physical-location-of-your-wifi-router/

Which refers to the canonical Geolocation API from Google:
https://developers.google.com/maps/documentation/geolocation/intro

Notice all you need is:

1. BSSID 1
2. BSSID 2
3. Signal Strength

> the answer is that only the
> MAC address of the wi-fi device get harvested. Turning the wi-fi
> device into a software access point doesn't hide anything because the
> wi-fi device MAC address has to be exposed no matter what software is
> using it to move data.

I think there is a difference between the MAC address of teh WiFi devices
(5GHz and 2.4GHz) being sent in the clear in the *packets* and the MAC
address of the WiFi devices (5GHz and 2.4GHz) being sent as an Access Point
*broadcast*.

Google *says* they don't harvest hidden access points, and Google says
they'll drop non-hidden access points with "_nomac" in the SSID - but other
than those two protections, it seems that Google allows all poorly
configured Android devices to harvest *your* access point SSID and BSSID
and Signal Strength, along with the GPS coordinates of the poorly
configured Android device, many times a day (all in the background).

Given that, I think the answers to my questions are:

Q1: When do poorly configured Android devices harvest "your" cellphone
SSID/MAC/SS & GPS?
A1: Only when your cellphone is set as an non-hidden access point.

Q2: What information is needed to figure out if a cellphone is at the local
starbucks at this very moment?
A2: You first must set the cellphone into being an access point, and then
all you need to do is query the Google Public API for three things:
a. The BSSID of the cellphone access point
b. The BSSID of the local starbucks
c. Some bogus Signal Strength data that implies they're close together

If they *are* close together, then some poorly configured Android device
would already have thrown them under the bus and they'd be in the Google
Public API which you just queried.

[Jeff Liebermann]

On Sat, 17 Sep 2016 01:59:36 -0000 (UTC), Horace Algier
<hor...@horatio.net> wrote:

>On Thu, 15 Sep 2016 01:04:30 -0400, Winston wrote:
>
>> Huh? The wireless routers I've configured allow changing of their MAC
>> addresses, often during the initial setup/configuration.
>
>Everyone on the planet knows that you can clone *one of* the router's MAC
>addresses. But that's the *wrong* MAC address.
>
>Look in the record for alt.internet.wireless for example:
> http://tinyurl.com/alt-internet-wireless
>
>I think this is the thread, but it doesn't matter because you can't clone
>the MAC address you *want* to clone for *this* purpose!
>https://groups.google.com/forum/#!topic/alt.internet.wireless/-PK03bCEheM[1-25]
>
>Here is what Jeff Liebermann said in that thread:
>Cloning the router's mac address can't work.
>Using the router feature of MAC address cloning or
>changing only changed the MAC address for the WAN (internet) port.

Notice that I said router, not client radio, access point, or some
unspecified software running on your unspecified smartphone. The
"hardware clone" feature found in consumer router firmware only
changes the WAN port MAC address. The LAN ports (including Wi-Fi) are
unaccessible by mere mortals. Like a PC or laptop allows anyone to
change the MAC address of its ethernet port or wireless device, you
can change the MAC address of a software based smartphone access point
if you have root access.

However, that's for a normal router that hasn't been hacked or has had
the firmware replaced. If you have root and shell access, you can
just use ifconfig to change the MAC address of any addressable port.
For example, in DD-WRT:
ifconfig wlan0 down
ifconfig wlan0 hw ether 11:22:33:44:55:66
ifconfig wlan0 up

That's also for a normal non-rooted smartphone. If you root it, you
can again use ifconfig to change the MAC address of any port.
<http://www.gohacking.com/spoof-mac-address-on-android-phones/>

If you want to drive Google partly nuts, just change your smartphone
wi-fi MAC address at irregular intervals. That won't stop them from
tracking you by some of the other stuff they are harvesting from your
phone, but it's a good start.

Gotta stop typing for a day. I tried to start a chain saw today and
now right wrist is swollen.

[Horace Algier]

On Fri, 16 Sep 2016 22:22:51 -0700, Jeff Liebermann wrote:

> Notice that I said router, not client radio, access point, or some
> unspecified software running on your unspecified smartphone. The
> "hardware clone" feature found in consumer router firmware only
> changes the WAN port MAC address.

Hi Jeff,
I do remember almost everything that you've ever said, that I understood.

And, while most people *think* you can clone the LAN ports "of the router",
it's not so easy (as you are explaining). Basically, for "our" purposes,
changing the WiFi (2.4GHz or 5GHz) Access Point MAC address can't easily be
done on a typical home router even though you are "admin" on that router.

I have no idea if *that* restriction applies to a *cell phone* so I will
read on ...

> Like a PC or laptop allows anyone to
> change the MAC address of its ethernet port or wireless device, you

> *can* change the MAC address of a software based smartphone access point

> if you have root access.

Ooooooh.... this is new. Interesting too... Please do go on...

> However, that's for a normal router that hasn't been hacked or hasn't had
> the firmware replaced.

Ok. Fair enough. So you're saying that the Access Point (5Ghz and 2.4GHz)
MAC address is not easy to change on a router that doesn't have the
firmware replaced with custom softwqare.

> If you have root and shell access, you can
> just use ifconfig to change the MAC address of any addressable port.
> For example, in DD-WRT:
> ifconfig wlan0 down
> ifconfig wlan0 hw ether 11:22:33:44:55:66
> ifconfig wlan0 up

I do this on Linux daily (I have a script) - so - are you saying that if
you had root access to an iOS or Android cellhone or if you have "special"
more-than-root access on a router, that you *can* easily change the MAC
address that is associated with the cellphone's SSID access point?

> If you root it, you
> can again use ifconfig to change the MAC address of any port.
> <http://www.gohacking.com/spoof-mac-address-on-android-phones/>

OK. SO is this the summary?
1. ROUTER
a. You have root access on the router, but you still can't change the
Access Point MAC address on most consumer router firmware
b. However, if you load *special* router firmware, you *can* change the
Access Point MAC address <=== Is that what you're saying?

2. CELLPHONE
a. You do not have root access on either an iOS or Android cellphone unless
you jailbrake or root it, so you can't change the MAC address of the access
point of a non-rooted (aka non jailbroken) iOS or Android device.
b. However, if you jailbreak (or root) the iOS or Android device, you *can*
change the access point MAC address (which is what Google harvests).

> If you want to drive Google partly nuts, just change your smartphone
> wi-fi MAC address at irregular intervals. That won't stop them from
> tracking you by some of the other stuff they are harvesting from your
> phone, but it's a good start.

We already know there is one way to prevent them from *harvesting* an
access point MAC address - and there is another (different) way to prevent
Google from *saving* your harvested access point MAC address - and there is
yet another way to (do something) with respect to Microsoft harvesting of
your access point MAC address:

1. If you *hide* the access point SSID broadcast, poorly configured Android
devices will *not* send your access point MAC address to Google.
2. If you append *_nomac* to the end of your access point SSID, then Google
promises to remove your access point from their database.
3. If you insert "_optout", then Microsoft will leave you alone (somehow)

> Gotta stop typing for a day. I tried to start a chain saw today and
> now right wrist is swollen.

Ouch. I use a chain saw a *lot* as I create paths that go for miles and
miles and miles, so I have to cut a lot of dead wood to clear it away. My
Stihl is pretty good about starting up, but still - it's a pull on the
wrist.

Please heal. We need your acumen on her, as there's precious little to go
around.

Looking at the reference for spoofing the MAC on Android & iOS, it seems
these are the requirements for Spoofing the Access Point MAC Address:
a. Rooted Android Phone
b. BusyBox app installed on your phone
c. Once BusyBox is installed, you need to install Terminal app

Here's how to do it manually (according to that reference):
$ su
$ busybox iplink show eth0
(This will show your current MAC address, just for your confirmation)
$ busybox ifconfig eth0 hw ether DE:AD:BE:EF:CA:FE

You have now spoofed your MAC address successfully. To check for the change
enter the following command again:
$ busybox iplink show eth0

Here are two apps that do it for you (according to Google Play):

Wifi Mac Changer by Osama Abukmail
https://play.google.com/store/apps/details?id=com.wireless.macchanger&hl=en

MacMan by Maxters
https://play.google.com/store/apps/details?id=net.maxters.droid.macman&hl=en

Do you think the process to spoof the Access Point MAC address is similar
for jailbroken iOS phones?

[Horace Algier]

On Sat, 17 Sep 2016 06:17:39 +0000 (UTC), Horace Algier wrote:

> Here are two apps that do it for you (according to Google Play):
>
> Wifi Mac Changer by Osama Abukmail
> https://play.google.com/store/apps/details?id=com.wireless.macchanger&hl=en
>
> MacMan by Maxters
> https://play.google.com/store/apps/details?id=net.maxters.droid.macman&hl=en
>
> Do you think the process to spoof the Access Point MAC address is similar
> for jailbroken iOS phones?

Googling, it seems the iOS process is (far) more complex than is Android
for spoofing the MAC address of the access point (because Apple keeps
breaking it with every new OS release, apparently).

So, in essence, you can't spoof the access point MAC address on any recent
iOS version...
https://gist.github.com/pwnsdx/b39e961b6d719bd2aab0

But, if you try, these are the minimum requirements:
a. A jailbroken iOS device
b. MobileTerminal package or any SSH terminal to execute commands on the
iOS device
c. developer-cmds & network-cmds packages (available on Cydia).

But the problem is that Apple prevents you from doing this (as Apple
prevents you from doing most things you can do on all other platforms).

Details here:
http://best-mac-tips.com/2014/08/14/changing-your-mac-address-on-ios-iphone-ipad/
Where the author concludes:
"So, my best-mac-tip when it comes to spoofing your MAC address on an iOS
device is simply that you can┤. This lack of user control (i.e.
customisation) is just one of the many reasons why I use Android phones and
tablets."

[Andy Burns]

Andy Burns asked:

> is "Horace Algier" the latest nymshift for "Alice J and "Aardvarks"?

I'll take the <tumbleweed/> as confirmation. Despite changes of server,
client, name, xposted groups or email address, you're recognisable at
100 paces ...

[nospam]

In article <nrio22$1l6c$1...@gioia.aioe.org>, Horace Algier

<hor...@horatio.net> wrote:

> > Do you think the process to spoof the Access Point MAC address is similar
> > for jailbroken iOS phones?
>
> Googling, it seems the iOS process is (far) more complex than is Android
> for spoofing the MAC address of the access point (because Apple keeps
> breaking it with every new OS release, apparently).

apple doesn't break stuff with every new release.

nevertheless, ios has had mac address randomization built into the os
since ios 8, which occurs in some situations (it can't be all for
obvious reasons that you probably don't understand).

you've been told this before and you continue to ignore it so you can
lie.

<http://photos.appleinsidercdn.com/gallery/9525-1286-BpmmSGjIUAA34adpng-
large-l.png>

[Peter Köhlmann]

nospam wrote:

> In article <nrio22$1l6c$1...@gioia.aioe.org>, Horace Algier
> <hor...@horatio.net> wrote:
>
>> > Do you think the process to spoof the Access Point MAC address is
>> > similar for jailbroken iOS phones?
>>
>> Googling, it seems the iOS process is (far) more complex than is Android
>> for spoofing the MAC address of the access point (because Apple keeps
>> breaking it with every new OS release, apparently).
>
> apple doesn't break stuff with every new release.

It does. I have 2 apple machines myself. And I know several apple users who
are afraid of updating the OS. Because they have made the experience that
all too often something does not work anymore

[Frank Slootweg]

Yes, "Horace Algier" is indeed "Aardvarks".

Here are some of his other, recent, socks:

"Paul M. Cook", "Joe Clock", "Marob Katon", "Chris Rangoon"

[Horace Algier]

On Fri, 16 Sep 2016 13:04:00 -0700, Jeff Liebermann wrote:

>>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 tripped over a broken concrete walkway at a customers while doing my
> best to not pay attention. I came down on my knees and wrists. Some
> skin missing from the knees, stiff knee muscles, and sprained wrists.
> I was recovered enough yesterday to get talked into helping move a hot
> tub. Now, I feel worse. The wrists are sufficiently healed that I
> can now function without a pain killer. I think I'll live.

Wow. Sorry about that fall. I saw your pictures, and you're in decent shape
for an old guy like me. (You were wearing army stuff from the army-navy
store.)

I hope you heal soon.

> Wireless client(s) talking to cell phone. The wireless client radio
> is a bridge between ethernet and wi-fi.
> The soft access point in the cell phone bridges wi-fi to the data
> modem in the cell phone, which is another bridge.
> Every hop along the way is bridging, usually with MAC addresses
> involved.

Jeff - since there is a "soft access point" on both iOS and Android phones,
does that mean that this soft AP SSID/BSSID/SS & GPS location is sent to
Google by all those poorly configured Android devices?

> That wasn't your original question. However, I can easily answer
> that. Google got into trouble because they were also sniffing and
> storing the Wi-Fi payload. Google believes that it is entitled to
> collect any data that is does not constitute user information, which
> is loosly known as metadata. Worst case is that it might not record
> your credit card number sniffed during drive by, but might record the
> time and date when a credit card was used. Less extreme might be
> Google recording when and from whom something was purchased, but not
> what was purchased. The dividing line between acceptable data
> collection and the invasion of privacy is a moving target. I had
> hoped that the courts would have settled the matter by now, but that's
> hardly the case.

Jeff - you're apparently talking about the Google vehicle that drives along
all the roads in the United States. I'm *not* talking about that WiFi
collection vehicle.

I'm talking about the fact that almost all Android cellphones are poorly
configured in that *they* are collecting the SSID/BSSID/SS of all access
points, and sending that, plus the current GPS location to Google many
times a day.

It's already discussed on *many* web sites.
Winston supplied three of them already:

http://arstechnica.com/information-technology/2014/11/where-have-you-been-your-smartphones-wi-fi-is-telling-everyone/
http://www.zdnet.com/article/how-google-and-everyone-else-gets-wi-fi-location-data/
http://www.theregister.co.uk/2011/04/22/google_android_privacy_concerns/

So we're *only* talking about what data the poorly configured Android
cellphones provide to Google many times a day for all the iOS and Android
phones it encounters.

> "We want you to understand what data we collect and use."
> <https://privacy.google.com/your-data.html>
> Hmmm... doesn't mention wireless sniffing because Google has announced
> that it no longer collects wifi data:
> <http://www.pcworld.com/article/196372/google_privacy.html>
> <http://www.dailymail.co.uk/sciencetech/article-2292624/Google-hit-7M-fine-wifi-snooping-Street-View-cars-intercepted-emails.html>
> Note that metadata and data are quite different.

That's for the car.
We're talking about poorly configured Android cellphones collecting this
data.
See the URLs from Winston for details.
They're titled:
1. Where▔e you been? Your smartphone┬ Wi-Fi is telling everyone.

2. How Google--and everyone else--gets Wi-Fi location data

3. Google location tracking can invade privacy

> Gotta run. I'll attack the rest later (time permitting). I can
> explain how wi-fi works, but I can't explain every detail of how
> Google collects wireless data. It would be helpful if you actually
> asked a question. Tacking a question mark on an assertion is
> difficult to decode.

Hi Jeff,

I realize you always try to help, and that you provide details, which is
expensive in costs of energy and time.

I read *everything* you write, but I don't always understand everything you
write.

However, the *only* question that matters is under what circumstances is an
iOS or Android cellphone's SSID/BSSID/SS and GPS location *reported* to
Google databases by poorly configured Android cellphones.

I *think* the answer is that this happens *only* when the iOS or Android
cellphone is configured to act as an *access point*.

I'm just trying to confirm that setting up an iOS or Android phone as an
access point is the *only* situation where an iOS or Android cellphone is
reported to the Google API that collects the SSID, BSSID, Signal Strength,
and GPS location from a nearby poorly configured Android device.

[Kerr Mudd-John]

On Sat, 17 Sep 2016 14:28:21 +0100, pamela <inv...@nospam.com> wrote:

> On 05:41 14 Sep 2016, Horace Algier wrote:
>>
>> 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
[]
>
> It sounds like someone has a lot of time on their hands.
Not enough to search the internet and find their own answers though.

--
Bah, and indeed, Humbug

[bruce]

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 .

--

[Winston]

Horace Algier <hor...@horatio.net> wrote:
>> The cloning is on a different MAC address, which is not the MAC
>> address of concern here.

bruce <br...@invalid.dyndns.tv.invalid> replied:
> Huh?

Referring to a typical consumer-grade wireless router, I believe he
meant that cloning a MAC address usually was to change the WAN MAC
address, whereas he was discussing the WLAN MAC address, which (at the
time he wrote that) he thought couldn't be changed without hardware
mods. I think he has since learned that WLAN MAC addresses are, in
general, set via software from saved configuration.

There are many consumer-class routers I've never dealt with, so I don't
know if he's right in thinking that the manufacturer's firmware for some
routers does not support changing the WLAN MAC address.

Elsewhere I said I don't see this as big issue. Even when the WLAN MAC
address can be changed, in practice, for most routers out there, my
impression is that once the router's been configured, the WLAN MAC
address one sees at a particular location generally won't change unless
the router gets replaced.
-WBE

[Horace Algier]

On Sat, 17 Sep 2016 09:17:12 +0100, Andy Burns wrote:
On 17 Sep 2016 17:27:50 GMT, Frank Slootweg wrote:

It's well known that the nyms "Frank Slootweg" and "Andy Burns" are the
same troll, hence no response is necessary.

[Horace Algier]

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.
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.

I think here is where we get mired in conflicting details, which are better
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.

I'm completely and intimately familiar with the fact that the BSSID only
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.

Are you saying that you have 32 different access points in "a single
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.

I see why you are frustrated in this conversation.

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]

In article <nrku8g$9od$1...@news.mixmin.net>, Horace Algier

<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:
<https://admin.mashable.com/wp-content/uploads/2014/03/motorola-dynatac-
8000x1.jpg>

[Horace Algier]

On Sat, 17 Sep 2016 10:08:20 -0400, nospam wrote:

> nevertheless, ios has had mac address randomization built into the os
> since ios 8

This is an interesting paper...
http://papers.mathyvanhoef.com/asiaccs2016.pdf

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

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

In the first one, we create fake hot spots to induce clients to connect
using their real MAC address. The second technique relies on the new
802.11u standard, commonly referred to as Hotspot 2.0, where we show that
Linux and Windows send Access Network Query Protocol (ANQP) requests using
their real MAC address. ...

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

[Horace Algier]

On Sat, 17 Sep 2016 19:04:01 -0400, Winston wrote:

> Referring to a typical consumer-grade wireless router, I believe he
> meant that cloning a MAC address usually was to change the WAN MAC
> address, whereas he was discussing the WLAN MAC address, which (at the
> time he wrote that) he thought couldn't be changed without hardware
> mods.

This is correct.

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

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

> I think he has since learned that WLAN MAC addresses are, in
> general, set via software from saved configuration.

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

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

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

> There are many consumer-class routers I've never dealt with, so I don't
> know if he's right in thinking that the manufacturer's firmware for some
> routers does not support changing the WLAN MAC address.

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

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

> Elsewhere I said I don't see this as big issue. Even when the WLAN MAC
> address can be changed, in practice, for most routers out there, my
> impression is that once the router's been configured, the WLAN MAC
> address one sees at a particular location generally won't change unless
> the router gets replaced.

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

The main question is:
1. Under what circumstances is an iOS or Android *phone's* MAC address
*uploaded* to the Google PUblic Database by poorly configured Android
devices in the vicinity?

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

[Horace Algier]

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.

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.

>>> 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.
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.

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

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

Nobody is disputing what you're saying - but what you're saying has
*nothing* whatsoever to do with the topic at hand!

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

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

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

>>> 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.

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 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.

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.

[Horace Algier]

On Sun, 18 Sep 2016 03:43:26 +0000 (UTC), Horace Algier wrote:

> This is an interesting paper...
> http://papers.mathyvanhoef.com/asiaccs2016.pdf
>
> Why MAC Address Randomization is not Enough: An Analysis of Wi-Fi Network
> Discovery Mechanisms
>
> "We present two attacks that reveal the real MAC address of a device, even
> if MAC address randomization is used.

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

2.1.1 iOS
Apple added MAC address randomization to its devices
starting from iOS 8 [42]. In iOS 8, randomized addresses are
only used while unassociated and in sleep mode [18]. iOS 9
was extended to also use randomization in what Apples calls
location and auto-join scans [42]. Based on our own experiments,
this means that randomization is now also used when
the device is active, i.e., when the screen is turned on.

2.1.2 Android
Android 6.0 uses randomization for background scans if
the driver and hardware support it [2]. Unfortunately, we
did not have a device to test and verify this in practice.
Although Android versions before 6.0 do not support randomization,
several applications supporting this feature have
been released [9, 3]. Common features of those applications
are a periodical update of the MAC address to a random
value, but also the manual modication of this address by
the user. Note that those applications require root privilege
to operate, which reduce their impact for the average user.

2.1.4 Linux
Linux added support forMAC address randomization during
network scans in kernel version 3.18. The address should
be randomized for each scan iteration [24]. Drivers must be
updated to support this feature. The mvm module of the
iwlwifi driver supports randomization since kernel 3.18.
The brcmfmac driver added support for this in kernel 4.5.
The privacy-oriented Linux distribution Tails [1] does not
support MAC address randomization during network scans.
Instead, it generates a (new) random MAC address at boot.
This random address keeps the rst 3 bytes of the original
address, the Organization Unique Identier (OUI), and
only randomizes the last three bytes. While not as optimal
as periodical address changes, it does prevent tracking over
extended periods of time.

2.1.3 Windows
Microsoft supports randomization since Windows 10 [45].
Enabling randomization is possible if the hardware and driver
support it. Interestingly, not only does Windows use random
addresses for probe requests, it also uses a random address
when connecting to a network. To assure the client always
uses the same address when connecting to a particular network,
a per-network address is calculated as follows [27, 28]:
addr = SHA-256(SSID; macaddr; connId; secret)[:6] (1)
Here SSID is the name of the network, macaddr the original
MAC address, and connId a parameter that changes
if the user removes (and re-adds) the network to its preferred
network list. The secret parameter is a 256-bits cryptographic
random number generated during system initialization,
unique per interface, and kept the same across reboots
[28]. Bits in the most signicant byte of addr are set
so it becomes a locally administered, unicast address. This
hash construction is similar to the generation of IPv6 interface
identiers as proposed in RFC 7217 [21]. It assures that
systems relying on xed MAC addresses continue to work as
expected, e.g., when authentication is performed based on
the MAC address. Users can also manually instruct the OS
to daily update the per-network address randomly.

[Horace Algier]

On Sun, 18 Sep 2016 03:49:37 +0000 (UTC), Horace Algier wrote:

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

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

http://papers.mathyvanhoef.com/asiaccs2016.pdf

2.1.4 Linux
Linux added support forMAC address randomization during
network scans in kernel version 3.18. The address should
be randomized for each scan iteration [24]. Drivers must be
updated to support this feature. The mvm module of the
iwlwifi driver supports randomization since kernel 3.18.
The brcmfmac driver added support for this in kernel 4.5.
The privacy-oriented Linux distribution Tails [1] does not
support MAC address randomization during network scans.
Instead, it generates a (new) random MAC address at boot.

This random address keeps the first 3 bytes of the original
address, the Organization Unique Identier (OUI), and

only randomizes the last three bytes. While not as optimal
as periodical address changes, it does prevent tracking over
extended periods of time

2.1.2 Android
Android 6.0 uses randomization for background scans if
the driver and hardware support it [2]. Unfortunately, we
did not have a device to test and verify this in practice.
Although Android versions before 6.0 do not support randomization,
several applications supporting this feature have
been released [9, 3]. Common features of those applications
are a periodical update of the MAC address to a random

value, but also the manual modification of this address by

the user. Note that those applications require root privilege
to operate, which reduce their impact for the average user.

2.1.1 iOS
Apple added MAC address randomization to its devices
starting from iOS 8 [42]. In iOS 8, randomized addresses are
only used while unassociated and in sleep mode [18]. iOS 9
was extended to also use randomization in what Apples calls
location and auto-join scans [42]. Based on our own experiments,
this means that randomization is now also used when
the device is active, i.e., when the screen is turned on.

2.1.3 Windows
Microsoft supports randomization since Windows 10 [45].
Enabling randomization is possible if the hardware and driver
support it. Interestingly, not only does Windows use random
addresses for probe requests, it also uses a random address
when connecting to a network. To assure the client always
uses the same address when connecting to a particular network,
a per-network address is calculated as follows [27, 28]:
addr = SHA-256(SSID; macaddr; connId; secret)[:6] (1)
Here SSID is the name of the network, macaddr the original
MAC address, and connId a parameter that changes
if the user removes (and re-adds) the network to its preferred
network list. The secret parameter is a 256-bits cryptographic
random number generated during system initialization,
unique per interface, and kept the same across reboots

[28]. Bits in the most significant byte of addr are set

so it becomes a locally administered, unicast address. This
hash construction is similar to the generation of IPv6 interface

identifiers as proposed in RFC 7217 [21]. It assures that
systems relying on fixed MAC addresses continue to work as

[Frank Slootweg]

Says Horace Algier... 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"...

Andy, I hope you're not offended! :-)

[Horace Algier]

On 19 Sep 2016 15:42:28 GMT, Frank Slootweg wrote:

> Andy, I hope you're not offended! :-)

The troll Andy Slootweg doth protest too much, methinks.

[Carlos E.R.]

On 2016-09-16 21:33, Horace Algier wrote:
> On Thu, 15 Sep 2016 09:49:06 -0700, AL wrote:
>
>>> Yep. Resistance if futile. You've already been assimilated.
>>
>> And Google is not the only assimilator... 8-O
>
> The Nordstrom example is interesting, but it's not the mechanism that I'm
> looking at in this question.

wait.

> The question is... under what *other* conditions (other than acting as an
> Access Point) does an iOS or Android mobile device get put into the Google
> Public Database by poorly configured Android devices?

Notice this bit in the article:

«that would scan for smartphones with Wi-Fi turned on and scanning for
networks»

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


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

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


--
Cheers, Carlos.

[Andy Burns]

Frank Slootweg wrote:

> Horace Algier wrote:
>
>> It's well known that the nyms "Frank Slootweg" and "Andy Burns" are the
>> same troll, hence no response is necessary.
>
> Says Horace Algier... 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"...
>
> Andy, I hope you're not offended! :-)

Heh, not at all.

Just standing back and watching as he continues making a fool of
himself, and trying to reel in fresh catches ...

[Frank Slootweg]

There's no such person/entity, but there *is* the dishonest lying
obnoxious pompous nymshifting morphing jerk Horace Algier
<hor...@horatio.net>... oops I mean "Aardvarks"... oops I mean "Paul

[Horace Algier]

On Mon, 19 Sep 2016 18:41:33 +0100, Andy Burns wrote:

> Just standing back and watching

Talking to yourself Frank Burns.