Comment by ForHackernews
8 days ago
If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
I agree there's some marginal benefit that sandboxed GApps need to prompt the user for permissions (rather than having privileged system level access) but at the end of the day, Google Maps will get GPS perms and Google will know everywhere your phone goes.
> If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
Sure, but that's the same if you run TikTok with microG (which will relay your data to the Google servers just like the Play Services) or in waydroid on a Mobile Linux. But you can't blame the system for what the apps are allowed to do by the user.
Take your Google Maps example: if the user wants to run Google Maps, obviously they will be sharing data with Google. It's very weird to blame the system for that.
What the sandbox brings is that for users who want to run the Play Services (because they want to run TikTok, knowing that it will share data with some servers, including but not limited to the Google servers through the Play Services), then at least the Play Services are not root on their OS. So then instead of running microG, you can run the Play Services and have the same kind of benefits.
Now if you don't want your apps to contact Google, then by all means, don't install the Play Services! But don't install microG either! And don't install Google Maps!
It's all about trade-offs, it's not an all or nothing situation. Sandboxed Play Services is better than privileged Play Services.
I agree it's about trade-offs. I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
You're of course correct that we can't blame the system for choices made by users, but I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
Regarding location, please see my comment higher in the thread about the location rerouting through GrapheneOS.
Also, it's not a better option to use MicroG. MicroG is in most OSes where it's bundled running priviliged and still connects to Google. Moreover, their reimpementation isn't complete and also not as well odne as Google's.
> encouraging users to install sandboxed GApps
What you link isn't an encouragement at all. It's offered as an option, because there is a demand for it in order to keep compatability with apps high. It's a usability feature (compatability) that's implemented much more securely and privately than on other OSes because it runs in the sandbox. Users are not forced at all to use it nor are they pushed to it.
Not all GrapheneOS project members (devs and moderators) even use Google Play, so how would they be "lulling us into complacency".
> focusing on the security angle only
The app sandbox isn't only a security feature, it's a privacy feature. Access to your data is gated behind permissions due to the sandbox. This is privacy.
> I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
microG still forwards the requests to the Google servers. Not sure what you mean by "tracking APIs"? microG is a reverse-engineered, open source implementation of a subset of Play Services, right? It's not obviously a better option: for instance, some things that are supported in Play Services are not supported in microG, and microG sometimes breaks (because of changes in the API).
> allows you to select alternative Location Providers
GOS does that, too.
> I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps
I don't get that. It does not encourage them to install Play Services, it makes it available. Because for many (most?) users, it is important to have it.
I am not sure what you are trying to say: is your opinion that there is no point in using an alternative OS (like GOS, /e/OS, LineageOS, IodeOS, ...) or are you trying to say that GOS is not the most secure/private alternative OS?
4 replies →
>GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
Sandboxed-Google-Play is not encouraged or promoted. It is suggested if you need apps only accessible via Google Play or needing Google services purely because it provides the maximum compatibility. GrapheneOS have always said that Android's strnegth is a large wealth of open source apps (many of which do not need Google). If more everyday apps (media streaming, taxi, food delivery & rewards, banking, government, social media) did not depend on Google, GrapheneOS would not spend the time, resources and effort that they have on sandboxed-google-play.
Communication between apps using IPC happens on mutual consent and is explicit. You can't just throw data to Play Services and expect it to accept it and process it well, that's not how it works. Communication via IPC is always very intentional and specific, so it will be very structured data for specific purposes, not just a dump of all your data. Firebase Cloud Messaging (FCM) is a push messaging service, it doesn't need to be used to send the actual notification. It's perfectly possible to just use FCM to wake the device and then handle notifications by yourself as app. The way FCM can be used is much different from Apple's system. Apple forces you to use their services for notifications while Google allows you to use FCM just for waking your device. It's also possible for apps to not use FCM at all and to just use WebSockets or UnifiedPush.
If you just grant Google Maps location permission and don't give it to Play Services and keep your sandboxed google play settings to the default, the location requests are rerouted through the GrapheneOS servers. If you want to use network location to get quicker location locks and location indoors, you can also use GrapheneOS network location, so you don't need to use the Google implementation for that.
And, even if you would decide to use Google directly for the location, you can perfectly avoid giving permanent location access. You can hand it over only once or only when the app is in use. So Google doesn't know everywhere your phone goes, at all.