• General

  • How to mitigate identifiability from Google accessing installed apps?

I'm currently researching configurations and app downloading on GrapheneOS; more on this here. As part of this, I found Google identifying the user (in part) based on the unique fingerprint from the apps they have installed to be a one of the hardest problems to solve. It can be mitigated by compartmentalization through multiple user profiles, but if it is possible to avoid this in another way, I'd still prefer a solution in which all apps are downloaded from the owner profile. This is where I'd appreciate your help, ideas, and knowledge.

Google will inevitably know which apps are installed through the Play Store itself. If there are only a few apps installed for each instance of the Play Store because different areas of usage are split into multiple user profiles, I assume this to be of little risk to identifiability and linkability. However, the more apps are installed like this, the more unique and valuable this fingerprint can become. It's hard to judge at which point exactly the risk becomes too great, and of how much use data on all installed apps on the whole device would be for Google. Maybe someone can shed some light into when deanonymization should be deemed realistic because of this?

I'm uncertain whether Google will inevitably know about all apps inside a user profile, including those installed from different sources (like F-Droid, Aurora Store, Obtainium, Accrescent). In this case, it concerns an owner profile in which Sandboxed Google Play is installed, and the Play Store is used with a Google account to download at least some apps. However, none of these apps are used inside the owner profile itself.

One potential issue is IPC, for which I assume Google will have access to all installed apps, regardless of source. This might be prevented by disabling the apps immediately after install, which doesn't impede the functionality of updates or usability inside other user profiles if installed there. However, I don't know how the GrapheneOS implementation that allows disabling all apps works exactly, so I'm uncertain.

Another issue would be the Play Store recognizing apps from other sources, especially if it offers them as well. As disabled apps can still be updated, they can at least be recognized in some way. This might be avoided by only installing apps or versions thereof that aren't offered in the Play Store; for example, the F-Droid version of Bitwarden instead of the Play Store one. However, this approach will not be possible for all apps and sources; Aurora Store and APKPure can't be used at all. And still, even that might not suffice – more info about what exactly the Play Store can access would be appreciated. Another approach might be using storage scopes to try separating Play Store apps, but I'm again unsure whether this can work.

As you see, I have a few ideas, but also lots of uncertainty. I already did some research into these topics, but for some I haven't found much info. Please don't hesitate to share your ideas, more in-depth knowledge of the systems involved, or even good sources for my research. Thank you!

    • [deleted]

    • Post #2
    • Edited

    iustitia Google will inevitably know which apps are installed through the Play Store itself.

    I think an app can get the list of all installed apps and system apps in all users, If it declares the QUERY_ALL_PACKAGES permission in its manifest. So If you have an Google app (including Play services, Play store and Services Framework) installed and It declares the QUERY_ALL_PACKAGES permission, It could get the list of all installed apps and system apps in all users

    iustitia One potential issue is IPC, for which I assume Google will have access to all installed apps, regardless of source.

    IPC on AOSP and obviously GrapheneOS is mutual. So you shouldn't assume that "Google will have access to all installed apps, regardless of source.".

    iustitia Another issue would be the Play Store recognizing apps from other sources, especially if it offers them as well. As disabled apps can still be updated, they can at least be recognized in some way. This might be avoided by only installing apps or versions thereof that aren't offered in the Play Store; for example, the F-Droid version of Bitwarden instead of the Play Store one.

    The Bitwarden app on both Play store and F-Droid uses the same package name, so Play store could recognise It.

            [deleted]

            Thank you for the detailed answer!

            [deleted] So If you have an Google app (including Play services, Play store and Services Framework) installed and It declares the QUERY_ALL_PACKAGES permission, It could get the list of all installed apps and system apps in all users

            Does that mean there's no way to hide the installed apps? If it is the case, am I correct in assuming that installing SGP and using PS in the owner vs. some user profiles wouldn't make a meaningful difference when it comes to Google fingerprinting you based on the installed apps?

            [deleted] IPC on AOSP and obviously GrapheneOS is mutual. So you shouldn't assume that "Google will have access to all installed apps, regardless of source.".

            To clarify, with "access to all apps" I meant having the knowledge which apps are there, not necessarily the ability to communicate with them. I assumed that Google would need to know which apps might be available, even if an actual attempt for IPC would fail because of missing consent. Is this correct, or does IPC work differently to avoid giving apps information about which other apps are installed?

                    • [deleted]

                    • Post #4

                    iustitia Does that mean there's no way to hide the installed apps? If it is the case, am I correct in assuming that installing SGP and using PS in the owner vs. some user profiles wouldn't make a meaningful difference when it comes to Google fingerprinting you based on the installed apps?

                    Note the "I think" part. I am not really sure.

                      Google apps including Google Play have no special privileges on GrapheneOS. It has no special ability to see other apps or communicate. Portraying this as something specific to Google apps is incorrect. Apps can see the other apps installed in the same profile, and if two apps within a profile agree to it they can communicate with each other. GrapheneOS has a planned App Communication Scopes feature similar to our existing Storage Scopes and Contact Scopes to enable choosing which apps in the same profile are visible and can be communicated with for each app.

                        @[deleted] QUERY_ALL_PACKAGES does not provide the ability to see apps in other profiles. In fact, QUERY_ALL_PACKAGES does not provide the ability to do anything that cannot be done without it. Listing a broad query definition is essentially equivalent to QUERY_ALL_PACKAGES. Queries are also not required to detect which apps are in the same profile in the first place. An app not defining a single query or having QUERY_ALL_PACKAGES doesn't mean it can't see the apps installed in the same profile, although it seems Android intends to work towards that being the case.QUERY_ALL_PACKAGES has no privacy or security impact. Those low-level permissions are not supposed to be visible to end users because they aren't actually part of the privacy or security model. It's not good that Android surfaces the info via the highly misleading and inaccurate "All permissions" view which has inaccurate text on what these do and doesn't account for the fact that most have toggles in the permission menu, special access permissions menu or elsewhere such as the battery restriction modes.

                          GrapheneOS

                          Thanks for clearing that up. It did strike me as somewhat contradictory to the usage guide.

                          GrapheneOS Portraying this as something specific to Google apps is incorrect.

                          My question was specifically about Google, but it wasn't my intention to portray Googles abilities as special. To my understanding, the only difference to most apps would be the Play Store having permission to install apps, but this wouldn't be any different for Accrescent or F-Droid. Whether this permission opens up an additional way to gain information about installed apps (even from other sources), I don't know.

                          GrapheneOS Apps can see the other apps installed in the same profile, and if two apps within a profile agree to it they can communicate with each other.

                          Okay, so my assumption was correct here. Would an app that's disabled inside a user profile still be visible for other apps inside the same user profile?

                          Could you please share some thoughts on installing all apps through the owner profile but thus being able to only grant first-party-downloads permission to all user profiles? I'm aware there isn't a blanket answer. Still, someone with a great overview sharing their opinion about both sides of the trade-off (threat of linkability, identifiability vs. improved security) could be very helpful. My struggle comes down to the difficulty of assigning an exact value to the up- and downsides here because even with a clear threat model in mind, it's hard (but crucial) to always take all relevant factors into account.

                          GrapheneOS GrapheneOS has a planned App Communication Scopes feature

                          You just can't help pushing the boundaries further and further, can you? :D

                                  GrapheneOS

                                  What about the work profile, does that offer the same separation where apps can't know which other apps are installed?

                                    GrapheneOS
                                    Could you clarify something for me regarding app identifiability.

                                    As has been mentioned an app can see the list of installed apps in the profile. So far as i can tell i don't see how this could be used for finger printing. What exactly do they see? List of package names? What about version numbers? Anything else?

                                    Since app lists are different from profile to profile, i don't see how this can be used as a meaningful data point to use for finger printing.

                                    One scenario i can think of is, even without IPC, apps could upload the android_ID of their profile to a shared datapool and that way if one of the apps has a real "id" then the other apps will discover the profile's owner ID from the datapool. But they have to be in same profile. And they could do this with IPC too if they wanted too.

                                    But this can be mitigated by separate profiles.

                                    Anything else?

                                    .
                                    .

                                    Separately, one thing that comes to mind is, as you know when installing the same app in a different profile, the SAME app install files are pulled from the already existing copy in another profiles (right?).

                                    But what happens if i re download the install apk of " same version" and "same key" but from a different source into a new profile and try to install it? An example would be an apk from play store and an apk from github, both with same key and version. Will the "new" files actually get installed in the new profile? Or will the existing files be pulled from main profile? Or will the new files get installed and replace the other profiles'?

                                    This is relevant in the sense that, say i have installed Sandboxed Google Play in 2 different profiles and with 2 different google accounts, (installed through GOS Apps app separately). When i try to install an app from play store on the 2nd profile (using its own google account) that is already installed in the 1st profile (not transferring the app from 1st profile), what happens? will either the app or GP notice anything unique about the existing installer files that would give away the identity of the first profile to the second one?

                                    Another way of putting it is, if an installer apk is made "unique" by having been embedded with "some kind" of unique identifier on each "download instance":

                                    1. would installing this app into a new profile by exporting it from the main profile transfer over the "id" into the new profile?
                                    2. How would installing a "new download instance" with a different embedded ID interact with the already existing files in another profile?

                                    This obviously is a vector that could potentially "leak" over to other profiles an app's "self identification". Its a bit difficult trying to explain this, i hope you get my meaning.

                                    Please note that I'm only using the "embedded ID" concept as a concept and not an exact method. As you know there could be a multitude of way in which to make installers and consequent installations "uniquely identifiable", which I'm not too knowledgeable on. Wondering what you might have to say about that.