Google admits it tracked user location data even when the setting was turned off

[harry newton]

Google admits it tracked user location data even when the setting was
turned off. It did so via cell tower data.
<https://www.theverge.com/2017/11/21/16684818/google-location-tracking-cell-tower-data-android-os-firebase-privacy>

Android phones gather your location data and send it to Google, even if
you+IBk-ve turned off location services and don+IBk-t have a SIM card.

Since January, all kinds of Android phones and tablets have been collecting
the addresses of nearby cellular towers and sending the encrypted data to
Google+IBk-s push notifications and messaging management system when connected
to the internet. It+IBk-s a practice that customers can+IBk-t opt out of.

Google ultimately discarded the cell tower data...The findings are
surprising, given that cell tower data is usually held by carrier networks
and only shared with outside companies under extreme circumstances.

An update that removes this cell tower data-collecting feature will roll
out by the end of this month.

[harry newton]

He who is harry newton said on Tue, 21 Nov 2017 22:32:53 +-0000 (UTC):

> Google admits it tracked user location data even when the setting was
> turned off. It did so via cell tower data.
> <https://www.theverge.com/2017/11/21/16684818/google-location-tracking-cell-tower-data-android-os-firebase-privacy>

Does anyone know more about disabling "Firebase Cloud Messaging" services?
For example, what if you're on Android 4.3 (like I am) with all location
services disabled?

Here's another article...

Google collects Android users+IBk- locations even when location services are
disabled

<https://qz.com/1131515/google-collects-android-users-locations-even-when-location-services-are-disabled/>
Since the beginning of 2017, Android phones have been collecting the
addresses of nearby cellular towers+IBQ-even when location services are
disabled+IBQ-and sending that data back to Google.

Google was apparently collecting cell tower data from all modern Android
devices before being contacted by Quartz. A source familiar with the matter
said the cell tower addresses were being sent to Google after a change in
early 2017 to the Firebase Cloud Messaging service, which is owned by
Google and runs on Android phones by default.

Devices with a cellular data or WiFi connection appear to send the data to
Google each time they come within range of a new cell tower. When Android
devices are connected to a WiFi network, they will send the tower addresses
to Google even if they don+IBk-t have SIM cards installed.

Android devices never offered consumers a way to opt out of the collection
of cell tower data.

[nospam]

In article <ov29ik$kmd$1...@gioia.aioe.org>, harry newton

<ha...@is.invalid> wrote:

> Google admits it tracked user location data even when the setting was
> turned off. It did so via cell tower data.

you were *so* sure you had blocked google's ability to track you, going
to such extreme lengths as changing your google id every few weeks.

many people told you that you were still being tracked, but you blindly
dismissed it.

now you know.

[harry newton]

He who is nospam said on Tue, 21 Nov 2017 17:55:51 -0500:

> you were *so* sure you had blocked google's ability to track you, going
> to such extreme lengths as changing your google id every few weeks.
>
> many people told you that you were still being tracked, but you blindly
> dismissed it.
>
> now you know.

You would love that to be the case, but, you're jumping to conclusions out
of confirmation bias (i.e., you *wish* it were true).

I looked and I don't think it's the case for me since I don't see (yet)
anything called "Firebase Cloud Messaging" on my Android 4.3 phone.

Time will tell which phones were affected, but this is a good one for
Google to get sued on, as it certainly will take some 'splaining why they
captured unique cell tower IDs when Location Services were disabled.

All we know, so far, is that it started in January of this year, and that
it used "Firebase Cloud Messaging" services - whatever that is. I googled
it, and I don't think it's even on my phone - but it's too early to tell
just yet what's going on.

Google apparently immediately said they'd terminate the practice of
capturing cell tower unique IDs - so, it doesn't appear to be something
they sanctioned (because they wouldn't likely have agreed to terminate the
practice so quickly if they had their legal ducks already lined up).

Time will tell which devices are affected - but I don't even see the app on
my phone - which is rooted - so I can delete it - if I can find it - but it
doesn't seem to exist.

To other android users:
Q: Do you see a process for "Firebase Cloud Messaging" services?

[Jeff Liebermann]

On Tue, 21 Nov 2017 23:48:55 +0000 (UTC), harry newton
<ha...@is.invalid> wrote:

>To other android users:
> Q: Do you see a process for "Firebase Cloud Messaging" services?

It's not an app. It's service:
<https://firebase.google.com/docs/cloud-messaging/>
<https://firebase.google.com/products/cloud-messaging/>
You download the API and link it into your application. It runs on a
variety of platforms including Apple IOS.

More:
<https://www.google.com/search?q=Firebase+Cloud+Messaging>

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

[harry newton]

He who is harry newton said on Tue, 21 Nov 2017 23:48:55 +-0000 (UTC):

> To other android users:
> Q: Do you see a process for "Firebase Cloud Messaging" services?

I think this mashable article got some things wrong.
"Nope, your Android phone's not secretly tracking your location when you
tell it not to"
<http://mashable.com/2017/11/21/google-android-location-tracking-services-turned-off/>

What Google said was:'
"To ensure messages and notifications are received quickly, modern Android
phones use a network sync system that requires the use of Mobile Country
Codes (MCC) and Mobile Network Codes (MNC). In January of this year, we
began looking into using Cell ID codes as an additional signal to further
improve the speed and performance of message delivery. However, we never
incorporated Cell ID into our network sync system, so that data was
immediately discarded, and we updated it to no longer request Cell ID. MCC
and MNC provide necessary network information for message and notification
delivery and are distinctly separate from Location Services, which provide
a device+IBk-s location to apps."

I think the part Mashable got wrong was this sentence:
"But because Cell ID codes weren't fully integrated, and therefore were
immediately discarded after each request, there's simply no way for this
triangulation to ever occur."

IMHO, the mere fact that the unique cell ID was *transmitted* to Google
servers, is the breach of trust. I don't see "Firebase" on my phone.

Is Firebase on your Android phone?

[harry newton]

He who is Jeff Liebermann said on Tue, 21 Nov 2017 19:26:10 -0800:

> It's not an app. It's service:
> <https://firebase.google.com/docs/cloud-messaging/>
> <https://firebase.google.com/products/cloud-messaging/>
> You download the API and link it into your application. It runs on a
> variety of platforms including Apple IOS.
>
> More:
> <https://www.google.com/search?q=Firebase+Cloud+Messaging>

It's still early on since the news came out today, but it behooves us to
figure out then which apps incorporated the Firebase service.

BTW, I think this recent "mashable" article is dead wrong in that they
minimize the outrage by saying the unique cell tower ID was encrypted and
discarded.

"Nope, your Android phone's not secretly tracking your location when you
tell it not to"
<http://mashable.com/2017/11/21/google-android-location-tracking-services-turned-off/>

The mere fact the cell tower ID was *transmitted* to Google servers is the
breach of trust, IMHO.

[rickman]

harry newton wrote on 11/21/2017 6:48 PM:
> He who is nospam said on Tue, 21 Nov 2017 17:55:51 -0500:
>
>> you were *so* sure you had blocked google's ability to track you, going
>> to such extreme lengths as changing your google id every few weeks.
>>
>> many people told you that you were still being tracked, but you blindly
>> dismissed it.
>>
>> now you know.
>
> You would love that to be the case, but, you're jumping to conclusions out
> of confirmation bias (i.e., you *wish* it were true).
>
> I looked and I don't think it's the case for me since I don't see (yet)
> anything called "Firebase Cloud Messaging" on my Android 4.3 phone.
>
> Time will tell which phones were affected, but this is a good one for
> Google to get sued on, as it certainly will take some 'splaining why they
> captured unique cell tower IDs when Location Services were disabled.
>
> All we know, so far, is that it started in January of this year, and that
> it used "Firebase Cloud Messaging" services - whatever that is. I googled
> it, and I don't think it's even on my phone - but it's too early to tell
> just yet what's going on.
>
> Google apparently immediately said they'd terminate the practice of
> capturing cell tower unique IDs - so, it doesn't appear to be something
> they sanctioned (because they wouldn't likely have agreed to terminate the
> practice so quickly if they had their legal ducks already lined up).

You would love for that to be the case, but you're jumping to conclusions

out of confirmation bias (i.e., you *wish* it were true).

There are the legal issues involved, but just as important if not more
important is the public image perception.

--

Rick C

Viewed the eclipse at Wintercrest Farms,
on the centerline of totality since 1998

[harry newton]

He who is rickman said on Tue, 21 Nov 2017 23:53:06 -0500:

> You would love for that to be the case, but you're jumping to conclusions
> out of confirmation bias (i.e., you *wish* it were true).

I'm the one *reporting* the issue here, not you, for heaven's sake.
I'm the one intimating Google can get *sued* for this, perhaps.
I'm the one asking for more information, for heaven's sake.
I'm the one who said Mashable errantly minimized the danger.

Not you. Not nospam.
Me.

All I'm saying are facts.
All you've said, is nothing of value.

I'm asking others to look on their phones for these reputed "Firebase Cloud
Messaging" services.

My phone is jailbroken where I can delete anything I want, where I *looked*
for anything on the phone remotely resembling a "Firebase Cloud Messaging"
service. I have plenty of root-only apps which seek out such things, but I
haven't seen it yet.

Admittedly, my phone is ancient, where the articles specifically mentioned
only the newer Android phones were updated in January of this year to send
the unique cell tower ID to Google servers.

So I'm the one asking *you* (and everyone here) what *they* have on their
phone that resembles "Firebase Cloud Messaging" services running.

Where's the value YOU added?

[rickman]

harry newton wrote on 11/22/2017 12:05 AM:
> He who is rickman said on Tue, 21 Nov 2017 23:53:06 -0500:
>
>> You would love for that to be the case, but you're jumping to conclusions
>> out of confirmation bias (i.e., you *wish* it were true).
>
> I'm the one *reporting* the issue here, not you, for heaven's sake.
> I'm the one intimating Google can get *sued* for this, perhaps.
> I'm the one asking for more information, for heaven's sake.
> I'm the one who said Mashable errantly minimized the danger.
>
> Not you. Not nospam. Me.
>
> All I'm saying are facts.

And speculation... "it doesn't appear to be something

they sanctioned (because they wouldn't likely have agreed to terminate the
practice so quickly if they had their legal ducks already lined up)."

> All you've said, is nothing of value.

I think there is value in distinguishing between the facts and your
speculation.

> So I'm the one asking *you* (and everyone here) what *they* have on their
> phone that resembles "Firebase Cloud Messaging" services running.

Which has nothing to do with reporting facts.

> Where's the value YOU added?

Pointing out your speculation which is *not* fact.

[harry newton]

He who is Jeff Liebermann said on Tue, 21 Nov 2017 19:26:10 -0800:

> It's not an app. It's service:

Do you know how to tell, definitively, if any given phone is running this
compromised service?

I don't see it running when I look using these instructions:
<https://www.howtogeek.com/258300/how-to-access-androids-list-of-running-apps-in-6.0-marshmallow-and-above/>

However, it could be running *inside* an app that linked to the API.

When I check it with adb, I get the following error:
$ adb shell service list
error: device not found

I can check with "ps" though:
$ ps | grep -i service
Returns about a dozen services such as:
org.simalliance.openmobileapi.service:remote
samsung.clipboardsaveservice
com.sec.android.inputmethod:ACService
etc.
But:
$ ps | grep -i firebase
Returns nothing

At this point, I see no evidence (yet anyway) of firebase services on my
Android 4.3 phone. Do you?

[harry newton]

He who is rickman said on Wed, 22 Nov 2017 00:32:39 -0500:

>> Where's the value YOU added?
>
> Pointing out your speculation which is *not* fact.

Fair enough.

Do you know how to tell, definitively, if any given phone is running this
compromised service?

I don't see it running when I look using these instructions:
<https://www.howtogeek.com/258300/how-to-access-androids-list-of-running-apps-in-6.0-marshmallow-and-above/>

However, it could be running *inside* an app that linked to the API.

When I check it with adb, I get the following error:
$ adb shell service list
error: device not found

I can check with "ps" though:
$ ps | grep -i service
Returns about a dozen services such as:
org.simalliance.openmobileapi.service:remote
samsung.clipboardsaveservice
com.sec.android.inputmethod:ACService
etc.
But:
$ ps | grep -i firebase
Returns nothing

At this point, I see no evidence (yet anyway) of firebase services on my
Android 4.3 phone. Do you see evidence of it running on yours?

[Jeff Liebermann]

On Wed, 22 Nov 2017 05:40:42 +0000 (UTC), harry newton
<ha...@is.invalid> wrote:

>At this point, I see no evidence (yet anyway) of firebase services on my
>Android 4.3 phone. Do you?

I dunno and don't have the time to check. Since it's probably buried
the application code, I doubt if I'll find anything.

However, all this begs another question. Assuming that Wi-Fi is also
turned off in Airplane mode, what the hell is Google doing
TRANSMITTING anything? Unless its buffered, to use the phone for
location tracking would require transmitting the tower ID's when they
are heard. I would think that the airline companies would take a dim
view of this as Google's transmitting anything in an commercial
airliner in flight could interfere with aircraft navigation, which is
the purpose of having the Airplane mode. If some airliner falls out
of the sky due to a navigation error, Google's tracking trickery could
easily be deemed responsible.

Incidentally, there's quite a bit more information available that
could be used for location tracking than just the tower ID. The big
one is the propagation delay (ping time) between the handset and the
cell tower, which defines a location radius. Two or three such delays
would obtain your location quite accurately. However, Google could
just as easily transmit the GPS location or the individual satellite
delays in order to obtain a location. It's odd that they would
transmit only the tower ID's, as there so much more available.

I should probably fire up the spectrum analyzer, turn off the wi-fi,
and see if my Samsung S6 is belching anything in Airplane mode.
However, tomorrow is the Day of the Turkeys and I have other plans.

Happy Day of the Turkeys.

[harry newton]

He who is Jeff Liebermann said on Wed, 22 Nov 2017 09:32:54 -0800:

> I dunno and don't have the time to check. Since it's probably buried
> the application code, I doubt if I'll find anything.

That's understandable.
It was reported only yesterday, so, the pundits need to dig deeper for us.

> However, all this begs another question. Assuming that Wi-Fi is also
> turned off in Airplane mode, what the hell is Google doing
> TRANSMITTING anything? Unless its buffered, to use the phone for
> location tracking would require transmitting the tower ID's when they
> are heard.

The code, as I understand it, only activates when you're connected to the
Internet (via either cellular data or WiFi). Nothing else is required.
* no sim card
* factory defaults (i.e., no apps)
* location services turned off
<https://qz.com/1131515/google-collects-android-users-locations-even-when-location-services-are-disabled/>

"Devices with a cellular data or WiFi connection appear to send the data to
Google each time they come within range of a new cell tower."

Slate.com also said the information is sent the moment two things happen:
1. You're on the Internet (using WiFi or cellular data)
2. And you're "in range" of a cellular tower
<http://www.slate.com/articles/technology/technology/2017/11/how_to_stop_phone_from_tracking_location_android_latest_to_prove_you_should.html>

> I would think that the airline companies would take a dim
> view of this as Google's transmitting anything in an commercial
> airliner in flight could interfere with aircraft navigation, which is
> the purpose of having the Airplane mode. If some airliner falls out
> of the sky due to a navigation error, Google's tracking trickery could
> easily be deemed responsible.

I think the transmission only occurs if two things are simultaneous:
1. You're in range of a cell tower, and,
2. You're already on the Internet

If the SIM card is out of the phone, then the only way you'll be on the
Internet is with WiFi (or maybe also reverse tethering, I suppose).

> Incidentally, there's quite a bit more information available that
> could be used for location tracking than just the tower ID. The big
> one is the propagation delay (ping time) between the handset and the
> cell tower, which defines a location radius.

This is very interesting, as you always know the details that are juicy.

Where we both live, towers aren't necessarily close, but if, say, for
example, I'm staking out those pot farmers in Boulder Creek who were
arrested for shooting at suspected pot thieves during that fire a couple of
weeks ago, then I don't want ANY information about my proximity to ANY cell
tower to be transmitted.

Here's what Google was quoted as having said in the QZ.com article:
"In January of this year, we began ... using Cell ID codes as an additional

signal to further improve the speed and performance of message delivery"

> Two or three such delays
> would obtain your location quite accurately.

This is good information to know.
Well, actually, it's bad information to know.
But you know what I mean.

> However, Google could
> just as easily transmit the GPS location or the individual satellite
> delays in order to obtain a location. It's odd that they would
> transmit only the tower ID's, as there so much more available.

They *are* getting *more* than the unique cell tower id.
1. MCC
2. MNC
3. CID

Google provided this quote to Gizmodo:

"To ensure messages and notifications are received quickly, modern
Android phones use a network sync system that requires the use of Mobile
Country Codes (MCC) and Mobile Network Codes (MNC). In January of this

year, we began ... using Cell ID codes as an additional signal to further
improve the speed and performance of message delivery. ... MCC and MNC

provide necessary network information for message and notification delivery

and are distinctly separate from Location Services..."
<https://gizmodo.com/your-android-phone-has-been-sending-location-data-to-go-1820639889>

> I should probably fire up the spectrum analyzer, turn off the wi-fi,
> and see if my Samsung S6 is belching anything in Airplane mode.

I think airplane mode might still be working - except on some iOS devices
with the older OS's (which some of mine are on).

[Char Jackson]

On Wed, 22 Nov 2017 09:32:54 -0800, Jeff Liebermann <je...@cruzio.com>
wrote:

>However, all this begs another question. Assuming that Wi-Fi is also
>turned off in Airplane mode, what the hell is Google doing
>TRANSMITTING anything? Unless its buffered,

That seems likely, along with timestamps on everything to facilitate
correlation.

>to use the phone for
>location tracking would require transmitting the tower ID's when they
>are heard. I would think that the airline companies would take a dim
>view of this as Google's transmitting anything in an commercial
>airliner in flight could interfere with aircraft navigation, which is
>the purpose of having the Airplane mode. If some airliner falls out
>of the sky due to a navigation error, Google's tracking trickery could
>easily be deemed responsible.

Ever since most airlines have started allowing personal wireless devices
to remain on throughout commercial flights*, it's probably no longer a
big deal.

*Supposedly, not during take-off and landing, while the aircraft is
below 10,000 feet, but I travel very frequently for work and I can't
remember the last time I noticed anyone complying with that request.

As far as I know, there's no evidence to suggest that personal wireless
devices actually interfere with aircraft navigation or operation. The
whole thing, from the start, was done out of an abundance of caution,
not as a result of any specific test results.

[Jeff Liebermann]

On Wed, 22 Nov 2017 09:32:54 -0800, Jeff Liebermann <je...@cruzio.com>
wrote:

>However, all this begs another question. Assuming that Wi-Fi is also
>turned off in Airplane mode, what the hell is Google doing
>TRANSMITTING anything?

I've been working too hard and have screwed up. I somehow assumed
that it was Airplane Mode that was turned off, not Location Services.
They're quite different.

Just ignore me. Maybe a turkey overdose will help.

[Piet]

Jeff Liebermann wrote:
> However, all this begs another question. Assuming that Wi-Fi
> is also turned off in Airplane mode

All *transmitters* are turned off when you switch to Airplane
mode. But thereafter you can turn on Wifi and Bluetooth while
leaving Airplane mode on. But since the *receivers* aren't
turned off in Airplane mode, the phone can still receive the
tower ID's and store them.

> what the hell is Google doing TRANSMITTING anything? Unless
> its buffered, to use the phone for location tracking would
> require transmitting the tower ID's when they are heard.

Of course the data are buffered, to be transmitted as soon as
you have a wifi or mobile data connection.

-p

[amdx]

On 11/22/2017 5:43 PM, Jeff Liebermann wrote:
> On Wed, 22 Nov 2017 09:32:54 -0800, Jeff Liebermann <je...@cruzio.com>
> wrote:
>
>> However, all this begs another question. Assuming that Wi-Fi is also
>> turned off in Airplane mode, what the hell is Google doing
>> TRANSMITTING anything?
>
> I've been working too hard and have screwed up. I somehow assumed
> that it was Airplane Mode that was turned off, not Location Services.
> They're quite different.
>
> Just ignore me. Maybe a turkey overdose will help.
>

Here's a video showing all the travel the phone owner did, his voice
messages, many things. He shows how to stop it and if you want to stop
all of it.
> https://www.youtube.com/watch?v=4xgLhjTLn7Q

Interesting video,
Mikek

[Carlos E.R.]

On 2017-11-23 11:14, Piet wrote:
> Jeff Liebermann wrote:
>> However, all this begs another question. Assuming that Wi-Fi
>> is also turned off in Airplane mode
>
> All *transmitters* are turned off when you switch to Airplane
> mode. But thereafter you can turn on Wifi and Bluetooth while
> leaving Airplane mode on. But since the *receivers* aren't
> turned off in Airplane mode, the phone can still receive the
> tower ID's and store them.

To my knowledge, the receivers are also turned off. There is no purpose
to leaving them on and wasting battery.

--
Cheers, Carlos.