Sandboxed MicroG?
I had heard that one could install MicroG on Graphene OS and it would work. Is that not correct then?
User2288 If they made their own build and included MicroG in its privileged context, sure.
matchboxbananasynergy No I don't mean it in that context. I mean it in the context of intalling MicroG normally like other apps on the normal GOS rom.
I ask because I had told others in a post that they can run MicroG on GrapheneOS and I was also quoting others. If that's incorrect then I need to stand corrected. Do you happen to know how functional MicroG would be installed as a non-privileged app on GOS?
- Edited
vit microG uses Google services and apps depending on Google Play still use the Google Play SDK and Google Play libraries. microG replaces the middleman (Google Play services) between the Google Play libraries and many of the Google services they use. microG downloads and runs Google binaries for certain components. It's not really a reimplementation of Google services.
microG requires privileged functionality for many of the basics. It needs to be able to impersonate another app for certain checks, which is privileged functionality. Those checks are likely to be expanded until the point that it doesn't work at all without that spoofing.
The whole point of the sandboxed Google Play approach is that it runs as regular apps in exactly the same app sandbox used for the apps depending on it where the Google Play SDK and Google Play libraries run. It provides absolutely no special access. This means it provides no additional access or capabilities. 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. Google Play could also simply officially support running as a sandboxed app and we wouldn't need our compatibility layer. Our compatibility layer makes it work as simply a regular app, but they could do that themselves if they wanted to make it work on devices without it integrated.
Sandboxed Google Play compatibility layer does reimplement Google Play functionality itself including the Google Play location API, which is provided via a reimplementation using the OS location API by default. We're entirely capable of reimplementing more of the APIs when it makes sense.
[deleted]
- Edited
There is a MicroG repo available on Aurora Droid. I haven't managed to successfully install microG services core. Not that I need it. I used sandboxed Google for a while now, I got rid of it, since I didn't find it essential for my use case.
- Edited
Divestos is now implementing successfully sandboxed MicroG. This would replace optionally full Google play services in GOS. With full Google play services some apps show ads even when internet permission is denied. That means those apps have somehow access to internet.
Signal for instance shows "you may receive messages" when friends call or message me while I revoked its internet permission. This was made possible by the sandboxed Google play services
NewUser DivestOS still gives it the privileged ability to pretend to be Google Play despite it not implementing the same security checks, which introduces serious security flaws and would not meet the standards for GrapheneOS.
That means those apps have somehow access to internet.
They do not. They can display ads and receive FCM push messages. They could also receive pushes via Unified Push or another implementation. The Network toggle controls both direct access and indirect access via APIs requiring the INTERNET permission. Apps choose the permissions required to use their APIs, and it is not an app communication toggle which would be extremely broken. You seem to wrongly believe this is specific to Google Play and it isn't. You're using multiple apps which include the Google Play code and you aren't avoiding that by using microG. Apps within the same profile are free to communicate with mutual consent including the Google Play code included by those apps.
- Edited
@NewUser You wrongly believe that the FCM toggle in microG controls all forms of access to microG, which it doesn't. You also seem to wrongly believe that apps within the same profile can't communicate in general. You were linked to a post here which explained that microG does not change the fact that each app using Google Play includes the Google Play code and can use it without Google Play installed, including apps communicating. Your issue seems to be that you don't trust the Google Play code, but microG doesn't change this in any way. 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, which it doesn't, just as it doesn't actually violate the INTERNET permission by delivering data to apps such as Ads or even push messages but not allowing them to send data.
- Edited
GrapheneOS I understand that MicroG is less secure than Google play services because of the spoofing signature requirement. But I made a small experience. Google translate is not working offline on Divestos with MicroG( this is a new Google egoistic policy). But it's working in GOS with Google play services with internet permission revoked.
I also noticed that some apps are showing ads in GOS even when internet permission is denied. In Divestos this doesn't happen.
My conclusion was that Google play services gives apps the possibility to use internet even when it's denied. I may be wrong. But I just concluded that Google play services are more invasive than MicroG.
That's why I suggested GOS team members to allow users to choose between MicroG and play services. For people who just needed Google push notifications MicroG is enough.
On GOS, I revoked internet access to Signal. I called my account from another mobile. My Signal app sent me a notification "you may receive messages...". The same thing didn't happen in Divestos.
Also MicroG occupies less storage than the whole play services set.
NewUser That's why I suggested GOS team members to allow users to choose between MicroG and play services.
See https://grapheneos.org/#never-google-services
GrapheneOS will never include either Google Play services or another implementation of Google services like microG.
I understand that MicroG is less secure than Google play services because of the spoofing signature requirement. But I made a small experience.
It's less secure because it doesn't implement the same security checks. Spoofing it being Google Play is only a problem because of that and is bypassing a security check while not preserving the security checks which that check is meant to uphold.
Google translate is not working offline on Divestos with MicroG( this is a new Google egoistic policy). But it's working in GOS with Google play services with internet permission revoked.
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.
I also noticed that some apps are showing ads in GOS even when internet permission is denied. In Divestos this doesn't happen.
It's not implemented. It would be trivial to block with a toggle for sandboxed Google Play but our focus has been app compatibility not providing a bunch of toggles for which features are available.
My conclusion was that Google play services gives apps the possibility to use internet even when it's denied. I may be wrong.
It's completely wrong.
But I just concluded that Google play services are more invasive than MicroG.
They're regular sandboxed apps on GrapheneOS. Any regular sandboxed apps within the same profile can communicate with mutual consent. Sandboxed Google Play has no special privileges on GrapheneOS, unlike microG even on DivestOS where it has the special privileged to pretend to be Google Play.
That's why I suggested GOS team members to allow users to choose between MicroG and play services. For people who just needed Google push notifications MicroG is enough.
It's less secure and even that tiny part of the functionality doesn't work reliability.
We already made a proper reimplementation of the Google Play location API, unlike microG, and we're completely capable of doing the same thing with other portions of it or including having functionality which works without installed. That's not going to involve using an insecure project with an untrustworthy development team.
On GOS, I revoked internet access to Signal. I called my account from another mobile. My Signal app sent me a notification "you may receive messages...". The same thing didn't happen in Divestos.
You're wrong, that works fine with microG too. 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. That breaks the app and it won't get calls or push notifications anymore, unlike using it in a profile without Google Play.
Also MicroG occupies less storage than the whole play services set.
That's a given when it implements a tiny portion of the functionality (including missing security checks) and app compatibility.
I understand the concerns regarding security, signature spoofing and compatibility. Would you ever consider an opt-in toggle to allow signature spoofing for MicroG (and only MicroG), similar to how DivestOS is doing it?
For example in my case, I'm only interested in FCM push notifications and nothing else from Google Play Services. With MicroG it's clearly documented what it does and what is out of scope for the project, while Google Play Services are more of a black box and probably makes way more network connections than just to FCM. For me, I'd rather have the signature spoofing and other potential security downsides of MicroG, but the potential privacy benefits and peace of mind that the only connections allowed to Google are for push notifications and nothing else.
Of course, if this was somehow possible with Google Play (through some kind of firewall?) that would be a great solution too. Like if you had a more elaborate network permissions for Google Play: "Internet: yes/no/FCM only".
- Edited
Elk9877 I agree a lot with that approach.
I think the answers given where really useful too. Which part does those security checks, do the apps implementing the Libaries do them?
Because if its only the Google servers that wouldnt matter when using other servers instead. That is the thing of microG, replacing Google services with others like Mapbox, UnifiedNLP and Unifiedpush (afaik).
I also find it a bit counterintuitive to include those redirection functionalities like to the OS location into the whole google play bundle. Imagine the replacement services would all be done, you would still need to install those huge apps just to use for example rerouted location calls?
Elk9877 You have misconceptions about Google Play and Google services. The apps using Google Play are using the proprietary Google Play libraries. These libraries can and do connect to Google services with Google Play installed. Google Play is not required to use Google services. Not having Google Play doesn't get rid of all the connections to Google. microG makes far more connections to Google than only for FCM.
- Edited
@GrapheneOS (closed thread)
We have to make our own proper implementation of alternate location services for the OS. Those existing ones don't follow the security model and have other major issues.
There is no reason for a network location service to be tied to Play compatibility. AOSP has support for network location services.
This sounds like quite some work but is exactly what I imagine to be the best model.
microG downloading proprietary components that have more access than sandboxed Play, is very bad and understandable to be not wanted.
Not sure if I fully understood the reasoning behind the "secured connections", as I would assume TLS is fine?
But yeah, I saw that rerouting fine location requests to the OS was already a thing. I saw it as part of the sandboxed play compat layer, but I assume it is also there if you dont install it.
The fact that MLS is proprietary is shocking tbh. You can contribute to them and to OpenCellID using an app called "TowerCollector".
Now I wonder, what alternative network location data could be used as Network location provider?