Graphene generally seems to feel that running official signed Google adware is more secure than using open source alternatives that might require signature spoofing or having root on your own device.
Also, for some reason some people think that microG means deGoogling. That's not at all the case. microG still communicates with Google servers.
microG doesn't meet the project's requirements. If you look at the big picture, microG offers worse app compatibility and is less secure. The cons outweigh the pros by a lot. "Google bad" isn't an argument that works for us. App compatibility is very important.
At the end of the day, I need a functional smartphone that can run the apps needed for daily life. MicroG offers that while reducing my exposure to Google.
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.
This isn't meaningful when the other user-installed apps are calling Google Play Services in the same sandbox.
GrapheneOS gives drastically less access to closed source Google Play code including the SDK, libraries and droidguard than the microG approach on /e/. It's strictly less, not more in any way. GrapheneOS does not allow it to access anything not already accessible to the SDK and libraries in the apps using those.
This Google service functionality also doesn't come as part of GrapheneOS. GrapheneOS has network location, geocoding and other functionality included in the OS via standalone implementations not tied to Google service compatibility as they are with microG.
GrapheneOS does reimplement the Google Play location service, but it does so inside of apps using it as a library to avoid needing a new service with location access and other privileges. It uses the OS network location when enabled but the OS network location is entirely independent from it.
---
App & mini Google Play Services = access is restricted, like other regular apps.
App & mini Google Play Services + Sandboxed Google Play (unprivileged) = virtually the same access as above
App & mini Google Play Services + microG (privileged) = Google has the same access as the situations above, but with worse app compatibility, worse security (especially because of privileged access), and worse privacy (leaks).
---
You're worried about apps without special permissions to anything sharing usage data that they have access to anyway while ignoring the huge problems with microG just because "Google bad". That's hardly a sane approach to privacy.
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.
To take some examples, MicroG stubs out the analytics and ads APIs. Your "sandboxed" Play would send that data to the mothership and return with ads.
https://github.com/microg/GmsCore/wiki/Implementation-Status
https://github.com/microg/GmsCore/blob/32bc8954ff872d0e1a05d...
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.
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.
That sounds like you are exactly rebuilding microG. To me, this is an endorsement of their approach not a rejection of it. If you don't like their implementations, it would be more public spirited to contribute patches, but it's your project.
One of the main companies behind microG providing most of their funding (Murena) has repeatedly falsely claimed GrapheneOS is mainly used by criminals and heavily pushed talking points claiming more private/secure devices mainly benefit criminals and pedophiles. These are 2 of many examples and are the tip of the iceberg:
https://www.clubic.com/actualite-604786-murena-e-os-intervie...
https://grapheneos.social/@GrapheneOS/116353973732143171
It's very strange to claim we aren't being community minded when considering the context of their years of effort to mislead people about GrapheneOS and harm our team. The microG project and several of the organizations backing it have spent years misleading people about GrapheneOS by falsely claiming it isn't a privacy project and misrepresenting what we provide. Many of their supporters do the same, including throughout posts on this site.
Those operating systems and phone products heavily mislead users about what they provide in their products and get people using devices with atrocious privacy and security due to lack of bare minimum privacy/security patches and protections. We see that as directly opposed to our efforts of improving mobile privacy and security. They're directing people away from reasonably private and secure devices such as an to devices not even getting the increasingly inadequate standard Android privacy/security patches for months or even years at a time.
Leaving aside the emotional folderol, "rebuilding the Google Mobile Services functionality" is exactly what MicroG does. You are both offering stub reimplementations of GmsCore as system apps. AFAIK, microG is essentially a one-man project initially funded by a grant from the German government[0] and it predates /e/OS by several years.
GrapheneOS's approach is far different from microG's. It's not about rebuilding everything from scratch, it's about making Google Play Services behave as a non-privileged app.
microG isn't a one person project and has been largely funded by Murena, Calyx and FUTO. The government funding they get is mainly through Murena. The one person you're talking about working on microG has directly participated in attacks on GrapheneOS with false claims about it and our team, but most of it has come from the organizations funding it and paying people to work on it. Each of those 3 listed organizations has engaged in a massive amount of attacks on the GrapheneOS project including harassment. We haven't ever engaged in that towards any of them. You can see numerous cases throughout this thread of unprovoked personal attacks on our team and lies about us as individuals. It is not something both sides are doing as we haven't done it.
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.
We get it. Your behavior makes reading the posts hard for no reason.
This is not Facebook, people take time to read here.
> many privacy and security issues
> leaking location to apps that dont have the location permission.
Could you share some details on these three points?
> 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.
Wow, no kidding! I checked the source code and sure enough, it downloads the DroidGuard APK from Google[0], and loads a class from it[1], (seemingly?) without any kind of sandboxing or separation. I believe I'm safe because I don't have the Play Integrity API enabled, but I really wish the UI was more explicit about this, because the info text only says
> microG GmsCore contains a free implementation of SafetyNet, but the official server requires SafetyNet requests to be signed using the proprietary DroidGuard system.
[0]: https://github.com/microg/GmsCore/blob/32bc8954ff872d0e1a05d...
[1]: https://github.com/microg/GmsCore/blob/32bc8954ff872d0e1a05d...
(Correction from prior statement)
GmsCompat is a layer that runs the official google play services and store in the app sandbox which also strips it of all privileges and teaches it to function with only the bare minimum.
The app itself is sandboxed
But it is taught to run without the app panicking
The app sandbox is an OS feature: https://source.android.com/docs/security/app-sandbox.
Sandboxed Google Play is never preinstalled, so people who wish to deGoogle can do so. And I'm sure GrapheneOS users who don't want to use Google devices will be happy to get a supported Motorola in the future.
Sandboxed Google Play has no privileged permissions, which means that those apps have the same permissions as any other apps you can install on Android, meaning the same restrictions.
All that plus the fact that Sandboxed Google Play is a better approach because it offers better app compatibility and is more secure. microG doesn't meet the project's standards.
Also, GrapheneOS has plenty of users, and we're growing fast. People appreciate quality.
GrapheneOS is not going to compromise on privacy or security, and so far, pixel devices are the only devices meeting the hardware security requirements. People have not had an issue taking that seriously.
That would be an extreme reduction in privacy, not an improvement.
GrapheneOS lets you change aspects of location, including PSDS, SUPL, and network location. GrapheneOS also reroutes googlefusedlocation requests to the OS. If you would rather be able to turn it off entirely, GrapheneOS is is capable of this, not MicroG.
GrapheneOS doesn't have such a narrow focus. As we keep saying, GrapheneOS prioritizes privacy, security, and Android app compatibility. Given those three things:
Privacy: microG's leaks and failure to implement other checks and there's arguably no real gain in privacy since the Sandboxed Google Play approach means Google Play Services and Store don't have privileged permissions.
Security: microG needs privileged permissions to work properly and can also download Google binaries and runs them in that privileged context, depending on settings
App compatibility: It's an incomplete reimplementation. Even microG's GitHub says as much.
Why would GrapheneOS take so many steps back just because the only real compelling argument in favor of microG is "Google bad"?
I am not worried about a random third worlder hacking my phone. This would only be possible if I allow it by user mistake. I am however worried about Google and its business model. As are many others.
MicroG is great because it limits Google's tracking as much as possible. It's lication services can be routed to a more trustworthy party, and you can actually select which APIs microG forwards to Google. Sandboxed Play Services don't allow any of this, and it's bloated and battery hungry in comparison.
Case closed.
Unlike GrapheneOS, CalyxOS comes with a bunch of connections to Google services and privileged integration of those services into the OS. It automatically grants highly privileged access and data to multiple Google apps when installed including Android Auto. It also has a bunch of other problematic third party connections. GrapheneOS avoids bundling third party apps and services not meeting our privacy standards.
microG and sandboxed Google Play don't compare the way you claim when it comes to privacy or battery life at all. GrapheneOS also does replace Google Play APIs including the location API with our location rerouting feature. Unlike the microG implementation, it avoids introducing major privacy issues including microG having a history of leaking location data to apps which aren't granted access to it.
GrapheneOS also doesn't come with sandboxed Google Play included and works very well without it. We implement network location, geocoding and other features without tying those to compatibility with Google APIs. We'll also continue to expand compatibility with apps depending on Google APIs without sandboxed Google Play as part of improving the sandboxed Google Play compatibility layer. It isn't only for running Google apps as regular sandboxed apps. It's also for replacing parts of the Google APIs for apps using the Google Play libraries.
GrapheneOS is more deGoogled than alternatives, so if you're thinking privacy = deGoogling, then GrapheneOS is a good option.
But you seem to be under the impression that microG improves privacy. That's not the case when you look at the big picture. Consider why people need microG in the first place. It's basically there to pretend to be Google Play Services for apps that rely on Google Play Services. Which apps are those? Apps with Google libraries in them.
So, pretend apps with Google libraries are an "app & mini Google Play Services", and the breakdown is like this:
---
App & mini Google Play Services = access is restricted, like other regular apps.
App & mini Google Play Services + Sandboxed Google Play (unprivileged) = virtually the same access as above
App & mini Google Play Services + microG (privileged) = Google has the same access as the situations above, but with worse app compatibility, worse security (especially because of privileged access), and worse privacy (leaks).
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.
The operating systems you believe are privacy projects greatly reduce 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.
Lagging behind the already inadequate standard privacy/security updates by months and even years isn't compatible with providing reasonable protection for user privacy. Only a subset of the issues Google classifies as High or Critical severity are backported to the older releases of Android those are usually based on. Taking many months to move to newer releases is much more problematic than it appears. The backports to those older releases also get applied with a substantial delay. Firmware and drivers are usually not kept properly updated even when those are regularly released such as for Pixels. Many standard privacy and security protections are missing or disabled. An assorted of third party services are added too.