I have never understood why people using MicroG can use apps like SNCF-Connect, while I cannot.
SNCF-connect is the largest online marchant in France. Since june, I cannot click the "pay" button anymore. It coincides with the new feature of Pay with Google.
So : is it because MicroG allows calls to Google services on e/OS devices, while my LineageOS refuses ? Or because MicroG implemented a try catch around this call, without any call to Google's servers ?
If it connects to Play Store, then isn't that the same as Aurora? Can people's accounts be banned? That would really suck to pay for something and lose it because Google banned you haha!
It really sucks but there is no other widely supported standard for in-app purchases. Some services refuse to use credit/debit cards payments for some reason.
Some Play Services calls are stubbed out as no-ops and others are reimplemented either with fully free replacements (e.g. navigation) or else by calling proprietary Google remote endpoints (e.g. firebase)
This is why I always think emperor git wears no clothes. Hiding these kind of intermediate junk commits from history should not require rewriting and breaking the distributed history you all share. imho the correct solution would be a tag-like layer for annotating existing commits with metadata (additional signatures, hide-flags, retroactive comments, etc) or just a full 2nd dag, but whatever: git sucks at annotating history and annotating history is a core workflow in git.
The proper solution is that your merge commit should describe exactly what was merged and why. Git pre-fills it with a default "Merge branch-X into branch-Y" message so you can quickly exit the editor and still have a functioning DAG. It's just not ideal to leave it like that, precisely for this reason.
Fossil (https://fossil-scm.org/home/doc/trunk/www/index.wiki) doesn't fill out a default message, and sometimes that has annoyed me, but it does make you think about what you're doing. If you look in the Fossil and SQLite trees, almost all merges include a full description of what the merge was all about and why. Fossil also doesn't forget the entire history of the branch (including from which commit it was branched from), so it has that advantage too.
It's too bad you have to rely on signature spoofing to be able to use this as an alternative (but obviously I understand why). The spoofing looks narrowly scoped on LineageOS, but in general I imagine it creates some risk.
Why can't they signature spoof for those fundamental apps and prevent installing or uninstalling them, similar to how you can't uninstall google stuff on stock android?
Signature spoofing violates the android security model. It means giving privileged access to microG, which means giving privileged access to google. For a privacy project, granting 3rd parties privileged access is unacceptable.
MicroG isn't a 3rd party: it's auditable FLOSS code running on my own device. If you consider microG unacceptable you should never "apt install" anything.
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 does provide open source reimplementations
The sad thing about GOS is that, despite whatever technical merits it may actually claim, the sheer toxicity of its community is enough to drive many interested users as far away as possible.
Case in point: this very comment by "grapheneos" predictably lambasting MicroG in great detail and then - without a hint of irony - giving GOS props for doing things the "right" way.
Your message would go so much further if for once you considered how it is being conveyed.
Edit: just came across several other essays-as-a-comment in this thread, further vindicating the sentiment.
GrapheneOS project members and our community posting accurate information in response to inaccurate attacks and our project and team. You're pushing fabricated stories and other falsehoods to mislead people about GrapheneOS and harm it.
Here's one of the main corporations behind microG smearing hardened devices as being for criminals and pedophiles, which they have done repeatedly:
That's only a small portion of it. There's a massive amount of this and much more from microG developers and multiple corporations supporting it including vile personal attacks and spreading of harassment content by the CEO of Murena and many others involved in it.
> You're pushing fabricated stories and other falsehoods to mislead people about GrapheneOS and harm it.
I'm commenting on what I see as a consistent pattern of behaviour. An observation that is only increasingly apparent with every one of these (frankly) unhinged responses. To wit: I observe that you lambaste MicroG before, and here in response you double-down with even harsher rhetoric.
Graphene is highly regarded on the technical merits, with a notable uptick in stories on HN to this effect of late - why would you constantly and unrelentingly sully that like this?
Please do not respond with a list of grievances, re MicroG (or others) - I'd genuinely like a specific response to my very unambiguous and direct question.
You responded to a post with accurate information with inaccurate personal attacks. You didn't have anything of substance so you went with false narratives about our team and community based on years of harassment towards us. There's nothing unhinged about our responses and the false narrative that we're insane, delusional and toxic for defending ourselves with factual information is utter nonsense.
Your posts are misdirection from the substance we provided. Your accusations are cover for your toxicity towards us. It's an attempt to falsely accuse us of engaging in what you're doing because we'll defend ourselves from it. These tactics have been used against us for years and don't work well anymore. Most people can see right through it. Your first post was a personal attack derailing the thread and you've continued down that path.
Given this seems to be going nowhere, I will leave it here and let the record reflect who's conduct was ultimately problematic here. But I do think this level of frantic vitriol coming from yourself and others in the Graphene community is not doing anyone any favours, and hope to see it change some day.
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.
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.
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.
GrapheneOS's approach is Sandboxed Google Play so the apps don't get special permissions. Without privileged access, Google apps get access to nothing more than what other apps can get access to on Android. So, for example, even if a device has microG installed, an app with a Google library would have virtually the same access as if Sandboxed Google Play was installed. And why would anyone need microG if not to provide compatibility for apps that rely on Play Services, aka apps with Google libraries?
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.
"Sandboxed" Google Play still gets everything that the other apps in the same profile offer up to it / to Google. I don't understand how you're gaining any privacy as a practical matter. The issue isn't GApps' privileged access to the system, it's that other apps send your data to Google via Google Play Services.
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.
> 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.
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.
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.
> GrapheneOS stubs out and reimplements APIs on the client side...They'll also be made available without having Google Play.
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.
We're rebuilding the Google Mobile Services functionality with a far different design and much higher standards for privacy, security, robustness and correctness. Our approach enables people to use Google apps as regular sandboxed apps while also working towards replacing those. It provides much broader app compatibility and it has major advantages for privacy and security which you're disregarding.
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:
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.
I don't think Murena should be throwing shade on your project (although the personal hostility seems to go both ways) I would much rather see free/open mobile operating systems collaborating to offer a better experience for users.
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.
The hostility is one-sided. I went back through old posts and found that while people on the GrapheneOS side (before my time) were sharing _objective facts_, and Murena's started responding with personal attacks.
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.
Murena has spent years overly attacking the GrapheneOS project and our team. They've repeatedly falsely claimed that it's not a privacy project, isn't useful to regular people, is primarily used by criminals, is mainly only used by criminals/pedophiles and much more. They've spread massive amount of misinformation about the features, app compatibility and other aspects of what it provides to promote the products they sell. They've made it very clear they're talking about GrapheneOS in most of the posts talking about criminals. We gave clear 2 examples where their claims are much broader due to not specifically naming GrapheneOS because it's harder to dismiss the authoritarian anti-privacy talking points they're pushing when it's an attack on all serious privacy projects. There are more cases where they mention GrapheneOS than where they push those anti-privacy talking points without mentioning it.
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.
MicroG is a good compromise between deGoogling and having things work. GrapheneOS is not.
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.
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.
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.
Those apps still contain the closed source Google Play SDK and libraries with microG including libraries which connect to Google directly. microG still uses most of the same Google services and even downloads closed source Google executables which it runs with all of the permissions and privileged access granted to it. That code runs with access to Location and invasive privileged access to the OS with microG as integrated in the main operating systems using it while on GrapheneOS it doesn't have any of that at all.
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.
You're not seeing the big picture. Imagine every app with a Google library is basically the app & mini Google Play Services.
---
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.
That is the meaning. The point of sandboxed google play is to reduce google services to the same unprivileged access all other apps get on android. Normally, google play is incredibly privileged.
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.
Running google code sandboxed is far more secure than running google code with privileged access. MicroG downloads and runs google code in a privileged context and has had many privacy and security issues like leaking location to apps that dont have the location permission.
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.
> It downloads and runs droidguard with the privileges it has, giving that full access to the privileged access granted to microG.
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.
It runs the Google Play executable code it downloads with the full permissions and privileges available to microG. Since microG is normally integrated with the Location permission along with a bunch of privileged access unavailable to regular apps, that can be accessed by the code it's running. The executable it's downloading is highly obfuscated and regularly changed because it exists to try to detect and defeat tampering via obfuscation and anti-tampering techniques. It heavily uses the privileged access available to it. This is enabled by default on /e/ in addition to the many other Google connections it adds by default both via microG which are not present in AOSP.
By "they" I assume you mean GrapheneOS supporters? I can only speak for myself, but I only flag things when they clearly deserve to be flagged. Fair discussions are important. They help us grow as people and even in our case, GrapheneOS, but we encounter a crazy amount of misinformation here. Some members of our team are also targets for endless harassment. It's so unfortunate that people behave that way. There are also clear sockpuppets attacking GrapheneOS while promoting others. There was a brand new account participating in this thread that was clearly doing that.
Misinformation, harassment, and people who are using unfair methods to win arguments and damage the reputation of others is unacceptable. That's the kind of thing that I flag. What other people do with their permissions is up to them, but I would say that I wouldn't condone people flagging just because they disagree. I'd consider flagging genuine questions to be awful behavior as well.
I ask a lot of questions in the GrapheneOS community, I oppose a lot of opinions that are held there, but I have never been "flagged" for questioning or for debating something. The only time somebody is going to be flagged is if they are being outright disrespectful spreading misinformation or just being a general asshole.
In the GrapheneOS community, "being outright disrespectful spreading misinformation" is pretty much anything that brings solid counter-arguments to Daniel Micay's personal points of view. You probably haven't tried debating some advanced security and privacy topics with them.
As a member of the GrapheneOS team, I can say you're very incorrect.
Within the project, there's a lot of discussion and collaboration. Daniel is the most famous of all of us because he started the project, but we all work together and value each other's opinions. You can see the same in the issue tracker and other places as well. All of us, Daniel included, are happy to consider other ideas or approaches.
Instead of making some broad accusation about someone, you should be more specific. I hope that your bitterness isn't because one of us rejected a feature request or explained why our team implemented something in a specific way that you disagree with.
As a community member I can also attest to this. After I gave Other8026 more details about my app and background I shared on the forum, they restored my thread.
As someone outside of GrapheneOS community and preferring an alternative phone to GOS, I do see flagging and downvoting of my posts on HN. I even stated clearly more than once that I am happy about the GOS development but just prefer something else that you can't get from it.
Nevertheless my (and others') comments are often considered as attacks. Examples of flagged comments:
Other people have noticed that GOS community attacks almost every other alternative, instead of joining forces against Google and co.: https://news.ycombinator.com/item?id=49564756
The GrapheneOS crowd is constantly accusing everyone in attacks and spreading misinformation about their phones (including in this discussion). Simple replies to misunderstandings and links to earlier reply would be much more polite. At the same time, I also see FUD and misinformation about alternative phones from GOS supporters on HN, e.g., https://news.ycombinator.com/item?id=47855369
You do realize that people use the flag feature all the time, right? People have abused the feature to remove our comments in the past too. It's beyond unacceptable to accuse us, without basis, that we're flagging all of your comments.
You are accusing us of "attacking" other groups when we're repeatedly pulled into conversations and we give objective answers and respond to misinformation about GrapheneOS. We have every right to correct misinformation about GrapheneOS. We have every right to defend ourselves against harassment.
Objective facts aren't "attacks." Why are you misrepresenting what we say? Isn't it better if people can make informed decisions?
> It's beyond unacceptable to accuse us, without basis, that we're flagging all of your comments.
You are right that I have no evidence that this group flagged the comments. I just say that I see such pattern in GOS-related discussion. I did not accuse anyone about "all my comments" though. This would indeed be beyond unacceptable.
I am happy to receive objective answers to the misunderstandings. I do have a lot of misunderstandings, too. Replies from the GOS supporters are often helpful. However they often lack some respect to the alternatives. Words like "atrocious security" do not bring us closer.
This is a false narrative. You're engaging in personal attacks based on fabrications. It's a demonstration of why you would have had moderation intervention in the GrapheneOS community.
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.
GrapheneOS doesn't include Google Play (Services) on fresh install, user's explicitly can opt-in. It seems to be the only AOSP based OS that doesn't make any connections to Google by default [1], and is therefore the only true de-googled AOSP OS.
It's not a priority but GrapheneOS does better at deGoogling than other OSes, including adding features to the OS so people have fewer reasons to install Sandboxed Google Play. One big example is Network Location, so now users don't have to grant Google Play Services location permissions.
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.
Right. They prefer to spend their time and energy proactively reacting to and debating every comment that mentions GrapheneOS on socials instead of focusing on real issues.
The point of GrapheneOS is privacy, period, not something as narrow as simply deGoogling.
GrapheneOS isn't a single person. One or two of us responding to misinformation on socials doesn't mean work isn't getting done. Unfortunately there are people who spend a lot of their own time making new accounts and attacking GrapheneOS instead of doing something more productive with their own time.
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.
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.
That's very false. GrapheneOS is primarily a privacy OS that also focuses on security to provide strong privacy.
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.
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.
GrapheneOS has 500000+ users, and that is with only pixels. Maby more are waiting for the compatible Motorola hardware.
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.
Sandboxed Google Play isn't installed by default, so users have a choice if they want to use it or not. Many don't.
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).
No, it would not. That would require expanding trust to a 3rd party, and granting privileged access to software that downloads and runs google code. That software has also had issues such as leaking location to apps that dont have location access.
That would be an extreme reduction in privacy, not an improvement.
They pointed out privacy issues and you're still claiming that GrapheneOS is security first? Location leaks are a privacy issue, for example.
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"?
Note that MindTheGapps is distributed at https://github.com/MindTheGapps/. The dot-com domain looks like unaffiliated SEO squatting and could change download links to malware anytime.
There's also https[//]microg.cc and https[//]microg.net, both masquerading as homepages for MicroG, and Duckduckgo finds several more. I actually reported the latter to Namecheap a year ago, but got no response back.
Is there a good authority to report these to? Clearly registrars aren't interested in taking them down, and they're probably not serving malware right now, but fake download sites for software running with elevated privileges is a security incident waiting to happen.
This about Play Services and not the Play Store. Play Services are a bunch of extra APIs/services that Google does not make available as part of AOSP. The non-nefarious reason is to make it possible to fix bugs and roll out features faster because the OEMs are terrible at rolling out new Android versions. The possible nefarious reason is to make more of Android closed-source.
At any rate, microG is a reimplementation of Play Services.
Telegram is practically a spy app for both Russian and Western agencies now. While Durov tried to claim total neutrality in his interview with Tucker Carlson, his stance completely flipped after France detained him. Telegram is now proactively cooperating with EU and USA agencies and sharing user data, normal chat logs (everything that is not "Secret Chats"), IP addresses and phone numbers with law enforcement.
The founder and leader of /e/ and Murena has repeatedly claimed highly private and secure devices primarily benefit criminals and pedophiles. He has also falsely claimed that GrapheneOS is mainly used by criminals. /e/ and Murena heavily mislead users about what they provide. In reality, they lag incredibly far behind on standard privacy/security patches and protections. They set a fake Android security patch level despite having many patches missing. They even miss a large subset of the AOSP patches. Drivers and firmware are rarely updated and lag far behind the official releases. Linux kernel updates are barely provided.
/e/ adds many privacy invasive services to the OS including tracking users with random identifiers for updates. They sent user speech data to OpenAI for years without obtaining consent beyond it being hidden in a massive terms of service but have finally moved away from doing that in newer versions. They still have a bunch of other privacy invasive services and still add many more Google services compared to AOSP by default along with giving those privileged access. microG on /e/ downloads and runs Google Play executables with highly privileged access by default and they give highly privileged to Android Auto and other components as their way of getting those running.
Like many people, my concern is not the hypothetical possibility of a security threat; it is the completely certainty that my data is being collected and monetized by private entities who have access to it "legitimately" (i.e., the technology is designed from the ground up to transmit it against my will).
So, sincere question - how is GrapheneOS superior to /e/ in protecting personal privacy against large corporations?
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.
The vast, vast, vast majority of Android devices aren't on Android 17 yet. The update has just started rolling out to 2026 flagships from non-google manufacturers.
So, yes, grapheneos piggybacking on google's support for a single device do give them Android 17 faster. But you're saying that as if lineageos, who supports a vast amount of devices, is being lazy/careless with security by pointing to something that only the Pixel has yet (and grapheneos by association).
The post wasn't about LineageOS. LineageOS rolls back privacy and security compared to AOSP in multiple substantial ways but /e/ rolls both back drastically more. /e/ lags far further behind on both major updates and backported patches than LineageOS, lags far behind on browser engine updates, barely updates the Linux kernel, drivers or firmware at all and adds many privacy invasive services itself. /e/ uses far more Google services than AOSP and gives those highly privileged access along with giving privileged access to Google apps.
The vast majority of Android devices have absolutely atrocious security. It's rapidly getting worse due to AI models accelerating vulnerability discovery and exploitation. It's a complete disaster where there are public local exploits for most Android devices available on GitHub and soon it will be remote exploits too.
Most Android devices being quite insecure doesn't justify products which are increasingly unsafe marketed as being private options. Not keeping up with the updates and relying on increasingly incomplete backports of High and Critical severity patches to older releases is one factor among many, not the whole picture at all.
AOSP hasn't had support for Pixels since the release of Android 16. Pixels are in fact much harder to support than many other devices due to needing to keep up with Android updates including the QPR1 and QPR3 updates which are Pixel exclusive and not pushed to AOSP anymore. LineageOS skipped supporting 10th gen Pixels until recently due to this.
GrapheneOS will keep up with Android updates for the upcoming Motorola flagship too and that's starting out on the Linux 6.18 branch. We'll be porting to new Linux kernel LTS branches ourselves soon long before the devices move themselves. We're in the process of moving to Linux 6.18 for Pixels and we'll port all the devices forward to new versions. That's necessary to avoid the ongoing privacy and security disaster caused by the increasingly incomplete backports of Linux kernel patches to the older LTS branches and Android's GKI LTS branches lagging far behind.
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.
/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.
SNCF-connect is the largest online marchant in France. Since june, I cannot click the "pay" button anymore. It coincides with the new feature of Pay with Google.
So : is it because MicroG allows calls to Google services on e/OS devices, while my LineageOS refuses ? Or because MicroG implemented a try catch around this call, without any call to Google's servers ?
[1] https://doc.e.foundation/os/apps/app-lounge/
Fossil (https://fossil-scm.org/home/doc/trunk/www/index.wiki) doesn't fill out a default message, and sometimes that has annoyed me, but it does make you think about what you're doing. If you look in the Fossil and SQLite trees, almost all merges include a full description of what the merge was all about and why. Fossil also doesn't forget the entire history of the branch (including from which commit it was branched from), so it has that advantage too.
These commits match the advisories published 3 weeks ago:
https://github.com/microg/GmsCore/security
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.
The sad thing about GOS is that, despite whatever technical merits it may actually claim, the sheer toxicity of its community is enough to drive many interested users as far away as possible.
Case in point: this very comment by "grapheneos" predictably lambasting MicroG in great detail and then - without a hint of irony - giving GOS props for doing things the "right" way.
Your message would go so much further if for once you considered how it is being conveyed.
Edit: just came across several other essays-as-a-comment in this thread, further vindicating the sentiment.
Here's one of the main corporations behind microG smearing hardened devices as being for criminals and pedophiles, which they have done repeatedly:
https://www.clubic.com/actualite-604786-murena-e-os-intervie...
https://grapheneos.social/@GrapheneOS/116353973732143171
That's only a small portion of it. There's a massive amount of this and much more from microG developers and multiple corporations supporting it including vile personal attacks and spreading of harassment content by the CEO of Murena and many others involved in it.
I'm commenting on what I see as a consistent pattern of behaviour. An observation that is only increasingly apparent with every one of these (frankly) unhinged responses. To wit: I observe that you lambaste MicroG before, and here in response you double-down with even harsher rhetoric.
Graphene is highly regarded on the technical merits, with a notable uptick in stories on HN to this effect of late - why would you constantly and unrelentingly sully that like this?
Please do not respond with a list of grievances, re MicroG (or others) - I'd genuinely like a specific response to my very unambiguous and direct question.
Your posts are misdirection from the substance we provided. Your accusations are cover for your toxicity towards us. It's an attempt to falsely accuse us of engaging in what you're doing because we'll defend ourselves from it. These tactics have been used against us for years and don't work well anymore. Most people can see right through it. Your first post was a personal attack derailing the thread and you've continued down that path.
Look at ForHackernews' comments and you'll understand why we counter them.
What's toxic about responding to people attacking GrapheneOS?
> 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.
Why do you consider it an attack to accurately summarize your own opinions?
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.
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 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.
https://grapheneos.org/usage#sandboxed-google-play
¯\_(ツ)_/¯
https://grapheneos.org/features#sandboxed-google-play
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.
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.
[0] https://www.prototypefund.de/en/projects/microg
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.
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.
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.
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.
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...
https://news.ycombinator.com/item?id=50171175
Misinformation, harassment, and people who are using unfair methods to win arguments and damage the reputation of others is unacceptable. That's the kind of thing that I flag. What other people do with their permissions is up to them, but I would say that I wouldn't condone people flagging just because they disagree. I'd consider flagging genuine questions to be awful behavior as well.
Within the project, there's a lot of discussion and collaboration. Daniel is the most famous of all of us because he started the project, but we all work together and value each other's opinions. You can see the same in the issue tracker and other places as well. All of us, Daniel included, are happy to consider other ideas or approaches.
Instead of making some broad accusation about someone, you should be more specific. I hope that your bitterness isn't because one of us rejected a feature request or explained why our team implemented something in a specific way that you disagree with.
Nevertheless my (and others') comments are often considered as attacks. Examples of flagged comments:
https://news.ycombinator.com/item?id=49565142
https://news.ycombinator.com/item?id=49542065
https://news.ycombinator.com/item?id=49536149
Other people have noticed that GOS community attacks almost every other alternative, instead of joining forces against Google and co.: https://news.ycombinator.com/item?id=49564756
The GrapheneOS crowd is constantly accusing everyone in attacks and spreading misinformation about their phones (including in this discussion). Simple replies to misunderstandings and links to earlier reply would be much more polite. At the same time, I also see FUD and misinformation about alternative phones from GOS supporters on HN, e.g., https://news.ycombinator.com/item?id=47855369
You are accusing us of "attacking" other groups when we're repeatedly pulled into conversations and we give objective answers and respond to misinformation about GrapheneOS. We have every right to correct misinformation about GrapheneOS. We have every right to defend ourselves against harassment.
Objective facts aren't "attacks." Why are you misrepresenting what we say? Isn't it better if people can make informed decisions?
You are right that I have no evidence that this group flagged the comments. I just say that I see such pattern in GOS-related discussion. I did not accuse anyone about "all my comments" though. This would indeed be beyond unacceptable.
I am happy to receive objective answers to the misunderstandings. I do have a lot of misunderstandings, too. Replies from the GOS supporters are often helpful. However they often lack some respect to the alternatives. Words like "atrocious security" do not bring us closer.
(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.
1: https://eylenburg.github.io/android_comparison.htm
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.
GrapheneOS isn't a single person. One or two of us responding to misinformation on socials doesn't mean work isn't getting done. Unfortunately there are people who spend a lot of their own time making new accounts and attacking GrapheneOS instead of doing something more productive with their own time.
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.
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.
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).
That would be an extreme reduction in privacy, not an improvement.
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"?
https://mindthegapps.com/
Is there a good authority to report these to? Clearly registrars aren't interested in taking them down, and they're probably not serving malware right now, but fake download sites for software running with elevated privileges is a security incident waiting to happen.
At any rate, microG is a reimplementation of Play Services.
You can directly download the Telegram APK from: https://telegram.org/android
(Or using the app store that is part of /e/OS and serves as a front for both the Play Store and F-Droid.)
The real reason to me is that they want to avoid Android forks outside of their control.
I mean Google!
Murena also sent data to Open AI, right? Didn't tell their users.
Also mixed up sessions on their service and users got other users' data downloaded on their devices.
We can't trust your judgement.
/e/ adds many privacy invasive services to the OS including tracking users with random identifiers for updates. They sent user speech data to OpenAI for years without obtaining consent beyond it being hidden in a massive terms of service but have finally moved away from doing that in newer versions. They still have a bunch of other privacy invasive services and still add many more Google services compared to AOSP by default along with giving those privileged access. microG on /e/ downloads and runs Google Play executables with highly privileged access by default and they give highly privileged to Android Auto and other components as their way of getting those running.
https://clubic.com/actualite-604786-murena-e-os-interview.ht...
https://grapheneos.social/@GrapheneOS/116353973732143171
So, sincere question - how is GrapheneOS superior to /e/ in protecting personal privacy against large corporations?
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.
So, yes, grapheneos piggybacking on google's support for a single device do give them Android 17 faster. But you're saying that as if lineageos, who supports a vast amount of devices, is being lazy/careless with security by pointing to something that only the Pixel has yet (and grapheneos by association).
The vast majority of Android devices have absolutely atrocious security. It's rapidly getting worse due to AI models accelerating vulnerability discovery and exploitation. It's a complete disaster where there are public local exploits for most Android devices available on GitHub and soon it will be remote exploits too.
Most Android devices being quite insecure doesn't justify products which are increasingly unsafe marketed as being private options. Not keeping up with the updates and relying on increasingly incomplete backports of High and Critical severity patches to older releases is one factor among many, not the whole picture at all.
AOSP hasn't had support for Pixels since the release of Android 16. Pixels are in fact much harder to support than many other devices due to needing to keep up with Android updates including the QPR1 and QPR3 updates which are Pixel exclusive and not pushed to AOSP anymore. LineageOS skipped supporting 10th gen Pixels until recently due to this.
GrapheneOS will keep up with Android updates for the upcoming Motorola flagship too and that's starting out on the Linux 6.18 branch. We'll be porting to new Linux kernel LTS branches ourselves soon long before the devices move themselves. We're in the process of moving to Linux 6.18 for Pixels and we'll port all the devices forward to new versions. That's necessary to avoid the ongoing privacy and security disaster caused by the increasingly incomplete backports of Linux kernel patches to the older LTS branches and Android's GKI LTS branches lagging far behind.
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...
It's better to buy one of these directly and flash a preferred ROM yourself.