Software doesn't stop being open source because the releases are signed to be able to verify those. Any OS can be installed on the supported device. The verified boot key hash shown at boot will be different for an unofficial build and so will a query to the hardware asking it to provide it. Auditor and AttestationServer are open source. Those work fine with unofficial builds and forks of GrapheneOS after making builds of those with the correct key.
It's ludicrous to claim software with signed releases isn't open source. Having private keys used to generate the signatures for APKs, updates and the vbmeta image doesn't somehow make it not open source. Every APK is signed and the software isn't somehow not open source because the signature requires the private keys. There are standard tools to compare APKs with different signing keys to ensure the build is reproducible and the same thing exists for the OS as a whole which contains many signed APKs and a signed vbmeta image with verified boot metadata.
The signatures enable the update client to verify the releases and the firmware to verify the OS with the public key flashed by the user as part of installing the OS. Signed updates and verified boot fully work with any build of GrapheneOS following our build instructions. Auditor and AttestationServer also work once they're rebuilt with the new verified boot hash included.
GrapheneOS is only 100% open source if you do not count a giant pile of proprietary and privileged binary blobs required for it to function on any supported hardware.
This is not the fault of the Graphene team so much as a fundamental problem in the mobile chipset market.
Desktop/Laptop CPUs give you dramatically more control, especially with OpenSIL etc.
There are simply are no sovereign software solutions for modern mobile hardware.
> The need for proprietary code for firmware and hardware is the same on desktop.
The Linux distro I founded has zero blobs. Built completely from source and boots and runs on real laptops and desktops. That is what 100% open source looks like. Meanwhile every Android distro requires a vendor partition with dozens of black box blobs.
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.
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.
The record shows you began this interaction with personal attacks, false accusations and fabrications in response to substance. You made clear references to harassment content which you're well aware exists. The toxicity you've display isn't permitted towards anyone in our community and you're not welcome to participate in it or contact us again.
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.
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.
Post hoc nonsense, your position is that because GrapheneOS, its users and community understand the issue and explain it on an objective basis this results in your subjective view of the community being toxic because you don't like the answer and it's delivery.
None of your points above have any relation to each other nor does one explain another.
You concocted a weak argument to justify ad hominem and say 'community toxic'.
Well done in providing an example of vapid demogoguery.
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.
Sandboxed google play can only send the location to google if google services or playstore were granted the location permission. Accessing location for apps, including google, cannot be sidestepped as MicroG once allowed.
GrapheneOS lets you change aspects of location, including PSDS, SUPL, and network location. GrapheneOS also reroutes googlefusedlocation requests to the OS. If you would rather be able to turn it off entirely, GrapheneOS is is capable of this, not MicroG.
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"?
"Google bad" is THE compelling argument to flash a custom ROM. Many projects like CalyxOS go privacy first, security second.
I am not worried about a random third worlder hacking my phone. This would only be possible if I allow it by user mistake. I am however worried about Google and its business model. As are many others.
MicroG is great because it limits Google's tracking as much as possible. It's lication services can be routed to a more trustworthy party, and you can actually select which APIs microG forwards to Google. Sandboxed Play Services don't allow any of this, and it's bloated and battery hungry in comparison.
CalyxOS doesn't preserve the standard privacy of the Android Open Source Project. It certainly doesn't greatly improve it as GrapheneOS does. CalyxOS consistently goes many months without shipping standard Android privacy and security patches. It doesn't provide highly important improvements to privacy such as Contact Scopes, Storage Scopes, secure paste, fixes for Android's VPN leaks and many other privacy patches/protections provided by GrapheneOS. Lagging far behind on standard privacy patches and protections is a major issue and it's even more of an issue when the very poor security is considered. Privacy depends on security, not only privacy patches, privacy protections and which services are used.
Unlike GrapheneOS, CalyxOS comes with a bunch of connections to Google services and privileged integration of those services into the OS. It automatically grants highly privileged access and data to multiple Google apps when installed including Android Auto. It also has a bunch of other problematic third party connections. GrapheneOS avoids bundling third party apps and services not meeting our privacy standards.
microG and sandboxed Google Play don't compare the way you claim when it comes to privacy or battery life at all. GrapheneOS also does replace Google Play APIs including the location API with our location rerouting feature. Unlike the microG implementation, it avoids introducing major privacy issues including microG having a history of leaking location data to apps which aren't granted access to it.
GrapheneOS also doesn't come with sandboxed Google Play included and works very well without it. We implement network location, geocoding and other features without tying those to compatibility with Google APIs. We'll also continue to expand compatibility with apps depending on Google APIs without sandboxed Google Play as part of improving the sandboxed Google Play compatibility layer. It isn't only for running Google apps as regular sandboxed apps. It's also for replacing parts of the Google APIs for apps using the Google Play libraries.
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.
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.
You very actively seek out discussions about GrapheneOS where you make inaccurate claims about both GrapheneOS and our team. You frequently use it as an opportunity to heavily promote products which are the direct opposite of privacy and security hardened devices. Those products are heavily promoted by those companies with false marketing and misinformation.
Immense harm has been caused through the misconceptions the companies behind those products have propagated to make money. It harms actual privacy, security and open hardware efforts. We aren't on the same side as those companies and aren't working towards the same things. We aren't going to agree on that unless you eventually end up moving on to promoting different products without those issues.
We're on the same side as several legitimate projects you promote including QubesOS. However, you promote those as part of attacking GrapheneOS and usually group it together with phony privacy products.
reply