If I’m not using any Google apps, how is micro g a security risk?

Any app can choose to embed the play services for displaying ads or sending data. And those are not just passive libraries, they are actively sending tons of stuff to Google. As they are not isolated as user apps you always have to assume the worst, that they send all your stuff to google.

This is the best answer

The Google Play libraries could do everything that it can do without it. In many cases, Google’s libraries including the Google Ads SDK do work without Google Play. There is no inherent need for Google Play to use Google services. You can see for yourself that Google Maps works fine without it, although it depends on it for some functionality even though that could also work without it. Everything that sandboxed Google Play can do could simply be done by the Google libraries without it though.

Apps within the same profile are free to communicate with mutual consent including the Google Play code included by those apps.

Each app you’re using which depends on it includes the Google Play code with their access, and that includes the Google Play code in each of these apps being able to communicate between them if it decided to do that.

microG provides much less functionality and therefore much less app compatibility than sandboxed Google Play in general. Unfortunately, some of the missing functionality are missing security checks.

Also, Signal is a perfect example where the app works fine without Google Play including with push but will not work correctly in a setup you proposed in the other thread of using it with FCM disabled.

(Signal sees the faked google play services and automatically uses them for push messages. Its own websocket request thing is only used with a warning, if they are not found)

I am relieved, because I was at first questioning what I told you.

• MicroG presents itself as a fully FOSS app, and many parts are
• it still downloads Google binaries for certain things
• apps still use Google libraries embedded in them
• microG is highly unstable because it fakes to be Play services and if the usage is high enough, Google will increase checks that will make require it to fake values all the time.

So it is insecure because it allows Google binaries to run without a container.

UnifiedNLP, Mapbox tiles, UnifiedPush, are all great. But if apps implement Google libraries, only official play services will work reliably. Its responsibility you know, it could break and then the project gets flooded with bug reports and gets a bad reputation.

only present if you explicitly give permission

Those have to be internal permissions as microG has to be installed into the system partition and thus doesnt need any permissions.

It is a long time ago that I used microG though.

I just don’t see the point of worrying about problems that haven’t occurred yet

Proactive security. I wouldnt want to be in a situation where I cannot use my phone anymore suddenly, until the OS has patched a vulnerability that would probably not exist if their entire implementation was different (as a sandboxed app).

The problem is that microG needs to fake values etc. For some reason that means it cannot be a user app, which makes it fundamentally incompatible with the more secure GrapheneOS approach poorly.

I would like to use those service too, GrapheneOS allows redirecting location queries to the OS at least, so the app thinks it gets that fancy Google location data (fine location, NLP) but it actually just gets the A-GPS (rough location).

you’re concerns and mine are not the same.

Probably but that transparency point was interesting.

Can you show me the updates that are delayed for months by fairphone?

They have to have release notes for their updates. No motivation to dig them up tbh.

They are an OEM, this is relevant because GrapheneOS “just” takes the complete AOSP updates for the exact phones they produce directly from Google (which is a huge help, they have all the patches, Kernel, vendor code etc. for exactly those phones) and feed it into their build system.

That will all be automatic. So they add the apps and stuff and build the packages, and ship them.

Fairphone needs to patch their own (?) Kernel, as their phones are somewhat unique. No idea how to do that, but they will have a mix of components and the kernel has to work on those. This is a bit more work but doesnt explain months of delay.

Also OEMs get early access exactly for that reason, so that they can patch their custom kernels and code, because Android phones are SOCs, every Android is different.

There are steps towards mainline kernel support, which means that the phones can run on regular Linux with less trouble. This improves the patching and modification process, ensures longer updates, … and of course also saves money. Google is doing things in that direction.

Also idk if Murena gets early access from Fairphone, because Fairphone is using a Google certified OS and Murena doesnt. So this may be a problem.