• General

  • How big of privacy risk is it having Play services installed?

This thread has been derailed with low quality answers to the question and off-topic discussions. Part of what makes a forum useful compared to real time chat is the permanence and search friendliness. I've removed the off-topic discussion to make a high quality answer more visible and to avoid needing to delete the thread.

It was fine to mention that Protonmail's app works without Play services but requires it for push notifications, but the thread isn't meant to be a discussion about different email services. Suggesting using the web app instead comes with substantial drawbacks for the already problematic encryption approach and isn't an equivalent alternative.

On GrapheneOS, the Google Play apps are sandboxed apps like any others. Play services has absolutely no access beyond what other apps can access. Every app using Google Play uses the Play SDK and Play libraries so the Google Play code is already part of those apps with or without Play services. Whether or not you have Play services, Protonmail's app includes the Play SDK and the FCM client library. This library doesn't provide a fallback to function without Play services present. Many of the other libraries such as Google's Ads SDK provide fallback code and work without Play services being present.

User installed apps can never access each other's data and they cannot access profile data without permission. They're always sandboxed in the standard app sandbox. Play services and the Play Store are not exceptions from this. Apps within the same profile can communicate with mutual consent on both sides. Google Play being present isn't relevant to whether apps include the Play SDK and Play libraries. Apps can use Google services without Google Play being present. You can see that Google Maps completely works without Play services with only a few missing features, as a nice example of how it's not required. The Google Ads SDK works fine without Play services too. Thinking that not having Play services means apps aren't able to use Google code and services is very wrong. Play services on GrapheneOS is a regular sandboxed app. It has the same app sandbox and restrictions as every other app. If you install an app like Discord using the Play SDK, Google Play already has code execution within the standard app sandbox through Discord. Whether or not you install Play services for Discord to be fully functional is up to you, but if you think you're not giving the Google Play code as much access by not installing it you're wrong and are misunderstanding the whole sandboxed Google Play approach.

Please read https://grapheneos.org/usage#sandboxed-google-play. I think we do a good job explaining it there.

    strcat

    Thanks for cleaning up the thread!

    I believe I do understand your argumentation about the regular sandboxed apps. But based on what you also say about the mutual agreement of communication between apps, it seems to me that Google Play Services are not that "regular" after all. I mean, many apps will communicate with that specific app, as that is one of its intended jobs. That means, Google Play Services doesn't only have access to the stuff that we grant it to access but it will also have access to all the stuff that other apps will send to it.

    Example: Other apps will communicate with Google Play Services to show notifications via the Google push notifications system. So, I assume at least those notifications can be intercepted by Google Play Services. So, this is already something more that "regular" apps won't be able to do because it would be unlikely that some app would ever send such information to them.

    I would also assume that other Apps would probably send other data to it or try to request data from it and thereby leaking more information towards Google. Maybe an App wants to get some kind of data related to a specific location. In that way, Google would know the location information related to that request.

    Am I mistaken with that assessment?

        graphy442556

        Yeah, that's my interpretation of it as well. They say that Google Play Services are no different than any other installed app, because any app can communicate with any other app if there's mutual consent. But it is different because most apps will be built with that mutual consent intended for integration with Google Play.

            graphy442556 eatinggrumble84

            It's the app developer's choice to share information with Google services or any other services. By using FCM, they agree to the terms of service for it. Apps can communicate with Google services or any other services without Play Services being installed so Play Services is not special in this way.

            Maybe an App wants to get some kind of data related to a specific location. In that way, Google would know the location information related to that request.

            Like any other app, Play Services can't access your location without being granted the Location permission. GrapheneOS also reroutes Play Services location API requests to the OS by default, so apps using the Play Services location API can work without Play Services having the Location permission.

                  lberrymage

                  I think the original message was thinking of the following case:

                  • app1 has location permission and allows communication with Play Services via mutual consent
                  • Play Services has location permission revoked (i.e. not granted) and allows communication with app1 via mutual consent

                  In this case, Play Services can access your location without being granted the Location permission by proxy. It can't access it directly via the location APIs and hence can't decide to access it on its own accord, but it can still get the same data when the app provides it to it.

                  This raises a few questions I've had, including:

                  • How do we know which apps have allowed communication via mutual consent with which other apps?
                  • How do we know what data will be shared between two apps with mutual consent? Are there any limitations on this, e.g. say an app wants to use FCM for notifications, the only thing it really needs is to be on the receiving end of a communication stream of only obtaining the notifications from Play Services... do the minimal permissions required to achieve this also allow that app to send arbitrary data to Play Services?
                  • Would it theoretically be possible to revoke either side of the mutual consent via toggles that could be provided by the OS?

                  Sorry if this is straying again too far from the original discussion, but I think this is especially relevant for Play Services. I know I can look in the app's manifest and ultimately get information for my first question (maybe not all of the information I'd want, I'm not sure), but it's quite complicated to figure out and requires a lot of knowledge to understand exactly what each intent (or other relevant aspect) means. For example, say I want to use Gboard. Gboard has intents that interact with Play Services (as far as I can tell from looking in the manifest), but it works just fine without Play Services installed. I'd like to use Gboard in my profiles that have Play Services, but I'm worried that it might be sharing the content of what I type to Play Services. But, in a profile without Play Services, I don't have to be worried about this.

                      Googe Play Services - isn't it supposed to be named Google Mobile Services (GMS)? I think when people think Google Play Services, they think Google Play Store, which isn't required.

                      On my old rooted Pixel phone, I semi-de-Googled via ADB and/or blocked almost everything Google-related via firewall + hosts file. I left Google Mobile Services (GMS) for FCM. It worked.

                      The issue with FCM is that it knows which apps push notifications, when, and to whom (account-wise). It doesn't know the content of notifications, but knowing that you received a ProtonMail notification at a specific time is already sensitive metadata.

                      Some apps aren't honest about necessity for GMS/FCM. For example, Authy, keeps showing error every time I launch it because I don't have GMS on GrapheneOS phone, but it works without issues. It immediately notifies me when I try to add another device to Authy account.

                      This gives me an idea - open-source push notification service created with zero-trust policies to make sure the service itself doesn't log and/or store or even know which app pushes what and to whom.

                      10 days later

                      algaeita

                      • How do we know which apps have allowed communication via mutual consent with which other apps?
                      • How do we know what data will be shared between two apps with mutual consent? Are there any limitations on this, e.g. say an app wants to use FCM for notifications, the only thing it really needs is to be on the receiving end of a communication stream of only obtaining the notifications from Play Services... do the minimal permissions required to achieve this also allow that app to send arbitrary data to Play Services?
                      • Would it theoretically be possible to revoke either side of the mutual consent via toggles that could be provided by the OS?

                      These are all important questions I think about too. Currently, I have Sandboxed GPS installed in a different profile to my main Owner profile only because I'm not sure about the answers to the above questions.

                      As an example (for something I worry about regarding inter-process communication (IPC) via mutual consent), I have GBoard installed but with all permissions revoked (including network). This gives me functionality of the app without having to worry about it reporting back to Google.

                      However, if I have Sandboxed GPS installed (with network permissions allowed), I imagine there will be mutual consent for IPC between the two apps, and even though GBoard won't have network permissions, it can share my typing data with Sandboxed GPS, thereby providing a work around for my data GBoard data to be shared with Google.

                      I guess a lot of these unknowns are derived from the ambiguity of what mutual consent between apps entails, which apps implement it, what data is shared exactly and whether the user has any ability to limit such consent.

                        5 days later

                        • [deleted]

                        • Post #32

                        algaeita I consider this to be crucial and the unknown stops me for now to use "sandboxed play services". I read the thread in /faq and /usage about these but these questions seems to be unanswered. Would it be possible for someone from GOS to look into it and try to provide more information?

                            strcat "Suggesting using the web app instead comes with substantial drawbacks for the already problematic encryption approach and isn't an equivalent alternative."

                            Please explain the "already problematic encryption approach". Perhaps it refers to the idea that using the app, final message encryption occurs on the pixel; whereas when using a browser, the message is sent unencrypted via HTTPS to the website, where it is then encrypted by a proton process before insertion into the database? Is there a discussion about this somewhere?

                                3 months later

                                [deleted] : I have the exact same questions. I even wonders if, somehow and with all its drawbacks, MicroG is not better under this dimensions: it is built to remove each and any private data from those sent to Google.

                                    a month later

                                    matchboxbananasynergy : have you or do you know anyone who have read through MicroG code, even quickly? This is a real question, nothing sarcastic or negative in it. I must humbly admit I've been using MicroG in the past but never went into its code to fully understand its functioning (despite I'm working in IT security... oh my...)

                                      a month later

                                      • [deleted]

                                      • Post #39

                                      Would it be possible for someone from GOS team to comment on Algaeita comment from Sep 1, 2022 in this thread? These questions in other words seems to be spread in many threads on this forum, but they - IMO - seems to be avoided, or left only with users guess how it could actually work.

                                      I have one more question to the topic. Google play services are sandboxed on GOS and have no access to hardware identifiers - or at least that is what I understood (maybe incorrectly?), I am wondering how Google play decides that the app is compatible with the devices and find the "correct" apk for the device. Would it be possible to comment on that too?

                                        [deleted] Finding the "correct" apk for the device is about the device's CPU architecture. CPU architecture is not an identifier as it's not unique. Identifiers are unique properties that can be used to identify and differentiate individual devices.

                                          4 months later

                                          (regarding Protonmail):

                                          newbie24689 "Suggesting using the web app instead comes with substantial drawbacks for the already problematic encryption approach and isn't an equivalent alternative."

                                          Please explain the "already problematic encryption approach". Perhaps it refers to the idea that using the app, final message encryption occurs on the pixel; whereas when using a browser, the message is sent unencrypted via HTTPS to the website, where it is then encrypted by a proton process before insertion into the database? Is there a discussion about this somewhere?

                                          Oh, that's an important question that seems to have gone unnoticed.