Sincere question: what is the point of using this OS for privacy and then using Google services? The intro runs though how it’s very easy to do this. Maybe I’m missing something.

▲

cool_cherry 3 days ago | parent | next [-]

It's actually really great!

Google Play Services is a dependency for some apps, and GrapheneOS allows for people to take steps to protect their privacy while still being able to use those apps.

First, with GrapheneOS google play services run in a sandbox like any other app. (play services have more privileged access in vanilla android)

It also works well with a multi-user setup. The default account in Android is the "owner account" and in GrapheneOS (and AOSP) you can use the owner account to create multiple distinct user accounts on the device. Then, you can only install google play services in one user account. Google play services won't start if you're not logged into that user account.

Google play services won't have visibility into your other user accounts and what you're doing there. And even in your account with play services installed, there's a bit more privacy because of the sandboxing (although I believe google play will know all of the apps installed in that user account)

There's a full explanation here: https://grapheneos.org/usage#sandboxed-google-play

Edit: I am a web security researcher and longtime user of GrapheneOS and have always been impressed by the features, frequent security updates, and focus on usability, security, and privacy. They've upstreamed numerous security improvements to Android and other open source projects (so if you're running Android, they've probably made your phone more secure!).

https://grapheneos.org/faq#upstream

I encourage folks to join me in making a regular small donation to the project if you have some cash to spare. They're doing good work.

https://grapheneos.org/donate

▲

andrepd 2 days ago | parent [-]

Why is this in any way superior to microg, apart from compatibility? Microg simply spoofs/shims the API while not actually contacting Google servers at all.

	▲	neobrain 2 days ago \| parent \| next [-]
		> Microg simply spoofs/shims the API while not actually contacting Google servers at all. It's not quite that simple; it still contacts Google servers as soon as you enable push notifications, for example, which then won't run in a sandbox. Never enabling any such services is possible, but you have to be somewhat careful about what you're doing.
	▲	strcat a day ago \| parent \| prev [-]
		microG still uses Google services for accounts, push messaging and many other features. microG itself has functionality requiring downloading and running Google executables as part of itself. It doesn't change the fact that apps depending on Google Play are using Google Play libraries often making connections on their own without Play services. GrapheneOS sandboxed Google Play compatibility layer provides far broader app compatibility while giving strictly less access to Google Play code. Sandboxed Google Play runs as a set of regular apps with no special access or privileges. It's the same app sandbox the apps using it run in with the Google Play SDK and libraries built into them. GrapheneOS improves the app sandbox and permission model substantially, which applies to sandboxed Google Play in the same way. GrapheneOS implements functionality such as location services via the OS and reroutes apps using Google Play APIs to the OS APIs. We have our own network location and geocoding implementations in the OS. We're building our own fully local text-to-speech and speech-to-text services right now.

▲

palata 2 days ago | parent | prev | next [-]

Just the fact that you have more control over the permissions you give to apps makes it worth it for me.

* If an app wants to access your contacts, you can choose which contacts, and you can choose to feed them a "fake" list (which is an empty list). Same for storage.

* You can choose not to give network access to an app, and the system will tell the app that there is no signal all the time.

The other very nice feature is that the Google Play Services and Play Store aren't running as system apps (i.e. they don't have root access): they just run like any other app. So you can choose not to share your contact list with them, for instance.

▲

ysnp 3 days ago | parent | prev | next [-]

GrapheneOS primarily exists to give you tools to exert more control over what apps have access to and to better protect your data. What you do with those tools is entirely your own concern. Where those apps come from is not GrapheneOS's concern.

I don't think most people use Google services out of choice anyway, but more because sometimes that's the only way to get functionality you may need.

▲

arminiusreturns 3 days ago | parent | prev | next [-]

Security, including privacy, is about layers of hardening. In this case, minimization of leakage and other privacy concerns for some can still be worth the tradeoffs. For example, some apps literally refuse to work on a completely de-googled phone. (I ran one for many years with no google services). Also, the general control the user gets offers a lot more ability to harden than most android. I bricked my phone and am currently borrowing one and using stock android and there are things like facebook that are literally uninstallable... At least on lineage/graphene the user can actually control the system.

▲

unethical_ban 2 days ago | parent | prev | next [-]

I have done less isolation with GrapheneOS than others. I have one profile and that profile has Google Play Services because I have friends on several chat apps, and Signal is the only one that reliably notified me when I got a new message.

Google apps are still in a sandbox.

Location services and other features can be provided by non-Google services.

I know the OS itself isn't siphoning data; With my Oneplus 12 I had to check both Google and Oneplus configs to make sure I wasn't leaking anything.

I can disable network access for apps.

I can limit app access to Contacts and files with "scopes". For example, I have Whatsapp for only a few known people. Whatsapp demands access to your contacts. I can set up a scope called "Whatsapp Users", add only my friends to it, and then give Whatsapp Contact access to that scope.

▲

krior 3 days ago | parent | prev [-]

Afaik, Google services are run in a sandbox on Graphene OS.

▲

tietjens 3 days ago | parent [-]

Hm ok but location data etc still goes to them? What about the device fingerprint?

I’m just wondering what the selling point for using Graphene with Google is. Very Graphene curious.

▲

strcat 2 days ago | parent | next [-]

> but location data etc still goes to them

No, they can be installed as regular sandboxed apps and you don't need to grant them any of the standard permissions such as Location. They have the same app sandbox and permission model as other apps including all of the GrapheneOS improvements. For example, if you want to use a Google Play feature requiring Contacts access, you can use Contact Scopes instead. However, barely any Google Play functionality needs more than the added Network permission.

Location services work perfectly fine without Google Play installed. For apps depending on Google Play and using the Google Play location API, GrapheneOS redirects the requests to the OS by default. If you want network-based location for location detection without satellite reception, you can enable the network-based location service built into GrapheneOS. The only reason to give the Location permission to Google Play would be if you want to use a feature they provide depending on it such as location sharing.

▲

thothless 3 days ago | parent | prev [-]

as a new graphene adopter, still figuring stuff out myself, but it's been surprisingly easy and satisfying to do a hard cut-over to graphene.

cool_cherry explained exactly how I've been using it, with my main 'owner' account not having play services installed at all, only instead installed on another user, which only takes a few seconds to switch to.

you can easily install owner apps onto other user profiles. or grant/forbid the other user profiles to install apps themselves.

users are not tied to google accounts, only your google play installations.

I was able to install google play apps on 'owner' user and then uninstalled google play services and play store. if they don't require play services to function, they work fine, otherwise they just might not function or may function/look surprisingly differently when they don't have their network connections.

location, network, other permission have defaults and can set them on per-app basis like on normal android.

a unique device MAC address is generated for each wifi connection.

	▲	strcat 2 days ago \| parent [-]
		It's worth noting they're still regular sandboxed apps regardless of whether you use dedicated profiles for this. The main reason to use a separate profile for this is for fine-grained control over which apps can/will use Google Play. Apps in the same profile can see it's there and choose to use it. For example, Signal will use Google Play services for push notifications via Firebase Cloud Messaging (FCM) when it's in the same profile. If it's not there, Signal uses their own inefficient WebSocket-based push which uses significantly more power due to lack of optimization. Molly is a fork of Signal with support for UnifiedPush as an efficient alternative to FCM. Many apps from the Play Store don't use Play services, while many others be used with or without Play services where they may have extra functionality or different behavior when Play services is available. Others have a hard dependency on it. There are many other ways to apps to get apps than the Play Store. For getting apps from the Play Store, there's both the sandboxed Play Store and Aurora Store as options. Play Store requires an account for installing/updating apps but it can be a throwaway one like the ones Aurora Store uses by default. Note Aurora Store does not currently check the store's signature metadata to secure the initial install better than HTTPS alone.