Hacker News

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!

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.

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 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'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.

Okay, so lemme break this down real simple

(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.

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.

de-Googleling is unfortunately not a priority for GrapheneOS.

GrapheneOS is incredibly focused on security. Privacy is clearly a second thought to them.

They could also have it decoupled from the OS with an open-source version, these are two different subjects.

The real reason to me is that they want to avoid Android forks outside of their control.

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.

Ah no! Oh well.

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.

https://clubic.com/actualite-604786-murena-e-os-interview.ht...

https://grapheneos.social/@GrapheneOS/116353973732143171