Path: ...!weretis.net!feeder9.news.weretis.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!nnrp.usenet.blueworldhosting.com!.POSTED!not-for-mail
From: Andrew <andrew@spam.net>
Newsgroups: comp.mobile.android
Subject: Re: Why do so many people confuse Google's Firebase (cloud API) with Google Services Google Firebase App Indexing (search results)?
Date: Mon, 24 Jun 2024 06:04:25 -0000 (UTC)
Organization: BWH Usenet Archive (https://usenet.blueworldhosting.com)
Message-ID: <v5b299$2bfl$1@nnrp.usenet.blueworldhosting.com>
References: <v5769t$25rv$1@nnrp.usenet.blueworldhosting.com> <ldpa96Ftm5tU1@mid.individual.net> <v58jpr$84b3$1@dont-email.me> <v58kgk$1bn0$1@nnrp.usenet.blueworldhosting.com> <ldqqknF5uj5U5@mid.individual.net> <v59moa$2882$1@nnrp.usenet.blueworldhosting.com> <ldrid2F9di9U2@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 24 Jun 2024 06:04:25 -0000 (UTC)
Injection-Info: nnrp.usenet.blueworldhosting.com;
	logging-data="77301"; mail-complaints-to="usenet@blueworldhosting.com"
Cancel-Lock: sha1:reqZg156KGxv9dX7bx0D4s6g+sQ= sha256:0renfUJN95ROBalPQ20/i3iyL7HWuMi3UqIBCX2ll9w=
	sha1:E8AahCYblqIgGwJTwuzrtJ4KUck= sha256:Zkc1ZnorMyBZMqj4D70ig2Si/FZe0kzfTXuM7VRe9Ho=
X-Newsreader: PiaoHong.Usenet.Client.Free:1.65
Bytes: 5813
Lines: 83

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)