I hope this can be resolved.

MarkF

I recently changed over to GrapheneOS on my Pixel 9 Pro XL. I was initially very happy with it, but I then started seeing errors that made me uncomfortable. There were 3:

Hardened malloc errors being thrown by Filen
Frequent messages saying that Obtainium had failed to check for updates
One of my banking apps showing an error saying that it was shutting down because AnySoft keyboard was present on the phone, and if I wanted the banking app to be usable I needed to get rid of AnySoft.

This didn't exactly inspire confidence, and for the time being I've reverted to my iPhone. But can somebody either reassure me about these errors, or tell me how to get round them?

dc32f0cfe84def651e0e

MarkF One of my banking apps showing an error saying that it was shutting down because AnySoft keyboard was present on the phone, and if I wanted the banking app to be usable I needed to get rid of AnySoft.

GOS should restrict apps' ability to list other apps installed.

raccoondad

MarkF can somebody either reassure me about these errors

None of these errors have any issues, I'm not sure what I should reassure you about. If harden malloc makes filen angry you can disable it.

Obtainium may be the source failing to reply or just an issue with background pulling, regardless if it works with a manual sync you should be mostly fine.

Banking apps are just like that

I just don't know what you are expecting, or why those would make you uncomfortable.

Watermelon

MarkF Hardened malloc errors being thrown by Filen

raccoondad If harden malloc makes filen angry you can disable it.

The errors by the hardened memory allocator mean that it does its job in protecting @MarkF from potential vulnerabilities. Instead of disabling the hardened memory allocator, consider switching to a less buggy alternative. Or save the log from the notification and send it to the Filen developer so they could fix it. The log could contain any sensitive data that you store/handle in Filen, though.

fid03

MarkF One of my banking apps showing an error saying that it was shutting down because AnySoft keyboard was present on the phone, and if I wanted the banking app to be usable I needed to get rid of AnySoft.

If an app is set up to only allow being used with certain keyboard apps, that is a restriction that the app developers created, and will be the case on stock Pixel OS as well.

raccoondad

dc32f0cfe84def651e0e GOS should restrict apps' ability to list

No, GOS doesn't do this? Android apps can see each other

dc32f0cfe84def651e0e

raccoondad Unfortunately, no. Would be a killer feature for privacy. It is possible to compartmentalize apps by using different user profiles, but it's not the way for a keyboard.

Byteang3l

raccoondad as far as I know, apps can only do this if they have the "query all packages" permission. And SELinux avc denials block apps from accessing other apps directories, the only imperfection here is IPC and potentially user error.

Vomitorius

I would recommend to try futo keyboard

raccoondad

Byteang3l apps can only do this if they have the "query all packages" permission

That is true but would require seeing the requested permissions from the bank app

Carlos-Anso

Byteang3l

The are various ways an app can determine what other apps are installed in the same user/work profile or private space. The app does not need this permission declared in their manifest.

Byteang3l

raccoondad the manifest xml would reveal that prior to installation.

mmobder

MarkF Hardened malloc errors being thrown by Filen

It's actually Filen's issue and not GOS. If that's frequent, report the issue to Filen and/or use an alternative (if available)

mmobder

MarkF AnySoft

again, doesn't like the GOS issue, but if your bank app devs complains on it, maybe there are known issues with anysoft kb privacy/security.

Byteang3l

Carlos-Anso Yes, but only in very limited and intentional ways. An app can notice another app only when that other app explicitly exposes itself, usually through something the user can see or trigger, like sharing or opening a file, or choosing an app. It can’t just silently list or spy on everything that’s installed. Preventing this very scenario is why the "query_all_packages" permission was introduced in Android 11+

https://developer.android.com/training/package-visibility

raccoondad

Byteang3l is the manifests permission list shown during install? Sure you can look at source, but bank apps don't reveal that. Other then that, you would have to decompile, no?

Carlos-Anso

Byteang3l

Unfortunately its much wider open than that. The permission you talk about does not effectively block apps working out what other apps are installed the way you appear to believe. There are lots of install time / "non-dangerous" permissions which like this one lead people to make incorrect assumptions about what an app can or can not do.

Byteang3l

raccoondad technically you would have to decompile, or upload to VT or something. But it's not difficult enough that I'd consider it a barrier.

Byteang3l

Carlos-Anso I’m not claiming it’s a perfect wall. Without query_all_packages, apps can still infer specific apps in certain contexts, but they can’t freely enumerate what’s installed or read/write other apps’ data, thanks in part to AVC read/write denials and the lack of the permission for apps that don’t have it. That’s the distinction I’m pointing at. IPC is still the biggest issue besides user error, and GrapheneOS at one point mentioned considering app communication scopes, which would largely mitigate the remaining vulnerabilities, though I’m not sure if that work is still ongoing. If you have documentation saying otherwise in regards to app enumeration, I’d love to see it.

phospmph

Byteang3l There are indirect ways for any app to query all other installed apps in the same profile. See https://nitter.net/lberrymage/status/1581373590980608001 on how it was done in Bitwarden's legacy Xamarin app.

Byteang3l

phospmph interesting, although that Bitwarden case is real, it’s just a specific workaround, not normal behavior. They abused a broad queries permission in the manifest to see other apps without query_all_packages. Android 11+ mitigates this, and SELinux still blocks access to other apps’ data. So it's still just an edge case, an exception to the rule rather than the rule. This would fall under my example of user error, installing a malicious app with a suspicious manifest. I do appreciate the anecdotes, but in terms of what's considered fact, I'm going to abide by the information in the link I posted from developer.android.com.