[microtonal]

Ehm, microG on /e/OS is talking to Google all the time. They also use proprietary Google blobs for passing basic Play Integrity. /e/OS also gives a bunch of Google apps (including Google Maps and Android Auto) privileged access (you can find the signing key fingerprints in the source code of the /e/OS microG fork).

[bornfreddy]

No Google Maps or Android Auto on my phones, so I don't care much about privileged access - they have none anyway.

No, microG is definitely not talking to Google all the time, NetGuard would warn me if it did. I would assume it is not even running when I disable it (which is easily done, as opposed to stopping Google Services in GrapheneOS) - but to be fair I didn't actually validate that.

I kind of like GrapheneOS otherwise, this is by far my biggest gripe. I can even survive the icons. But avoiding Google (and other big tech) is the reason I am not on a cheaper and more convenient phone with regular Android, so if GrapheneOS refuses to support an alternative to Google Play Services, I'm not too happy about it. If there are real problems with microG then I'm sure the authors would be interested in a better solution too.

[akimbostrawman]

>No Google Maps or Android Auto on my phones, so I don't care much about privileged access - they have none anyway.

You don't seem to understand how play service / MicroG work. Maps or Auto Apps aren't the ones having the privilaged access but Play Service and MicroG.

>NetGuard would warn me if it did. I would assume it is not even running when I disable it

Since play services/microg have higher privileges than NetGuard they could just bypass it.

>But avoiding Google (and other big tech) is the reason I am not on a cheaper and more convenient phone with regular Android, so if GrapheneOS refuses to support an alternative to Google Play Services, I'm not too happy about it. If there are real problems with microG then I'm sure the authors would be interested in a better solution too.

That doesn't make any sense at all. GrapheneOS by default has _0_ Google connections unlike LineageOS, /E/ or any other AOSP fork. MicroG is not an alternative to not using play services at all = actually avoiding Google, but a open source reimplementation that still has all the privacy and security issues of regular play services. GrapheneOS sandboxes Google play services only have the privacy issues since just like with MicroG you still connect to Google = not actually avoiding Google.

The issue with no notification without play services can be easily fixed by not using privacy hostile apps which only work with them.

[bornfreddy]

You are missing the point. MicroG allows me to disable it when I want to, and push notifications still work when I (rarely) need to enable it.

It's not about security, it is about privacy. While MicroG in theory could bypass NetGuard, I very much doubt that anyone would bother. My privacy is not that precious.

But as I said, neither solution is great. How about sandboxing MicroG too?

[akimbostrawman]

There is no privacy advantage by using MicroG compared to Google play services. You still connect to there service all the same giving privileged access to your device. There is a security AND privacy advantage by using sandboxed google play because they limit the kind of system access it has compared to MicroG/play services.

Again the only advantage of MicroG compared to play services is that it's open source, you still have all the same privacy and security issues.

Its already a lot of work to support the official play services and make them work in a sandbox, supporting another layer in between is more headache than its worth it or they have time/money for. Not to mention that sandboxed play services work with much more feature than MicroG such as android auto.

[bornfreddy]

> There is no privacy advantage by using MicroG compared to Google play services. You still connect to there service all the same giving privileged access to your device.

...assuming you are connected all the time, or at least that the services are running all the time. In my case they are not. I only enable them every once in a while, when I need to be alerted of something. This might not be how most people use their phones, but I do it because there is no way to preserve any privacy at all if you are running Google services 24/7 (sandboxed or not).

I see Google services as malicious software - not security malicious (Google can't risk that) but privacy malicious. This is why I care more about ability to turn them on / off than about what kind of access they have. Even inside the sandbox, as regular apps, they have way too much info about me.

As I said: I would prefer sandoxed MicroG, but given the available options non-sandboxed MicroG is preferable to sandboxed always-on Google services.

[microtonal]

No, microG is definitely not talking to Google all the time, NetGuard would warn me if it did.

https://www.kuketz-blog.de/e-datenschutzfreundlich-bedeutet-...

When I tested /e/OS a few months back, I found the same.

(which is easily done, as opposed to stopping Google Services in GrapheneOS)

This is incorrect. By default, GrapheneOS does not even have Google Play Services, it is something you have to install explicitly through the GrapheneOS App Store.

I can even survive the icons.

What is the problem with the icons? Only their own icons are black/white. If you install other apps, they'll just have their standard icons.

if GrapheneOS refuses to support an alternative to Google Play Services, I'm not too happy about it

As I mentioned, you can use it without Play Services, it is not even installed by default. But if I have to choose between sandboxed Play Services or privileged microG which loads Google binary blobs into that privileged process (for SafetyNet), I will pick sandboxed Play any day.

That's besides them doing many other weird things. Like their App Lounge does not install F-Droid apps directly from F-Droid, but through middle-man proxy that they do not want to reveal the owner of (cleanapk.org). That combined with Android's TOFU security model makes it a vector for rolling out backdoored applications or intentionally delaying app security updates.

Either they are incompetent or they are malicious.

If there are real problems with microG then I'm sure the authors would be interested in a better solution too.

/e/OS does not use vanilla microG, but their own fork of it.

[bornfreddy]

Sorry for late reply, just noticed your post.

We are talking about different threat models. I trust Google not to hack my phone, but I don't trust them not to spy on me. So yes, running a Google binary blob in privileged mode occasionally is preferred to running non-privileged Google binary blob all the time (otherwise push notifications do not work on GrapheneOS, IME).

I never used App Lounge but always F-Droid directly, or Aurora Store, so I can't comment on that.

But more importantly, you seem to confuse my rant against GrapheneOS not supporting MicroG as an endorsement of /e/OS. I know they have their set of problems, some of which you outlined. However if my goal is to limit communication of my device with Google as much as possible, then they (/LineageOS) still win. Which is a pity, I like GrapheneOS security focus otherwise, but my primary priority is degoogling my phone as much as possible (and no, it is not possible to do it completely without serious tradeoffs I am not willing to make).