You can read some of the discussion here: https://discuss.grapheneos.org/d/4290-sandboxed-microg/11
I really don't understand why people keep asking for Micro G in GOS, what does it provide that the current sandboxed implementation doesn't?
You can read some of the discussion here: https://discuss.grapheneos.org/d/4290-sandboxed-microg/11
I really don't understand why people keep asking for Micro G in GOS, what does it provide that the current sandboxed implementation doesn't?
missing-root MicroG is a FOSS reimplementation of what Apps think Playservices do
The trouble with this neat statement is that the reality is more complex.
Its explained in this discussion
Croak3114 You can read some of the discussion here: https://discuss.grapheneos.org/d/4290-sandboxed-microg/11
microG downloads proprietary Google libraries and then uses them.
Also apps that communicate with Google Play or microG contain proprietary Google libraries that handle that communication. Those libraries are also set up to communicate directly from the app with Googles servers, they dont need to pass that communication to the Play apps or microG.
For example you can see here details of how firebase libraries work on devices with or without Play Services
https://firebase.google.com/docs/android/android-play-services
When compared to sandboxed Play it becomes questionable what functional security or privacy guarantees can be gained by microG being FOSS.
There are security benefits from using sandboxed Play compared to microG. There is also much better app compatibility.
Its highly unlikely GrapheneOS will ever have support for microG. Its already a lot of work maintaining sandboxed Play. Trying to also implement support for microG in a way that met GrapheneOS security standards and then to maintain that compatibility up to these standards going forward would be a load more work for questionable benefits. There is much more important work that the GrapheneOS team wants to focus upon.
Viewpoint0232 That's what DivestOS did.
Please correct me if I'm wrong, I'm not an expert.
bookreader If microG and the apps you use with it use propietary services/libraries then somethings are still secret in your setup and i don't see how you can guarantee your personal information is not stolen by them, its unclear to me this actually accomplished something.
I read the linked answer from the GrapheneOS account.
The fact that it runs Google binaries makes it intransparent (about that fact) and worse than sandboxed Play.
If DivestOS runs it sandboxed and only allows to spoof Evil Corps Signature, and the downloaded blobs are also always the latest, I see no problem with it.
The main benefits are the alternative backends supported by microG. There are no standalone solutions anymore.
I think it would be awesome to have google-less unifiedPush and UnifiedNLP for apps that actively support it. No spoofing, no play services. Apps requesting the rough (GPS) location will invoke sandboxed UnifiedNLP, that feeds the location to the OS which then redirects it to apps, thinking its the GPS location.
Same for UnifiedPush which is only supported by FOSS apps anyways.
I know this is a lot of work. I already donated a lot :D please do the same.
Having these as standalone solutions, not being integrated in the play stuff that I dont use on my main profile, would be brilliant.
A thought: network location is critical infrastructure. If GPS sattelites where just bombed, what then? Use Google or Apple? The situation is like that currently.
missing-root I think it would be awesome to have google-less unifiedPush and UnifiedNLP for apps that actively support it.
Would that even be possible to replace FCM with UnifiedPush? Don't the apps that rely on FCM basically "hardcode" the connection to Google on the server side?
Viewpoint0232 yes and they also may be able to use all the GPlay stuff without any services installed.
Which is a concept I dont get, why does Android need a system app if the apps could do all that themselves?
Now after looking at their code, its all FOSS? So this is a transparent FOSS project replacing the Play services for various things, either by connecting to Google or by using different services like UnifiedPush, UnifiedNLP or MapBox tile server alltogether.
It's an open source project which sits between closed source libraries used by apps and closed source services. It downloads and runs some closed source components too. The Google Play code is still there in the apps using it. The whole point of sandboxed Google Play is that it can't do more than the Google Play code that's running in the apps, avoiding giving it any more access or data. Their libraries in the apps can already do everything sandboxed Google Play can do if they choose to. Nothing stops them doing FCM in the same way as sandboxed Google Play within each app. They do make their Ads and Analytics libraries work when Google Play isn't present. It's a misconception that Google Play or an alternative to it is needed to use Google services.
It fakes values and signatures to connect to Google
You're misunderstanding this. It spoofs signatures to bypass the security model for Play services. It doesn't implement the same security checks so this is a privacy and security issue. It doesn't properly secure the connections to Google in the way that Play services itself does, among other issues.
Also relying on it may be highly unstable. But if it is a trusted FOSS project, how would it be different running microG unsandboxed, from running the complete, proprietary and bloated Playservices as a user app, and only channeling the wanted calls (?), as how I understand it?
Either way, you're using the official Google Play code inside the apps using it. microG does not avoid using the Google Play code.
Several of the developers working on it have repeatedly covered up and downplayed vulnerabilities. They continue doing so. Being open source doesn't make something trustworthy or safe.
missing-root GrapheneOS already has our own alternate implementation of the Google Play location service that's used by default. It reroutes the apps to using the OS location service and emulates the presence of a network location service when it's not available. Network location services belong in the OS and not as part of something tied to Google Play compatibility. AOSP has standard support for network-based location services, it just doesn't come with one.
It allows to use Mozilla Location Provider
This is a proprietary service which requires sending your location data to it in real time, just like Google's service. They don't publish the data to run it yourself or to run it locally without a server. It also has very poor data since the FirefoxOS project died and they stopped focusing on it. It doesn't really provide the same thing as the Apple and Google services.
So it makes apps work without needing Google, which is awesome. The question is its security and clarifications.
No, it doesn't. The apps using it are still using the Google Play libraries and Google services. It doesn't avoid that most of the services are Google services.
@Viewpoint0232 @bookreader No, that's completely inaccurate. The apps are still using the proprietary Google Play libraries and it still uses many of the services. The whole point of sandboxed Google Play is reusing the same app sandbox for the rest of the code beyond the libraries built into the apps.
missing-root Sandboxed Google Play can't do anything more than a regular app. You seem to be missing the whole point of it, which is that it does not add any extra capabilities to what the Google Play code running as part of apps can fundamentally already do without it. Sandboxed Google Play simply works around the fact that they don't make substantially larger libraries with all the functionality available as fallback code within them. They do this for the Ads, Analytics and many other libraries but not all of them.
Viewpoint0232 You can't coerce apps into using a different push service.
If DivestOS runs it sandboxed and only allows to spoof Evil Corps Signature, and the downloaded blobs are also always the latest, I see no problem with it.
It doesn't properly secure the connections to the services or the local API access control model. That is the main security issue with microG whether it's an unprivileged app or not.
The main benefits are the alternative backends supported by microG. There are no standalone solutions anymore.
GrapheneOS already reroutes the Google Play location API to the OS by default and that will provide support for using any of the functionality we provide in the OS in the future. There's no need for other location providers to be tied to Google Play compatibility.
I think it would be awesome to have google-less unifiedPush and UnifiedNLP for apps that actively support it. No spoofing, no play services. Apps requesting the rough (GPS) location will invoke sandboxed UnifiedNLP, that feeds the location to the OS which then redirects it to apps, thinking its the GPS location.
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. We don't have a use for it. There's no need for it to be tied to Google Play compatibility and it's simply not relevant. There's already support for rerouting location requests to the OS location services including network location. Rerouting is already the default and the only reason to disable it is if you want to use the Play services network location service.
Having these as standalone solutions, not being integrated in the play stuff that I dont use on my main profile, would be brilliant.
There is no reason for a network location service to be tied to Play compatibility. AOSP has support for network location services.
Please use the existing active thread instead: