alt Hacker NewsThanks, but there's no way anybody here hasn't already heard all of that. GrapheneOS' statements are inevitably reposted to every thread and subthread that touches on the topic.
Yes, I knew it's in a sandbox at the time of writing my comment above; no, that doesn't make it a privacy paradise compared to microG.
The sandbox still needs internet access for a lot of GMS' functions and lots of apps send information into it. For example, Signal will actively reach out for notification bundling, so Google gets to know who runs Signal, what IP address they're on, with who else they share that address as they go to school and work, build a social graph... So while the sandbox is definitely very useful and I'm glad it exists as open source software that other Android distributions can be inspired by, it doesn't definitively solve fundamental problems with running unwanted software on your device
Do you know what privileged context means? As in, what access this grants concretely? I tried to look it up once, ended up in Android source code trees, and left more confused than I went in. It looked like it gets no extra file access at all, which is strange right? What does privileged mean if not that? I tried su'ing to the user ID of GMS and this confirmed that the GMS user can't access other apps' data folders. So I'm no longer sure what to even make of this wording. Is it maybe about syscall hardening that isn't applied to privileged apps or so, so like exploit protection rather than normal permissions? The benefit of that would be protecting from exploits that Google could send. Do we think they'd legit do that, short of receiving an NSL that compels them?
Rather than running the unwanted proprietary (but necessary) software wholesale and attempt to sandbox it, I'd much rather substitute as much as possible with open code (where we know what it does) and have a much smaller set of proprietary components that need to be kept around in a sandbox and active only when necessary. For example, microG will replace Gmaps with Mapbox, reducing how much data is sent out about you to Google (they don't get to see which city you are probably in while using the map in Too Good To Go, for example).
It seems fairly obvious to me that less data sharing plus less proprietary code (that needs to be sandboxed) is better than letting Google go wild and installing their apps as-is with self-updating functionality (in said sandbox). What threat would sandboxed microG pose that sandboxed GMS doesn't? Is there any logic to GrapheneOS not wanting to build upon microG to get the remaining proprietary parts properly sandboxed, rather than starting over from scratch?
Replies
For context, GMSCompat is Google Mobile Services Compatibility. GrapheneOS installed the google play store and services as normal apps, and worked backwards to make it behave. There is no google specific sandbox, rather it uses the standard android user app sandbox. This means google is bound by the same rules, as special casing anything creates more maintenance burden and attack surface. GMSCompat is fully open source.
> "Thanks, but there's no way..."
Its reposted because the information is accurate, and misinformation regarding it is very prevalent.
> "Yes, I knew it's in a sandbox..."
Relative to MicroG, sandboxed google play is much more private, secure, and usable. I would not describe it as a privacy paradise, but MicroG does not improve upon this, and instead makes these aspects worse.
> "The sandbox still needs internet access..."
Most google libraries operate independently of google services and do not depend on them to function. FCM is an exception due to how push notifications are optimized (by using one app for the connection). MicroG does not avoid this.
> "For example, Signal will actively reach..."
You do not need to provide an identity to google. This can also be avoided with a VPN, and is not specific to google. There is the concern of metadata but Signal sends empty notifications without any identifying info. They are only used to wake the app up to fetch its own notifications.
> "So while the sandbox is definitely very useful..."
It confines google services to the same rules and restrictions as all other apps. MicroG does not. MicroG also does not avoid running unwanted software, referring to the google libraries in apps and the google code MicroG downloads.
> "Do you know what privileged context means..."
MicroG violates the security model by necessitating signature spoofing, which puts it in a position to receive data it was not intended to receive, there is also attack surface exposed by having access forbidden by the app sandbox. Sandboxed google play is bound by the same app sandbox as all other apps, and would not be any more or less capable of exploiting the device than any other app. The idea that google would try to exploit the device is nonsensical though. But granting both google and a 3rd party privileged access is still unacceptable.
> "Rather than running the unwanted proprietary (but necessary) software..."
Google play services runs in the android user app sandbox. It is not an "attempt", it is successful at doing this. MicroG being open source does not matter in regards to privacy or security. It did not change how MicroG has leaked location to apps without location permissions, it does not change how it downloads and runs google code both privileged and outside of its own APK, and it does not change how other apps are running google libraries anyway. Note that the proprietary code it downloads is not confined to the app sandbox.
> "For example, microG will replace Gmaps..."
Im unsure if you are referring to the app Google Maps, or google maps integration. GrapheneOS reroutes googlefusedlocation requests to the OS, rather than google services. You can use an app other than google maps, and apps with google map integration can simply send your location to google directly, independent of google services or MicroG.
> "It seems fairly obvious to me that less data sharing..."
Googles access to data is not limited by using MicroG, relative to sandboxed google play. And the size of proprietary code is irrelevant, that code can be anything. It can be malicious with 2 lines, or benign with 2 million. Access is what is vital, not size. Google is not permitted to "run wild", and is granted no additional access compared to any other app. Im unsure what you mean by self updating functionality, but for apps from the playstore, nearly all of them are signed with a key that google holds, and MicroG can do nothing about this. GrapheneOSs App Store is responsible for updating google play and google services, it cannot update itself.
> "What threat would sandboxed microG pose that sandboxed GMS doesn't?..."
Using MicroG necessitates GrapheneOS violate the android security model, trust a 3rd party unnecessarily, cripple 99% perfect compatibility, use code that is not near as battletested as play services, run google code as privileged, and run a software that has had serious privacy violations in the past. Not only is the base insufficient, but any finished product based on it still would not compare to GMSCompat. The logic is that GrapheneOS wants the best compatibility, the least changes to the android app sandbox, 0 privileged google components, no violations to the android security model, and no need to maintain a reimplementation when google services and store are already maintained by a huge organization.
note where I wrote:
> su'ing to the user ID of [another app]
Look, I have root, so you can hack me! And my bootloader is wide open, too! In your words:
> > Root access and an unlocked bootloader are insecure, even for low threat models. These devices are vulnerable and should not be used for any sensitive data.
I'm serious that anyone should feel free to prove the point by sending me a responsible disclosure notice about having found a way in, but the threat clearly isn't serious enough for that to actually be concretely possible. Which is not to say that it's never relevant, but "such a device shouldn't be used" is not valid as a blanket statement