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 3 of 3 — ← Prev page 1 2 [3]

#34415

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

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

This is correct.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#34411

On Sat, 17 Sep 2016 16:12:40 -0400, bruce wrote:

>> This is not true that "SSID has nothing to do with cellphones".
> 
> Yes, I'm afraid it is true.  To reject it implies that you believe that
> all cellphones do wifi.  I have two on the shelf in this room that do
> not do and never did do wifi.

OK. You found a corner case, where not all cellphones do WiFi.
Since I also have iOS equipoment, all my iOS equipment has WiFi also.

While I am sure they exist, I personally have never seen a cellphone that 
doesn't do WiFi; but I also have a limit on cellphones of 16GB minimum, 
1GHz minimum, 1GB RAM minimum, etc., where the cost is never below $200 so, 
the cellphones "I" have bought *all* have WiFi.

I did goof with the wife's $200 Moto G, which only has 2.4GHz WiFi, since I 
simply *assumed* that all of the WiFi cellphones had *both* 2.4GHz and 5GHz 
WiFi ... so I agree with you on the wide range of what Android phones do.

>> As Jeff and I just discussed, if an Android or iOS cellphone acts as
>> an Access Point, then that cellphone will broadcast an SSID.
> 
> This is consistent with what I wrote above and what I wrote below.  This
> action has nothing to do with it being a cellphone but to do with it
> acting at this point as a wifi device.

I think here is where we get mired in conflicting details, which are better 
discussed in person, because the mere fact that the BSSID is encapsulated 
in the clear in the WiFi packet is *absolutely meaningless* for the purpose 
of this discussion *if* all those poorly configured Android devices don't 
*upload* that BSSID to the Google Public Database.

The *only* BSSID that matters for this discussion is the BSSID which is 
*uploaded* to the Google Public Database by all those poorly configured 
Android devices.

>> If that iOS or Android cellphone broadcasts an SSID, it also
>> broadcasts a BSSID, which is unique to that cellphone.  
> 
> Not necessarily.  The protocols allow the creation of a BSSID on the
> fly.  It only has to be unique within the (very short) range of the
> radios in use.

I'm completely and intimately familiar with the fact that the BSSID only 
has to be unique on the subnet, e.g., you can use DE:AD:BE:EF:CA:FE on your 
own network and it won't matter, as long as only a single device on your 
network has that BSSID.

Up until Jeff's later responses, I had thought that the BSSID that matters 
(which is the one *uploaded* to the Google database by poorly configured 
Android devices!) was hard to change, and it is, for a typical 
factory-software router.

But Jeff explained that certain firmware will enable that all-important 
BSSID (which is the one that is *uploaded* to the Google database by poorly 
configured Android devices) *can* be changed on a router.

In addition, Jeff noted that, for Android devices which are *rooted*, that 
all-important BSSID (which is the one *uploaded* to the Google publid 
database by poorly configured Android devices) *can* be changed.

Unfortunately, a quick search on Google shows a history of Apple *breaking* 
any jailbroken device's ability to change that specific BSSID with each new 
OS version - so we can effectively say it can't easily be done on iOS 
(which is another reason why iOS has less privacy than Android in certain 
situtations).

>> In fact, it
>> broadcasts *two* BSSIDs, one for each radio (5Ghz and 2.4Ghz).
> 
> Actually, any wifi device acting as a BSS can identify itself as up to
> 32 BSSIDs and 1 or more SSIDs per radio.  So, yes, a single radio can
> simultaneously be using 32 different BSSIDs/MACs.

Are you saying that you have 32 different access points in "a single 
radio"?

It's possible - but remember, the *only BSSID that matters* for this 
conversation is the one that is *uploaded* to the Google Public Database by 
poorly configured Android devices.

All other BSSIDs are meaningless for the purpose of this discussion.

Given that, are you saying that you have *32* different SSIDs which are 
being uploaded, as we speak, to the Google Public Database by all poorly 
configured Android devices in your vicinity?
 
>> It's *those* unique BSSIDs which are captured by poorly configured
>> Android devices and uploaded multiple times a day to the Google Public
>> Database, along with the GPS location of the poorly configured Android
>> device and the SSID and Signal Strength of the access point.
> 
> As I said below, poorly configured has nothing to do with it when any
> user level program running on the BSS or within the cellphone can access
> the very same wifi information and pass it on to whomever it wishes.

I see why you are frustrated in this conversation.

Jeff already noted that there are *plenty* of situations where a BSSID is 
found, in the clear, in the context of WiFi communications.

Since *this* discussion is *only* about exploring privacy flaws in the 
Google Public Database, the only BSSID that matters for this discussion is 
the BSSID that is *uploaded* to the Google Public Database by all poorly 
configured Android devices in your vicinity.

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

#34412

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

> >> This is not true that "SSID has nothing to do with cellphones".
> > 
> > Yes, I'm afraid it is true.  To reject it implies that you believe that
> > all cellphones do wifi.  I have two on the shelf in this room that do
> > not do and never did do wifi.
> 
> OK. You found a corner case, where not all cellphones do WiFi.
> Since I also have iOS equipoment, all my iOS equipment has WiFi also.
> 
> While I am sure they exist, I personally have never seen a cellphone that 
> doesn't do WiFi; 

this one doesn't:
<https://admin.mashable.com/wp-content/uploads/2014/03/motorola-dynatac-
8000x1.jpg>

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

#34416

On Sat, 17 Sep 2016 16:12:40 -0400, bruce wrote:

>> Notice this allows such iOS or Android cellphones to be tracked!
> 
> Did I ever say anything to contradict this?  I merely pointed out that
> cellphone configuration, if done "properly" (whatever that means) won't
> cure the problem when user level code running on the equipment can
> accomplish the same thing.  In fact, it might be through user level code
> that it is being accomplished right now.

Since *this* discussion is *only* about exploring privacy flaws in the 
Google Public Database, the only BSSID that matters for this discussion is 
the BSSID that is *uploaded* to the Google Public Database by all poorly 
configured Android devices in your vicinity.

>>> SSID is just a name.  There could be thousands of wifi access points
>>> around the world with the same SSID.
>>
>> I agree. SSID is "just a name". If the name ends with "_nomac", Google 
>> promises to *drop* that SSID from its' public database.
> 
> While Google might honor the use of the suffix (for now) it doesn't mean
> that anybody else will.

It's even worse than that.
1. While we all know that *hiding* the SSID is futile, it's actually 
*useful* to hide your SSID in that the poorly configured Android devices 
apparently do *not* upload "hidden" SSIDs to the Google Public Database.

2. However, most of us don't "hide" our SSID from being broadcast (since 
there is almost zero security value in hiding the SSID broadcast).

3. Hence, our SSIDs are being *uploaded* to the Google Public Database by 
poorly configured Android devices whether or not we have "_nomac" at the 
end of the SSID.

4. What's worse, the *unique* BSSID of the radio is also uploaded at the 
same time (along with the signal strength of the SSID and the current GPS 
location of the poorly configured Android device).

Therefore, the SSID is the *least* of our privacy worries (unless we're 
dumb enough to name our SSID after our first and last name or something 
similarly identifiable).

The privacy concern is the association of the *hard-to-change* unique MAC 
address with its GPS location. 

These two critical pieces of metadata are *uploaded* to the Google Public 
Database by poorly configured Android devices, whether or not you put 
"_nomac" on the SSID.

>> However, you must realize that the Google Public Database contains
>> *more* than the SSID! It contains the *unique* BSSID associated with
>> that SSID, and furthermore, it contains the Signal Strength of that
>> access point at a specific GPS location of the poorly configured
>> Android device that is near that access point.
>>
>> Anyone who doesn't *understand* that paragraph above can't possibly 
>> understand the topic of this thread - so it's critical that the paragraph 
>> above be *understood*.
> 
> That "paragraph above" means absolutely nothing until one understands
> that even in a "properly configured" phone user level code could be
> gathering the same information (or more) and sending it to agents
> unknown. 

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

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

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

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

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

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

>>> A wifi access point consists of one or more radios to create a WAN.
>>> Each radio is a BSS with a BSSID, which is also known as a MAC.  Each
>>> network device/radio has (by design, but not always in fact) a unique
>>> value for the MAC.
>>
>> I agree. Specifically, if an iOS or ANdroid cellphone is acting as an 
>> access point, then its 5GHz and 2.4Ghz radio will broadcast the following:
>> a. The cellphone AP SSID
>> b. The cellphone AP BSSID
>>
>> What you must understand to understand the question, is that poorly 
>> configured Android devices will *send* to Google not only that information 
>> above, but *more* information!
>>
>> Poorly configured Android devices will send to Google:
>> a. Your cellphone AP SSID
>> b. Your cellphone AP BSSID (aka MAC address)
>> c. Your AP signal strength seen by the poorly configured Android cellphone
>> d. The GPS location of the poorly configured Android cellpone
> 
> As stated above, poorly configured is not the problem, and Google might
> not be the only recipient.

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

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


>>> A device wishing to connect to a wifi access point looks for a
>>> broadcast wifi packet with a particular SSID in the data field of the
>>> packet.  The header to the packet contains the BSSID/MAC of the
>>> access point in source field.  To connect to the access point the
>>> device sends a packet back to the sender of the broadcast by putting
>>> the access point's BSSID in the destination field of the packet and
>>> its own MAC in the source field.  The rest of the connection protocol
>>> is left as an exercise for the reader.
>>
>> This part is understood that the BSSID of the 5Ghz and 2.4GHz radios
>> in both iOS and Android devices is sent in the clear in packets
>> whenever those cellphones connect to an access point.
>>
>> But I'm not talking about that.
>>
>> I'm only talking about when an iOS or Android cellphone has the
>> following four bits of information *sent* to the Google database by
>> poorly configured
>> Android devices:
>> a. Your cellphone AP SSID
>> b. Your cellphone AP BSSID (aka MAC address)
>> c. Your AP signal strength seen by the poorly configured Android
>>     cellphone
>> d. The GPS location of the poorly configured Android cellpone
> 
> Get off this poorly configured fixation you have.  A perfect config-
> uration with any amount of user-level programs has potentially the same
> nasty possibilities.

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

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

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

#34242

I assume you're referring to things like:

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

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

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

and the like.  (I Googled for "Android, cellphone, collecting router
SSID, location, privacy" and got those and many other articles.)

There's two broad categories: whether there are risks to the person
carrying the cellphone and whether there are risks to the people around
them operating a wireless router.

It looks to me like you are NOT talking about risks to the wireless
router owners.  You're asking about locating a cellphone owner, so I'll
focus on that.

There were several ideas floating around a few years ago, as I recall.

* In NYC skyscrapers and the like, there are situations where knowing
  more than just the street address might be useful.  If the building
  has wireless routers, and if their locations are known, then it
  becomes possible to estimate which floor one is on from which router
  signals one hears and how strongly.

* IIRC (and I might not be), there was talk of whether it would be
  practical to gradually replace expensive cellphone towers with large
  numbers of cheap WiFi access points for cellphones (femto access
  points, I think I've heard them called).  Doing so would also help
  pinpoint the cellphone's location more accurately than is possible
  with the big cellphone towers, since the range of any particular
  femto-cell would be small.  Cellphones able to switch between
  cellphone mode and WiFi mode on the fly, or even just use WiFi for
  data, might also reduce TelCo-metered usage.

You speak about getting a location via Google even though you enter a
fake signal strength.  I don't see how that can work.  If you say a
signal is really strong, that indicates you're close.  If you say the
signal is weak, you're further away.  Choose any combination of places
around the world and make up whatever signal strengths you like, and you
probably can get a result anywhere on Earth, even if those numbers are
impossible in practice.

If I have a wireless router in Google's database, and you submit
something that says you hear my router (at all), I would think it'll say
you're somewhere near me, even if you aren't.  As you enter more
numbers, you can triangulate a position, but if you're making up
numbers, the answers wouldn't be meaningful.


A few specific points:

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

(B)SSID aside, all cellphones are tracked to the level of "nearest
cellphone tower" whenever they're on.  If they're within range of more
than one tower, the range of possible locations is greatly reduced.

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

Huh?  The wireless routers I've configured allow changing of their MAC
addresses, often during the initial setup/configuration.  (See DD-WRT,
ifconfig options wlanbssid #id and wlanaddr #addr (the latter sets the
WLAN local MAC address).  Regarding some other options, 'man ifconfig'
says "Note that this feature does not significantly enhance security as
MAC address spoofing is easy to do.")

There once was a company that manufactured Ethernet devices that all had
the same MAC address.  When customers discovered that, they got upset.
The manufacturer changed to providing unique addresses (I think).  While
customers could change the MAC address, they didn't have enough
information to ensure the address they chose was unique, as the
manufacturers do.

OTOH, if you meant cellphone instead of router, I'd mostly agree:
cellphone handsets are intended to have unique IDs.  However, I'm not
sure whether that's the same as the MAC address the cellphone would use
to connect to a WiFi hotspot (but maybe it is).

Whether it's changeable or not doesn't really matter: once a router has
been configured, its MAC addresses are rarely changed (short of
replacing the router), so once SSID X has been heard transmitting at
location Y, the X,Y pair should be valid for some time.  [I can also
think of ways to handle the case of duplicate MAC addresses (except when
the duplicates are operating so close to each other that one can be in
both of their signal areas at the same time).]

Fortunately, they're irrelevant to the question of whether Google's
database can be used by someone remotely to locate a cellphone user in
the absence of actual signal information.  I don't see an obvious way to
do that.  There's also the method of accessing the cellphone's own
recorded location history file (see articles), but that doesn't involve
Google.

Have I completely missed the point?
 -WBE

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

#34314

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#34315

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

> There's two broad categories: whether there are risks to the person
> carrying the cellphone and whether there are risks to the people around
> them operating a wireless router.

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

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

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

That's all I'm asking about.

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

That is the question!

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

#34318

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

> OTOH, if you meant cellphone instead of router, I'd mostly agree:
> cellphone handsets are intended to have unique IDs.  However, I'm not
> sure whether that's the same as the MAC address the cellphone would use
> to connect to a WiFi hotspot (but maybe it is).

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

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

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

#34319

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

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

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

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

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

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

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

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

#34331

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

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

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

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

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

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

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

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

#34335

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

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

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

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

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

> Like a PC or laptop allows anyone to
> change the MAC address of its ethernet port or wireless device, you
> *can* change the MAC address of a software based smartphone access point
> if you have root access.

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

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

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

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

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

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

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

2. CELLPHONE
a. You do not have root access on either an iOS or Android cellphone unless
you jailbrake or root it, so you can't change the MAC address of the access
point of a non-rooted (aka non jailbroken) iOS or Android device.
b. However, if you jailbreak (or root) the iOS or Android device, you *can*
change the access point MAC address (which is what Google harvests).
 
> If you want to drive Google partly nuts, just change your smartphone
> wi-fi MAC address at irregular intervals.  That won't stop them from
> tracking you by some of the other stuff they are harvesting from your
> phone, but it's a good start.

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

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

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

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

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

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

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

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

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

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

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

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

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

#34337

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

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

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

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

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

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

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

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

#34346

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

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

apple doesn't break stuff with every new release. 

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

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

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

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

#34349

nospam wrote:

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

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

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

#34414

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

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

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

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

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

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

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

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

#34417

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

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

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

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

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

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

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

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

#34418

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

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

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

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

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

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

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

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

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

#34320

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

> (B)SSID aside, all cellphones are tracked to the level of "nearest
> cellphone tower" whenever they're on.  If they're within range of more
> than one tower, the range of possible locations is greatly reduced.

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

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

#34321

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

> You speak about getting a location via Google even though you enter a
> fake signal strength.  I don't see how that can work.  If you say a
> signal is really strong, that indicates you're close.  If you say the
> signal is weak, you're further away.  Choose any combination of places
> around the world and make up whatever signal strengths you like, and you
> probably can get a result anywhere on Earth, even if those numbers are
> impossible in practice.


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

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

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

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

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

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

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

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

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

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

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

[toc] | [prev] | [standalone]

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

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

csiph-web