Why do so many people (including myself, at first) confuse Google's
Firebase (cloud API) with Google Services Google Firebase App Indexing
(search results)?

Firebase (cloud related):
<https://firebase.google.com/firebase-and-gcp>
"Firebase and Google Cloud share three products: Cloud Firestore,
Cloud Functions, and Cloud Storage. These are the same products
that exist in Google Cloud, simply exposed for client-side
developers via Firebase. You can access the same data from the
server SDKs (Google Cloud) and the client SDKs (Firebase),
so your frontend and backend teams can work in concert."

Google Services Firebase App Indexing (search related):
<https://medium.com/android-news/firebase-app-indexing-for-personal-content-getting-personal-content-into-search-c52bfe45b3ac>
"A note about privacy: The personal content index only exists
on the user's device. None of the user's personal content is
uploaded to Google servers and it only remains on the device
while the app is installed. However, aggregated statistics
about apps' usage of App Indexing and other system health
information may be uploaded to Google servers."

Notice that the words "ON THE DEVICE" is supposed to make you feel
safer; however the caveat is that Google samples statistics frequently
(about once or twice a month in my experience) of this extremely detailed
private data (e.g., every map location you ever searched for and every
contact you've ever contacted and every app you've ever opened up, etc.)
means, as far as I can tell, it doesn't matter one bit if an application
has no Internet access... because Google does.

The main unanswered question is how to tell if any given app has
Google Services Firebase App Indexing incorporated into it, so that we know
to delete those apps, unless they're essential apps.

An example is I deleted Windy because it used Firebase App Indexing:
<https://i.postimg.cc/qR8zr72r/appindex01.jpg>

And I deleted googlequicksearch, Google TV, T-Mobile and YouTube because
they used Google Services Firebase App Indexing (replacing them with apps
that did not use Google Services Firebase App Indexing such as NewPipe).
<https://i.postimg.cc/Fs8GDLfX/firebase01.jpg>

The problem with Google Services Firebase App Indexing databases (which you
can only see if you enable Developer options) is they contain extremely
personal information about your activities, such as what you use GasBuddy
for (which is why I deleted Gas Buddy even as it's a useful app otherwise).
<https://i.postimg.cc/nhCCVxmB/mapsloctrack03.jpg>

In summary, almost nobody (least of all me) knows how to describe the
difference between Firebase (the cloud Firebase) and Firebase App Indexing
(the search Firebase) so this thread is asking for a better description.

In addition, while the extremely private information stored on your device
for Firebase App Indexing isn't directly uploaded to the Internet, Google
clearly says they will (and do) upload statistics which we have no idea
what they are (nor how frequently they're uploaded, nor to whom) - so
another question is what happens to that extremely private data that is
stored in the Firebase App Index on the cellphone (other than it's included
in search results, presumably those run on the phone's data itself).

I barely know what Firebase (cloud) and Firebase App Indexing (search) do;
but it's really sad if I know it better than anyone else - hence - I'm
asking everyone else to pitch in so that we can tell, at a glance, which
apps use Firebase App Indexing so that we can avoid them, on sight.

Andrew, 2024-06-22 20:48:

> Why do so many people (including myself, at first) confuse Google's
> Firebase (cloud API) with Google Services Google Firebase App Indexing
> (search results)?
>
> Firebase (cloud related):
> <https://firebase.google.com/firebase-and-gcp>
> "Firebase and Google Cloud share three products: Cloud Firestore,
> Cloud Functions, and Cloud Storage. These are the same products
> that exist in Google Cloud, simply exposed for client-side
> developers via Firebase. You can access the same data from the
> server SDKs (Google Cloud) and the client SDKs (Firebase),
> so your frontend and backend teams can work in concert."

Firebase App Indexing was part of Firebase and not a separate product:

<https://firebase.google.com/docs/app-indexing?hl=en>

Also note, quote:

"Firebase App Indexing is no longer the recommended way of indexing
content for display as suggested results in Google Search App. This page
points to other useful Google developer products."

[...]
> In addition, while the extremely private information stored on your device
> for Firebase App Indexing isn't directly uploaded to the Internet, Google
> clearly says they will (and do) upload statistics which we have no idea
> what they are (nor how frequently they're uploaded, nor to whom) - so
> another question is what happens to that extremely private data that is
> stored in the Firebase App Index on the cellphone (other than it's included
> in search results, presumably those run on the phone's data itself).

If you don't trust Google, don't use their products!

> I barely know what Firebase (cloud) and Firebase App Indexing (search) do;
> but it's really sad if I know it better than anyone else - hence - I'm
> asking everyone else to pitch in so that we can tell, at a glance, which
> apps use Firebase App Indexing so that we can avoid them, on sight.

Firebase in general is a framework by Google to build apps which use
additional services for authentication, communication and storage:

<https://firebase.google.com/docs/projects/learn-more?hl=en>

For developers this makes a lot a things easier, since you can use the
Firebase infrastructure instead of implementing
client-server-communication etc. on your own.

But again: if you don't trust Google, don't use their products!

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote on Sun, 23 Jun 2024 02:58:16 +0200 :

> Andrew, 2024-06-22 20:48:
>
>> Why do so many people (including myself, at first) confuse Google's
>> Firebase (cloud API) with Google Services Google Firebase App Indexing
>> (search results)?
>>
>> Firebase (cloud related):
>> <https://firebase.google.com/firebase-and-gcp>
>> "Firebase and Google Cloud share three products: Cloud Firestore,
>> Cloud Functions, and Cloud Storage. These are the same products
>> that exist in Google Cloud, simply exposed for client-side
>> developers via Firebase. You can access the same data from the
>> server SDKs (Google Cloud) and the client SDKs (Firebase),
>> so your frontend and backend teams can work in concert."
>
> Firebase App Indexing was part of Firebase and not a separate product:
> <https://firebase.google.com/docs/app-indexing?hl=en>

The question I asked is a very difficult question to answer.

Hence... thank you for hazarding an answer as when there is confusion, none
of us can communicate on the same level until we're all at a similar level
of knowledge, which, for Firebase, will almost never be able to happen
here.

Even so, it's good information that the probable reason for the Firebase
terminology being used by Google marketing to refer to what appears to be
two completely different capabilities, may very well be that they were, at
one point in time, part of the same suite of tools in the past.

This apparently uncomfortable truth is one reason I said that anyone (me
included) who discusses "Firebase" without pinning down *which* Firebase
they're discussing, will just end up confusing everyone, me included.

> Also note, quote:
> "Firebase App Indexing is no longer the recommended way of indexing
> content for display as suggested results in Google Search App. This page
> points to other useful Google developer products."

I was aware that the Firebase App Indexing (search) feature was deprecated,
but my own Samsung Galaxy A32-5G phone shows it's definitely in use today.

Even so, it's good to know that "Android App Links are the recommended way
of linking users directly from search results, websites and other apps to
specific content within your app"
<https://developer.android.com/training/app-links>

>> In addition, while the extremely private information stored on your device
>> for Firebase App Indexing isn't directly uploaded to the Internet, Google
>> clearly says they will (and do) upload statistics which we have no idea
>> what they are (nor how frequently they're uploaded, nor to whom) - so
>> another question is what happens to that extremely private data that is
>> stored in the Firebase App Index on the cellphone (other than it's included
>> in search results, presumably those run on the phone's data itself).
>
> If you don't trust Google, don't use their products!

That's terrible advice. For a whole bunch of reasons. Don't get me wrong
though, as I know what you're saying (i.e., you're saying Google is evil).

However, one reason it's terrible advice is we're just trying to UNDERSTAND
what's going on; and to say don't use any product if you want to understand
how it works, is just about the worst advice possible, IMHO.

However, another more pragmatic reason that's terrible advice is there are
only two practical choices for cellphones: Android & iOS.

Given we're not an iOS group (for different reasons), we are all using
Android. Now, you could be talking about rooting & using AOSP... but...

Given my Samsung Galaxy A32-5G baseband is unrootable, I'm forced to use
some version of Android so I'm stuck using Google products de jure.

Even so, I do delete most Google packages, but I keep Google Maps and
Google Play Services for reasons that are related to functionality; & both
of those are still making full use of the Firebase App Indexing (AFAIK).

Anyway, the point is saying if you want to understand a Google product,
don't use it - is terrible advice - which we can forget & move forward.
>> I barely know what Firebase (cloud) and Firebase App Indexing (search) do;
>> but it's really sad if I know it better than anyone else - hence - I'm
>> asking everyone else to pitch in so that we can tell, at a glance, which
>> apps use Firebase App Indexing so that we can avoid them, on sight.
>
> Firebase in general is a framework by Google to build apps which use
> additional services for authentication, communication and storage:
> <https://firebase.google.com/docs/projects/learn-more?hl=en>
>
> For developers this makes a lot a things easier, since you can use the
> Firebase infrastructure instead of implementing
> client-server-communication etc. on your own.

Thank you for repeating what Google claims Firebase is, where I suspect the
utter vagaries in that description are intentional by Google so that they
can shove anything they want into Firebase - but then I have to wonder how
does Firebase differ from GSF (Google Services Framework) and how does
Firebase differ from GMS (Google Mobile Services) which, again, many
developers link into their apps.

Notice all three packages can be described under the exact words that are
used above for Firebase - which tells me those words are effectively
meaningless in that they say nothing of any technical value to us.

> But again: if you don't trust Google, don't use their products!

Please stop saying that if you want to understand how a product works, the
only way is to not use that product. It's a nonsensical meaningless
platitude that holds not only no value - but which implies that you feel it
is impossible to understand how any Google product actually works.

While it's clear that few here understand what Firebase is (least of all
me), it's only slightly more clear how GSM and GSF differ, I think.
*What is the difference between Google Service Framework(GSF)*
*And Google Mobile Service(GMS)?*
<https://stackoverflow.com/questions/37337448/what-is-the-difference-between-google-service-frameworkgsfgoogle-mobile-servi>

What's missing of course, is the answer to how these differ:
a. Firebase (I can't find a package with that name on my Android)
b. GSF (Google Services Framework) <com.google.android.gsf>
c. GMS (Google Mobile Services) <com.google.android.gms>

On 23/06/2024 01:58, Arno Welzel wrote:

> But again: if you don't trust Google, don't use their products!

If you want a cellphone which doesn't watch you there's really only
PinePhone OS available, and that's hardly a system everybody can use.
Anything else, and Google (or Apple), the phone manufacturer, and the
cellphone operator will be recording what you are doing with the phone
and where you are while you're doing it. Sure, a rooted phone will cut
down what Google can do, but you can't guarantee it has stopped
everything. If you /think/ you've turned it off or
uninstalled/deactivated it (whatever "it" is!) how do you know?

Basically, if you use a cellphone, assume someone, somewhere, is
watching and recording.

--
Jeff

Jeff Layman wrote on Sun, 23 Jun 2024 08:44:59 +0100 :

> Basically, if you use a cellphone, assume someone, somewhere, is
> watching and recording.

I think the advice of "if you don't trust Google, don't use them" is bad in
the same way as people tell immigrants who complain about racism "if you
don't like living in the USA, go back to where you came from".

Particularly when I'm simply trying to UNDERSTAND how it works.

So it's like saying, if you want to understand how it works, then don't use
Google", which is a nonsensical statement that holds negative value here.

Having said that....

I am aware of _why_ he said that, which is that another person who shall
remain unnamed, just drove him nuts with all his "worries" about Google.

I wasn't that person.
I'm not "worried" about Google (per se).

I'm just trying to understand how the phone works.

Specifically, for this thread, I suspect NOBODY knows how these three
things can be defined in a way that makes sense to any of us ... yet.

1. GSF (Google Services Framework) <com.google.android.gsf>
2. GMS (Google Mobile Services) <com.google.android.gms>
3. Google Firebase & Google Services Firebase App Indexing

Note that the definition given for "Firebase" would apply to all three.
That's the problem with generic descriptions.

We are on an Android newsgroup. It's a technical newsgroup.
We should be able to figure out how those three things differ.

Andrew, 2024-06-23 09:18:

> Arno Welzel wrote on Sun, 23 Jun 2024 02:58:16 +0200 :
>
>> Andrew, 2024-06-22 20:48:
>>
>>> Why do so many people (including myself, at first) confuse Google's
>>> Firebase (cloud API) with Google Services Google Firebase App Indexing
>>> (search results)?
>>>
>>> Firebase (cloud related):
>>> <https://firebase.google.com/firebase-and-gcp>
>>> "Firebase and Google Cloud share three products: Cloud Firestore,
>>> Cloud Functions, and Cloud Storage. These are the same products
>>> that exist in Google Cloud, simply exposed for client-side
>>> developers via Firebase. You can access the same data from the
>>> server SDKs (Google Cloud) and the client SDKs (Firebase),
>>> so your frontend and backend teams can work in concert."
>>
>> Firebase App Indexing was part of Firebase and not a separate product:
>> <https://firebase.google.com/docs/app-indexing?hl=en>
>
> The question I asked is a very difficult question to answer.

No, it's quite simple:

"Firebase" is a mostly cloud based platform with a number of services
provided by Google: messaging, storage, usage analytics, indexing and so on.

"Firebase App Indexing" is one single feature of that and not a separate
product.

[...]
>> If you don't trust Google, don't use their products!
>
> That's terrible advice. For a whole bunch of reasons. Don't get me wrong
> though, as I know what you're saying (i.e., you're saying Google is evil).
>
> However, one reason it's terrible advice is we're just trying to UNDERSTAND
> what's going on; and to say don't use any product if you want to understand
> how it works, is just about the worst advice possible, IMHO.
>
> However, another more pragmatic reason that's terrible advice is there are
> only two practical choices for cellphones: Android & iOS.

No, there are also "dumb" phones out there which don't use any "smart"
operating system at all or are at least very limited:

<https://www.thelightphone.com/>

And there is the Librem 5 which does not use Android or iOS either but
its own "PureOS":

<https://puri.sm/products/librem-5/>

And since Android is open source, there are also Android versions like
e/OS/ or devices by Murena *without* any Google services at all:

<https://e.foundation/e-os/>
<https://murena.com/products/smartphones/>

And LineageOS can also be used without any Google services at all:

<https://lineageos.org/>

And using F-Droid you can get many apps as well. Of course if you *must*
use a smartphone as a second authentication factor for your bank account
or similar applications, you may just get a cheap device which is only
used for that purpose and nothing else.

> Given we're not an iOS group (for different reasons), we are all using
> Android. Now, you could be talking about rooting & using AOSP... but...

See above.

> Given my Samsung Galaxy A32-5G baseband is unrootable, I'm forced to use
> some version of Android so I'm stuck using Google products de jure.

No, you can just buy a different device.

--
Arno Welzel
https://arnowelzel.de

Jeff Layman, 2024-06-23 09:44:

> On 23/06/2024 01:58, Arno Welzel wrote:
>
>> But again: if you don't trust Google, don't use their products!
>
> If you want a cellphone which doesn't watch you there's really only
> PinePhone OS available, and that's hardly a system everybody can use.

Or e/OS/ or Murena or Librem 5 and so on...

--
Arno Welzel
https://arnowelzel.de

Andrew, 2024-06-23 09:57:

> Jeff Layman wrote on Sun, 23 Jun 2024 08:44:59 +0100 :
>
>> Basically, if you use a cellphone, assume someone, somewhere, is
>> watching and recording.
>
> I think the advice of "if you don't trust Google, don't use them" is bad in
> the same way as people tell immigrants who complain about racism "if you
> don't like living in the USA, go back to where you came from".

No every comparison makes sense.

> Particularly when I'm simply trying to UNDERSTAND how it works.

Well - I tried to explain that. But it seems you believe "Firebase App
Indexing" is "bad" and "Firebase" is also "bad" and you just want to get
rid of it or at least avoid it. So the only logical answer is then not
to use such devices.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote on Sun, 23 Jun 2024 16:43:35 +0200 :

>> Particularly when I'm simply trying to UNDERSTAND how it works.
>
> Well - I tried to explain that. But it seems you believe "Firebase App
> Indexing" is "bad" and "Firebase" is also "bad" and you just want to get
> rid of it or at least avoid it. So the only logical answer is then not
> to use such devices.

This is a purely emotional response...

I feel for you Arno, as I am aware that you are a developer yourself, with
a published app, and that you are trying to help us, who have never
published any app on the Google Play Store.

The best some of us have done (me included) is follow a tutorial on the net
to build and modify our own personal apps using Android Stuido (which I've
done for about a dozen apps which I wrote up long ago on this newsgroup).

But following a tutorial and making minor edits is different than
publisheing a bona fide app on the Google Play Store, which you've done.

So you deserve respect for your abilities (as I do mine, which are lesser).

I don't remember who suggested HeliBoard, but if it was you, then I
appreciate that suggestion, as I briefly compared it to OpenBoard and found
them to be roughly equivalent (I only tested briefly the top-level usage).

In that HeliBoard discussion, I was pained to see you forced to respond to
people who merely said that they were so afraid of Google that anything
HeliBoard did with respect to permissions was anathema - which I disagreed
with but you valiantly struggled to help that person, to your credit.

Since I read every discussion on this newsgroup since the dawn of time,
I've learned a lot about apps from suggestions, so I was very happy to see
you suggest PMX, for example, to look at permissions. As you're likely
aware, I tested PMX and only ran into one problem - but it is a good app.

I pretty much test *every* free app ever suggested on this newsgroup, mind
you, so I probably know more about apps than most people here do. In
addition, I uninstall every package that I can uninstall (e.g., YouTube,
Google GMail, T-Mobile Diagnostics, etc.) and at the same time I do not
have any accounts on the device (not Google, not Samsung, not Amazon, and
certainly not from any app like a weather app or a pedometer app or a
photo-identification app, etc., that asks me to create a login to use it).

I practice privacy in ways that probably nobody here even understands, such
as using Developer options to randomize every AP connection MAC (which is
not the default, despite people thinking it is) and to hide the SSID
broadcast (which is for privacy, not security - despite people thinking it
is) and I don't put contacts into the default sqlite database (which I
doubt anyone here has any inkling how that improves the privacy of everyone
that I interact with), and I have one-tap shorcuts to all the Google
settings on Android that need to be reset every time I clear the cache
(which likely nobody but me knows all of them, they're so vast), etc.

My point is I feel for you when you were defending HeliBoard, where I am
not worried about HeliBoard's permissions (or those of OpenBoard), but I
would like to learn more about what Firebase App Indexing is doing on my
phone, because even as it has been deprecated by Google, even Google is
still using it (Android 13, Galaxy A32-5G) as are *many* other companies
(Windy, Google TV, YouTube, GasBuddy, etc.).

Unfortunately, developers are seduced by the Adam's apple that Google
offers them, which contains at least three serpents, as listed below.

1. GSF (Google Services Framework) <com.google.android.gsf>
2. GMS (Google Mobile Services) <com.google.android.gms>
3. Google Firebase & Google Services Firebase App Indexing

What would make this thread useful would be a good summary of the
difference be, where I take an amateurish stab at it below.

1. GSF => APIs for apps to link into Google Backup, Play Store Services,
Contacts Sync, and Account Management (plus location services
I think, which is why so many apps now require "precise location"
even though they have no need for it - because Google made the
option for location services w/o Wi-Fi removed from the API!)
2. GMS => APIs for Gmail, Chrome, Google+, Google Maps & Youtube.
3. Firebase => APIs for Cloud stuff + completely separate search stuff

--
*What is the difference between Google Service Framework(GSF)*
*And Google Mobile Service(GMS)?*
<https://stackoverflow.com/questions/37337448/what-is-the-difference-between-google-service-frameworkgsfgoogle-mobile-servi>

<https://firebase.google.com/firebase-and-gcp>

Firebase (cloud related):
<https://firebase.google.com/firebase-and-gcp>
"Firebase and Google Cloud share three products: Cloud Firestore,
Cloud Functions, and Cloud Storage. These are the same products
that exist in Google Cloud, simply exposed for client-side
developers via Firebase. You can access the same data from the
server SDKs (Google Cloud) and the client SDKs (Firebase),
so your frontend and backend teams can work in concert."

Google Services Firebase App Indexing (search related):

<https://medium.com/android-news/firebase-app-indexing-for-personal-content-getting-personal-content-into-search-c52bfe45b3ac>
"A note about privacy: The personal content index only exists
on the user's device. None of the user's personal content is
uploaded to Google servers and it only remains on the device
while the app is installed. However, aggregated statistics
about apps' usage of App Indexing and other system health
information may be uploaded to Google servers."

Notice that the words "ON THE DEVICE" is supposed to make you feel
safer; however the caveat is that Google samples statistics frequently
(about once or twice a month in my experience) of this extremely detailed
private data (e.g., every map location you ever searched for and every
contact you've ever contacted and every app you've ever opened up, etc.)
means, as far as I can tell, it doesn't matter one bit if an application
has no Internet access... because Google does.

The main unanswered question is how to tell if any given app has
Google Services Firebase App Indexing incorporated into it, so that we know
to delete those apps, unless they're essential apps.

An example is I deleted Windy because it used Firebase App Indexing:
<https://i.postimg.cc/qR8zr72r/appindex01.jpg>

And I deleted googlequicksearch, Google TV, T-Mobile and YouTube because
they used Google Services Firebase App Indexing (replacing them with apps
that did not use Google Services Firebase App Indexing such as NewPipe).
<https://i.postimg.cc/Fs8GDLfX/firebase01.jpg>

The problem with Google Services Firebase App Indexing databases (which you
can only see if you enable Developer options) is they contain extremely
personal information about your activities, such as what you use GasBuddy
for (which is why I deleted Gas Buddy even as it's a useful app otherwise).
<https://i.postimg.cc/nhCCVxmB/mapsloctrack03.jpg>

Arno Welzel wrote on Sun, 23 Jun 2024 16:41:10 +0200 :

>> The question I asked is a very difficult question to answer.
>
> No, it's quite simple:
>
> "Firebase" is a mostly cloud based platform with a number of services
> provided by Google: messaging, storage, usage analytics, indexing and so on.
>
> "Firebase App Indexing" is one single feature of that and not a separate
> product.

Thanks again for hazarding a guess as I know how rough Usenet is to people
who make guesses - rightly or wrongly so - where I'm only trying to nail
down what the difference is between what Google calls
a. Firebase App Indexing (on-device search data + uploaded statistics)
b. Firebase (where Firebase is only the back end to Google Cloud)

I realize you know a lot about Android but I'm also rather intelligent, so
I'm going to respectfully disagree with you when you suggested the "back
end" of the "front and back" end of the Firebase (cloud) APIs was "Firebase
App Indexing".

If your assumption is correct, then Firebase App Indexing (search) is just
the back end of the cloud - but that's not what it is as far as I can tell.

The back end of Google Cloud services is Google Firebase (cloud) APIs.
Not Google Firebase App Indexing (as far as I can tell anyway).

Hence, as far as I can tell (bearing in mind I've searched for years this
topic), is they're COMPLETELY SEPARATE APIs which Google gave the same name
to.

Hence, I believe it's not as simple as you made it to be, but I do not
fault you as I said.... this is a hard question to answer... mainly because
Google doesn't make it easy to figure out what the differences are.

> And using F-Droid you can get many apps as well. Of course if you *must*
> use a smartphone as a second authentication factor for your bank account
> or similar applications, you may just get a cheap device which is only
> used for that purpose and nothing else.

I look at privacy from every angle feasible, where 2FA/MFV is anathema.

Suffice to say I have years of experience with this, and still, to this
day, I never use 2FA/MFV, and I have many instances where I've worked with
developers (such as Marcel Bokhorst (M66B) for FairEmail) and with K9 Mail,
developers to get the Thunderbird-like OAUTH2 to be used instead of
2FA/MFV, which I consider yet another privacy hole.

We won that battle after about 3 months of Google forcing everyone who was
weak into 2FV/MFV, which, at least to Google's credit, they allowed people
to back out of (as Apple *never* allows you to back out of 2FV/MFV).

>> Given my Samsung Galaxy A32-5G baseband is unrootable, I'm forced to use
>> some version of Android so I'm stuck using Google products de jure.
>
> No, you can just buy a different device.

While I'm rather familiar with the concept of telling people if they don't
like living in the United States, they should just go back to where they
came from, that's an historic Germanic attitude that I don't harbor,
despite the fact I was born to a German-born father & mother in the USA.

I would rather simply try to understand the differences between these three
sets of API's from Google that developers can link into their apps.

1. GSF => APIs for apps to link into Google Backup, Play Store Services,
Contacts Sync, and Account Management (plus location services
I think, which is why so many apps now require "precise location"
even though they have no need for it - because Google made the
option for location services w/o Wi-Fi removed from the API!)
2. GMS => APIs for Gmail, Chrome, Google+, Google Maps & Youtube.
3. Firebase => APIs for Cloud stuff + completely separate search stuff

Andrew, 2024-06-23 19:41:

> Arno Welzel wrote on Sun, 23 Jun 2024 16:41:10 +0200 :
>
>>> The question I asked is a very difficult question to answer.
>>
>> No, it's quite simple:
>>
>> "Firebase" is a mostly cloud based platform with a number of services
>> provided by Google: messaging, storage, usage analytics, indexing and so on.
>>
>> "Firebase App Indexing" is one single feature of that and not a separate
>> product.
>
> Thanks again for hazarding a guess as I know how rough Usenet is to people
> who make guesses - rightly or wrongly so - where I'm only trying to nail
> down what the difference is between what Google calls
> a. Firebase App Indexing (on-device search data + uploaded statistics)
> b. Firebase (where Firebase is only the back end to Google Cloud)

What do you mean with "hazarding a guess"?

Just *read* the documentation instead of "guessing" things:

<https://firebase.google.com/?hl=en>
<https://firebase.google.com/docs/app-indexing?hl=en>

[...]
>>> Given my Samsung Galaxy A32-5G baseband is unrootable, I'm forced to use
>>> some version of Android so I'm stuck using Google products de jure.
>>
>> No, you can just buy a different device.
>
> While I'm rather familiar with the concept of telling people if they don't
> like living in the United States, they should just go back to where they
> came from, that's an historic Germanic attitude that I don't harbor,
> despite the fact I was born to a German-born father & mother in the USA.

Oh my... :-(

Did anyone forced you to purchase a Samsung Galaxy A32-5G and does not
allow you to get any other device ever?

> I would rather simply try to understand the differences between these three
> sets of API's from Google that developers can link into their apps.

Then learn how to develop apps, really.

> 1. GSF => APIs for apps to link into Google Backup, Play Store Services,
> Contacts Sync, and Account Management (plus location services
> I think, which is why so many apps now require "precise location"
> even though they have no need for it - because Google made the
> option for location services w/o Wi-Fi removed from the API!)

Correct - GSF, "Google Services Framework" gives apps access to Google
Play Services and some services

> 2. GMS => APIs for Gmail, Chrome, Google+, Google Maps & Youtube.

Correct - GMS, "Google Mobile Services" are mostly all the services
Google provides even without Android.

> 3. Firebase => APIs for Cloud stuff + completely separate search stuff

Correct - but "Firebase" also contains "Firebase App Indexing" and
"Firebase App Indexing" is *not* a separate product besides Firebase.

--
Arno Welzel
https://arnowelzel.de

Andrew, 2024-06-23 19:41:

[...]
> Unfortunately, developers are seduced by the Adam's apple that Google
> offers them, which contains at least three serpents, as listed below.
>
> 1. GSF (Google Services Framework) <com.google.android.gsf>
> 2. GMS (Google Mobile Services) <com.google.android.gms>
> 3. Google Firebase & Google Services Firebase App Indexing

No, developers are not "seduced". It's about software companies who need
to solve their problems and these problems are not just technical, but
also include things like:

- "how can we measure which feature in our apps is used most?"
- "how can we make sure, notifications to our users get delivered?"
- "how can we make sure, users don't loose all data when they change the
device and reinstall the app on another device?"

Of course you can re-invent the wheel everytime and try to come up with
your own solution to do application usage metrics or trying to convince
users to give you feedback (which usually does not work - BTDT). You can
also try to implement your own cool message sending system on your own
servers or invent another way of backing up data instead of using the
existing infrastructure in Android.

But in the end this leads to apps which are often insecure due to badly
implemented code or badly maintained servers which have outdated
certificates for HTTPS or bad privacy policies.

All the stolen account information in the last 5-10 years did usually
not come from Apple, Google or Microsoft but from servers maintained by
people who though they are bright enough to handle such business. Even
Adobe had it's hard time to learn that maintaining private user data is
not a simple task.

So it became more or less best practice not to try to invent the wheel
again but just use the services of the platform you develop software for.

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote on Sun, 23 Jun 2024 23:19:20 +0200 :
> What do you mean with "hazarding a guess"?
>
> Just *read* the documentation instead of "guessing" things:
>
> <https://firebase.google.com/?hl=en>
> <https://firebase.google.com/docs/app-indexing?hl=en>

The fact is you got it wrong. But I don't blame you for guessing.

I said from the start that almost nobody understands that Firebase (cloud)
has absolutely nothing whatsoever in common with Firebase App Indexing.

You included.
They're two completely different things using partially the same name.

Anyone who isn't aware of that, doesn't understand what either of them
does.
Which is the main reason why I authored this thread.

To clarify, once and for all, the difference between them.
To simplify that difference to make the point, this is the main difference
(as far as I'm aware).

1. Firebase (back end cloud APIs)
2. Firebase App Indexing (on-device search results + uploaded statistics)

My point always was that anyone who doesn't know that difference will only
confuse people by conflating them - because they're completely different.

The purpose of this thread is to find someone who knows the differences.

> Did anyone forced you to purchase a Samsung Galaxy A32-5G and does not
> allow you to get any other device ever?
>
>> I would rather simply try to understand the differences between these three
>> sets of API's from Google that developers can link into their apps.

As I said, I'm very well aware of the Germanic racism rampant in the United
States, having been born of Prussian-born parents in the USA, which tells
anyone trying to understand how Google works to go and find another country
to live in.

I'm not going to fall prey to racist comments so I said before and I will
say now that I will simply say that the answer to trying to understand what
Google Firebase (cloud) vs Google Services Firebase App Indexing (on-device
search & index uploads) are, is not to avoid Google at all costs.

It's just not.

> Then learn how to develop apps, really.

Again, the answer to the question of what the difference is between Google
Firebase (cloud) adn Google Services Firebase App Indexing (on-device
search & index uploads) is not to become a developer. It's just not.

The answer is likely far simpler, such as this short summary is:
a. Firebase (back-end APIs to Google's cloud)
b. Firebase App Indexing (on-device search results & uploads to Google)

>> 1. GSF => APIs for apps to link into Google Backup, Play Store Services,
>> Contacts Sync, and Account Management (plus location services
>> I think, which is why so many apps now require "precise location"
>> even though they have no need for it - because Google made the
>> option for location services w/o Wi-Fi removed from the API!)
>
> Correct - GSF, "Google Services Framework" gives apps access to Google
> Play Services and some services

The good news is that it's well known that any app that links with GSF is a
crappy app in terms of privacy such that the Aurora Store will allow you to
filter those apps out of search results.
<https://i.postimg.cc/P5YYKT3H/aurora14.jpg> Filter out apps linked to GSF

Note that the people who wrote the Aurora Store know they Google Play Store
repository better than anyone - & they implemented this GSF filter for us.

Simply stated: If you're installing apps with GSF in them, they're crap
(in terms of privacy).

>> 2. GMS => APIs for Gmail, Chrome, Google+, Google Maps & Youtube.
>
> Correct - GMS, "Google Mobile Services" are mostly all the services
> Google provides even without Android.

The main problem I have with GMS is that Google is desperate for us to
think that it's normal to require Wi-Fi precision scanning to do simply
geolocation when it's not. The reason is Google needs Wi-Fi precision
scanning for other reasons - and that's why Google recently made it such
that anyone linking in GMS must also force Wi-Fi precision scanning,
whether or not the app needs Wi-Fi at all, let alone precision scanning.

Given the danger inherent in apps eating the serpent's seductive GMS apple,
the authors of the Aurora Store have told me they're already in progress to
add a filter so that we can filter out any apps that link in GMS code.

Currently I do that with the Muntashirakon App Manager, but that's after
the app is already installed. The Aurora Store will allow us to filter out
any apps that have the privacy-invasive GMS linked in BEFORE we install
them.

Look to this newsgroup for reports once I test out the code they're working
on but I haven't received it yet - but mark my words - it's coming up.

>> 3. Firebase => APIs for Cloud stuff + completely separate search stuff
>
> Correct - but "Firebase" also contains "Firebase App Indexing" and
> "Firebase App Indexing" is *not* a separate product besides Firebase.

We're going to have to disagree on that statement, and the fact that not a
single link you've provided backs that up, is what I base that on.

Yes, I know you saw (and misinterpreted) the words "back end" to the Google
Cloud for "Firebase" but what you misunderstood was that Firebase is the
back end to Google Cloud.

Firebase App Indexing is NOT associated in the least with the Google Cloud.
If you insist that it is, simply show me a single cite that says that.

None exists. So I already know you can't.

Bear in mind, this is not your fault. As I said from the beginning, almost
nobody understands this stuff. It's a hard question to answer.

That you guessed wrongly is not a deprecation on you.
It's what most people do.

I'm here only for the correct answer.
And if your answer is correct, then you should be able to produce a cite
that explicitly says that "Google Services Firebase App Indexing" is a
component (deprecated or not) of the Google Firebase Cloud Services.

But it's not.
This is something almost nobody knows.

Arno Welzel wrote on Sun, 23 Jun 2024 23:29:06 +0200 :

> No, developers are not "seduced".
> It's about software companies who need
> to solve their problems and these problems are not just technical, but
> also include things like:
>
> - "how can we measure which feature in our apps is used most?"
> - "how can we make sure, notifications to our users get delivered?"
> - "how can we make sure, users don't loose all data when they change the
> device and reinstall the app on another device?"
>
> Of course you can re-invent the wheel everytime and try to come up with
> your own solution to do application usage metrics or trying to convince
> users to give you feedback (which usually does not work - BTDT). You can
> also try to implement your own cool message sending system on your own
> servers or invent another way of backing up data instead of using the
> existing infrastructure in Android.
>
> But in the end this leads to apps which are often insecure due to badly
> implemented code or badly maintained servers which have outdated
> certificates for HTTPS or bad privacy policies.
>
> All the stolen account information in the last 5-10 years did usually
> not come from Apple, Google or Microsoft but from servers maintained by
> people who though they are bright enough to handle such business. Even
> Adobe had it's hard time to learn that maintaining private user data is
> not a simple task.
>
> So it became more or less best practice not to try to invent the wheel
> again but just use the services of the platform you develop software for.

We can respectfully agree to disagree, as I have had multiple recent
communications on the XDA Developers site with the (current, de facto)
developers of the well-known and highly respected Aurora Store, who seem to
understand well enough why falling to the GSF (Google Services Framework)
seduction is so dangerous as to provide a *filter* against GSF APIs lazily
incorporated into apps.
<https://i.postimg.cc/RF06HBB3/aurora05.jpg> Filtering out GSF APIs

To over simplify it for the reader of this thread, any app which includes
the seductive Google GSF API's is poison in terms of privacy.

Hence, if you want an app that does NOT include the seductive Google GSF
API's, you will simply click that filter and you will never see them in
your search results.

In addition to all well-written apps shunning the incorporation of GSF
seductive APIs, you can note that all the open source apps of any merit
*refuse* to link in GSF (Google Services Framework), which simply is an
Adam's Apple of delicious APIs that make the developers' life easier.

As everyone here is well aware, I test these apps and I report back to the
developers the bugs I find, where I have recently (within the past month)
been told they're even going to implement a filter against GMS (Google
Mobile Services) inclusion into apps - so that we can avoid them on sight.

The point is that both GSF & GMS are likely tremendously dangerous to
privacy, and they're not even needed - where I don't disagree with you that
the least competent of app developers are seduced by Google dangling that
sweet serpents apple of seductive APIs in front of every developer's grasp.

Back to Firebase (cloud) and Firebase App Indexing (search), I think what
probably happened is that Firebase App Indexing came first and then it was
deprecated and then Google decided to re-use the fancy marketing name.

The end result is that anyone talking about Firebase who is unaware that
there are two completely different Firebase implementations, will just end
up confusing everyone who is aware that there are two different
implementations in wide use, one of which - while deprecated - is still in
wide use.

All I want from this thread is to flesh out what these four things are:
GSF, GMS, Firebase (cloud), Firebase App Indexing (search & index)

My position is anyone who doesn't understand what they are, probably has no
idea how to ascertain whether an app including them has any privacy or not.

To the end of understanding them, my simplified summary, so far, is this:

1. GSF (links to mostly Google spyware APIs)
2. GMS (links to mostly Google applications APIs)
3. Firebase (back-end links to mostly Google cloud APIs)
4. Firebase App Indexing (on-device search with statistics sent to Google)

Andrew wrote on Sat, 22 Jun 2024 18:48:30 -0000 (UTC) :

> Google Services Firebase App Indexing (search related):
> <https://medium.com/android-news/firebase-app-indexing-for-personal-content-getting-personal-content-into-search-c52bfe45b3ac>
> "A note about privacy: The personal content index only exists
> on the user's device. None of the user's personal content is
> uploaded to Google servers and it only remains on the device
> while the app is installed. However, aggregated statistics
> about apps' usage of App Indexing and other system health
> information may be uploaded to Google servers."

If I didn't say it directly, Google is *definitely* the recipient of the
Firebase App Index aggregated statistics which are uploaded periodically.

The simplest way I can summarize what that cite clearly states, is this:
a. Google isn't gathering the data (which is to be found in a local search)
b. The app is gathering the data (to be found in a local search)
c. But the app isn't uploading that data (which it stored on the device)
d. The app is just storing the data (making it available to the search)
e. Google says they only upload "aggregate statistics" about that data.
f. Not the data itself.

In summary, of three things, we only fully know two of them:
a. We know what data each app is storing in the firebase app indexing db
b. We know who is uploading that index (google) and to where (google)
c. But we do not know how much of that index google is uploading

Certainly the Google Services Firebase App Indexing contains extremely
detailed accounts of your activities, down to every contact you've
connected with and every app you've used and every location you've searched
for and which songs and movies you've viewed, etc.

But Google says they only upload to their servers an "aggregate index".
Whatever that is.

Does anyone know more about what this "aggregate index" actually contains?

Andrew <andrew@spam.net> wrote:
>
>
> Firebase App Indexing is NOT associated in the least with the Google Cloud.
> If you insist that it is, simply show me a single cite that says that.

Given that the only evidence you've provided to support that assertion is
an eight year old medium post, there's absolutely no certainty you're
correct. Your track record points to the opposite.

> None exists. So I already know you can't.
>
> Bear in mind, this is not your fault. As I said from the beginning, almost
> nobody understands this stuff.

Including you.

> It's a hard question to answer.

Especially when the question is invalid.

Everyone knows google changes their services continually and without
warning.
https://killedbygoogle.com/

It is very, very likely that the thing you claim was different eight years
ago is now the same thing or bundled into the product of the same name
available today.

Occam's razor would logically explain that two services with same name
provided by the same provider are in fact the same thing. That's a
reasonable starting point and the onus is on you to show otherwise with
up-to-date information.

Andrew, 2024-06-24 08:04:

> Arno Welzel wrote on Sun, 23 Jun 2024 23:19:20 +0200 :
>> What do you mean with "hazarding a guess"?
>>
>> Just *read* the documentation instead of "guessing" things:
>>
>> <https://firebase.google.com/?hl=en>
>> <https://firebase.google.com/docs/app-indexing?hl=en>
>
> The fact is you got it wrong. But I don't blame you for guessing.

I did not guess.

And also understand that "App Indexing" is also mentioned as example int
the *Firebase* samples collection:

<https://github.com/firebase/quickstart-android/blob/master/app-indexing/README.md>

However since Google does no longer recommend using "Firebase App
Indexing" the old code samples got removed. But you can still access
them thanks to Git and the possibility to access older versions of the code:

<https://github.com/firebase/quickstart-android/tree/12d0ace067a11319d47109c98cb08f82275eca25/app-indexing>

--
Arno Welzel
https://arnowelzel.de

Andrew, 2024-06-24 08:04:

[...]
> Back to Firebase (cloud) and Firebase App Indexing (search), I think what
> probably happened is that Firebase App Indexing came first and then it was
> deprecated and then Google decided to re-use the fancy marketing name.

No:

<https://github.com/firebase/quickstart-android/tree/12d0ace067a11319d47109c98cb08f82275eca25/app-indexing>

Quote:

Introduction

- Read more about Firebase App Indexing

Getting Started

- Add Firebase to your Android Project.
- Open the App Indexing project in Android Studio.
- Run the sample on your Android device or emulator by issuing
the following command using adb tool:
(...)

(End of quote)

It makes no sense to instruct anyone to "Add Firebase to your Android
Project" to be able to use "Firebase App Indexing" if those where
completely different products which did not have any connection with
each other at all.

--
Arno Welzel
https://arnowelzel.de

Chris wrote on Mon, 24 Jun 2024 07:18:17 -0000 (UTC) :

> Occam's razor would logically explain that two services with same name
> provided by the same provider are in fact the same thing. That's a
> reasonable starting point and the onus is on you to show otherwise with
> up-to-date information.

If you can't do even the simplest things on Android, Chris, stop lecturing
me by endlessly repeating you have no idea how to use an Android phone.

Here's a screenshot of Firebase App Indexing on my phone, Chris.
<https://i.postimg.cc/qR8zr72r/appindex01.jpg> All your Maps searches

Given your propensity to endlessly lecture by telling me you have no idea
how to use an Android phone, please show me a screenshot of the Google
Firebase App Indexing results on your Android phone, Chris.

That should take you all of ten seconds to do, right?
Maybe twenty seconds.

Let's see it.

Seriously. You have no business lecturing on Firebase App Indexing if you
can't do something that incredibly simple on an Android phone, Chris.

Arno Welzel wrote on Mon, 24 Jun 2024 10:10:31 +0200 :

>> The fact is you got it wrong. But I don't blame you for guessing.
>
> I did not guess.
>
> And also understand that "App Indexing" is also mentioned as example in
> the *Firebase* samples collection:
>
> <https://github.com/firebase/quickstart-android/blob/master/app-indexing/README.md>

Thanks for that link, for without cites, people are just guessing, and most
people wouldn't know Firebase App Indexing if it stared them in the face.

Hence, most people will always guess wrong.

As I said, almost nobody understands the difference, and that's why I said
it was a hard question to answer. Hence I appreciate that you found another
cite which backs up exactly what I have been saying all along (remember, I
am the one who knew from the start that there are two Firebase-named
products from Google, one of which is deprecated but still in use - neither
of which has any relation to the other).

Looking at that first cite, it says:
<https://github.com/firebase/quickstart-android/blob/master/app-indexing/README.md>
"Firebase App Indexing Quickstart
Firebase App Indexing is no longer the recommended way of indexing
content for display as suggested results in Google Search App.
Please check the App Indexing Documentation for more details."
<https://firebase.google.com/docs/app-indexing>

Both clearly say, rather obviously, absolutely NOTHING about the cloud.
It's all about on-device search results (as I have been saying all along).

Here is an example from my phone of what's in that Firebase app index.
<https://i.postimg.cc/QtfJ59LP/firebase02.jpg> Firebase indexed app data

Does your phone show similar Firebase App Indexing XML data?

> However since Google does no longer recommend using "Firebase App
> Indexing" the old code samples got removed. But you can still access
> them thanks to Git and the possibility to access older versions of the code:
> <https://github.com/firebase/quickstart-android/tree/12d0ace067a11319d47109c98cb08f82275eca25/app-indexing>

Again, I repeat. If this was so simple to answer, then even Chris would
know how to answer it - so I appreciate that you're trying to help out.

It's a difficult question to answer simply because there's not much about
it, but the fact it's deprecated is nearly meaningless as it's on your
phone right now - whether or not it's deprecated.

And, more to the point, it's uploading its index statistics to Google
servers, which is really the reason we need to understand this thing.

Looking at the link you kindly suggested I take a look at:
<https://github.com/firebase/quickstart-android/tree/12d0ace067a11319d47109c98cb08f82275eca25/app-indexing>

Again, I appreciate that you confirmed with cites that the entire GitHub
site you referenced says absolutely NOTHING about the cloud (as expected).
"The Firebase App Indexing Android quickstart demonstrates
how to get your app to be found in Google Search."

What's interesting in that second link is this adb command:
c:\> adb shell am start -a android.intent.action.VIEW -d "https://www.example.com/articles/test" com.google.samples.quickstart.appindexing

To make sure I was connected to adb, I ran this test first:
c:\> adb shell am start -n com.google.android.gms/.location.settings.LocationAccuracyActivity
Which successfully started that activity on my phone over adb, saying:
"Starting: Intent { cmp=com.google.android.gms/.location.settings.LocationAccuracyActivity }"

But when I ran the listed command, it failed:
c:\> adb shell am start -a android.intent.action.VIEW -d "https://www.example.com/articles/test" com.google.samples.quickstart.appindexing
Which reported:
"Starting: Intent { act=android.intent.action.VIEW
dat=https://www.example.com/...
pkg=com.google.samples.quickstart.appindexing }
Error: Activity not started, unable to resolve Intent { act=android.intent.action.VIEW dat=https://www.example.com/... flg=0x10000000 pkg=com.google.samples.quickstart.appindexing }"

To debug why it failed, I ran a search for a random package name:
C:\> adb shell pm list packages | findStr /i "osmand"
Which reported "package:net.osmand.plus" so I know that it's working.

Then I searched for the desired package in question:
C:\> adb shell pm list packages | findStr /i "appindexing"
C:\> adb shell pm list packages | findStr /i "quickstart"
C:\> adb shell pm list packages | findStr /i "com.google.samples"
etc.
Each and every one of which shows that this
com.google.samples.quickstart.appindexing package is not on my system.

Nonetheless, the point is that NOTHING in the description shows any
relationship whatsoever to the cloud, including this related link.
<https://stackoverflow.com/questions/tagged/android-app-indexing>
"App indexing allows us to enable Google to crawl through an android
app's content and present it to users through Google Search results."

In summary, I appreciate you found those links because it is my premise
that very few people understand what Firebase (cloud) is compared to what
Google Services Firebase App Indexing (search) is, where it matters mainly
because Firebase App Indexing is beyond your direct control - and yet -
Google clearly says they upload an index of statistics to Google servers.

That's why it is important to understand what it is, and what it does.

Arno Welzel wrote on Mon, 24 Jun 2024 10:14:59 +0200 :

> It makes no sense to instruct anyone to "Add Firebase to your Android
> Project" to be able to use "Firebase App Indexing" if those where
> completely different products which did not have any connection with
> each other at all.

I'm going to agree with you based on my own search using this keyword:
<https://www.google.com/search?q=com.google.samples.quickstart.appindexing>

The key links that arise from that search are the following of import:
<https://firebase.google.com/docs/samples>
<https://firebase.google.com/docs/android/learn-more>
<https://developers.google.com/search/apis/indexing-api/v3/quickstart>
<https://devlibrary.withgoogle.com/products/firebase/repos/firebase-quickstart-android>
<https://firebaseopensource.com/projects/firebase/quickstart-android/auth/readme/>
<https://stackoverflow.com/questions/41649828/android-firebase-app-indexing-app-not-showing-in-google-autocomplete-suggestio>
<https://developers.google.com/android/guides/setup>
<https://firebaseopensource.com/projects/firebase/quickstart-android/analytics/readme/>
<https://devlibrary.withgoogle.com/products/firebase/repos/firebase-quickstart-android/pages/app-indexing/readme>
<https://github.com/firebase/quickstart-android>

It looks perhaps like Google lumped a billion unrelated things into what
Google had decided to call "Firebase" and then Google, at some point,
deprecated the "Firebase App Indexing" component of Firebase (which never
had anything to do with the cloud).

So the real question is what "stuff" does Google no lump into Firebase?
The answer is NOT just the cloud, as they have advertising analytics also.

Andrew wrote on Mon, 24 Jun 2024 09:22:12 -0000 (UTC) :

> As I said, almost nobody understands the difference, and that's why I said
> it was a hard question to answer.

I think I finally found the answer, where I used a search term that came
out of one of your links, to finally figure out what Firebase truly is.

See this post.
<https://www.novabbs.com/computers/article-flat.php?id=53732&group=comp.mobile.android#53732>

Apparently, to Google, Firebase is a whole bunch of "stuff", only some of
which is related to "the cloud" where other stuff is related to "ad
analytics" and the like; but one of the things inside the "stuff" is the
"Firebase App Indexing" which is deprecated but which still exists on your
phone and on mine.

The proof is below:
<https://i.postimg.cc/nhCCVxmB/mapsloctrack03.jpg> Test Firebase tracks

Anyone responding saying it's deprecated should first look on their own
phone because, deprecated or not, it exists and it uploads an index to
Google servers periodically.

Andrew <andrew@spam.net> wrote:
> Chris wrote on Mon, 24 Jun 2024 07:18:17 -0000 (UTC) :
>
>> Occam's razor would logically explain that two services with same name
>> provided by the same provider are in fact the same thing. That's a
>> reasonable starting point and the onus is on you to show otherwise with
>> up-to-date information.
>
> If you can't do even the simplest things on Android, Chris, stop lecturing
> me by endlessly repeating you have no idea how to use an Android phone.

lol. You can't help yourself, can you? I made no comment about Android.

> Here's a screenshot of Firebase App Indexing on my phone, Chris.
> <https://i.postimg.cc/qR8zr72r/appindex01.jpg> All your Maps searches

I'm happy for you. It doesn't answer the challenge I gave you.

This will help: https://en.wikipedia.org/wiki/Firebase

Andrew <andrew@spam.net> wrote:
> Arno Welzel wrote on Mon, 24 Jun 2024 10:14:59 +0200 :
>
>> It makes no sense to instruct anyone to "Add Firebase to your Android
>> Project" to be able to use "Firebase App Indexing" if those where
>> completely different products which did not have any connection with
>> each other at all.
>
> I'm going to agree with you based on my

premise being ridiculous and illogical.

>
> It looks perhaps like Google lumped a billion unrelated things into what
> Google had decided to call "Firebase" and then Google, at some point,
> deprecated the "Firebase App Indexing" component of Firebase (which never
> had anything to do with the cloud).
>
> So the real question is what "stuff" does Google no lump into Firebase?
> The answer is NOT just the cloud, as they have advertising analytics also.

It's literally all on wikipedia.

Google had no role in naming Firebase, they simply bought an existing
product.

Arno Welzel wrote on Sun, 23 Jun 2024 16:41:41 +0200 :

>> If you want a cellphone which doesn't watch you there's really only
>> PinePhone OS available, and that's hardly a system everybody can use.
>
> Or e/OS/ or Murena or Librem 5 and so on...

Thank you for helping us answer the question of how Firebase App Indexing
fits into the overall agglomeration of stuff which Google calls "Firebase".

Thanks to your persistence, and to mine, we have a good answer.
<https://www.google.com/search?q=com.google.samples.quickstart.appindexing>

One of the hits of that specific search term found a list of "stuff"
samples showing (at least) 14 "things" Google considers part of Firebase.

1. A/B Testing (Google Services Firebase A/B Testing)
2. AdMob (Google Services Firebase AdMob)
3. Analytics (Google Services Firebase Analytics)
4. App Indexing (Google Services Firebase App Indexing)
5. Authentication (Google Services Firebase Authentication)
6. Cloud Firestore (Google Services Firebase Cloud Firestore)
7. Cloud Functions (Google Services Firebase Cloud Functions)
8. Cloud Messaging (Google Services Firebase Cloud Messaging)
9. Cloud Storage (Google Services Firebase Cloud Storage)
10. Crashlytics (Google Services Firebase Crashlytics)
11. Dynamic Links (Google Services Firebase Dynamic Links)
12. Performance Monitoring (Google Services Firebase Performance Monitoring)
13. Realtime Database (Google Services Firebase Realtime Database)
14. Remote Config (Google Services Firebase Remote Config)

While "Google Services Firebase App Indexing" is deprecated,
Firebase App Indexing is still very active on our Android phones,
where an UPDATE_INDEX is still, even today, being uploaded
periodically to Google servers based on what this cite explains.

Google Services Firebase App Indexing
<https://medium.com/android-news/firebase-app-indexing-for-personal-content-getting-personal-content-into-search-c52bfe45b3ac>
"A note about privacy: The personal content index
only exists on the user's device.
None of the user's personal content is uploaded
to Google servers and it only remains on the
device while the app is installed.
However, aggregated statistics about apps' usage
of App Indexing and other system health
information may be uploaded to Google servers."

You can see it for yourself on your own phone in front of you.
<https://i.postimg.cc/KvCkLccr/firebase03.jpg> Firebase tracking