[Documentation] Privacy and usability aspects of the sandboxed play services and comparison to MicroG

[PhysicsIsAwesome]

Hi,

There is an interesting discussion going on on reddit about the privacy aspects of the sandboxed play services. It would be nice if you could answer some of the questions, since a lot of people seem to be interested in that topic. I guess that some people relying on play services even consider switching to GrapheneOS from stock or other custom ROMs, so this is a great opportunity to make GrapheneOS more popular.

The documentation of GrapheneOS is pretty good, but I think this part could use some elaboration to make things more clear for users. Especially the case when someone relies on play services for some apps, but does not want to have a separate user profile, since switching between profiles back and forth is cumbersome, media stops playing etc. And how this compares to MicroG and I mean not only from a security perspective, but from a privacy perspective. So what data is being sent to Google, and steps taken to minimize this. Also if there is/could be some kind of firewall, to select which apps are allowed to see and communicate with play services and vice versa, aside from separate user profiles.

Additionally it would be good to know what is known to work and what not, like FIDO2 keys as an example, which arguable are important for security minded people.

Thanks and best regards PhysicsIsAwesome

[thestinger]

Apps using Play services use Google libraries running within their own app sandbox. Those Google libraries can contact Google services without Play services installed. Many of those libraries including the Google Ads SDK work fine without Play services. You can also easily confirm that Google Maps itself works fine without Play services. Play services being present or not doesn't change whether apps can use Google services and doesn't change which apps are using Google libraries.

Sandboxed Play services minimizes the data sent to Google because the apps are fully sandboxed with zero special access or privileges. Installing it provides zero additional access to the Google code you're already running via the Google libraries in each app using Play services. You don't need to grant any permissions or access to it in order to use it. You can optionally choose to log into an account via the Play Store in order to use the Play Store app and other functionality depending on being logged in. You can use an anonymous throwaway account. Aurora Store doesn't bypass the need to be logged in to use the Play Store but rather has a service for automatically creating throwaway anonymous accounts.

Using a dedicated user or work profile applies just as much to microG as it does to sandboxed Play services. The reason for the recommendation is because apps within the same profile which are using Google libraries will use Play services for APIs like FCM when it's present within the same profile. That's true whether you use microG or the sandboxed Play services. That isn't a difference between them. For example, if microG or Play services (either one) is present in the same profile, then apps like Signal and WhatsApp will attempt to use FCM for their push functionality rather than their own push functionality. By using a dedicated profile, you can explicitly control which apps will use it. Either way, these apps include Google libraries.

The sandboxed Play services feature is able to provide 95% of the Play services APIs rather than a tiny subset of them like microG. It doesn't require granting special privileges to it as is the case for microG with signature spoofing. Keep in mind you can install microG on GrapheneOS. It requires that the OS gives it special privileges for bypassing the security checks in other apps: their signature checks for Play services, which exist to protect the data those apps trust with Play services. The point of that is not handing it over to arbitrary apps with the same app id which may be malicious or lack the same precautions taken to protect the data such as certificate pinning, greatly reduced CA trust store and the security model enforced for the Play services APIs including signature checks of apps using it or providing certain things to it.

Google's FCM library could implement the FCM service within the app when Play services isn't available. It's entirely capable of doing that, but rather chooses not to do it. Note that they choose to implement full fallback functionality for the Google Ads SDK because they earn money selling ads. They choose not to do it for much of the other functionality since it wouldn't benefit them.

Since the sandboxed Play services is a fully sandboxed app, it isn't capable of providing more capabilities, access or functionality to apps than they're inherently capable of having without using it. Apps and the Google libraries they use are just as capable of doing everything that it's capable of doing. It's the same full app sandbox with zero special access or privileges. Our documentation focuses on the fact that it has zero special access or privileges for that reason. We don't go into enormous depth about what that means or about why this design approach was chosen, but it was chosen because it's inherently a no compromises approach in the sense that it provides zero additional access, privileges or capabilities to Google's Play services code. Please keep in mind that each app using it has the Play services libraries included and those libraries are fully capable of contacting Google services and implementing fallbacks when Play isn't available. Look at the Ads SDK and at Google Maps, among many other examples.

Google Maps Go is similar to the Google Maps app without all that fallback code to make it work when Play services isn't present in order to make it substantially smaller. This is the main reason for them not including fallback code for more of the services. Another reason is that apps will often not update the libraries for long periods of time, or ever again if they stop being maintained. The Ads SDK prefers using the generally more up-to-date Play services copy of the code when it's available, and otherwise falls back to the code within the app when it isn't available. It can have the same capabilities either way. They have https://developers.google.com/admob/android/lite-sdk providing a lighter copy of the Ads library without the fallback code.

As always with GrapheneOS, our goal is fundamentally improving privacy and security along with keeping apps and services on an equal playing field. Google's apps and services should not have any special integration into the OS and neither should other third party apps or services. Our approach puts them on an equal playing field with everyone else. It doesn't attempt to enumerate badness in Play services.

[thestinger]

The usage guide is mostly intended to explain how to use it and the semantics of it rather than going into depth about the meaning behind what's stated there and how things work. That's the kind of content which belongs in a dedicated page for https://grapheneos.org/articles/ because as you can see, simply writing up a response here (which I've also posted on Reddit) already turns into a large post. That's without substantial review / expansion which would happen if turning it into an article. It takes a lot more work to make an article for the site than it does to make a response here, because writing it up for the site is taking more seriously and great care is taken with the wording in order to avoid misleading people or giving the wrong impression. Hope that makes sense. I agree that this could be turned into an article for the site.

[PhysicsIsAwesome]

Thank you very much for the fast and extensive answer! Makes it a lot more clear to me.

FIDO2 keys did not work on phones without play services. Do you know whether they or other similar security standard keys now work with the sandboxed play services?

[thestinger]

Security keys do work without Play services, but most apps use the Play services FIDO library for accessing them. Note that Android phones have hardware keystores with support for physical confirmation usable as FIDO security keys without needing a separate security key. Google supports that for Google accounts, although they do it via Play services.

The APIs for using NFC, USB and Bluetooth along with the traditional hardware keystore within the phone and the more secure StrongBox secure element keystore (Titan M on Pixels, Qualcomm SPU on other flagship Qualcomm phones with the feature) are fully available to normal apps to use. They just need to ask for consent from the user to authorize access to a USB device, pair with a Bluetooth device, etc.

The FIDO library within Play services hasn't really been tested and made to work with the sandboxed Play services yet. It's possible that some of the functionality already works. It's likely that at least some of it won't work without expanding the compatibility layer. It hasn't been a focus yet.

GrapheneOS plans to provide a reusable FIDO2 implementation via the StrongBox keystore as an open source library, which we'll use within Vanadium to implement the feature. However, it would be better if that happened in AOSP and Chromium since if we simply do it ourselves, it wouldn't be widely adopted by other apps.