DivestOS' unprivileged microG implementation

Latest release of my DivestOS can now run microG in an unprivileged manner:

  • not a privileged system app and not a regular system app
  • not pre-installed
  • no special permissions
  • no automatically granted permissions
  • feature gated behind a toggle in Settings
  • user must install the apps themself
  • only available to the profile the user installed it to
  • signature spoofing is behind the toggle and bound to the official microG build certificates and gated with version code and target SDK checks and can only spoof the Google signature
  • can’t access location
  • no SafetyNet, will even be blocked in next update: Ability for integrators to disable SafetyNet checks · Issue #1971 · microg/GmsCore · GitHub
  • all abilities default disabled/opt-in, compared to other systems where they are opt-out
  • has warnings on enable and warnings on website
  • I won’t be supporting or recommending it, but it is available to users at their own discretion.

thoughts?

10 Likes

Isn’t It better to just run actual Google Play services as unprivileged like GrapheneOS? MicroG can break at any time If Google decides to do server-side changes, and MicroG was also caught leaking User’s Google account password to logcat: GmsCore leaking Google account password on login · Issue #1567 · microg/GmsCore · GitHub

1 Like

That would be much more work to maintain and initially backport.
This is an extremely simple implementation that is in line with the goals of DivestOS.

numbers wise: Sandboxed Play is in excess of 5,000 lines changed, whereas this is barely 100.

Sandbox Play is far more of a first-class feature in GrapheneOS, whereas unprivileged microG is moreso a bonus feature for DivestOS.

3 Likes

I think allowing a flawed and insecure re-implementation of Google Play services to spoof actual Google Play services should probabaly not be ‘in line with goals of DivestOS’…

There is no need to ship Google’s proprietary code in an Custom OS, in fact MicroG runs proprietary Google binaries (like droidguard, safetynet, snet)

in fact MicroG runs proprietary Google binaries

Please read my post again, such execution will be blocked next update.

There is no need to repeat issues I already document back to me:

If a user trusts microG to achieve what it does then there is no issue with this implementation.
I don’t care if some proprietary garbage app that depends on Play ends up talking to an impersonator (microG) if the user evidently consents to it by explicitly opting-in.

Here is the toggle itself which literally notes this for the time being:

7 Likes

This is very nice. Is Safetynet required for banking apps or do they run as long with microG as they don’t detect root?

@Regime6045

Safetynet required

That is dependent on the specific apps.

I think this is quite neat. It’s makes divestos a good alternative to grapheneOS for other devices and other purposes.

Personally I am happy user of mainly grapheneOS but this surely will make my backup phone more useful.

Congratulations on the achievement

2 Likes

Does this work if you use microg inside work profile?

@anonymous72
Yes, it is per-profile as it is just a normal user app.

1 Like

This is a really cool idea. So one big benefit would be network location services, right?

I use a DOS phone with only GPS, plus a Lineage phone with Google Play Services primarily for driving navigation in situations where I need reliability.

So while this feature is not recommended, are there any downsides compared to Lineage+Google, or would it be an example of harm reduction? DOS is available for my Lineage phone, so perhaps it warrants a switch.

@Hynow

This implementation gives microG no special permission to deal with locations.

And yes, of course I’d recommend DivestOS over LineageOS:

2 Likes

So there is no UnifiedNlp and/or ability to provide location to a maps app like Organic Maps?

@Hynow
Organic Maps and others work just fine via GPS without microG/UnifiedNlp.

Just switched from LineageOS to DivestOS today on my Pixel 2 and am enjoying it so far. Love the projects desire to reduce closed source blobs.

4 Likes
  • every app talking to microG does so using the full proprietary Google Play Services library
  • microG can additionally download and execute proprietary programs from Google for Safetynet support

Please read everything in full before replying, this is adressed in DivestOS.

So it seems there’s three (four) different approaches:

  1. Sandboxed Play Services like in GOS, main advantage being best compatibility, main disadvantage being that you run Google proprietary spyware (even though somewhat mitigated by the sandbox denying lots of info to Google)
  2. Privileged microG with signature spoofing like in CalyxOS, main advantage that it’s open source and you don’t directly have Google apps installed, main disadvantage that Google ironically has more access to your phone info compared to sandboxed Play Services, given the privileged system app status of microG (at least that’s what the GrapheneOS dev says)
  3. Unprivileged microG like in DivestOS, main advantage same as above, main disadvantage that SafetyNet doesn’t work (for banking apps)
  4. Run neither, main advantage that you don’t talk to Google, main disadvantages that your apps needing FCM notifications and integrated maps and Safetynet probably won’t work correctly

In my opinion, DivestOS has the best balance. I wish others like CalyxOS or GrapheneOS would copy this approach.

All Google-Play certified devices, including Google’s own, ship Google Play Services in /system/priv-app, AKA as a privileged system app.

CalyxOS Does the same, but for microG.

SafetyNet would work, if DivestOS wouldn’t disable it.

So how come nobody made a sandboxed microG with Safetynet support? Wouldn’t that be the most privacy and freedom while still allowing notifications and banking apps to work?

I am pretty sure Sandboxed GMS exists because GMS isn’t designed to run as a normal user app

Because you can already run microG in userspace instead of installing it as a privileged system app, I don’t see the need.