R.Wieser, 2024-06-21 11:14:

> Arno,
>
>> I stand corrrected, yes, you're right. On current android versions, apps
>> don't have to ask for that permission, but you still need to add this in
>> the app manifest as developer, so people can check wether the app
>> uses network connections at all.
>
> Have you ever considered the possibility that all that has changed is the
> popping up of the confirmation dialog for those particular permissions ?
>
> IOW, if the permission request is NOT in the manifest its NOT given, but if
> it is there its given without confirmation.
>
> Hey, maybe you have knowledge and the tools to create a small testing app,
> test it and tell us the results ?

There are already many apps out there which can do this, for example:

<https://f-droid.org/de/packages/com.mirfatif.permissionmanagerx/>

And F-Droid also shows the permission of any app which you can download
there - and Heliboard does *not* have internet access:

<https://f-droid.org/de/packages/helium314.keyboard/>

--
Arno Welzel
https://arnowelzel.de

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

>> Hey, maybe you have knowledge and the tools to create a small testing app,
>> test it and tell us the results ?
>
> There are already many apps out there which can do this, for example:
>
> <https://f-droid.org/de/packages/com.mirfatif.permissionmanagerx/>

It's always good to obtain tool recommendations from folks who know a lot
about Android, where my Galaxy is unrootable but I do use ADB every day and
I use the Android Wireless Debugging tile all the time to allow ADB
authentication (either by pairing, which requires a password, or by direct
connection by USB or over Wi-Fi) - but others who may not be using ADB...
they will have to do some homework first.
c:\> adb connect 192.168.0.2:36295
c:\> adb pair 192.168.0.2:43145 016983

Even with all that knowledge, my initial connection over ADB failed; but it
may have been because I was also using screencopy mirroring at the time.
c:\> scrcpy -s 192.168.0.2

Nonetheless, here are the installation particulars that I ran just now.

https://f-droid.org/de/packages/com.mirfatif.permissionmanagerx/
https://f-droid.org/repo/com.mirfatif.permissionmanagerx_125.apk
Name: permission-manager_com.mirfatif.permissionmanagerx_125.apk
Size: 2847225 bytes (2780 KiB)
SHA256: 678FAC2556E610E080E058F1E1F362F0259C8BF314B7580282C678BFA750AF19

Privileges: Root or ADB access is required to get AppOp permissions and to
change permissions state. [Don't Remind] or [OK]

a. Enable Wireless Debugging (pairing) or ADB Over Network.
b. Enter port and tap connect button.
c. Allow ADB authentication when prompted.

https://mirfatif.github.io/PermissionManagerX/help/en/#faq1

Help: Why PMX requires root or ADB access?
Android won't allow a normal user app to change
other apps' manifest or AppOps permissions, even its
own. Only reading AppOps without root or ADB is
possible provided that hidden APIs are not
blacklisted on your device (which is very unlikely
on Android 9+).

That's why we run a separate process with high
privileges to circumvent the restrictions.

By default, the background process (daemon) is run
with ADB UID (2000) or (if rooted) System UID (1000).

On rooted devices, UID can be changed in PMX
Advanced Settings.

My device isn't rooted. How can I use PMX?
Use PMX with ADB.

However ADB is not as powerful as root is. PMX takes
more time to build the list of apps when its running
with ADB.

What are hidden APIs?
The core functionality of PMX revolves around
Hidden APIs. These are the capabilities required to
perform tasks (like granting or revoking permissions)
which can only be performed by privileged system apps.

So these capabilities aren't available to normal
user apps. But PMX uses these capabilities with the
help of root or ADB. Usually a user should not be
concerned about this.

Arno Welzel wrote on Sun, 23 Jun 2024 03:01:11 +0200 :

> It depends on the device. Newer devices have a "TPU" which can handle
> speech recognition offline. However older devices may not be as powerful
> to do this and always rely on a server.

When I looked up TPU, I thought it meant "text processing unit" but it
really means "tensor processing unit", apparently, which is confusing.
<https://medium.com/@champion_icterine_goldfish_62/how-googles-tpu-technology-may-improve-ai-capabilities-of-samsung-galaxy-s25-series-1a3c6274040f>

> Simple test: enable airplane mode to disable any kind of network
> connection and see, if speech recognition still works. In my case, on a
> Google Pixel 6a, this is the case - Google speech recognition even works
> without any active network connection at all.

Ah. <slaps head!> How stupid of me. That's a great idea.

That's a sensible idea, which I should have thought of, so thanks for being
kind in suggesting that I put the phone in airplane mode first.

1. For the Samsung Keyboard microphone, STT failed in airplane mode
saying "No network connection".

2. For the OpenBoard keyboard microphone, STT worked in airplane mode.

3. For the HeliBoard keyboard microphone, STT worked in airplane mode.

4. For the Google Voice Typing microphone, STT worked in airplane mode.

The good news is both HeliBoard and OpenBoard (which, as far as I can tell,
are equivalent in most ways) do not need the Internet in order to do STT.

Thanks for suggestion that quick test.

Andrew,

>> Oh yes, there seems to be a difference : the first being the back-end and
>> second the front-end. At least, if I maye take Googles own word for it :
>>
>> https://firebase.google.com/firebase-and-gcp
>
> Thank you for noticing that there's a difference between "Google Firebase"
> and "Google Services Firebase App Indexing",

:-) that was never the question.

The link there and the quote I posted seem to contradict your, rather
pertinent, claim that both of the above have zero to do with each other.

> While I will freely admit to not knowing what either one truly is, I don't
> think one is just the back end of the other - simply because the whole
> purpose of "Google Services Firebase App Indexing" is for the app to get
> its data in the users' search results ON THE PHONE (as far as I can tell),
> while the whole purpose of "Google Firebase" is for the app to link in
> access to Google's cloud.

You already mentioned that data gathered on your phone by that Firebase
framework gets send off too somewhere you don't know, but you still refuse
to consider the possibility that a same-named software "in the cloud", also
from Google, could be the recipient of it.

Yeah, you're definitily confusing me, and it has got nothing to do with our
difference in knowledge..

> As far as I can tell, those are two completely different endeavors.

Well, lets agree on disagreeing on that, shall we ?

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

Are you gullible or what ?

Ask yourself: if Google doesn't want to upload that "personal content" to
itself, than why are they gathering it in the first place ?

Its sounds like the defence of a common thief : "No, no, I just was putting
that stuff in my pockets, but I wasn't planning of taking it with me,
Constable. No, really." - and just as believable.

> Notice that means it doesn't matter one bit if an application has
> no Internet access... Because Google does.

Thats the second time you're claiming "because Google does", and the second
time you forgot to substanciate it with anything - even though I explicitily
asked for it. Do it a third time and I'll plonk you.

And I'll give you a bone: I can imagine that /some/ app will communicate,
over the internet, with people/companies unknown. But that "some app" still
needs to be given, by the user, access to the internet. Trying to make it
sound as if Google somehow (magically?) gets that access without the user
having any say in it doesn't fly.

By the way:

>The problem is that when everyone is talking about stuff they don't know
>much about (including me), then everything any one person says tends to
>confuse any other person - because they're not starting from the same
>knowledge level.

Ah yes, thats a nice vague claim with lots of escape room. :-)

I could mention that I've listened to people who definitily had a lot more
knowledge than me and experienced zero confusion, and that is than covered
by the "tends to" (the "just not now" part). And someone else can mention
that most all information they have been given confuses them, and thats
cover by it too.

IOW, you can use it over the full spectrum of a persons experience (with
being given, or even asked for, information) and its never wrong. And that
makes it absolutily meaningless.

Regards,
Rudy Wieser

Arno,

>>> An app *must* contain the permission request in the manifest,
>>> regardless if it actually uses it or not.
>>
>> I take that as "regardless if it *directly* uses it or not."
>
> There is no "direct use". Either an app does use an system API
> which requires a permission or not.

:-) I think we are talking about the same thing., though I think from
different vantage points. The "direct use" quip was about the difference of
only asking the permission when the app actualy uses it, versus asking for
all permissions at install time.

> "Late binding" is required for *all* permissions in newer Android
> versions. I am not sure when Google changed this, but as far I
> remember, Android 6 introduced that.

I decision I consider as being bad. For reason(s) I already mentioned.
I hope my phones OS doesn't follow it.

>> :-) You talk as if you are smart enough, but at the same time you seem
>> to blindly trust an apps honesty in obeying a setting it manages it
>> itself.
>> I don't.
>
> I don't either - but I can read and understand source code:

:-) I've worked my way thru enough sourcecode to know that a lot can go on
in there that I will never be able to fully grasp. Kudos to you that you
can.

> And yes, I also develop Android software myself:

I'm not at all surprised about it.

>> They *tell you* that they will /just/ take the contact names, and leave
>> everything else (you know, phone numbers, adresses, etc.) alone, and
>> you believe them ? Again, I don't.
>
> Who is "they"?

The apps infopage (wherever it is stored) ?

> Heliboard is not sold by a company but provided by a bunch of
> contributors (at the moment 26 - see
> <https://github.com/Helium314/HeliBoard/graphs/contributors>) who
> spend their free time to maintain a keyboard app you can use for free.
>
> So you believe all these guys work on that app to spy on you?

Is there any reason why I should believe that /all/ app makers - or in this
case all 26 contributors of it - are all fully above board ? On which
ground please ?

Also, *You* have the capability to inspect their sourcecode, and make your
decisions on that. I would call that distrust too. I'm not at your level
of expertise, so I'm not allowed to have the same distrust ?

And FWY, I was-and-am talking about apps in general. You keeping pushing a
specific app forward as proof that my distrust is unwarranted is therefore
meaningless to me.

And pardon me, but as someone who can inspect such apps (I take it you have
some kind of de-compiler at hand too) you must have encountered a number
which are rather ... iffy in what they try to do, and "not quite" matching
their info sheet.

FYI, I'm frequenting a website which regulary talks about how, often
high-ranked, android apps contain malware, purposely put there by the app
maker or because (s)he used a third-party library which cointained it.

> Then don't use the app or better don't use smartphones at all - and
> yes, I am really serious!

You sound as if I trust the OS I'm running I also *must* trust the apps that
can run on it. I sure hope I misinterpreted that.

>> Also, there is a reason why some phone OS-es offer you to provide
>> apps asking for such a permission a fake list.
>
> Which does not solve the issue, that you still have to trust the OS that
> it works as intended.

Indeed. The only difference is that if I (think I) can trust the OS than
it becomes a bottleneck for the apps that are up to no good, and thereby
neutralize those. So instead of having to worry about all the apps I would
want to put on my phone I only have to worry about one. I don't know
about you, but that sounds like quite an improvement.

> Yes - everything is possible! Even if an app has *no* permissions at
> all it still can be harmful since there may be a security bug in Android
> which a malicous app can exploit. And yes, I am really serious!

:-) The website mentioned talks about such stuff too. So yes, I'm aware
of that.

> No, I have no problem trusting an open source app I can check of myself.

:-) You're lying. You're not *trusting* it, you're *vetting* it. Just like
I try to do. But somehow /my/ vetting is problematic to you. Why ?

> No I don't expect anything except not being paranoid and trying
> to understand *why* I told you that about Heliboard.

Ask yourself how I could possibly *know* why you mentioned that app. You
might be fully above board, but you could as easly be someone who's trying
goading people into installing (trojaned) malware. (don't worry, I'm leaning
to the former).

And do ask yourself why I would trust someone I cannot touch if he violates
that trust ? Thats not trust, that is merely acknowedging that there is no
other choice.

But to be honest, Heliboard looks, permission wise, to be one of the better
ones. If-and-when I install it I likely won't give it that READ_CONTACTS
permission though.

Than again, I might just go for the other one in my (short) list, which only
asks access to the dictionary and vibrate.

Regards,
Rudy Wieser

Arno Welzel wrote:

> And F-Droid also shows the permission of any app which you can download
> there - and Heliboard doesnot have internet access:

confirmed by dumping the manifest from the apk

C:\Users\Andy\AppData\Local\Android\Sdk\build-tools\34.0.0\aapt2.exe
dump xmltree C:\Users\Andy\Downloads\helium314.keyboard_1004.apk --file
AndroidManifest.xml | find /i "android.permission"

A:
http://schemas.android.com/apk/res/android:name(0x01010003)="android.permission.READ_USER_DICTIONARY"
(Raw: "android.permission.READ_USER_DICTIONARY")

A:
http://schemas.android.com/apk/res/android:name(0x01010003)="android.permission.RECEIVE_BOOT_COMPLETED"
(Raw: "android.permission.RECEIVE_BOOT_COMPLETED")

A:
http://schemas.android.com/apk/res/android:name(0x01010003)="android.permission.VIBRATE"
(Raw: "android.permission.VIBRATE")

A:
http://schemas.android.com/apk/res/android:name(0x01010003)="android.permission.WRITE_USER_DICTIONARY"
(Raw: "android.permission.WRITE_USER_DICTIONARY")

A:
http://schemas.android.com/apk/res/android:name(0x01010003)="android.permission.READ_CONTACTS"
(Raw: "android.permission.READ_CONTACTS")

A:
http://schemas.android.com/apk/res/android:permission(0x01010006)="android.permission.BIND_INPUT_METHOD"
(Raw: "android.permission.BIND_INPUT_METHOD")

A:
http://schemas.android.com/apk/res/android:permission(0x01010006)="android.permission.BIND_TEXT_SERVICE"
(Raw: "android.permission.BIND_TEXT_SERVICE")

R.Wieser, 2024-06-23 10:21:

> Arno,
>
[...]
>> No I don't expect anything except not being paranoid and trying
>> to understand *why* I told you that about Heliboard.
>
> Ask yourself how I could possibly *know* why you mentioned that app. You
> might be fully above board, but you could as easly be someone who's trying
> goading people into installing (trojaned) malware. (don't worry, I'm leaning
> to the former).

I did not mention the app, that was "Henry The Mole"
<henrythemole@mckenziesfarm.old> in his post on June 17, 2024.

I just tried explained how I came to the conclusion that it does not
abuse private data and that it does not use Firebase either. I also
repeatetly suggested *not* to trust me blindly but to ask someone else
who is able to understand the source code of Heliboard and maybe even
compile your own version based on that code to be sure what you get!

--
Arno Welzel
https://arnowelzel.de

R.Wieser wrote on Sun, 23 Jun 2024 08:15:09 +0200 :

> You already mentioned that data gathered on your phone by that Firebase
> framework gets send off too somewhere you don't know, but you still refuse
> to consider the possibility that a same-named software "in the cloud", also
> from Google, could be the recipient of it.

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

I even quoted an article saying exactly that.

> Are you gullible or what ?
>
> Ask yourself: if Google doesn't want to upload that "personal content" to
> itself, than why are they gathering it in the first place ?

a. Google isn't gathering the data.
b. The app is gathering the data.
c. But the app isn't uploading that data.
d. The app is storing the data on your device.
e. Google says they only upload "statistics" about that data.
f. Not the data itself.

All that was extremely clearly said in the cites I already provided.

Arno Welzel wrote on Sun, 23 Jun 2024 03:01:57 +0200 :

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

The goal is to understand things. To that end, I am far less concerned with
Firebase Cloud Services than with Firebase App Indexing, which is explained
rather clearly below in this cite:

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

From that alone, it's clear 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 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?

Andy Burns wrote on Sun, 23 Jun 2024 09:25:51 +0100 :

>> And F-Droid also shows the permission of any app which you can download
>> there - and Heliboard doesnot have internet access:
>
> confirmed by dumping the manifest from the apk

Just as an aside to help others confirm permissions in any app, both PMX
and Muntashirakon App Manager will dump the permissions of any given app.

PMX: <https://i.postimg.cc/4yy10LVz/pmx01.jpg>
App Manager: <https://i.postimg.cc/nLXWPwH1/heliboard07.jpg>

Andrew wrote:

> PMX and Muntashirakon App Manager will dump the permissions of any given app.

Do their lists of dumped permissions correspond with f-droid's list or
the list from aapt2?

Arno,

> I did not mention the app, that was "Henry The Mole"
> <henrythemole@mckenziesfarm.old> in his post on June 17, 2024.

He was the first to suggest it. You shoved it forward several times after
him.

> I just tried explained how I came to the conclusion that it does not
> abuse private data

Thts pretty-much the problem : you're still talking about a(n specific) app,
while my focus was-and-is on the permission.

And although you are right that the absense of the INTERNET permission for
that app seems to indicate that exfiltration isn't possible*, I do not leave
my safe open because I've locked the front door.

*though at least one person here seems to think that Google can exfiltrate
without it.

But yes, looking at the apps manifest I do not recognise any way in which it
could. On the other hand, that doesn't mean much, as I'm a newbie in this
(why do you think I have been asking about it?), and I could easily miss
another permissions unwanted interaction.

The end result ? Especially with privacy related permission I don't allow
what I do not see any need for and can be done differently. Which, for this
case, I explained that several days back.

> I also repeatetly suggested *not* to trust me blindly but to ask someone
> else
> who is able to understand the source code of Heliboard

I do not have anyone in my neighbourhood who could, or even wanted to do
that. They just install the stuff and trust it into high-heaven.

> and maybe even compile your own version based on that code to be sure what
> you get!

:-) I seem to remember that, in relation to you making the same claim
earlier, I asked you if you also vetted the libraries that an app uses. I
did not hear anything back, so I take that as a "no". And as chances will
have it the website I mentioned before also posted articles about how app
builders sometimes build malicious apps - not because they intended to do
so, but simply because they used third-party libraries that contained the
malicious code.

Besides, I think also mentioned that I do not (yet?) have access to both the
knowledge needed for it, or the tools to do so.

Regards,
Rudy Wieser

Andrew,

>> You already mentioned that data gathered on your phone by that Firebase
>> framework gets send off too somewhere you don't know, but you still
>> refuse
>> to consider the possibility that a same-named software "in the cloud",
>> also
>> from Google, could be the recipient of it.
>
> If I didn't say it directly, Google is *definitely* the recipient of the
> Firebase App Index statistics which are uploaded periodically.

Its fantastic how you "answer" questions that have never been asked, and not
even touch the quote you put above it.

Do I need to quote you on where you said that the Firebase cloud hasn't got
*anything* to do with the Firebase on your phone (stated last friday), or do
you now think you remember having done so ?

Heck, even your new thread, "Why do so many people confuse Google's Firebase
(cloud API) with Google Services Google Firebase App Indexing (search
results)?" just SCREAMS about how still think you are right, but are now
asking (begging?) people to provide you with the proof/support for it.

>> Ask yourself: if Google doesn't want to upload that "personal content" to
>> itself, than why are they gathering it in the first place ?
>
> a. Google isn't gathering the data.
> b. The app is gathering the data.

Ah yes, lets put some semantics on the road.

Newsflash : trying to put up a smoke-screen like that doesn't make you look
good.

> c. But the app isn't uploading that data.

Ah yes, the famous "no it isn't" <full stop> response. No support for it
or even an explanation for it given.

Besides the problem that I didn't question over what (app ? Service ?
Something else ?) does the actual upload - even though you try to make it
sound I did.

> d. The app is storing the data on your device.

Do tell what "the app" is and where I claimed otherwise.

> e. Google says they only upload "statistics" about that data.

I have a bridge to sell you, and some prime building land too.

> f. Not the data itself.

And you would know that ... how ?

IOW, another claim that you did not wish to accompany with anything that
would substanciate it - which causes it not to have any meaning whatsoever.

Andrew, all you are doing now is to dig the pit into which you fell deeper.
As a result your believability score took a nosedive.

Maybe you where/are not aware, but I have a problem with people, like you,
who state stuff as if they are facts, but forget to support them with
anything.

Than again, I seem to remember I mentioned that at least once ...

Regards,
Rudy Wieser

Andy Burns, 2024-06-24 09:32:

> Andrew wrote:
>
>> PMX and Muntashirakon App Manager will dump the permissions of any given app.
>
> Do their lists of dumped permissions correspond with f-droid's list or
> the list from aapt2?

Yes - see for yourself:

<https://f-droid.org/en/packages/helium314.keyboard/>

Permissions

read your contacts
Allows the app to read data about your contacts stored on your
phone. Apps will also have access to the accounts on your phone that
have created contacts. This may include accounts created by apps you
have installed. This permission allows apps to save your contact data,
and malicious apps may share contact data without your knowledge.
android.permission.READ_USER_DICTIONARY
run at startup
Allows the app to have itself started as soon as the system has
finished booting. This can make it take longer to start the phone and
allow the app to slow down the overall phone by always running.
control vibration
Allows the app to control the vibrator.
android.permission.WRITE_USER_DICTIONARY
helium314.keyboard.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION

--
Arno Welzel
https://arnowelzel.de

Arno Welzel wrote:

> Andy Burns wrote:
>
>> Do their lists of dumped permissions correspond with f-droid's list or
>> the list from aapt2?
>
> Yes - see for yourself:
>
> <https://f-droid.org/en/packages/helium314.keyboard/>

I did look, which is why I asked ... the f-droid list is not identical
to the aapt2 list.

On Mon, 24 Jun 2024 06:34:49 -0000 (UTC), Andrew <andrew@spam.net> wrote:

>The goal is to understand things. To that end, I am far less concerned with
>Firebase Cloud Services than with Firebase App Indexing, which is explained
>rather clearly below in this cite:

>From that alone, it's clear 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 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?

Being the ludite that I am, I had never heard of Firebase, so I turned to
Wikipedia (https://en.wikipedia.org/wiki/Firebase). There I found this
among the weeds:

*****
User privacy controversies

Firebase has been claimed to be used by Google to track users without their
knowledge. On July 14, 2020, a lawsuit was filed accusing Google of
violating federal wire tap law and California privacy law. It stated that
through Firebase, Google collected and stored user data, logging what the
user was looking at in many types of apps, despite the user following
Google's own instructions to turn off the web and app activity collected by
the company.[17] The lawsuit was dismissed in January 2022, with Chief US
District Judge Richard Seeborg ruling that a promise to avoid collecting
user data did not amount to a contract.[18]

[17] "Google faces lawsuit over tracking in apps even when users opted
out". Reuters. July 14, 2020. Retrieved July 14, 2020.

[18] "US federal judge dismisses breach of contract claims in privacy
class action against Google". www.jurist.org. January 27, 2022. Retrieved
May 18, 2022.

*****

That seems like a very odd decision to me, but there's not really much
detail in that blurb. But it sure adds bulk to the general cloud (no pun
intended) of opinion that, "Google is evil". And I would be interested to
hear the judge's reasoning in that decision.

--
croy

Andy,

> I did look, which is why I asked ... the f-droid list is not identical to
> the aapt2 list.

It would have been nice if you would have mentioned the differences.

Is it possible those are BIND_INPUT_METHOD and BIND_TEXT_SERVICE ? As
those are not under "uses-permission", but under "service" -> "permission".

Regards,
Rudy Wieser

R.Wieser wrote:

> Andy Burns wrote:
>
>> I did look, which is why I asked ... the f-droid list is not identical to
>> the aapt2 list.
>
> It would have been nice if you would have mentioned the differences.

The aapt2 permissions

android.permission.READ_USER_DICTIONARY
android.permission.RECEIVE_BOOT_COMPLETED
android.permission.VIBRATE
android.permission.WRITE_USER_DICTIONARY
android.permission.READ_CONTACTS
android.permission.BIND_INPUT_METHOD
android.permission.BIND_TEXT_SERVICE

The f-droid permissions

android.permission.READ_USER_DICTIONARY
run at startup (why not use the proper name android.permission
RECEIVE_BOOT_COMPLETED?
control vibration (again call it android.permission.VIBRATE)
android.permission.WRITE_USER_DICTIONARY
helium314.keyboard.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION

> Is it possible those are BIND_INPUT_METHOD and BIND_TEXT_SERVICE ?

Yes those are not listed by f-droid

> those are not under "uses-permission", but under "service" -> "permission"

Thanks, wasn't aware of the distinction, but it's still "a permission"

Also there's no mention of android.permission.READ_CONTACTS

Regarding the DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION, I found this

<https://stackoverflow.com/questions/74146297/android-adding-dynamic-receiver-not-exported-permission-in-release-build>

R.Wieser wrote on Mon, 24 Jun 2024 10:45:07 +0200 :

>> d. The app is storing the data on your device.
>
> Do tell what "the app" is and where I claimed otherwise.

There are many apps doing it, for example, "Windy" is doing it.
<https://i.postimg.cc/QtfJ59LP/firebase02.jpg> Firebase indexed app data

The only question that remains unanswered is what is contained in that
index which Google says they may upload to their servers, since Google
explicitly says what they upload is not the data that Windy saves on the
device (which is intended to be found in on-device search results).

If you can answer that question, that would add value for the team.

croy wrote on Mon, 24 Jun 2024 07:25:50 -0700 :

> Being the ludite that I am, I had never heard of Firebase, so I turned to
> Wikipedia (https://en.wikipedia.org/wiki/Firebase). There I found this
> among the weeds:
>
> *****
> User privacy controversies
>
> Firebase has been claimed to be used by Google to track users without their
> knowledge. On July 14, 2020, a lawsuit was filed accusing Google of
> violating federal wire tap law and California privacy law. It stated that
> through Firebase, Google collected and stored user data, logging what the
> user was looking at in many types of apps, despite the user following
> Google's own instructions to turn off the web and app activity collected by
> the company.[17] The lawsuit was dismissed in January 2022, with Chief US
> District Judge Richard Seeborg ruling that a promise to avoid collecting
> user data did not amount to a contract.[18]
>
> [17] "Google faces lawsuit over tracking in apps even when users opted
> out". Reuters. July 14, 2020. Retrieved July 14, 2020.
>
> [18] "US federal judge dismisses breach of contract claims in privacy
> class action against Google". www.jurist.org. January 27, 2022. Retrieved
> May 18, 2022.
>
> *****
>
> That seems like a very odd decision to me, but there's not really much
> detail in that blurb. But it sure adds bulk to the general cloud (no pun
> intended) of opinion that, "Google is evil". And I would be interested to
> hear the judge's reasoning in that decision.

Thanks for confirming everything I've been saying, which is (essentially)
that unless the person (or article) specifically mentions "Firebase App
Indexing", then that person (or article) is useless for the purpose asking
them to provide any insight into the privacy aspect of Firebase App
Indexing.

As you've certainly already learned from that Wikipedia Firebase article,
there is not only no mention whatsoever of "App Indexing", it doesn't even
mention the word "indexing"; so it's essentially useless for our purpose.

As you've also already ascertained, even the blurb about the privacy
issues, when you delve into it, also doesn't mention the words "app
indexing", so it's really a dead end.

Is the lawsuit about Firebase App Indexing?
We don't know because Firebase App Indexing was never mentioned (AFAICT).

Moving forward, Arno helped me with some keywords such that I think I wrote
a pretty good summary of what Firebase App Indexing is in terms of the
overall Firebase suite of completely and utterly unrelated tools.
*Why do so many people confuse Google's Firebase (cloud API)*
*with Google Services Google Firebase App Indexing (search results)?*
<https://www.novabbs.com/computers/article-flat.php?id=53751&group=comp.mobile.android#53751>

If I knew what I know now when I had opened that thread, I wouldn't have
titled it that, as it turns out that Google uses the word "Firebase" to
lump into the collection of APIs a huge amount of completely unrelated
things, only one of which is Firebase App Indexing.

Here's just some of the wholly unrelated things Google considers 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

The main unknown is how can we figure out what exactly is
Google uploading when they get the SEND_INDEX results?

Andy,

>> Is it possible those are BIND_INPUT_METHOD and BIND_TEXT_SERVICE ?
>
> Yes those are not listed by f-droid
>
>> those are not under "uses-permission", but under "service" ->
>> "permission"
>
> Thanks, wasn't aware of the distinction, but it's still "a permission"

I wasn't aware either. This subthread ("they differ") brought them to my
attention. So thank you.

> run at startup (why not use the proper name android.permission
> RECEIVE_BOOT_COMPLETED?

Most smartphone users have little-to-no technical background. They would
be stumped to translate the latter to the former - which they have a better
chance to understand.

>> Is it possible those are BIND_INPUT_METHOD and BIND_TEXT_SERVICE ?
>
> Yes those are not listed by f-droid
>
>> those are not under "uses-permission", but under "service" ->
>> "permission"
>
> Thanks, wasn't aware of the distinction, but it's still "a permission"

Yep, it is. I can imagine quite a bit of funky stuff you could do when you
can inject keystokes into the phone.

> Also there's no mention of android.permission.READ_CONTACTS

Although the apk in question doesn't seem to have any way to send the data
anywhere, forgetting to mention such a privacy related permission is not
good. Luckily the phone itself will still ask for it.

> Regarding the DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION, I found this
[snip]

I also did search for an explanation to that permission, and remember having
found the same webpage. But alas, even after reading it I have no idea how
an app protecting itself from malfunctioning (not to say malicious) other
apps needs a permission. I'm rather likely missing something there, but I
don't know what. :-(

Regards,
Rudy Wieser

R.Wieser wrote on Mon, 24 Jun 2024 20:32:10 +0200 :

>> Also there's no mention of android.permission.READ_CONTACTS
>
> Although the apk in question doesn't seem to have any way to send the data
> anywhere, forgetting to mention such a privacy related permission is not
> good. Luckily the phone itself will still ask for it.

As another related side note, if you want to see which installed apps have
been granted permission to access contacts, Permission Manager shows it.
<https://i.postimg.cc/NFD9fWjG/permissionmanager.jpg>

Permission Manager
<https://github.com/YourStreet/android-permission-manager>
<https://play.google.com/store/apps/details?id=in.yourstreet.permissionmanager>
(I have this installed but I don't see an APK there anymore.)

Not sure why, but when I granted contact access to HeliBoard,
it still didn't show up in the Contacts permission tab though.

Andrew

>>> d. The app is storing the data on your device.
>>
>> Do tell what "the app" is and where I claimed otherwise.
>
> There are many apps doing it,
[snip]

Ah yes, a nice "lets flip the whole thing" from THE app to "many apps".

You still forgot (if that is the correct word for it, and I doubt it) one
thing though : quoting me on where I said otherwise.

> The only question that remains unanswered is what is contained in
> that index which Google says they may upload to their servers,

Really ? You seemed to indicate you aready knew what went into it (as
posted by you in the evening of last friday)

But nope. A number of other questions remain unanswered.

Like why you think it was a good idea to resort to semantics, what you tried
to do with that smokescreen, and substanciations to your "the app isn't
uploading that data" and the "Not the data itself" claims.

> If you can answer that question, that would add value for the team.

Andrew - or should I just call you Arlen - why would I want to be part of a
team (of one, just you) who cannot explain, let alone support his own
claims* but keeps pushing them nonetheless, even when he's been told that
that doesn't really create confidence in you ? Who also makes makes
claims that suggest wrongdoing and than when called out on them refuses to
respond ?

* and is now pumping others, and now me, to come up with it.

Besides, you do not want team members (equals), you want gofers who provide
you with the stuff you need - after which you ditch them.

Though I must say your table manners have improved considerably. No
incoherent ranting when someone disagrees with you. Your MO is still the
same though.

Regards,
Rudy Wieser

Andrew,

> Not sure why, but when I granted contact access to HeliBoard,
> it still didn't show up in the Contacts permission tab though.

Assuming your phones OS works correctly and should have displayed it, whats
your conclusion ?

And having come to a conclusion, what do you think you could do to verify it
?

Ah, whom am I kidding here. There is no way you will be able to come up
with an answer to either.

Regards,
Rudy Wieser

R.Wieser wrote on Tue, 25 Jun 2024 09:37:20 +0200 :

>> Not sure why, but when I granted contact access to HeliBoard,
>> it still didn't show up in the Contacts permission tab though.
>
> Assuming your phones OS works correctly and should have displayed it, whats
> your conclusion ?

We'd need more data which is why the best way to answer your question is
for you (or anyone else who is curious to obtain that answer) to install
the app & test it and then let us know what it reported. Just like I did.