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

Groups > alt.os.linux > #38801 > unrolled thread

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

Back to article view | Back to alt.os.linux

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 Vladimir <niemda@me.com> - 2016-09-13 20:47 +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 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 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 1 of 3  [1] 2 3  Next page →

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

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?




 

[toc] | [next] | [standalone]

#38806

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.

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

#38808

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.

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

#38815

On 2016-09-13, Horace Algier <horatio@horatio.net> wrote:
> Thanks for taking a risk by trying to answer the question.

I will, just to support conversation and enjoy some NNTP nostalgia. :)

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

I think you are confusing terms here. MAC is unique identifier for
your network hardware: your Wi-Fi module, for example. SSIDs (if, of
course, we are talking about Wi-Fi here) are identifiers of the networks.

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

Yes, because it has to establish network, assign IP addresses and send
packets to correct devices, and so and so. Same happens when your device
connects to other network, to receive IP address or tell other devices
that specific address belongs to it; it has to broadcast its MAC. And
then, MAC address is broadcasted every time device wants to send a
packet to another device in same network. This called ARP in IPv4
networks.

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

Yes, they can do that, obviously. They have to be connected to network
which is established by this hotspot, of course. In this case, yes, they
can send MAC addresses and own GPS coordinates to Google. And Google (or
Apple, or Microsoft, or whatever E-Corp is there on the market now) can
build a map out of it.

So if some dude with Android device walks near you, his device cannot just
sniff your MAC address unless you keep open hotspot 24/7.

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

You can spoof your MAC addresses quite easily, if you afraid of it. You
can pretend to be an AppleTV, PlayStation or Raspberry Pi. :)

--
Vladimir Mikhaylenko (niemda@me.com)

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

#38817

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.

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

#38822

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

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

#38819

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

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

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

#38821

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.

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

#38823

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

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

#38826

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

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

#38838

On Wed, 14 Sep 2016 08:54:56 +0100, Frank Slootweg  
<this@ddress.is.invalid> wrote:

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

It's a xposting troll.

-- 
Bah, and indeed, Humbug

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

#38842

On Wed, 14 Sep 2016 00:27:22 -0000 (UTC), William Unruh
<unruh@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     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]

#38843

On Thu, 15 Sep 2016 08:45:37 -0700, Jeff Liebermann <jeffl@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...)
-- 
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]

#38872

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:

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

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

#38870

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.

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

#38875

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]

#38919

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]

#38841

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]

#38845

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]

#38873

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]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.os.linux

csiph-web