Google Keyboard w/ Network Permission Revoked

Rbr76711

I have been looking for an alternative to the stock keyboard. I seem to have difficulty hitting the correct key. After seeing this discussion I am giving FUTO a try. For now, works better for me over stock.

Vomitorius

Rbr76711 why Fossify is not an option?
https://f-droid.org/packages/org.fossify.keyboard/

LGgos

That dissertation was very informative reading.

I've been using Heliboard with the swipe library added as I find gesture typing so much faster, but find that it just doubles my typing time as it rarely types out the correct word compared to gboard and I'm constantly having to delete the word and type it in manually.

This settles my mind that Gboard isn't leaking anything of concern to my threat profile (others may vary) as long as the telemetry is switched off. Ironically I was considering Swiftkey under the logic of "at least it's not Google" but the dissertation was enough to tell me that it's far worse and lacks opt out. For all of Google's faults, it seems that at least for the keyboard they do respect your privacy choices

No one can know for sure and things might have changed since 2022 but I personally feel that using gboard with telemetry disabled will be a reasonable enough tradeoff for more accurate gesture typing.

Eirikr70

LGgos You might even be willing to deny network privilege to GBoard.

BeepBeep

LGgos
I tried for months to work with Heliboard but had the same experience. Very frustrating. My phone is configured to have access to the Play Store, so I have Gboard installed without either network access or GSF running in my secondary profile that I use for daily driving, and I don't use Gboard in the (typically inactive) profile which does have GSF. However, my tablet is completely Google free, and I don't want to depart from that. I switched to Futo keyboard, and for me it's noticeably better than Heliboard. I recall there being some negative politics voiced around Futo, but I need something private that works until there are other options. You might try Futo before feeding Google your data. [Thanks in advance for not yelling at me about Futo.]

LGgos

Eirikr70

From what I understand that makes no difference since it communicates via Google Play Services using IPC anyway

Eirikr70

LGgos The point is that apart from Google, none knows what it communicates to Google Play. Does it communicate to the same extent with Google Play as it would with the Google servers when network is allowed ?...

LGgos

Eirikr70 The paper you linked to seemed pretty good at breaking that down?

My interpretation is that it does all its telemetry communication through Google Play Services so the data allow/block for the keyboard app itself is probably just for things like voice typing. They said there was no evidence that the words typed or character frequency were leaving the device, and that the data batches were nothing of interest once telemetry was turned off. Which is good enough for me if no one has observed any change in behaviour of it in the past 3 years, but indeed I'll have a try at Futo before resorting to Gboard.

WestQuester

I am using Google Keyboard as well because I spend way too much time correcting typos with all the others. Network disabled, privacy settings on.

However, I'm not sure if the concerns over communication through Google Play Services is warranted or not. Being sandboxed means something and I don't think it's accurate to suspect that IPC means that apps can just send whatever they want between each other, otherwise I would think that would be a fundamentally concerning security issue, never mind privacy.

But I don't know for sure. I would love to know more about IPC and what is/isn't possible on the sandboxed versions in GOS.

Eirikr70

WestQuester IPC is just a contract between two apps to exchange data. If the two apps have "subscribed" that contract, the sandbox can't prevent them.

de0u

WestQuester I'm not sure if the concerns over communication through Google Play Services is warranted or not. Being sandboxed means something and I don't think it's accurate to suspect that IPC means that apps can just send whatever they want between each other, otherwise I would think that would be a fundamentally concerning security issue, never mind privacy.

The Android app sandbox doesn't mean "apps can't share any data at all ever". Apps are allowed to share all sorts of data, and IPC is an important part of how Android works. When a message app invokes a camera app to take a picture, that is IPC in action. And apps that use Google Play services routinely invoke those services via IPC.

WestQuester

de0u I never said that's what sandboxed means. Conversely, IPC doesn't mean apps can share whatever data they want either. Lots of assertions being made in this thread without anything to back it up. I've read a good bit on IPC but nothing that definitively answers my questions.

de0u

WestQuester IPC doesn't mean apps can share whatever data they want either.

That's pretty much what it's for. Here is some information about apps using intents to communicate.

It is true that IPC usually doesn't cross profile boundaries, though I think it might when there is clipboard sharing.

And there has been some talk of GrapheneOS adding a feature to filter IPC within a single profile.

But it is absolutely part of the Android design that apps can communicate via IPC about whatever they want to communicate about.

WestQuester Lots of assertions being made in this thread without anything to back it up.

So far I think you have made assertions without citing sources and I have cited sources. Also @Eirikr70 cited a source (Eirikr70).

WestQuester

de0u You just want to argue and you keep changing the assertion. Here's something to read:
https://discuss.grapheneos.org/d/12924-any-other-ways-to-secure-the-use-of-the-pixel-camera-and-gboard-from-ipc/2

Specifically, the GrapheneOS account, responding to this exact situation (the concern over Gboard without network permissions still communicating via IPC) said:

"These apps are not malware and are not exfiltrating sensitive data via network access in the first place unless you opt-in to sending usage data, so it's not really clear what you're aiming to accomplish by coming up with extreme ways they could do it as if they're malware colluding with other malware to bypass the permission model."

de0u

WestQuester Here's something to read:
https://discuss.grapheneos.org/d/12924-any-other-ways-to-secure-the-use-of-the-pixel-camera-and-gboard-from-ipc/2

I have read that. Note that it says:

"An app you grant the Contacts permission could share it with another app in the same profile. An app you give data could share it with another app in the same profile" and
"Apps in separate users can't communicate via standard IPC mechanisms and profile data is separate" (emphasis added) and
"Interprocess communication can be done via any access you've granted to shared resources or any access they have to shared resources by default."

I think all of that is very much in support of the notion that apps can share whatever they want via IPC within a user profile.

WestQuester The GrapheneOS account, responding to this exact situation (the concern over Gboard without network permissions still communicating via IPC) said:

"These apps are not malware and are not exfiltrating sensitive data via network access in the first place unless you opt-in to sending usage data [...]"

I expect that is true. But, assuming it's true, it's true because the app is not written to exfiltrate data if the option is set correctly. It is not because "being sandboxed means something" (the Android app sandbox is not stopping the data transfer) and it is not because there is some sort of IPC filtering stopping Gboard from sending data to Play.

The difference is relevant any time an app is installed that hasn't been inspected the way Gboard has, because apps can send whatever they want via IPC.

DeletedUser495

WestQuester if I were you, I would in no way downplay power and severity of IPC which is very hard if not outright impossible to root out, heavily affecting basic functionality of many apps, hence the postponement of long awaited IPC scopes.

de0u

WestQuester Here is an example of a user who was surprised to find that an app was using IPC to fetch advertisements from Google Play: https://discuss.grapheneos.org/d/9943-app-displaying-ads-without-any-permissions

WestQuester

DeletedUser495 What have I written that makes you think I've downplayed IPC? I want to know the reality of its abilities and limitations (thus I said "I'm not sure if concerns...is warranted or not....I don't know for sure. I would love to know more about IPC and what is/isn't possible on the sandboxed versions in GOS").

I'm neither promoting dismissing IPC, nor am I promoting alarmism that apps are sharing data all over to circumvent network permissions (like malware).

I agree, sandboxing does not prevent IPC, but IPC isn't just a free-for-all data sharing either. Permissions still have some effect (e.g., contacts being denied one app doesn't mean that it can just get it through IPC from another). I don't understand exactly how it works or its abilities or limitations, thus my query.

I've read just about every thread on this forum dealing with IPC and numerous articles. The scope and implications for privacy are still not clear to me.

Probably9857

WestQuester Permissions still have some effect

Yes, but...

WestQuester contacts being denied one app doesn't mean that it can just get it through IPC from another

That is precisely what is possible via IPC, with the caveats:

The app providing the data of course must have permission to access that data in the first place
The two apps must both agree to the sharing

The permissions of the app receiving the shared data are not really relevant.

LGgos

One could argue that anything Google is malware colluding with other malware, but of course this would be personal opinion.

MineralWater

I think the whole concept of GrapheneOS sandboxing the Google Apps would be completely useless if IPC would give access to all data within a profile.

So there must be limitations. Even Google would be in heavy trouble if they would construct their OS in a way that once the phone is unlocked all data can be accessed by simply building an app.

« Previous Page Next Page »