We were pulled into this conversation by people who were attacking GrapheneOS. We didn't want to participate in this conversation. GrapheneOS doesn't recommend or support microG. The topic of this entire post has nothing to do with us.
Look at ForHackernews' comments and you'll understand why we counter them.
What's toxic about responding to people attacking GrapheneOS?
For this specific comment in question, this is easily falsifiable: the top-level-comment was about signature spoofing, there was no mention of Graphene at all.
> What's toxic about responding to people attacking GrapheneOS?
You're making my point for me. Which, to be clear, I find sad because I want GrapheneOS to succeed, but that's really hindered by this behaviour.
Our responses throughout this thread are due to inaccurate attacks on the GrapheneOS project including the ones you've made. microG developers and the corporations funding it have a long history of misleading people about GrapheneOS and engaging in harassment towards our team. Their supporters have regularly engaged in harassment including attempts at physically harming our team members with swatting attacks. The CEO of one of the main companies funding and supporting microG has directly participated in harassment and linked to content on harassment sites. The lead developer of the project has participated in spreading fabrications about us and personal attacks on us. That's what is toxic, and your comments lying about us are toxic too.
No one "attacked" you about anything. I observed that you don't recommend MicroG (the topic of this thread) and noted that you discourage people from rooting their devices and suggest installing proprietary GApps instead of libre software like MicroG.
Why do you consider it an attack to accurately summarize your own opinions?
You're not accurately summarizing what we've said. You're attacking the GrapheneOS project with misrepresentations, misleading claims and outright falsehoods throughout this thread as you've done many times before. You've once again done so in your latest comment we're responding to right now. Most of the claims you've made throughout this thread have been debunked. Responding to those with accurate information is not aggression or toxicity. We're addressing inaccurate claims about GrapheneOS on this platform and will also post a long form response elsewhere.
Ok, I guess I misunderstood and you do recommend microG and endorse users having root access to their own devices, then?
Users having that access is not the same as the OS using that access for more than the bare minimum components and even giving it to apps based on a request prompt. Users need beyond that level of access to install GrapheneOS. It does not mean we think a production device should run a bunch of the OS as root and make it available to applications. GrapheneOS already has hardware-based virtualization where users have a development environment with root access without compromising the overall OS security for it. Running a bunch of different virtual machines is the right way to approach most of those things such as running agents locally for development without trusting them with direct access to anything.
Contrary to how you're portraying it, our own compatibility layer is fully open source software. microG exists to provide compatibility with apps using closed source Google libraries. Our compatibility layer exists to provide compatibility with closed source Google apps and apps using closed source Google code. Both are open source projects. Neither would have any significant real world use if apps weren't using Google's closed source libraries. We already have standalone network-based location, geocoding and other features. Those do not require compatibility with Google Play APIs and we disagree with it being strongly tied together.
GrapheneOS provides both standalone reimplementations of Google service features not tied to their closed source apps and libraries along with a compatibility layer for their closed source apps and libraries. All of our code for all of this is open source. microG is not an open source alternative to what we've built and are in the process of expanding ourselves. Both are open source and it's wrong to keep misleading people about what we provide and are building.
This is pointless, we're going in circles and you're just restating your views in a way that's unresponsive to my point.
1) a user having root inside a VM is not the same thing as having root and I suspect you well know that.
2) No one is claiming microG is an alternative to your sandbox - it's an alternative to the GApps you suggest people install into your sandbox. Again, you clearly know this.
GrapheneOS users have the ability to get root on their devices. GrapheneOS users are choosing to use an OS not expanding the trusted computing base to a massive portion of the userbase OS. Userdebug builds of GrapheneOS have user accessible root but not root access which can be requested by applications. The regular production builds limit root access to a minimal set of process still contained with SELinux policy to the extent they can be. Choosing to use an OS focused on privacy and security without root access for more than the bare minimum portion of the OS is not the user lacking control over their device.
GrapheneOS reimplements a growing portion of the services normally provided by Google Play services including network location and geocoding. It does this without having Google services built into the base OS with privileged access as /e/ does with microG. It doesn't strongly tie those services to Google Play services APIs as microG does.
GrapheneOS has a reimplementation of Google APIs including the location APIs and will be greatly expanding that over time. The existing implementations avoid the pitfalls of how this is approached in microG. We'll be continuing to expand this as the project scales up and it will become increasingly capable of running apps depending on Google Play APIs without without ever installing any Google apps.
Our Google Play compatibility layer is not a special sandbox for running Google Play. It's a compatibility layer to enable apps to run without privileged Google integration into the OS. It enables both Google apps and those depending on them to run. Over time, it will be expanding how much of the APIs are reimplemented by us to enable using more apps without Google Play than it currently does.
GrapheneOS doesn't recommend installing Google Play as you keep claiming. /e/ makes many connections to Google servers by default and gives highly privileged access to the implementation of those services (microG). microG on /e/ downloads Google executables (droidguard) by default and runs those with privileged access. GrapheneOS never gives that kind of highly privileged access and data to Google apps.
Our approach to reimplementing their APIs redirects them to other implementations from within the app using it instead of having a new highly privileged component sharing data across apps and having to enforce a permission model for them. Our Google Play location service reimplementation doesn't have to perform any permission checks itself since it just has apps query the OS location APIs including the OS network location provider when available. Those are standard AOSP APIs and we implement the Google Play APIs locally inside of the app using it on top of those.
> GrapheneOS doesn't recommend installing Google Play
https://grapheneos.org/usage#sandboxed-google-play
¯\_(ツ)_/¯
This is not a recommendation to install Google Play. You're doubling down on misrepresentations and outright fabrications.
I think that you should make this more clear on the linked page that you do not endorse Google Play and warn against its use in general.
It exists for whom wants it and is a recommended app source, that's all. Something not recommended would not be explicitly supported, deciding whether to use it or not is ultimately on the user who will not be warned against something that is supported...
It is not recommended over vastly more sane alternatives like Accrescent and getting apps directly from their respective developers (as signed by them) given you have an update mechanism of your own (or the app embeds one) and a manner of verifying the app's public signing key's provenance as something actually belonging to the developers you got said app from (where the former is a proper app store in construction and the latter is nigh impossible to perform cleanly due to typical developer non-cooperation). Nonetheless, Play Store ranks below these two for a third-party app source as it engages in weird practices like Play App Signing, etc. Users are not advised to get Play Store apps from non-Play Store app sources because Play Store already ranks the furthest behind, meaning nothing is recommended beyond it.
Aurora Store is recommendable in exceptional cases, namely when an app can't be downloaded from Google Play due to Play Integrity gating on the app's store listing, but which is known to work (eg. not perform Play Integrity checks itself in the intended manner, etc) after somehow downloaded and installed.
Although as you can verify, this recommended app source ladder is pushed on social media and official chat platform community spaces of GrapheneOS, not the website.