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