MicroG: Free-libre re-implementation of Google's proprietary Android user space (github.com)

microG uses many of the same closed source Google services, downloads and runs closed source Google Play binaries with Google access and exists to provide compatibility with closed source Google libraries used by apps. Using microG doesn't change that you're using closed source Google code on the client side and also on the server side for many of the services. It also still uses closed source Google Play code itself, including downloading and running droidguard which is highly obfuscated and dynamically changes on a regular basis. That code gets access to all the permissions and privileged access being given to microG including the Location permission and all the special privileged app access which is doesn't get when a user installs sandboxed Google Play on GrapheneOS.

microG has a poor privacy and security track record. They've repeatedly had severe privacy and security issues which are publicly discovered and then go unfixed for years. One of those which involved leaking location data to apps which weren't supposed to have access to it was documented on their wiki but yet not addressed for years. There are still privacy holes in the location implementation, although the most severe issue was fixed.

GrapheneOS does provide open source reimplementations of Google Play APIs including location. It provides those as OS libraries running in the apps using them instead of an extra service. That means location data access is restricted by the standard sandbox and permission model rather than needing to reimplement it in a service. Reimplementing it in a service means mistakes or failure to keep up with the modern permission model can create privacy holes, which has happened with the microG location service repeatedly and taken years to address.

GrapheneOS will have extreme difficulty being taken seriously while they are "you need to buy Google hardware to run this" project. This is why GrapheneOS has a tiny userbase.

If it was privacy first it would ship with microG by default.

That's very false. GrapheneOS is a better choice for deGoogling than alternatives.

Sandboxed Google Play isn't installed by default, so our users don't have to use it if they don't want to.

Sandboxed Google Play doesn't have privileged permissions and has no more permissions than other user-installed apps. This means that they have the same restrictions as other user-installed apps.

MicroG is a sloppy and ineffective reimplementation of google services that does not meet GrapheneOSs privacy, security, and usability requirements. MicroG does not make you degoogled and is not a compromise between being degoogled and making apps work. GrapheneOS, with or without google services, has far better app compatibility.

If you need a functional smartphone that runs the apps you need while reducing exposure to google, GrapheneOS is the best option for that by far.

> I don't understand how you're gaining any privacy as a practical matter.

Exactly.

Being too focused on "Google bad" means you're not seeing the bigger picture. microG is only a thing to provide app compatibility for apps that rely on Google Play Services. Which apps do you think do that? Apps with Google libraries that often have fallback implementations and can operate without Google Play Services.

So, given those facts, if someone has microG installed, Google still effectively has the same access as a device with Sandboxed Google Play, except microG users are stuck with worse app compatibility and because of signature spoofing it's less secure and code runs in that privileged context.

GrapheneOS focuses on privacy, security, and app compatibility. microG fails at security and app compatibility. Also, there are apparently leaks (that I admit I don't know the details of) regarding location that make it worse for privacy too. There could be more leaks that I don't know about.

microG still heavily uses closed source Google services and even downloads executables run with the full privileges of microG. It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.

Each app using Google Play still has the closed source Google Play SDK and libraries built into it in practice. It's extraordinarily rare to replace those libraries with the incomplete and buggy reimplementations from microG. Very close to zero otherwise open source apps are using those. The closed source Google Play SDK and libraries are therefore still part of the loop and have access to what the app can access. Many of the code paths in the Google libraries directly use Google services without requiring Play services including the full versions of the Ads and Analytics libraries.

The vast majority of data obtained by Play services is via the OS integration and permissions. Apps using it for push messaging, logging into accounts and many other features will send the same data to Google services regardless of whether you use it via sandboxed Google Play or microG.

GrapheneOS stubs out and reimplements APIs on the client side. That includes providing a complete implementation of the Google Play services location API not using on Google Play. These features are being expanded over time. They'll also be made available without having Google Play.

The GrapheneOS approach avoids giving an additional global service access to sensitive data from the OS and apps. microG has repeatedly had vulnerabilities leaking sensitive data to apps including location data. The approach of having an extra service sitting between apps and the OS which handles sensitive data means having to add all the same privacy and security checks as Play services which microG doesn't do in practice and it has caused severe privacy leaks. The main location leakage was eventually fixed but it persisted for years and there are still holes in the location service causing privacy issues.

Unlike microG, sandboxed Google Play doesn't get privileged access. That includes the executables (droidguard) downloaded by microG not getting privileged access. GrapheneOS also doesn't give privileged access to other apps such as Android Auto when those are installed as all the main operating systems using microG are doing. That privileged access gives access to highly sensitive data and doesn't require apps explicitly sending data to Google services, which will nearly all still go to Google services with a partial replacement of the middleware on the device.

The apps that use Google analytics/ads don't need Google Services on the device. The libraries are embedded into the app, and have just as much fingerprinting capabilities as sandboxes Google services.

They'll just flag you for asking.

I started to try to answer your question, but I found that the GrapheneOS account gave an answer. Here are quotes:

> microG still heavily uses closed source Google services and even downloads executables run with the full privileges of microG. It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.

> microG has repeatedly had vulnerabilities leaking sensitive data to apps including location data. The approach of having an extra service sitting between apps and the OS which handles sensitive data means having to add all the same privacy and security checks as Play services which microG doesn't do in practice and it has caused severe privacy leaks. The main location leakage was eventually fixed but it persisted for years and there are still holes in the location service causing privacy issues.

I also regularly try to explain to people why microG doesn't make sense. It's more of a big picture thing so it's hard to explain briefly. Consider why people would even install microG. It's only helpful for people who have apps that rely on Google Play Services. Those libraries can have fallback implementations and run even without Google Play Services or microG

Sandboxed Google Play is installed as a regular app. It has the same restrictions as other user-installed apps. If apps have Google libraries that don't need Google Play Services or microG are installed with regular apps, they effectively have the same access as Sandboxed Google Play. If those same apps are installed on a device with microG, Google effectively has the same access, big picture.

GrapheneOS's priorities are privacy, security, and app compatibility. There are issues with microG as far as privacy goes, as already noted. It requires privileged permissions to even work properly, and even microG admits that its reimplementations of Google Play Services features are incomplete, so it's worse in terms of app compatibility too.

There is a huge list of issues with /e/OS. Let me just give you a few examples:

Android 17 introduced a local network permission. GrapheneOS ported to Android 17 months ago. LineageOS, which /e/OS is based on just recently started releasing Android 17 updates. /e/OS may not be on Android 17 yet, I haven't checked. So, imagine for months apps have had access to the local network. What can they do with that?

That's just one example of how being far behind on updates can affect privacy.

/e/OS is far less deGoogled than GrapheneOS.

/e/OS lacks features like Storage Scopes, Contacts Scopes, Secure Paste, and sensors permission.

GrapheneOS is a privacy project and heavily improves it with important privacy protections including Contact Scopes, Storage Scopes, secure paste and much more. It preserves all of the standard privacy and security of AOSP while greatly improving upon both. It has major improvements to both privacy and security, but it's also starting from the point of the standard privacy and security being intact.

GrapheneOS doesn't connect to Google servers by default and avoids integrating any privileged access for either Google apps or partial replacements for those. The main operating systems integrating microG included always granted privileged access for microG, Google Play executables downloaded by microG (droidguard) which run with the privileged access it's granted and other Google apps including Android Auto.

https://grapheneos.org/features

/e/ greatly reduces both privacy and security compared to AOSP through not keeping up with standard patches, not providing important standard privacy/security protections and adding problematic services. It lags behind incomplete backports to older releases by many weeks or even months while not fully providing all the patches. They set an inaccurate Android security patch level across devices so users believe they have a lot of patches they don't. Users are also led to believe those are all the Android privacy/security patches when it's a minority of the overall patches due to most not being backported. Firmware, driver and kernel updates are largely not provided by /e/ even when those are available from the vendors including for Pixels. Those have extreme delays when they are provided, often being years behind for Pixels.

/e/ also doesn't keep all of the standard security model intact due to the changes made by LineageOS and /e/.

/e/ also adds a bunch of privacy invasive services along with rolling back privacy and security in many other ways.

https://discuss.grapheneos.org/d/24134-devices-lacking-stand...