@gvs @cliffwade Their response to corrections to inaccurate claims they made about the sandboxed Google Play compatibility layer and microG is to claim that accurate information is propaganda with no basis since it doesn't align with their views. Simply read the available documentation for the projects involved about how Google Play works and how microG works. Can see that Google Play is still running in each app using it, and that is within the same app sandbox used for sandboxed Google Play.
In apps, yes. But does microG itself download Google binaries? And which?
Thanks for your always detailed replies, I really appreciate that
@gvs @cliffwade @GrapheneOS Most of the google APIs are present in microg. https://github.com/microg/GmsCore
GitHub - microg/GmsCore: Free implementation of Play Services

Free implementation of Play Services. Contribute to microg/GmsCore development by creating an account on GitHub.

GitHub
@officialneige @gvs @cliffwade It only implements a small subset of the overall Google Play APIs. It's missing major parts of the APIs and has major parts simply stubbed out. A lot is only partially implemented or incorrectly implemented. As a particularly problematic example, microG until recently allowed apps to access Location data which should not have been able to access it because they didn't implement foreground and other checks until recently. There are still other issues like that one.
@gvs @cliffwade Yes, microG downloads binaries including droidguard and snet which are run within the microG context with all the privileges it has. On operating systems fully integrating it, microG is a privileged system app, so this gives those elevated privileges to the Google Play code too. snet checks the name of the SELinux name and it was part of a lazy approach to spoofing the current weak software attestation mode. It's not possible to spoof the strong hardware-based attestation mode.
@gvs @cliffwade The features downloading and running Google Play binaries are optional, but required for compatibility with a fair number of apps. Sandboxed Google Play on GrapheneOS runs in the standard app sandbox with absolutely no special access or privileges, and it provides compatibility with nearly every app including being able to use the Play Store, Google Play Games and apps heavily depending on Play. It does it without giving absolutely any more access than the libraries in the apps.
@gvs @cliffwade Since the sandboxed Play Store is supported, not just sandboxed Play services, apps depending on Play Asset Delivery, Play Feature Delivery, in-app purchases, license checks for the app and in-app purchases, etc. all work fine. Sandboxed Google Play cannot do anything that the Google Play libraries inside the apps using it cannot already do by themselves. The whole point of the approach is using the same sandbox and permission model, with all improvements we make to it included.
@gvs @cliffwade For example, GrapheneOS has Storage Scopes and now also Contact Scopes. If you need Play services functionality depending on access to media, you can instead enable Storage Scopes. If you need functionality depending on access to contacts, you can instead enable Contact Scopes. In general, 99% of the Play functionality works with only our Network permission enabled. Our Sensors permission can be disabled for it unless you need the special sensors functionality it provides.
@gvs @cliffwade Apps built to use Google Play include Google Play code, which runs with their own level of access within the standard app sandbox. This is true regardless of whether you have Google Play installed or not. It applies whether you use heavily privileged and deeply integrated standard Google Play, our sandboxed Google Play, microG or have nothing. Installing sandboxed Google Play does not provide any additional access or capabilities. Everything it can do can be done without it.

@gvs @cliffwade Since GrapheneOS significantly improves the app sandbox and permission model, using apps depending on Google Play on GrapheneOS via sandboxed Google Play gives significantly less access to those apps and to Google Play than it does on an OS using microG. Google Play has strictly more access to your data elsewhere, since more access is allowed for each app including the Google Play code running as part of the app.

See https://firebase.google.com/docs/android/android-play-services for some clear examples of this.

Dependencies of Firebase Android SDKs on Google Play services  |  Firebase for Android

Firebase
@gvs @cliffwade Most of these libraries work whether or not Play is installed. Some work better with it installed, and some don't work without it. However, 100% of functionality could work without Google Play installed if they chose to make the libraries larger and added fallback approaches such as each app maintaining their own FCM connection via foreground service and battery optimization exception when Play services is missing. They can do everything sandboxed Google Play can do without it.
@gvs @cliffwade Does this make sense? Our sandboxed Google Play compatibility teaches Google Play how to function within the regular app sandbox without any special privileges. For example, it uses a foreground service to keep it alive and requests a battery optimization exception. It reimplements dynamite modules via intent file descriptor passing instead of requiring substantial SELinux MAC and MLS sandbox bypasses. It reimplements install/update/uninstall via standard user consent approach.

@gvs @cliffwade There is nothing that we do in the compatibility layer which could not be done by the Google Play libraries used by apps without sandboxed Google Play.

Google Play itself could add official support for functioning without the usual massive amount of integration, privileged permissions, special SELinux MAC/MLS policies, etc. Our compatibility layer exists to provide support for this since they haven't done it. If they did it, we wouldn't need the compatibility layer anymore.