Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #34163 > unrolled thread

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

Back to article view | Back to comp.mobile.android

Contents

  How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-13 06:00 +0000
    Re: How to look up the GPS location of your MAC address or car on the Internet "Carlos E.R." <robin_listas@invalid.es> - 2016-09-13 15:34 +0200
      Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-13 16:06 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet "Carlos E. R." <robin_listas@invalid.es> - 2016-09-14 00:20 +0200
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-14 04:41 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet William Unruh <unruh@invalid.ca> - 2016-09-14 00:27 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-14 04:41 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Andy Burns <usenet@andyburns.uk> - 2016-09-14 07:35 +0100
            Re: How to look up the GPS location of your MAC address or car on the Internet Frank Slootweg <this@ddress.is.invalid> - 2016-09-14 07:54 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet "Kerr Mudd-John" <admin@127.0.0.1> - 2016-09-15 11:53 +0100
            Re: How to look up the GPS location of your MAC address or car on the Internet pamela <invalid@nospam.com> - 2016-09-17 14:28 +0100
              Re: How to look up the GPS location of your MAC address or car on the Internet "Kerr Mudd-John" <admin@127.0.0.1> - 2016-09-17 21:30 +0100
          Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-15 08:45 -0700
            Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-15 08:51 -0700
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:30 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 18:43 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet Andy Burns <usenet@andyburns.uk> - 2016-09-16 20:08 +0100
                Re: How to look up the GPS location of your MAC address or car on the Internet Andy Burns <usenet@andyburns.uk> - 2016-09-17 09:17 +0100
                  Re: How to look up the GPS location of your MAC address or car on the Internet Frank Slootweg <this@ddress.is.invalid> - 2016-09-17 17:27 +0000
                    Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 02:12 +0000
                      Re: How to look up the GPS location of your MAC address or car on the Internet Frank Slootweg <this@ddress.is.invalid> - 2016-09-19 15:42 +0000
                        Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-19 16:33 +0000
                          Re: How to look up the GPS location of your MAC address or car on the Internet Frank Slootweg <this@ddress.is.invalid> - 2016-09-19 17:42 +0000
                        Re: How to look up the GPS location of your MAC address or car on the Internet Andy Burns <usenet@andyburns.uk> - 2016-09-19 18:41 +0100
                          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-20 03:21 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-16 13:04 -0700
                Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 20:23 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-15 08:31 -0700
          Re: How to look up the GPS location of your MAC address or car on the Internet AL <noemail@none.invalid.com> - 2016-09-15 09:49 -0700
            Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:33 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet "Carlos E.R." <robin_listas@invalid.es> - 2016-09-19 19:22 +0200
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:30 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-16 13:16 -0700
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 04:52 +0000
    Re: How to look up the GPS location of your MAC address or car on the Internet William Unruh <unruh@invalid.ca> - 2016-09-14 00:24 +0000
      Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-14 04:40 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet bruce <bruce@invalid.dyndns.tv.invalid> - 2016-09-14 18:41 -0400
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 19:56 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet bruce <bruce@invalid.dyndns.tv.invalid> - 2016-09-17 16:12 -0400
              Re: How to look up the GPS location of your MAC address or car on the Internet Winston <wbe@UBEBLOCK.psr.com.invalid> - 2016-09-17 19:04 -0400
                Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:43 +0000
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 02:30 +0000
                Re: How to look up the GPS location of your MAC address or car on the Internet nospam <nospam@nospam.invalid> - 2016-09-17 22:54 -0400
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:43 +0000
        Re: How to look up the GPS location of your MAC address or car on the Internet Winston <wbe@UBEBLOCK.psr.com.invalid> - 2016-09-15 01:04 -0400
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 23:17 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-16 23:36 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 01:59 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 01:59 +0000
            Re: How to look up the GPS location of your MAC address or car on the Internet Jeff Liebermann <jeffl@cruzio.com> - 2016-09-16 22:22 -0700
              Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 06:17 +0000
                Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 06:32 +0000
                  Re: How to look up the GPS location of your MAC address or car on the Internet nospam <nospam@nospam.invalid> - 2016-09-17 10:08 -0400
                    Re: How to look up the GPS location of your MAC address or car on the Internet Peter Köhlmann <peter-koehlmann@t-online.de> - 2016-09-17 16:13 +0200
                    Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:43 +0000
                      Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 03:49 +0000
                        Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-18 04:00 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 01:59 +0000
          Re: How to look up the GPS location of your MAC address or car on the Internet Horace Algier <horatio@horatio.net> - 2016-09-17 02:00 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#34472

Horace Algier <horatio@horatio.net> wrote:
> 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.

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

[toc] | [prev] | [next] | [standalone]

#34478

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.

[toc] | [prev] | [next] | [standalone]

#34483

Horace Algier <horatio@horatio.net> wrote:
> 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.

  There's no such person/entity, but there *is* the dishonest lying
obnoxious pompous nymshifting morphing jerk Horace Algier
<horatio@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"...

[toc] | [prev] | [next] | [standalone]

#34482

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

[toc] | [prev] | [next] | [standalone]

#34499

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

> Just standing back and watching

Talking to yourself Frank Burns.

[toc] | [prev] | [next] | [standalone]

#34309

On Fri, 16 Sep 2016 18:43:57 +0000 (UTC), Horace Algier
<horatio@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.

>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.
-- 
Jeff Liebermann     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]

#34363

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.

[toc] | [prev] | [next] | [standalone]

#34252

On Tue, 13 Sep 2016 16:06:47 +0000 (UTC), Horace Algier
<horatio@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     jeffl@cruzio.com
150 Felker St #D    http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann     AE6KS    831-336-2558

[toc] | [prev] | [next] | [standalone]

#34256

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

[toc] | [prev] | [next] | [standalone]

#34303

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?

[toc] | [prev] | [next] | [standalone]

#34481

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.

[toc] | [prev] | [next] | [standalone]

#34299

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?

[toc] | [prev] | [next] | [standalone]

#34310

On Fri, 16 Sep 2016 19:30:07 +0000 (UTC), Horace Algier
<horatio@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.

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

[toc] | [prev] | [next] | [standalone]

#34330

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.

[toc] | [prev] | [next] | [standalone]

#34203

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

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

[toc] | [prev] | [next] | [standalone]

#34206

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?

[toc] | [prev] | [next] | [standalone]

#34239

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

-- 

[toc] | [prev] | [next] | [standalone]

#34308

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.

[toc] | [prev] | [next] | [standalone]

#34365

Horace Algier <horatio@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                        .

-- 

[toc] | [prev] | [next] | [standalone]

#34378

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

bruce <bruce@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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.mobile.android

csiph-web